Articles With Tag Web Design
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?
- 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,
- 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.
Since releasing of Crystal Clear and VacuumMail earlier this year, my download traffic has overridden my .Mac account ... and twice (so far) I've had to upgrade my account to accommodate the bandwidth. I don't mind that, nor do I mind the additional traffic on the Mars Downloads pages. What I do mind is the time it takes me to keep those pages updated! In fact, it takes so long I haven't been able to keep them in sync with the new stuff I was making.
I've been a pro webmaster for, well, a long time... since 1994, in fact. So keeping a couple of simple pages updated shouldn't make me break a sweat, right? Damn right! Problem is, the Download pages started as an experiment with Apple's iWeb software last year, and iWeb and WordPress don't mix well. To help them get along, I devised a simple checklist so all I'd have to do was:
- Generate the raw HTML from iWeb
- Massage the HTML by
- Tweaking a few CSS styles,
- Doing a few search/replaces,
- Doing a bit of reformatting, and
- Plopping the iWeb HTML in the WordPress template, and
- Moving the iWeb graphics and other files to the server.
At least, that's how I thought it was going to go. As it turns out, the convoluted HTML and CSS code that iWeb generates invariably causes problems when running inside Mars. This means each update can turn into a 2-3 hour scavenger hunt, with each contestant (Me, Me, and Me) trying to find a lost
px in a huge block of unreadable code.
So last week I vowed to find another way, and I think I have. The end solution means more work up front in generating the site to begin with, but should make it very easy to rearrange, add, or rewrite content or images on those pages.
Like most geeky Mac users, I delight in the little "easter eggs" I discover from time to time as I use my Mac. It's especially satisfying when I stumble across something cool about apps I thought I knew... even mundane little apps like TextEdit. This article describes how I learned to use TextEdit as an HTML editor (!!) It's the first in a planned series I'll be publishing to share and preserve my personal Mac OS X "easter eggs." I've already got a long Edgies note that's full of little tips and tricks on topics like Pages, Quicksilver, contextual menus, PackageMaker, and DevonThink Pro, as well as more on TextEdit.
I originally published this particular tip on MacOSXHints last summer, and I always intended to republish it here... but, well, I'm only now getting around to it. MacOSXHints is a great resource for Mac users, and I search its archives frequently. However, as a purveyor of tips, it's a bit limiting, since you can't include images or movies in your writeup, and you don't have much control over how it's presented. One of the main reasons I purvey tips, by the way, is to try to counteract the drivel a Google search often dredges up. For example, I searched again today to see if anyone had published this useful tidbit about TextEdit and couldn't find it anywhere... for the most part, Google gave me articles like this one on About.com, which just don't tell the full story.
If you’re a Mac user who’s wandered in to this article and don’t know what Growl is yet, you might want to stop by that essential open-source project’s home page to get acquainted. Once your Mac starts Growling, you’ll understand how fitting it is that Apple’s naming all their OS X releases after large cats.
If you’re a Windows user, you’re still welcome to read up on Growl and why it’s become a standard component of so many Mac users’ desktops even though it’s still only at version 0.7.4. If you find Growl cool, too, you know what to do.
This article isn’t about Growl, though. It’s about Growl displays—the part of Growl you actually see when an event occurs you’ve asked to be notified about. You see, like many other cool apps nowadays (Adium, Synergy, Menuet, etc.), Growl is “skinnable.” Part of the fun—and the utility—of Growl is that users can customize the appearance of different kinds of alerts. In fact, Growl provides you with an astonishing degree of control over your customizing, and this flexibility is one of Growl’s coolest aspects. Using the Growl Preference Pane, you can:
- Set a default Growl style as your starting point.
- Customize certain aspects of each Growl style. Some styles let you set different attributes for up to 5 different priority levels.
- Assign a default style to each different application that’s registered with Growl. (Here’s a growing list of Mac OS X applications that now include support for Growl event notifications.)
- Override the default for any specific notification event, or for a given event priority.
With so many options, it’s no wonder that Growl users collect Growl styles like some Mac users collect system icons or desktop pictures!
Growl notifications can take several forms: Email, speech (using the Mac’s built-in vocal chords), or visual displays. The visual display types are roughly broken down into two kinds:
- Displays you build with AppleScript or xCode (those with the extension .growlView), and
- Displays that are basically just little web pages (those with the extension .growlStyle).
It’s the latter type I want to briefly shout about today.
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.