Posts from 2004

Andrei’s redesigning Design By Fire.  I hesitate to comment on a partially-finished design, since I never know if the things that annoy or delight me are going to go away in the next revision.  I will say that there seems to be an awful lot of whitespace in the masthead area.  I’m more interested in responding to the concluding sentences of the section titled “Floats suck”:

All that CSS goodness however, does not mean that I think the logic behind float makes any real design sense, especially to someone who has an extensive graphic design background like myself. The whole float layout approach smacks of using a CSS property for more heavy duty work than it was intended.

That is precisely the case.  float was never meant as a layout tool.  I summarized the history of floats in the article “Containing Floats“, but the short version is that floats are not supposed to be a design tool.  They’re simply meant to take an element, put it to one side, and let other content flow around it.  That’s all.

Floats have been bent to the purpose of large-scale layout for exactly one reason: clear. Because you can clear a footer below two floated columns, float layout came into being.  If there had ever been a way to “clear” elements below positioned elements, we’d never have bothered to use floats for layout.  We’d have used floats in layouts, but that’s not the same thing.

Shaun Inman’s solution to this problem is to use JavaScript to “clear” positioned below others.  For whatever reason, I tend to resist using scripting to solve layout problems, but in this case we really don’t have any other choice.  I’m planning to employ his strategy when I adjust meyerweb’s design, since it’s possible to use it in such a way that things won’t be any worse if JavaScript is disabled, but much better if it is.

So to me, floats sort of suck for design purposes.  They’re not bad, but not great.  If you use them for their original (albeit limited) purpose, though, they rock.

• Floats Don’t Suck If You Use Them Right was published on Saturday, July 17th, 2004.
• It was assigned to the Standards category.
• There have been twenty-four replies.

So let’s say you’re trying to wirelessly connect an Airport Extreme system to a Netgear MR814v2 access point, but you find that it can’t or won’t do so.  You’ll be able to see the SSID from the access point, and even to manually configure your networking so the Mac thinks you’re connected to the Internet, but when you try to go somewhere (like a Web site) it won’t work.  If you try to pick up networking settings via DHCP, you’ll get a self-assigned address instead.  Furthermore, the MR814v2 will only occasionally notice the system as an attached device, and even when it does the situation doesn’t get any better.

So how do you get them working together?

1. First, make sure you’re reasonably up to date on firmware, having at least version 5.01.  I’m on 5.03, electing not to upgrade to 5.30.
2. Log into your MR814v2 using the administrator username and password.
3. In the left-hand menu, scroll to the bottom until you find the “UPnP” item.  Select it.
4. Enable UPnP (Universal Plug and Play) for the router.  Apply the change.

After a few seconds, everything should work fine.  It did for me, anyway; I was able to hit the Internet within seconds, and when I switched over to DHCP it immediately received a lease.  I’m using the system to post this entry, in fact.

I found the answer buried in a Mac OS X Hints thread.  I’m posting this largely so Google can find and add it to the collective cyberconscious.

• Airport Extreme and Netgear MR814v2 was published on Friday, July 16th, 2004.
• It was assigned to the Mac and Tech categories.
• There have been twenty-six replies.

To paraphrase Tim Bray, I had thought I’d said enough about the Dashboard and its markup, but when Dave Hyatt says he’s interested in hearing your thoughts, out loud you think.  Dave’s interest in my thoughts was sparked by Ian Hickson‘s post about extending HTML, where he raised objections to all the technical proposals made thus far and advocated working with the WHAT WG before adding anything new.  So let me first establish my baseline for my thinking on the subject, both past and present:

Dashboard will happen, and will be present in Tiger, and will have at least the features described thus far.  All that remains is to advocate for interoperability with standards.

That isn’t some sort of admission of defeat: I’m really looking forward to the Dashboard.  I think it’s a great thing.  I think it shows how, with just a little bit of extension, the standards we already know can be used in compelling and useful ways, and for that matter how standards can yield powerful applications on their own.  The baseline assumption I make above is a way of establishing the parameters for my discussions of the subject.  It helps keep me focused.

In order to keep things clean, I proposed an approach centering around a new DOCTYPE, and Tim Bray proposed another revolving around namespacing.  Ian pointed out the technical flaws in all of our suggestions.  Strictly speaking, Ian’s right: there are technical problems with each of the proposed solutions.  In the world of pragmatic standards, though, what’s important is making things work as necessary to get the job done.  Thus my approach.  You haven’t heard me complain about the addition of contenteditable to the Web Core’s DOM, for example.  Why would I?  Dave’s right to add it.

It seems that both Tim and Ian felt that creating a new DOCTYPE was a poor idea; one reason was that it would mean recreating the entirety of HTML in DashboardML, with elements bearing the same name and given (presumably) the same semantics.  I don’t really see why that’s a problem, since it’s already been done once before, for a little number we call XHTML.  Now, it might very well be a better idea to create WHATML instead of DashboardML.  That’s fine with me; in fact, I mentioned that as a possibility in my proposal.  The actual name and home of the new language doesn’t much matter to me, although I should point out that whoever is responsible for the new language, it’s going to require either a new DOCTYPE or some kind of namespacing solution.  If Apple’s additions can be accepted by the WHAT WG in time to get Dashboard shipped with Tiger, then great.  If not, they’ll have to move ahead without that imprimatur.  My goal is to advocate that they do so in a standards-friendly way.

In response to my comment that I thought Dashboard would be better off as XML instead of HTML, because that way you can make up whatever markup is needed, Ian said:

So let me get this right. It’s ok to send proprietary non-standard markup over the Web, so long as the angle brackets are XML angle brackets and not HTML angle brackets?

In a word, yes.  That’s what the W3C has been telling us for a while now, so why would I think otherwise?  Sure, the W3C publishes new stuff using XML and it’s all been thoroughly vetted and worked over and generally committeed to death, and that’s great.  But XML makes it possible to invent any markup language you like.  So far as I can tell, that’s kind of its point.  As long as things are well-formed, you’re good; if you’re both well-formed and valid, then angels descend from the markup heavens to sing your praises.

HTML is a well-defined, long-understood (almost-)SGML application.  Changing it willy-nilly is like making up new words to add to English.  (Hey, did you see that roopyrastic article in last month’s Scientific American?)  On the other hand, if you create a new XML language, then you’ve gone the Esperanto route.  The language is as valid as you say it is, and it is a whole new thing, but at least you’re not polluting an existing language with stuff you made up.

So with XML, anyone can make up anything and release it into the wild.  It might be argued that to send new XML languages flying around the public Web is a technological rebirth of the Tower of Babel, to which I would respond, “What else did you think was going to happen?”  In fact, it’s been happening for a while, as the widespread use of RSS will attest.  I haven’t noticed that being a major problem for anyone, and in fact you can combine RSS and CSS to display them in a browser.  That doesn’t seem to be a problem either.

Besides, all of the XML-centric solutions, flawed or not, were excluded by Dave from the outset when he said that Dashboard widgets needed to be HTML, not XML.  The reason given was to lower the entry barrier for would-be widget developers.  I personally don’t agree with that perspective, as I believe anyone skilled enough to create a decent widget will find XHTML (or even namespacing) syntax the least of their concerns.  My disagreement isn’t terribly relevant, though, since I’m not the one defining the way Dashboard widgets work.

As for the concern that adding new stuff to HTML will leave it free of semantics and confuse everyone, I don’t accept that at all.  The semantics that exist in HTML, XHML, and so on exist because we’ve collectively agreed on what they mean.  I don’t mean that we all held a big convention and voted on the meaning of h2.  The HTML specification defined what h2 means semantically, and the rest of us (authors, editors, search engines, etc.) tacitly agreed to go along with that definition.  The same thing can happen again—and, in RSS, already has.  RSS defines its own semantics, and everyone’s agreed to go along with its definitions.  It helps that the elements are given obvious names like description, of course.  RSS also has a title element for every entry in the feed.  Yet nobody, so far as I know, has gotten those title elements confused with HTML’s title element.

So now what?  Now the team at Apple keeps pushing forward to make Dashboard the best product it can be while still making it as easy to develop for as possible.  Fortunately, Dave is willing to publicly discuss how that will be accomplished, which is nothing short of amazing (although totally in keeping with what I know of Dave).  He has also said Apple is willing to submit their additions to the WHAT WG for discussion.  I honestly don’t know what more one could ask for at this juncture.  There is every opportunity to work with Apple (rather than protesting against it) to make sure that Dashboard widgets interoperate with the Web’s foundations… or at least don’t cause unnecessary problems.  Apple is listening.  It’s up to us to talk with them, understanding their needs and limitations while making clear our concerns and suggestions.

Despite my complete lack of time and reluctance to add still more mail to my bulging Inbox, I may well have to subscribe to the WHAT WG public mailing list.

• Dashboard Again was published on Thursday, July 15th, 2004.
• It was assigned to the Browsers and Standards categories.
• There have been eighteen replies.

This Saturday, July 17th, I’m going to be participating in a Blog-a-thon.  “What’s that?” you may ask.  It’s like a Walk-a-thon, where a person collects pledges for charity and then participates in a walk or other event.  Well, in this case Gini and Ferrett are conducting a Blog-a-thon, where they’ll be posting a new blog entry every half hour for twenty-four hours.  The proceeds go to charities of their choices.  In Ferrett’s case, it’s the The National Hemophilia Foundation, in honor of his late uncle Tommy.  Gini is raising money for the Breast Cancer Research Foundation, in honor of her late friend Annie.

This year, Gini’s cause is my cause as well, in honor of my late mother Carol.  If you’d like to support my participation in the event, or indeed simply support breast cancer research on general principles, then please go make a donation to Gini via PayPal.  As I say, all money raised for Blog-a-thon will go to the charities involved; nothing will be held back.

I won’t be going the whole 24 hours—I’m old, I’m terrible at all-nighters, and I have a baby girl to exhaust me.  What I will be doing is showing up early in the afternoon on Saturday with Carolyn and hanging out with the blogging crowd.  They’re planning to set up a web cam, so you’ll be able to see Carolyn furrow her brow at the rest of us.  I’ll also be posting entries as the spirit moves me, not on an every-half-hour basis.  Kat will join us later on in the afternoon.  We may or may not stay until the Blog-a-thon ends at midnight.  That will be determined by how we feel, and how well Carolyn deals with a whole house of hooting, giggling, typing people when she’s trying to sleep. 

Thanks to any and all who can help out.

• Blog-A-Thon was published on Tuesday, July 13th, 2004.
• It was assigned to the Personal category.
• There have been three replies.

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.