Posts in the (X)HTML Category

In our post-game analysis, Tantek and I felt that the Developers Day track on microformats went incredibly well.  Not only did we get a lot of good feedback, I think we turned a lot of heads.  The ideas we presented stood up to initial scrutiny by a pretty tough crowd, and our demonstrations of the already-deployed uses of formats like XFN, like XHTMLfriends.net and an automated way to subscribe to hCalendars and hCards, drew favorable response.

Even better, our joint panel with the Semantic Web folks had a far greater tone of agreement than of acrimony, the latter of which I feared would dominate.  I learned some things there, in fact.  For example, the idea that the Semantic Web efforts are inherently top-down turns out to be false.  It may be that many of the efforts have been top-down, but that doesn’t mean that they have to be.  We also saw examples where Semantic Web technologies are far more appropriate than a microformat would be.  The example Jim Hendler brought up was an oncology database that defines and uses some 600,000 terms.  I would not want to try to capture that in a microformat—although it could be done, I suspect.

Here’s one thing I think is key about microformats: they cause the semantics people already use to be impressed onto the web.  They capture, or at least make it very easy to capture, the current zeitgeist.  This makes them almost automatically human-friendly, which is always a big plus in my book.

The other side of that key is this:  it may be that by allowing authors to quickly annotate their information, microformats will be the gateway through which the masses’ data is brought to the more formal systems the Semantic Web allows.  It very well may be that, in the future, we’ll look back and realize that microformats were the bootstrap needed to haul the web into semanticity.

Tantek and I have had some spirited debates around that last point, and are actually in the middle of one right now.  After all, maybe things won’t go that way; maybe microformats will lead to something else, some other way of spreading machine-recognizable semantic information.  It’s fun to debate where things might go, and why, but I think in the end we’re both willing to keep pushing the concept and use of microformats forward, and see how things turn out down the road.

What’s fascinating is how fired up people get about microformats.  After SXSW05, there was an explosion of interest and experimentation.  Several microformats got created or proposed, covering all kinds of topics—from folksonomy formalization to political categorization.  A similar effect seemed to be occurring at WWW2005.  One person who’s been around long enough to know said that the enthusiasm and excitement surrounding microformats reminded him of the early days of the web itself.

As someone who’s at the center of the work on microformats, it’s hard for me to judge that sort of thing.  But I was there for some of the early WWW conferences, and I remember the energy there.  As I rode home from WWW2 in Chicago, I was convinced that the world was in the process of changing, and I wanted more than anything to be a part of that change.  To hear that there’s a similar energy swirling around something I’m helping to create and define is profoundly humbling.

That all sounds great, of course, but if it remains theoretical it’s not much good, right?  Fortunately, it isn’t staying theoretical at all, and I’m not just talking about XFN.  Want an example of how you could make use of microformatted information right now, as in today?  That’s coming up in the next post, where I’ll show how to make use of a resource I mentioned earlier in this post.

• Microformats and Semantics in Japan was published on Wednesday, May 18th, 2005.
• It was assigned to the (X)HTML, Microformats, semantic web, and XFN categories.
• There have been five replies.

I just talked with Ryan, organizer of the XHTML and CSS Workshop happening in London on Saturday, 4 June 2005, and he says there are only a few seats left—there were but seven when he contacted me on Friday, but for all I know it’s fewer now (and no doubt it is if you’re reading this post in the archives, instead of when it was first published).

Thanks to the very strong registration numbers, Ryan is seriously considering adding another day.  If that happens, it will mean the Saturday session is all sold out, so if you want to attend that day, you’d better get your reservation in quickly.  We’ll spend the day learning about the ins and outs of standards-based design, as well as chewing over attendee questions and generally having fun while we learn a ton.  And don’t forget about the exclusive Survival Kit CD-ROM that all attendees will receive.

All in all, a good time is in the offing, and it’s yours… but only if you grab a seat.

Update | 22 Apr 05: the Saturday session has sold out, and the Friday session has been scheduled.  Registration is open!

• London Workshop Filling Up! was published on Sunday, April 17th, 2005.
• It was assigned to the (X)HTML, CSS, and Speaking categories.
• There have been nine replies.

A little while back, I made a joke about presentational class names.  As it happened, there was a second joke hidden within the joke—as is so often the case with me—and I was delighted to see that one of my readers caught it.

But is there a reasonable alternative?  I’ve long been using the class value border to indicate when I want to put a border around a picture.  This is, to me, one of those gray-area situations that’s very hard to resolve.  I can claim that border is not very presentational: it doesn’t say anything about the specific appearance of the border, only that there should be one.  I could also argue that it’s entirely too presentational: from a semantic point of view, what does it matter if the picture is bordered or not?  It doesn’t, so the class name is unacceptable.

And yet, it does matter.  Visually, some images need to have borders, while others need to lack a border.  I can’t invent a new element or attribute to express the difference (not without writing my own DTD, anyway).  Technologically, class values are the only place I can make the distinction.

There are some other sort-of-presentational class names hanging around my site, too.  standalone is used when an image, or set of images, stands on its own, as opposed to illustrative images that are floated.  The intent is presentational, though again, standalone doesn’t say exactly how the images stand alone.  It just says that they do.

I’ve yet to come up with a good semantic way of saying “this image needs to have something that visually separates it from the rest of the page”.  I’ve kicked around ideas for other values, like framed or separated, but these fall into the same gray area… probably because the intent is basically presentational.  I’ve abstracted the presentationalism of the intent, but it’s still there.

So, anyone have a better class name, or even a better approach to drawing the distinction?  And before anyone tells me to quit worrying about this, I’m not worrying—I’m playing.  It’s like doing a crossword, or working on a logic puzzle.  Usually I just do this stuff in my head, but in this case I’m fairly stumped, and could use some help.

• Class Presentation was published on Sunday, April 3rd, 2005.
• It was assigned to the (X)HTML and CSS categories.
• There have been forty replies.

See, that’s why presentational class names are such a bad idea.

• Keep Your Classes Clean was published on Wednesday, February 23rd, 2005.
• It was assigned to the (X)HTML, CSS, Humor, and Standards categories.
• There have been eleven replies.

Adam Bosworth recently gave a talk about simplicity in technology, and how it’s far more important to be simple and sloppy than complex and pure.  For the most part I agree with him; my first draft of XFN and FOAF was, basically, “FOAF is complicated.  XFN isn’t.”  While that was a flip way to amuse the reviewers, it also summarizes the core reason I took to XFN when Tantek and Matt explained it to me.  Making things easy is always preferable to making them hard.  As RFC 1925 so correctly states, “In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.”

There are two places where I’d like to take issue with Adam, however.  (And I hope it’s not presumptuous of me to call him “Adam” instead of “Mr. Bosworth”.)

The first is the idea that the Web should never be more complicated than plain old HTML.  Adam says: “I very much doubt that an HTML that had initially shipped as a clean layered set of content (XML, Layout rules – XSLT, and Formatting- CSS) would have had anything like the explosive uptake.”  This is absolutely common sense.  I think it’s also common sense that any truly popular and useful system starts out basic—’primitive’, if you like—and grows in complexity.  The best such systems hide the complexity from the end user.  Automobiles have gone from a few very basic controls (steering, acceleration, braking) to the mobile gadget factories we pilot today.  I still don’t have to know how the engine works to drive one.

So I absolutely agree that HTML caught on because it was simple.  It had to be, because there was nothing to shield us from the system’s innards.  When the popular Web was getting started, I did my best to promote its use by writing a trilogy of HTML tutorials (1, 2, 3).  My entire goal there was to make it easier for anyone to publish their own content.  Want to publish your grandmother’s Apple Pan Dowdy recipe?  More pictures of pets?  Bring ’em on!  They way I figured, if everyone published what they knew, the best information would slowly rise to the top by virtue of gathering more links.  Years later, Google built an empire around the concept of the best information being the most heavily linked.  Ah well, another fortune lost.

Even then, I did take the time to teach well-formed markup because I knew that malformed markup was likely to cause trouble.  This wasn’t an elitist thing, or some sort of far-reaching clairvoyance: at the time, it was possible to break browsers with incorrect nesting of inline elements.  So it only made sense to tell readers, “Hey, if you nest elements, make sure they actually nest instead of just closing them at random.  Otherwise your page might not get displayed.”  Eventually, browsers got more tolerant of sloppy markup, and those kinds of warnings weren’t really needed any longer.

So anyway, here we are ten-plus years later, and we’re still arguing about table layout and XHTML being lower-case and blah blah blah.  In the first place, table-driven layout isn’t simple.  It’s flexible and sloppy, but not simple.  The vast majority of table-layout authors have never touched a tag in their lives.  They’ve just told some tool “do this”, and it did it.  They don’t care how.  They shouldn’t have to care how.  So whether the tool generates 50KB of table-and-spacer markup, or 15KB of semantic markup with another 5KB of CSS, is wholly irrelevant to the user.  As it should be.

It is, however, relevant to those of us who ply the back end of the Web.  I’m not going to go over the arguments now; you probably know them, and know how you feel.  But my feeling has always been that once word processors stopped fighting over file formats, and got on to fighting over ease of use and features while all reading the same formats, that’s when word processing software took off.  I feel the same about the Web.

Now, I’m kind of a fan of CSS.  Have been for a while.  I like it because it lets the design (largely) happen away from the markup, where changes are easier, and it allows all kinds of stuff that HTML layout never managed.  (Two examples right off the top of my head: letter-spacing and border-style.)  I also like JavaScript and the DOM—not because they’re pure, but because they do what they need to do.  Inspired by the work of others, I put all those pieces together recently and created a lightweight slide show system.  It isn’t perfect, and because there are DOM actions it doesn’t always tolerate sloppiness, but it’s pretty simple.  Once editors exist to let people just point, click, and type slides (and I suspect that such editors may exist in the relatively near future), it will be even easier.  And the underlying format will not matter to 95% of its users.  Nor should it.

Anyway, this brings me round to the other thing I wanted to talk about.  Early in the talk, Adam says:

…in one of the unintended ironies of software history, HTML was intended to be used as a way to provide a truly malleable plastic layout language which never would be bound by 2 dimensional limitations, ironic because hordes of CSS fanatics have been trying to bind it with straight jackets ever since, bad mouthing tables and generations of tools have been layering pixel precise 2 dimensional layout on top of it.

First off, I think that Tim Berners-Lee might have a slightly different perspective on what HTML was intended to do, but let’s skip that.  The part I don’t get is the perception that “CSS fanatics have been trying to bind” HTML.  Personally, I’ve been trying to free Web design from the limitations it’s long experienced.  I’ve been working in that direction for years now.  I won’t argue that the job is finished: far from it.  But a big reason I’ve long been an advocate of using CSS is that it loosens the straightjacket, not tightens it.  The work I did within the context of the CSS Working Group was intended to loosen the bonds even further.

Maybe that means I don’t meet Adam’s definition of a “CSS fanatic”, I don’t know.  Maybe I’m not one of the “hordes” of jackbooted geeks, seeking to impose my tyrranical notions on the unwashed.  Either way, this does bring me to the question I want to ask:  where does this perception come from, that CSS is promoted a way to make the Web harder and HTML more difficult?  I’m not trying to belittle the idea by asking; I’m genuinely curious, and a little dismayed.  I know I’ve worked very hard to clearly describe what’s good and bad about CSS, just as I have about table-based design.  I’ve put a lot of effort into helping people who want to learn CSS do so, and explaining to those who ask why I think using CSS is a good idea.  Most of the other CSS advocates I know have done the same.  What is it that we did or didn’t do that got across this idea of inflexibility, or intolerance, or just plain elitism?

Because when you get right down to it, I’m still all in favor of people putting their stuff up for the world to see.  These days, I’m also in favor of making it easier for everyone else to see that stuff, and for tools to collect and analyze that stuff.  Standards make that easier—CSS makes that easier, although not as a standalone savior, but as part of a mosaic.  If someone as well-regarded and experienced as Adam Bosworth doesn’t see that, then I can’t help but feel there’s been a failure to communicate.

• Simplicity Where It Counts was published on Monday, November 22nd, 2004.
• It was assigned to the (X)HTML, CSS, and Standards categories.
• There have been twenty-eight replies.