Articles In Category
HTML5 Audio and Video Guide
Theming A Web Page With Crystal Black:
A CSS Design for Web Inspector
For awhile, I've wanted to theme Safari's Web Inspector—the incredibly useful built-in website viewer/debugger/designer assistant—with the Crystal Black look and feel, but it wasn't immediately obvious how to do this. I assumed that the tool was just a part of Safari, and therefore built with classes and widgets from the Cocoa AppKit (which is the framework all Cocoa apps are built with). However, when I began to inspect the Inspector, I discovered that everything contained within its borders was simply web content: HTML, CSS, JavaScript, and images.
In other words, the Web Inspector tool is nothing but an intricate, sophisticated, and extremely well designed web page!
Having built a Crystal Black CSS file for web pages in general, and with my past expertise in CSS, I attacked this challenge with relish! It reminded me of the time I realized that Dashboard widgets are, at their core, nothing but little web pages (as are simply apps for the iPhone). In tackling this one, the main question was, How should the various elements look? And the hardest part was inspecting the various parts in of the Inspector in great detail to determine which CSS rules governed their default appearance and behavior.
As I discovered, the WebKit has a a sub-framework called "WebCore," which in turn has a folder of resources specifically for the Web Inspector. In the Inspector folder, among other things, is a suite of CSS files that handle different aspects of the Inspector's design and behavior. Of these, the primary one I needed to tweak was called simply "inspector.css."
Scripty2: In Beta, A Rewrite of Scriptaculous
WebKit Introduces Styleable Scrollbars
Compass: A New Concept for Managing CSS Styles
Classy: Unbelievably Cool Web Page Analysis
InfoWorld Article Dispels Many Enterprise Mac Myths
WebKit/Safari Keep Blazing the Trail to CSS 3.0
Looking back,
This is an update to the article I wrote last summer, when Safari 3.0 was first released. In the 9 months since then, a lot has happened, and I wanted to try to keep this info up to date. Opera, iCab, Konqueror, and Firefox have all made progress in adopting CSS 3.0 specifications, the next generation of the W3C's Cascading Style Sheets standard.
However, the WebKit team continues to lead the pack, as they have since I first contemplated this article over a year ago. In the last 6 months, that team has not only adopted more of the CSS 3.0 specs ahead of the others, but they have proposed several exciting new specs of their own, which the W3C is taking up as draft recommendations.
In addition to updating the state of CSS 3.0 in WebKit/Safari, I've also added some new demos for the Backgrounds section.
Here are the CSS 3.0 features I wrote about in July 2007:
- Box-shadow: Yes! Add drop shadows through CSS!
- Multi-column layout: Can we really do this now? With HTML?
- Resize: Give JavaScript hacks a rest and let users relax when typing input on web pages.
- Rounded corners: Any can be made round.
- Colors with transparency: There goes another ugly hack from way back!
- Background image controls: Remember how great it was when you could add images as well as colors to an element's background CSS style? Well, it's about to get a whole lot better!
And since then, WebKit and Safari 3.1 have adopted the following new ones:
- Adopted last October, WebKit introduced its first take at CSS Transforms, which it has submitted to the W3C for consideration. With CSS Transforms,
<DIV>s can be scaled, rotated, skewed and translated... all without using JavaScript! - Announced at the same time is the equally exciting implementation of CSS Animations. At the moment, the only type of animation that's documented and demonstrated on the WebKit blog is based on CSS Transitions, which let you define how an object or attribute changes over time from one state to another.
- Also in October, WebKit added the CSS Web Fonts feature, which lets designers beam fonts to users through CSS and HTML, approximating the capabilities of PDF in a much lighter-weight form.
- Then, after a lull, things started to heat up again last month, when Apple released Safari 3.1. Safari 3.1 incorporated all of the CSS 3.0 features WebKit had pioneered earlier, plus it added a bunch of things the WebKit team hadn't blogged about. Chief among these was support for CSS Attribute Selectors. This is something of a holy grail to advanced web developers, since it opens up a whole world of possibilities for using the Document Object Model (DOM) to build better web interfaces. When released, WebKit was the first and only browser to support this geeky, but highly practical feature.
- And then, just today, WebKit added support for CSS Gradients to its portfolio. Gradients are not yet a CSS 3.0 specification, but they are part of the HTML 5.0 spec. No doubt Apple's implementation will be referred to the W3C for consideration.
Apple Posts Major Update to Safari
Control.Modal: A Gallery of Lightbox and Modal-Window Effects Using CSS and Prototype
Far Out Menu Highlighter with JavaScript and CSS
Parallax Web Page Background Using Javascript and CSS
DED|Chain JavaScript Library Combines Yahoo! UI and jQuery
SEEdit: A Pro’s XHTML Editor
WebKit Browser Adds Support for CSS3 Multi-Column Text Layouts
WebKit Adds Support for CSS Box Shadows
GoodPage: A New WYSIWYG HTML/CSS Editor Debuts
WebKit Team Adds New CSS Methods for Text-Stroke
Background Gradiants with CSS
Run: Yet Another Prototype-Based Animation Framework Enters the Race
CSS3 Previews: Glimpses of Exciting Web Design Options To Come
Style Master: Pro Power Over Your CSS Code
Rendertests: Lots of useful browser testing here
Unobtrusive AJAX Star Rating Bar
Image Caption Makes Captioning Web Graphics Easy
CSS Tweak: Optimize Your CSS Online or With Dashboard Widget!
curvyCorners - Another Cool Script for Making Corners Round
Better Approach for Browser-Specific CSS?
WebKit Implements CSS3 Resize Property
Hack To Speed up Prototype’s Selectors
How’re We Doing Now? An Update on DHTML/Ajax Browser Compatibility
Since my original report on the browser and platform compatibility of some 50 Ajax JavaScript libraries in March, the market has continued to produce new toolkits at a rapid pace. I recently finished grading all (but one) of the 8 libraries added since March, and I’ve revisited the scores of another 8. With that, the time seemed right for a report on how Ajax library developers are doing at achieving cross-browser, cross-platform compatibility in the tools they’re giving us–tools which programmers around the world are using to hammer out their unique vision of Web 2.0.
I’m very pleased to report that the trend is moving strongly toward full compatibility. Of the eight new libraries, a full five of them achieve top grades of “A”. That’s a much higher percentage of the total than in March, and of the three non-A libraries, only one was a D (D+ actually). One was graded C+ and the other B. Of the revisited libraries, I was able to raise grades for three–Backbase, ICEfaces, and MochiKit. Only one library had a lower grade (Rico, down from A- to B), and the rest were unchanged.
Only two of the 8 new libraries have commercial licenses you’d have to pay for, and in one case you are really only paying for the IDE. Three of the new libraries require a java server architecture in order to be happy, one would prefer Cold Fusion, and the others are pure client libraries that are agnostic with respect to the application server. One library was added just a couple of days ago (Jitsu), and I haven’t had time to review it yet–but you’ll find it summarized here with the rest. Only one of these 16 libraries is DHTML with no Ajax controls–Uize. Even without Ajax, however, I think you’ll find Uize to be one of the most interesting here–especially in terms of visual richness.
Beautiful CSS Experiment in Equal Text Columns
CSS Drive: CSS galleries, examples, references, and tools
Cross-Browser Ajax: It Don’t Come Easy
In a case demonstrating that you can’t be sure your Ajax/DHTML website will truly be cross-browser just by including one of the toolkits that are known themselves to be fully so. From my own experience, even if you use Prototype, you’re likely to pick up a few odd JavaScripts along the way to include in your site. Or, you might take a stab at writing a function out of the blue. Either of the latter two steps can get you in trouble if you’re not careful.
Today’s case is an Ajax/DHTML “tutorial” which has been advertised on a couple of websites that a lot of folks in the Ajax community rely on for good tips and pointers. Unfortunately, the only thing the script is a good example of is cross-browser carelessness, or perhaps simply cross-browser “couldn’t care less”-ness on the part of the developer.
Complete, Compact CSS 2.1 Reference
xCuts Dashboard Widget: Tripping the Light Script.aculo.us
I’ve been writing for some time now about the kinship between Apple’s Dashboard Widgets and web pages. I’ve recently written a time or two about Ajax and the various wonderful dynamic HTML (DHTML) JavaScript libraries that are now available to web developers. And when I first starting compiling the lists of available Ajax/DHTML JavaScript libraries, I was planning to grade Apple’s Widgets library along with all the rest. In explaining why I didn’t, here’s what I wrote last month about Widgets and DHTML pages:
It’s interesting that 2 months after an Adaptive Path essay coined the term “Ajax,” Apple released Mac OS X 10.4 “Tiger”, with its amazing and powerful dashboard widgets system. Within a couple of months, there were over 1,000 widgets available on the web, and these little babies were capable of completely replacing (almost all for free!) a number of system utilities, menubar items, and whole applications on the Mac. I’m tempted to think that awareness of Apple’s widgets helped promote awareness of, and interest in, what could be accomplished with rich Ajax/DHTML toolkits. After all, widgets are simply little Ajax/DHTML programs running in a special layer of Mac OS X called the Dashboard… They use exactly the same technologies as all of the Ajax/DHTML libraries, and in fact you can run them inside of Safari outside of the Dashboard.*
And so, it was fitting that when I finally found time to work on a widget I’d been planning to build since last summer, I decided to use one of the leading Ajax/DHTML toolkits rather than Apple’s own, for most of the widget’s functionality. Having done most of my recent DHTML web work with Prototype and its light-hearted, freewheeling sidekick, Script.aculo.us, I naturally turned to those libraries to help me out.
Nothing To Cheer Here: Microsoft’s Ajax Toolkit Is a “D”
Back in early March when I first released the Ajax/DHTML Scorecard, rating all of the existing Ajax/DHTML toolkits against an ideal cross-browser scale, I rated Atlas an “E.†So, the good news for Microsoft fans is that Atlas is actually better than that. But not by much.
On April 4, I rescinded the original score after some readers correctly pointed out that I was treating Atlas differently from the other toolkits in the shootout. That’s because Atlas was simply vaporware in early March, and there was nothing to test. As I explained in an update to the article, the “E†was based on Microsoft’s past conduct in the cross-browser-support department. Here, they had been very bad big boys. Microsoft is the reason that we have to worry so much about cross-browser support today, so it stood to reason that their entry in the Ajax field would continue their past strategy of steering all users to Microsoft products and away from alternatives.
Though I was skeptical Microsoft had changed its stripes, one writer assured me that
In general Microsoft’s strategy with .NET is to require Windows on the server, but to be 100% browser compatible on the client. .NET components configure themselves automatically for the available browser features ( i.e. CSS levels, javascript dialects, or css/js disabling). While I’m still in the early phases of researching Atlas, it seems that this style of browser support has continued.
And so, I began testing with an open mind, especially after an Ajax blogger raved about Atlas in an article that was picked up by the No Fluff, Just Stuff RSS feed that I follow. (I’ll have to remember to ignore future articles by Brad Abrams, whose blog after all is hosted by msdn.com…)
Since Abrams was celebrating the release last week of the Atlas Control Toolkit, which includes 9 online demos of different Atlas controls, I decided to start my testing there. Unfortunately, Atlas failed on the very first control, the “Cascading Drop Down.†Though it worked in Firefox on Mac OS X, it failed in both Safari 2 and Opera 9. After going through three or four of these, Atlas was batting a very low score, and I decided to keep track of results more scientifically.
The end result? Of the 9 Atlas controls very publicly celebrated by Microsoft this week, here’s how Atlas rates:
- Firefox, 8 of 9 controls worked
- Safari, 4 1/2 of 9 controls worked
- Opera, 3 1/2 of 9 controls worked
I don’t think you can count this as cross-browser support, folks.
