Posts from July 2004

After collecting one hundred posted comments (and four pings) for the post “Wanted: CSS Luminary“, I closed comment posting and tallied the results.  This involved going through the comments and compiling a list of every name that was mentioned.  Once I filtered out duplicate or followup posts, I was left with a list of fifty-six names. Then I counted up the number of posts in which each name appeared, so any post that mentioned the same name more than once only registered a single vote for that person.  That yielded the top ten most-mentioned names, shown in Table 1.

Table 1. Most-mentioned names

Rank	Name	Mentions
1	Dave Shea	40
2	Doug Bowman	19
3	Jeffrey Zeldman	17
4	Dan Cederholm	14
5	Andy Budd	12
6	John Gallant	11
	Tantek Çelik	11
8	Holly Bergevin	10
9	Molly Holzschlag	8
10	D. Keith Robinson	7

I also decided to do some weighted scoring, like I used to do with the CSS Leader Board back in the day.  For this situation, the first name listed in a post was counted as a ‘primary mention’.  Any name listed second was a ‘secondary mention’, and a name after that a ‘tertiary mention’.  Any names after that were lumped together in a category called ‘hrair mention’, which I guess means I can’t even count as high as rabbits.  I gave five points for every primary mention, three points for every secondary mention, two for a tertiary mention, and one point for each hrair mention.  That yielded the same ten names and the same leaders, but the mid-field order got rearranged, as you can see in Table 2.

Table 2. Highest-scoring names

Rank	Name	Score
1	Dave Shea	162
2	Doug Bowman	53
3	Dan Cederholm	49
	John Gallant	49
5	Jeffrey Zeldman	47
	Tantek Çelik	47
7	Holly Bergevin	40
8	Molly Holzschlag	38
9	Andy Budd	30
10	D. Keith Robinson	23

So there you have it: the results of my wholly unscientific and vaguely subjective poll.  I’ll be passing the results along to the publisher in question, mostly by e-mailing the URL of this entry.  My thanks to everyone who responded, and congratulations to those who made the list!  I for one welcome our stylish new overlords.

For reference, here’s the entire list of names that was collected from the comments, sorted alphabetically by last name.

• Cameron Adams
• John Allsopp
• Holly Bergevin
• Bert Bos
• Doug Bowman
• Owen Briggs
• Andy Budd
• Dan Cederholm
• Tantek Çelik
• Andy Clarke
• Simon Collison
• Eric Costello
• Mike Davidson
• Kevin Davis
• Meryl Evans
• Todd Fahrner
• John Gallant
• Peter Gifford
• Daniel Glazman
• Danny Goodman
• Patrick Griffiths
• Aaron Gustafson
• Jeremy Hedley
• Andrei Herasimchuk
• Jon Hicks
• Ian Hickson
• Didier Hilhorst
• Molly Holzschlag
• Dave Hyatt
• Shaun Inman
• Makiko Itoh
• Jeremy Keith
• Egor Kloos
• Peter-Paul Koch
• Patrick Lauke
• Seamus Leahy
• Håkon Lie
• ‘Literary Moose’
• ‘Meg at Mandarin’
• Cameron Moll
• Stu Nicholls
• Paul O’Brien
• Dunstan Orchard
• Mike Pick
• D. Keith Robinson
• Richard Rutter
• Blake Scarbrough
• Christopher Schmitt
• Dave Shea
• Sue Sims
• Petr Stanicek
• Greg Storey (?)
• Anne van Kesteren
• Russ Weakley
• Simon Willison
• Jeffrey Zeldman

All right, I lied.  There were three suggested names I left off the list: John Kerry, George W. Bush, and Bill Gates.  I omitted them because none of the three men are known to have spent any time writing about or using CSS.  But hey, if either Kerry or Bush mentions CSS positively in a campaign speech, and isn’t talking about the Content Scrambling System, I’ll give him my vote!

Okay, that’s also a lie.

• Luminous Beings was published on Monday, July 12th, 2004.
• It was assigned to the CSS category.
• There have been three replies.

We just wrapped up our annual summer porch party, otherwise known as the “Paella and Sangria” party.  Kat makes three different paellas, and her own sangria, as well as a non-alcoholic version for those who can’t or won’t imbibe.  This party is sort of the smaller, outdoor version of our annual holiday party, which last year drew almost 150 guests.  Thankfully, the cleanup wasn’t too terrible, since the paellas were cooked in disposable tin pans and were mostly consumed anyway.  All the dessert stuff was totally gone by the time night fell.

It ended, as all good parties do, when the cops showed up.  Okay, it was one cop.  But still.

• Party Time was published on Sunday, July 11th, 2004.
• It was assigned to the Personal category.
• There have been no replies.

Thanks to Boss of All Bosses Jonas, I found myself taking a personality test that had, in the end, the following to say about me:

You are a WRCL–Wacky Rational Constructive Leader. This makes you a golden god. People gravitate to you, and you make them feel good. You are smart, charismatic, and interesting. You may be too sensitive to others reactions, especially criticism. Your self-opinion and mood depends greatly on those around you.

You think fast and have a smart mouth, is a hoot to your friends and razorwire to your enemies. You hold a grudge like a brass ring. You crackle.

Although you have a leader’s personality, you often choose not to lead, as leaders stray too far from their audience. You probably weren’t very popular in high school–the joke’s on them!

You may be a rock star.

Rock star?  I’m the Neil Young of CSS, baby!

• Have I Been Pegged? was published on Saturday, July 10th, 2004.
• It was assigned to the Humor category.
• There have been twenty replies.

It’s been interesting to see the back-and-forth over Dashboard the past few days.  Dave‘s posts have been greatly illuminating, and I belatedly discovered Tim Bray‘s initial reaction and further thoughts on the topic.  Dave has now done a test implementation of adding a default namespace for Dashboard widgets, using the namespace URI http://www.apple.com/2004/xhtml-extended/.  That doesn’t (yet?) point to an actual document, but that’s okay; URIs don’t have to refer to a specific resource.  They just have to be unique.  This is in contrast to URLs, which in theory have to point to something that actually exists.  Although clearly reality has a long way to go before it catches up with that theory.

As Dave points out, his approach not only makes it possible for HTML to be extended without breaking with existing standards, it also provides a handy “pay attention to the Dashboard stuff” trigger and it opens a clear path toward supporting XML-based widgets in the future.  This is all kinds of cool, and I can’t see any real drawbacks.  If you do, let Dave know, or comment on this post; I’ll collect them (since Dave doesn’t presently have commenting on his site) for his review.

Despite it being Dave’s second choice, the “create a new DOCTYPE” idea is something I want to discuss in a little more detail, if only to illustrate how it can work.  Here’s a markup example of an amazingly stupid and useless widget using a hypothetical DashboardML DTD.

<!DOCTYPE html SYSTEM
  "http://www.apple.com/dtd/2004/dashboardml-10.dtd">
<html>
<head>
<title>myWidget</title>
<style type="text/css">
body {background: aquamarine;}
</style>
<script type="text/javascript">
function startup() {
  alert('Happy!  Joy!');
}
</script>
</head>
<body onload="startup();">
<canvas blah="foo" yadda="baz">
<h1>Widget!</h1>
<div class="main">
<p>So cool.</p>
<p>So fine.</p>
</div>
<img src="yar.gif" composite="punchout" alt="Yar!">
<p id="footer">copyleft nobody</p>
</body>
</html>

By referring to a DTD defining a language that looks just like HTML except for the canvas element and composite attribute, along with any other additions, the markup stays free of explicit namespacing and works the way authors already expect.  It really is that simple.  IBM already does something like this, having created an “IBM XHTML 1.1 Transitional” DTD that’s used throughout their Web presence.  The comments at the top of the DTD file explain how it’s different than regular old XHTML, but the executive summary is that it permits some old table-and-spacer-era markup hacks in an XHTML environment.  If you run an IBM-XHTML compliant document through a validator that loads and uses IBM’s DTD to check over the document’s markup, then the document will validate.  The same thing could be done for Dashboard—or for any other project, really.  That’s the beauty of it.  We aren’t constrained to HTML any more, nor even to XHTML.  We’re only constrained by what clients will support… as always.

(It was pointed out to me via e-mail that XHTML is perfect for this, because it’s already modularized so all you have to do is tack on another module.  That would be quite true, except for Dave’s statement that the Dashboard widgets won’t be using XHTML.)

The other potential problem with my suggestion, according to Dave, is that the DOCTYPE is used to pick a rendering mode in current browsers.  Dave says he doesn’t want to restrict widget authors to one mode or the other.  Now, I’d personally have no problem forcing all widgets to be rendered in standards mode, but that’s probably just my inner purist talking.  If it were important to allow quirks mode, then create a transitional DashboardML DOCTYPE that triggers it; use the default (above) for triggering standards mode.  This would be consistent with current DOCTYPE switching schemes.

Regardless, at this point, I think we’re pretty well assured that things are headed in the right direction.  That’s very much thanks to Dave’s openness and genuine interest in doing the right thing, not to mention his swift response times.  Where things go from here, we’ll see, both at Surfin’ Safari and (I expect) by way of submissions to and work by the WHAT WG—which itself will be the subject of a post in the near future.

• Extended Dash was published on Friday, July 9th, 2004.
• It was assigned to the Browsers, Mac, and Standards categories.
• There have been ten replies.

Now we know more about Dashboard, and according to Dave, the widgets are indeed HTML, not XML.  Fortunately, hastily-applied bandages kept my ruptured vein from killing me.  As for my TiBook, some quick squeegee work saved the display, but now the keys are kind of sticky.  How’s that for an image?

As most people who know me are aware, I’m very much a real-world kind of guy.  That side of me is in favor of what’s being done to make Safari and the Dashboard more useful.  The additions to HTML and the DOM are indeed minimal—so far.  I’m sure the first few proprietary extensions to IE/Win were minimal, too.  After all, it’s just a tag called MARQUEE.  What’s one more element?

I also recognize that HTML is far too limited for anything except simple document structuring.  It doesn’t have interesting controls like sliders, and it certainly doesn’t provide any joy for people who want irregular shapes.  SVG does provide such things, but Dave’s point about it being a huge task to implement is understandable.  If only Quartz had been based on SVG instead of another technology… but there’s no sense crying about spilled milk under the bridge now, I suppose.

Of course, the theorist in me is quivering in outrage.  The browser-wars veteran isn’t too thrilled either.  For years, we heard Microsoft and Netscape say things like “standards are secondary to customer demands” and “standards aren’t as useful as the cool new proprietary features we’re adding”.  These things need not be inimical to standards support.  They should not require a breaking of standards.

As I observed previously, making Dashboard widgets be XML would solve the problem, or at least could fairly easily.  Dave says that won’t happen:

…it was suggested that the widgets be written in XML rather than HTML and that all of the new tags and attributes be namespaced. However, this would have dramatically increased the complexity of crafting Dashboard widgets. People know how to write HTML, but most of those same people have never written an XML file, and namespaces are a point of confusion.

I agree about namespaces being confusing; the only reason I have any comfort level with them is because we had to define multiple namespaces for the XML format we used on DevEdge, and I made enough mistakes using them that I eventually came to understand them.  Sort of.  To an author who’s only ever seen HTML or even XHTML, they would likely be very annoying.  I’d like to point out, though, that I suggested not namespacing everything, but creating a whole new DashboardML that used a whole bunch of elements that looked and acted the same as XHTML, with whatever additions were needed.  Thus the beginning of the document (after the DOCTYPE) might look something like this:

<html xmlns="http://www.apple.com/2004/dashboardml">
<head>
<title>This is an example</title>
</head>

So instead of pointing to the XHTML namespace URI, you point to the DashboardML namespace URI.  The end result is that you can have a document that looks exactly like XHTML, except for the additions (composite and so on).  It seems like it would be fairly simple to do, but again, I can’t say that with any authority.

So let’s assume that, for whatever reason, the above approach isn’t possible within the Tiger timeframe.  There is another way, one I mentioned briefly in my last post.  That would be to create a new DTD for DashboardML, one that’s a direct copy of the HTML 4.01 DTD with the needed additions.  It could look like this:

<!DOCTYPE html SYSTEM "http://www.apple.com/dtd/2004/dashboardml-10.dtd">

That would point to a DTD that defines DashboardML.  DashboardML would be exactly like HTML 4.01 (or whatever version they wanted) in every respect except for the additions of the canvas element and the composite attribute.  The advantage is that they can add more things if needed, and not pollute the HTML space.  Since Apple’s working with the WHAT WG to get these things accepted, then perhaps the WHAT WG should host the DTD.  Then it might look something like:

<!DOCTYPE html SYSTEM "http://www.whatwg.org/dtd/2004/whatml-10.dtd">

The URI could be anything, so long as it pointed to an actual DTD.  I don’t even care where it lives, so long as it lives somewhere.  I should also point out that this would need to be done even if the widgets were XML, as opposed to an HTML-like language.  Either way, they keep Dashboard extensions out of the HTML space.

Why should we even bother?  One word: validation.  By providing a DTD that defines the markup language being used to create the widgets, validation becomes a snap.  That’s important, because with validation, widget authors can keep their markup clean.  It will help them with their development efforts.

Here’s another reason to bother: reducing confusion.  “But Eric, a new DOCTYPE will increase confusion!” you might be thinking.  Maybe at first, although overall I doubt it will.  The confusion-reducing aspect is that when widgets get published on the Web—and they will be published on the Web—there will be an obvious indication that the markup is not traditional HTML, but something really close to it.  Browsers can then do what they’ve always done: handle what they understand, and ignore what they don’t.

It’s been argued that Dashboard widgets are intended for a closed environment, and not to sit out on the Web.  True, but that won’t change anything.  Within a week of their appearing in the WWDC build of Tiger, Dashboard widgets appeared on the public Web (they’ve since been pulled offline).  This won’t exactly tail off as more widgets are built.  If anything, we’ll see more and more widgets getting out into the wild—for example, when people find a widget they like and adapt it for use on their public sites.  The calendar is the most obvious example that comes to mind.  In order to keep things straight, widgets need to have their own DOCTYPE.  If nothing else, it will provide a convenient explanation when someone throws a widget onto their site and it breaks in other browsers.  (“Yeah, see, that uses DashboardML and only Safari supports it…”)

Over at the WaSP, Anders Pearson wrote:

Overall, though, it’s not that big a deal. Safari does an excellent (not perfect) job of supporting the various HTML, XHTML, and CSS specs as they’re written and ultimately, that’s what’s most important. If developers don’t want to use the extensions, they don’t have to.

As long as these extensions happen within a new document type, then I agree.  Allowing them to operate within any document bearing a W3C DOCTYPE would be a big, big mistake.

• DashboardML was published on Thursday, July 8th, 2004.
• It was assigned to the Browsers, Mac, and Standards categories.
• There have been four replies.

In his most recent post on the underpinnings of the Dashboard, titled Introducing the Canvas, Dave Hyatt said the following:

Another extension we made to HTML is a new element called the canvas. This element is essentially an image element that supports programmatic drawing.

And then, a bit later on:

In addition to the canvas element, we’ve also introduced a new attribute onto the img element. The composite attribute allows you to control how an image gets composited.

Wait a minute.  Did I just get hit over the head and magically transported back to 1994?  New HTML elements and attributes?  What the bleeding hell?!?

[insert sound of forehead banging repeatedly on desktop here]

I hope I’m reading his post incorrectly.  I hope that what Dave is really saying is that Dashboard widgets are actually XML, albeit an XML that looks very much like HTML except they’ve added some nifty stuff to it.  If so, great, fine, no problem.  XML lets you do whatever you want, really.  But if these are widgets that use actual HTML DOCTYPEs, and yet add this stuff, then the throbbing vein in my forehead is going to rupture and spray blood all over my shiny TiBook.  We just left that tag soup party.  I really don’t want to have another steaming, fetid bowl of it plopped down in front of me.  Not even one that exists in a ‘closed’ environment like OS X.

Even if Dashboard widgets are currently built around invalid HTML documents, it seems like there’s still plenty of time to convert them to well-formed XML, thus (largely) solving the problem.  Heck, there’s even time to create a DTD for the widgets, thus permitting the widgets to be both well-formed and valid.  I’m all in favor of that approach.  As a measure of last resort, a new HTML DTD could be written for “Dashboard HTML 1.0” or something like that.

But if it’s all really broken HTML 4.01, not XML, then there’s a serious problem.  From a forward-compatibility perspective, the Dashboard would be no better than Microsoft’s CSS-like extensions, the ones that let authors change the appearance of the browser’s scrollbars and other such wackiness.  In fact, they’d be much worse because there now exists the ability to create the Dashboard within the open framework the W3C has (slowly and painstakingly) created.  To ignore that would be the worst kind of regressive move.

• Wrapped in Canvas was published on Wednesday, July 7th, 2004.
• It was assigned to the CSS, Mac, and Standards categories.
• There have been nine replies.

Recently, I had a conversation with an editor at a relatively well-known and respected publisher about a CSS book concept they’re pursuing.  I don’t want to give too much away about the book itself, since it’s their idea and not mine, but I will say that the concept more or less requires that the book’s author be a recognized name in the CSS and Web design community.

For various reasons, I’m not able to take on the project myself, so we were bouncing around various names of other people who might be a good fit.  I shared some of my ideas, but I felt like I was struggling, and after we hung up I felt like I hadn’t really been a big help.  That bothered me, so I’m going to put this to you, dear readers: tell me who would automatically make you take a CSS book seriously and consider buying it just on the strength of the name alone.  (Remember, I’m not able to take this project, so don’t say, “Why, yours, Eric!” unless you want to be derided as a pointless suck-up.)  You should probably list a couple of names, just in case you all pick one person as your primary and he or she isn’t available to do the book, either.  After a week or so I’ll pass the results on to the publisher.  Even if someone else has already named your top choice(s), list them again.  The most commonly-listed names will be the ones who are at the top of the list.

So the floor is open.  Let’s hear some names!

• Wanted: CSS Luminary was published on Monday, July 5th, 2004.
• It was assigned to the Books and CSS categories.
• There have been one hundred five replies.

A lot of people have been saying it for years.  Within the last day or so, Scott Andrew said it.  Then Meryl said it.  Now I hear that the Department of Homeland Security says it, or so it would seem (I couldn’t find corroborating information on the DHS site).

Security is becoming more and more important, especially given the rise in organized attacks that exploit holes in IE and Windows, not to mention Outlook Express (known around the Meyer house as Virus Express).  It’s definitely worth looking into switching to another browser, if you haven’t already done so, and to strongly recommend the same to people you know.  Firefox is most often mentioned as a suitable replacement, and it will even import bookmarks, cookies, and settings from IE.

Of course, you may get pushback that Explorer is required for this site or that one.  Just point out that they can do 99% of their browsing in Firefox, and only launch Explorer for those few sites that need it.  After all, it isn’t like IE will be unavailable—they couldn’t get rid of it even if they wanted to do so.

Update: not only has CNN run a story along these same lines, but they mentioned Porter by name.  Way to go, dude!  Now when do I get namechecked by the news media?  <pout type="smirking" />

• Exploring Other Alternatives was published on Friday, July 2nd, 2004.
• It was assigned to the Browsers category.
• There have been five replies.