I said that you wrap portions of your document (or the whole thing) in an element element and use the customized element inside. This is incorrect, and actually a very bad idea. In fact, you define your customized elements using an element element and then use the customized elements later in the document. Something like this:

<element extends="h1" name="x-superh1">
</element>

<h1 is="superh1">UltraMegaPower!!!</h1>
<h1>Regular Old Power</h1>

The line break inside the element element isn’t required—I just threw it in for clarity.

The element element can optionally contain template markup, but I honestly don’t understand that part of it yet. I get the general idea, but I haven’t crawled through the specifics long enough to have really internalized all the fiddly bits. And as we all know by know, the fiddly bits are where understanding lives and dies. (Also where the Devil hangs out, or so I’ve been told.)

I still firmly believe that all this papers over a much bigger problem, which is the arbitrary barrier to devising and using actual custom elements (as opposed to customized existing elements). HTML5 already allows you to make up your own bits of language: you can make up any attribute you want as long as your preface the name with data-. Okay, so that’s a little bit clumsy naming-wise, but the capability is there. You don’t have to register your attributes, or declare them in a list, or any of that other stuff. You just make up data-timing or data-proglang or data-sttngcharacter on the spot and off you go.

This is not possible for elements. You can’t even make up a prefixed element name, whether it’s data-kern or x-kern or even xkern (to avoid the limitation that hyphens aren’t allowed in element names). You just can’t devise your own elements. The best you can do is use the element element to sprinkle some semantic dust bunnies on top of elements that already exist.

Of course, all this “you can’t” and “not possible” applies to the specification. Browsers will let you feed them any old element name and style it, script it, whatever. Some say that’s more than enough. If the browser lets you do it, why let the specification hold you back? And of course, that’s how most people will approach the situation.

To someone like me, though, who spent years (literal years) explaining to web folk the world over that just because Internet Explorer for Windows let you write width: 12 px, actually writing it was still a bad idea—well, those habits die hard. Just doing stuff because the browser let you do it is not always a good idea. In fact, more often than not it’s a bad idea.

None of that really matters, as I say, because people are going to inject their own elements into their markup. They’ll do it because it’s easier than thinking about the proper element to use, or they’ll do it because no appropriate element yet exists, or for some other reason. That’s why the HTML5 specification ought to include the ability to do it, so that we have a paved path and defined best practices. The capability is useful, as the data- attribute feature demonstrates. If there’s a good, solid technical reason why extending that customization from attributes to elements is not desirable, I’d really like to know what it is.

(Ed. note: this post has been corrected since its publication, and a followup clarification has been posted.)

Suppose you’re creating a super-sweet JavaScript library to improve text presentation—like, say, TypeButter—and you need to insert a bunch of elements that won’t accidentally pick up pre-existing CSS. That rules span right out the door, and anything else would be either a bad semantic match, likely to pick up CSS by mistake, or both.

Assuming you don’t want to spend the hours and lines of code necessary to push ahead with span and a whole lot of dynamic CSS rewriting, the obvious solution is to invent a new element and drop that into place. If you’re doing kerning, then a kern element makes a lot of sense, right? Right. And you can certainly do that in browsers today, as well as years back. Stuff in a new element, hit it up with some CSS, and you’re done.

Now, how does this fit with the HTML5 specification? Not at all well. HTML5 does not allow you to invent new elements and stuff them into your document willy-nilly. You can’t even do it with a prefix like x-kern, because hyphens aren’t valid characters for element names (unless I read the rules incorrectly, which is always possible).

No, here’s what you do instead (corrected 10 Apr 12):

1. Wrap your document, or at least the portion of it where you plan to use your custom markup,Define the element customization you want with an element element. That’s not a typo.
2. To your element element, add an extends attribute whose value is the HTML5 element you plan to extend. We’ll use span, but you can extend any element.
3. Now add a name attribute that names your custom “element” name, like x-kern.
4. Okay, you’re ready! Now anywhere you want to add a customized element, drop in the elements named by extends and then supply the name via an is attribute.

Did you follow all that? No? Okay, maybe this will make it a bit less unclear. (Note: the following code block was corrected 10 Apr 12.)

<element extends="span" name="x-kern"></element>
<h1>
<span is="x-kern" style="…">A</span>
<span is="x-kern" style="…">u</span>
<span is="x-kern" style="…">t</span>
<span is="x-kern" style="…">u</span>
mn
</h1>
<p>...</p>
<p>...</p>
<p>...</p>

(Based on markup taken from the TypeButter demo page. I simplified the inline style attributes that TypeButter generates for purposes of clarity.)

So that’s how you create “custom elements” in HTML5 as of now. Which is to say, you don’t. All you’re doing is attaching a label to an existing element; you’re sort of customizing an existing element, not creating a customized element. That’s not going to help prevent CSS from being mistakenly applied to those elements.

Personally, I find this a really, really, really clumsy approach—so clumsy that I don’t think I could recommend its use. Given that browsers will accept, render, and style arbitrary elements, I’d pretty much say to just go ahead and do it. Do try to name your elements so they won’t run into problems later, such as prefixing them with an “x” or your username or something, but since browsers support it, may as well capitalize on their capabilities.

I’m not in the habit of saying that sort of thing lightly, either. While I’m not the wild-eyed standards-or-be-damned radical some people think I am, I have always striven to play within the rules when possible. Yes, there are always situations where you work counter to general best practices or even the rules, but I rarely do so lightly. As an example, my co-founders and I went to some effort to play nice when we created the principles for Microformats, segregating our semantics into attribute values—but only because Tantek, Matt, and I cared a lot about long-term stability and validation. We went as far as necessary to play nice, and not one millimeter further, and all the while we wished mightily for the ability to create custom attributes and elements.

Most people aren’t going to exert that much effort: they’re going to see that something works and never stop to question if what they’re doing is valid or has long-term stability. “If the browser let me do it, it must be okay” is the background assumption that runs through our profession, and why wouldn’t it? It’s an entirely understandable assumption to make.

We need something better. My personal preference would be to expand the “foreign elements” definition to encompass any unrecognized element, and let the parser deal with any structural problems like lack of well-formedness. Perhaps also expand the rules about element names to permit hyphens, so that we could do things like x-kern or emeyer-disambiguate or whatever. I could even see my way clear to defining an way to let an author list their customized elements. Say, something like <meta name="custom-elements" content="kern lead follow embiggen shrink"/>. I just made that up off the top of my head, so feel free to ignore the syntax if it’s too limiting. The general concept is what’s important.

The creation of customized elements isn’t a common use case, but it’s an incredibly valuable ability, and people are going to do it. They’re already doing it, in fact. It’s important to figure out how to make the process of doing so simpler and more elegant.

My reason to bring this up is that I’m very interested by how TypeButter accomplishes its kerning: it inserts kern elements with inline style attributes that bear letter-spacing values. Not span elements, kern elements. No, you didn’t miss an HTML5 news bite; there is no kern element, nor am I aware of a plan for one. TypeButter basically invents a specific-purpose element.

I believe I understand the reasoning. Had they used span, they would’ve likely tripped over existing author styles that apply to span. Browsers these days don’t really have a problem accepting and styling arbitrary elements, and any that do would simply render type their usual way. Because the markup is script-generated, markup validation services don’t throw conniption fits. There might well be browser performance problems, particularly if you optically kern all the things, but used in moderation (say, on headings) I wouldn’t expect too much of a hit.

The one potential drawback I can see, as articulated by Jake Archibald, is the possibility of a future kern element that might have different effects, or at least be styled by future author CSS and thus get picked up by TypeButter’s kerns. The currently accepted way to avoid that sort of problem is to prefix with x-, as in x-kern. Personally, I find it deeply unlikely that there will ever be an official kern element; it’s too presentationally focused. But, of course, one never knows.

If TypeButter shifted to generating x-kern before reaching v1.0 final, I doubt it would degrade the TypeButter experience at all, and it would indeed be more future-proof. It’s likely worth doing, if only to set a good example for libraries to follow, unless of course there’s downside I haven’t thought of yet. It’s definitely worth discussing, because as more browser enhancements are written, this sort of issue will come up more and more. Settling on some community best practices could save us some trouble down the road.

Update 23 Mar 12: it turns out custom elements are not as simple as we might prefer; see the comment below for details. That throws a fairly large wrench into the gears, and requires further contemplation.

Anyway, here’s a sampling of the sites most frequently mentioned and how they’re using HTML5, listed in no particular order.

Using new-to-HTML5 markup (and DOCTYPE)

• MailChimp
• slashdot
• Obama for America
• About
• Unilever
• Myspace
• Sencha
• Nike Better World
• Apple
• The Killers
• The GLobe and Mail
• YouTube – Basically only the video element, and that only if you’ve enrolled in the HTML5 trial.

Using HTML5 DOCTYPE but no apparent new-to-HTML5 markup

• Google
• USA.gov
• Digg
• Yahoo – I’m told that Yahoo! Mail uses HTML5 features but I’m not a user so I can’t verify that.
• Flickr
• Netflix

And then there’s Facebook. Rumor has it they’re using HTML5 features like the History API while still bearing an XHTML DOCTYPE. I was also told they use video but all the videos I saw were Flash-based. It’s possible that more is going on—who knows, maybe Farmville is all HTML5 now—but I was only willing to put up with the user experience for so long.

Some notes:

• I didn’t run a spider script to verify which HTML5 elements, if any, were being used on a site. Instead I surfed around using a user stylesheet that highlights HTML5 elements and looked for dashed red outlines. If they were there, the site got “uses HTML5 markup”. If I didn’t see any, then “no apparent HTML5 markup”. This may mean I miscategorized a site or two, in which case sorry. Even if not, these lists won’t stay current for more than a couple of weeks, so regard this as a single snapshot in time, not the whole movie.
• In my limited and purely anecdotal peerings, far and away the most commonly-used HTML5 element was section. nav appeared to run a distant second.
• Any site that uses font replacement is using HTML5: canvas. I didn’t list such sites, so bear that in mind. (Sorry, Beano.) I just hope such sites change their DOCTYPEs to match.
• I did not list any site that lacked a DOCTYPE. I don’t care if the HTML5 DOCTYPE is optional, that doesn’t mean any DOCTYPE-less page is using HTML5. Or, if it does, my next step is to write a MeyerHTML DTD with an optional DOCTYPE and then charge you all $1 per site for using invalid markup in violation of the terms of the DTD’s license. And then I’m buying an island. Oahu seems nice.

Comments are switched off for once partly because I don’t really want another faceful of politics right now, and partly because attempts to post links to other HTML5 sites will end up in the spam trap and frustrate posters. Feel free to go nuts on your own sites, of course.

Writing to the Norm

No, not the fat guy on “Cheers.” Actually, it’s a fundamental issue every Web author needs to know about and appreciate.

Web browsers are written by different people. Each person has their own idea about how Web documents should look. Therefore, any given Web document will be displayed differently by different browsers. In fact, it will be displayed differently by different copies of the same browser, if the two copies have different preferences set.

Therefore, you need to keep this principle foremost in your mind at all times: you cannot guarantee that your document will appear to other people exactly as it does to you. In other words, don’t fall into the trap of obsessively re-writing a document just to get it to “fit on one screen,” or so a line of text is exactly “one screen wide.” This is as pointless as trying to take a picture that will always be one foot wide, no matter how big the projection screen. Changes in font, font size, window size, and so on will all invalidate your attempts.

On the other hand, you want to write documents which look acceptable to most people. How? Well, it’s almost an art form in itself, but my recommendation is that you assume that most people will set their browser to display text in a common font such as Times at a point size of somewhere between 10 and 15 points. While you shouldn’t spend your time trying to precisely engineer page arrangement, you also shouldn’t waste time worrying about how pages will look for someone whose display is set to 27-point Garamond.

That’s from “Chapter 1: Terms and Concepts” of Introduction to HTML, my first publication of note and the first of three tutorials dedicated to teaching HTML in a friendly, interactive manner. The tutorials were taken down a couple of years ago by their host organization, which made me a bit sad even though I understood why they didn’t want to maintain the pages (and deal with the support e-mail) any longer.

However, thanks to a colleague’s help and generosity I recently came into possession of copies of all three. I’m still pondering what to do about it. To put them back on the web would require a bit more work than just tossing them onto a server, and to make the quizzes fully functional would take yet more work, and after all this time some of the material is obsolete or even potentially misleading. Not to mention the page is laid out using a table (woo 1995!). On the other hand, they’d make an interesting historical document of sorts, a way to let you young whippersnappers know what it was like in the old days.

Reading through them, now sixteen years later, has been an interesting little trip down memory lane. What strikes me most, besides the fact that my younger self was a better writer than my current self, is how remarkably stable the Web’s fluidity has been over its lifetime. Yes, the absence of assuredly-repeatable layout is a core design principle, but it’s also the kind of thing that tends to get engineered away, particularly when designers and the public both get involved. Its persistence hints that it’s something valuable and even necessary. If I had to nominate one thing about the Web for the title of “Most Under-appreciated”, I think this would be it.

Many people have asked if the slides will be available. Indeed so: head on over to the session page, which I encourage attendees of the talk to visit so that you can leave a rating or comment on the session. The 5.4MB PDF of my Keynote slides is available there whether you attended or not.

While I was at the conference I was also interviewed by Mac Slocum on the topics of the HTML and Flash, and that’s been put up on YouTube along with interviews with Brady Forrest and Ge Wang (both of whom are awesome). I haven’t watched it so I don’t know how dorky I come off but I’ll bet it’s pretty dorky.

I indulged in a little good-natured ribbing of Adobe at the front of the interview (I kid because I love!) but the rest of it is, as best I recall, a decent distillation of my views. I’m hoping to get a few more detailed thoughts written and published here in the next week or two.

Many thanks to Brady Forrest and the entire Web 2.0 crew for having me on stage and getting me out to San Francisco. It’s always a great place to visit.

Why did I agree to participate? As much as I’d like to say “fat sacks of cash“, that wasn’t it at all. (Mostly due to the distinct lack of cash, sacked or otherwise. Sad face.) The contest’s entry requirements actually say it for me. In excerpted form:

• The entry MUST use one or more of the following technologies: Silverlight, Gestalt or HTML5…
• The entry MUST function in 3 or more of the following browsers: Internet Explorer, Firefox, Safari, Opera, or Chrome…
• The entry MAY use any of the following additional technology components…
  • CSS
  • JavaScript
  • XAML/XML
  • Ruby
  • Python
  • Text, Zip and Image files (e.g. png, jpg or gif)

Dig that: not only is the contest open to HTML 5 submissions, but it has to be cross-browser compatible. Okay, technically it only has to be three-out-of-five compatible, but still, that’s a great contest requirement. Also note that while IE is one of the five, it is not a required one of the five.

I imagine there will be a fair number of Silverlight and Gestalt entries, and I might look at them, but I’m really there—was really asked—because of the HTML 5 entries. By which I mean the open web entries, since any HTML 5 entry is also going to use CSS, JavaScript, and so on.

The downside here is that the contest ends in just one week, at 3pm U.S. Pacific time on 29 January. I know that time is tight, but if you’ve got a cool HTML 5-based application running around in your head, this just might be the time to let it out.

You might well say to yourself: “Self, is it just me, or are the people doing this completely off their everlovin’ rockers? Because the specification for something as fundamentally simple as HTML should reach maybe 200 pages, max.” You might even despair that the entire enterprise is doomed to failure precisely because nobody sane will ever sit down to read that entire doorstop.

But there’s no real reason to panic, because here’s the thing about the HTML5 specification that might not be obvious right away: it’s not for you. It’s for implementors. And that’s a good thing.

If you do start reading the HTML5 draft, you’ll start running into really lengthy, excruciatingly detailed algorithms for, say, parsing a time component. Or moving through the browser’s history. Or submitting a form. There’s an entire (long) chapter on how to process the HTML syntax.

Those are all good things, actually. They greatly increase the chances of interoperability actually happening within our lifetimes. There’s no guessing about, well, much of anything. It’s all been exactingly defined, to the extent that one can exactingly define anything using a human language. A browser team doesn’t have to wonder, or even guess, what to do when the document has been completely parsed. It’s all spelled out. And the people on those browser teams will, in the end, be the people who read that entire doorstop. (Their sanity is another matter, and not discussed here.)

How is all that stuff relevant to you, the author? In the sense that when browser teams follow the spec, their products will be interoperable, which is to say consistent. (Just imagine that for a moment.)

Beyond that, though, the detailed implementation stuff isn’t relevant to you. You are not expected to know all those algorithms in order to write HTML documents. Pretty much all you need to know is the markup. That’s the part that should be no more than 200 pages, yeah?

Turns out it is, and by a comfortable margin. Michael(tm) Smith’s HTML5: The Markup Language is a version of the HTML5 draft with all of those eye-wateringly pedantic implementor sections stripped out, and when I generated a PDF it came in at 147 pages. That’s what you really need in order to get up to speed on what’s in HTML5. It’s for you.

Then I received an invitation to join a small, in-person gathering of like-minded people, many of them just as confused and dispirited as I, to turn our collective focus to the situation and see what we found. I already had plans for the meeting’s scheduled dates. I altered the plans.

Over two long days, we poked and prodded and pounded on the HTML5 specification—doing our best to figure out what was meant by, and what would result from, this phrase or that example; trying to reconcile seemingly arbitrary design choices with what we knew of the web and its history and the stated goals of the HTML5 specification; puzzling over the implications of example code and detailed algorithms and non-normative notes.

In the end, we came away with a better understanding of what’s going on, and out of that arose some concerns and suggestions. But in the main, we felt much better about what’s going on in HTML5, and have now said so publicly.

Personally, there are two markup changes I’d like most to see:

1. The content model of footer should match that of header. As others have said, the English-language name of the footer element creates expectations about what it is and how it should work. As the spec now stands, most of those expectations will be wrong. To wit: if your page’s footer includes navigation links, and especially if you have an HTML5-structured “fat footer“, you can’t use footer to contain it.

   If this feels a little familiar, it should: the same problem happened with address, which was specified to mean only the contact information for the author of a page. It was quite explicitly specified to not accept mailing addresses. Of course, tons of people did just that, because they had an address and there was an address element, so of course they went together!

   A lot of us cringed every time this came up in the last ten years of conducting training, because it meant we’d have to spend a few minutes explaining that the meaning of the element’s name clashed with its technical design. We saw a lot of furrowed brows, rolled eyes, and derisively shaken heads. That will be magnified a millionfold with footer if things are allowed to stand as they are.

   As I said, the fix is simple: just change the content model of footer to state:

   Flow content, but with no header or footer element descendants.

   That’s exactly the same content model as header, and for the same reasons.

2. time needs to be less restrictive. That’s not very precise, I know. But as things stand now, you can only apply time to Gregorian datetimes, and you’re not supposed to use it for anything that couldn’t be easily represented in a calendaring program. The HTML5 specification says:

   The time element is not intended for encoding times for which a precise date or time cannot be established.

   That makes me wonder, in a manner not at all like Robert Plant, how precise do we have to be? The answer, I’m sorry to say, is too much.

   To pick an example: I have what I think of as a great use case for the time element, and while it uses the Gregorian calendar, it’s only accurate to whole months (as is Wikipedia’s version). In some cases I could get the values down to specific days; but in others, maybe not. So I can’t use the datetime attribute, which requires at least year-month-day, if not actual hours and minutes. I could omit the attribute, and just have this:

   <time>October 2007</time>
   

   In that case, the content has to be a valid date string in content—which is to say, a valid date string with optional whitespace. So that won’t work.

   I’ve pondered how best to tackle this, as did the Super Friends. Our suggestion is to allow bare year and month-day values as permitted in ISO8601. In addition, I think we should allow a valid date string to only require a year, with month, day, and time optional. That seems good enough as long as we’re going to go with the idea that the Gregorian calendar contains all the time we ever want to structure.

   But what about other, older dates, some of which are fairly precisely known within their own calendars? On that point, though the historian in me clamors for a fix, I’m uncertain as to what. PPK, on the other hand, has put alot of thought into this and written a piece that I have skimmed but never, perhaps ironically, found the time to read in its entirety.

These are not my only concerns, but they’re the big ones. For the rest, I concur with the hiccups guide, though of course to varying degrees. I’m still trying to decide how much I care (or don’t) about the subtle differences between article and section, for example, or the way aside fits (or doesn’t) with its cousin elements. And dialog just bugs me, but I’m not sure I have a better proposal, so I’ll leave it be for the time being.

At the other end of the two days, I felt a good deal more calm and hopeful than I did going in. As Jeffrey said, “the more I study the direction HTML5 is taking, the better I like it”. While there are still rough edges to be smoothed, there is time to smooth them. We’ve already seen responsiveness on some of the points we addressed in the hiccups guide, and discussions around others. The specification itself is daunting, especially to those who might remember the compact simplicity of the HTML2 spec. Fortunately, it has good internal cross-linking so that you can, with effort, track down exactly what’s meant by “valid date string with optional time” or “sectioning content” or “formatBlock candidate“.

With HTML5, the web is not ending, nor is it starting over. It’s evolving, slowly and in full view of the public, with an opportunity for anyone to have their say (which is not, of course, the same as having one’s proposals accepted). It’s the next step, and I feel quite a bit more confident that it’s a step onto solid ground.

You can get the details at the CW site, and note the special price for the first quarter of the seats. That’s right, this will be a small, intimate workshop, with plenty of chances for questions about and challenges to what I’m saying. Previous workshops have featured some really great conversations among everyone there, and I expect the same this time around.

I had meant to blog this before life intervened and took me out of my wifi cloud (and more on that soon), so time is a little more of the essence than usual—if you know someone who you think might be interested, pass the word on, willya? Thanks!

One of the things I’ll be talking about is the choice of markup language for the site, which ended up being HTML 5. In the beginning, I chose HTML 5 because I wanted to do something like this:

<li>
<a href="/2009/seattle/">
<h2><img src="/i/09/city-seattle.jpg" alt="Seattle" /></h2>
<h3>May 4—5, 2009</h3>
<p>Bell Harbor International Conference Center</p>
</a>
</li>

Yes, that’s legal in HTML 5, thanks to the work done by Bruce Lawson in response to my href-anywhere agitation. It isn’t what I’d consider ideal, structurally, but it’s close. It sure beats having to make the content of every element its own hyperlink, each one pointing at the exact same destination:

<li>
<h2><a href="/2009/seattle/"><img src="/i/09/city-seattle.jpg" alt="Seattle" /></a></h2>
<h3><a href="/2009/seattle/">May 4—5, 2009</a></h3>
<p><a href="/2009/seattle/">Bell Harbor International Conference Center</a></p>
</li>

I mean, that’s just dumb. Ideally, I could drop an href on the li instead of having to wrap an a element around the content, but baby steps. Baby steps.

So as Bruce discovered, pretty much all browsers will already let you wrap a elements around other stuff, so it got added to HTML 5. And when I tried it, it worked, clickably speaking. That is, all the elements I wrapped became part of one big hyperlink, which is what I wanted.

What I didn’t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link. Sometimes everything would lay out properly, and other times the bits and pieces were all over the place. I could (randomly) flip back and forth between the two just by repeatedly hitting reload. I thought maybe it was the heading elements that were causing problems, so I converted them all to classed paragraphs. Nope, same problems. So I converted them all to classed spans and that solved the problem. The layout became steady and stable.

I was happy to get the layout problems sorted out, obviously. Only, at that point, I wasn’t doing anything that required HTML 5. Wrapping classed spans in links in the place of other, more semantic elements? Yeah, that’s original. It’s just as original as the coding pattern of “slowly leaching away the document’s semantics in order to make it, at long last and after much swearing, consistently render as intended”. I’m sure one or two of you know what that’s like.

As a result, I could have gone back to XHTML 1.1 or even HTML 4.01 without incident. In fact, I almost did, but in the end I decided to stick with HTML 5. There were two main reasons.

1. First, AEA is all about the current state and near future of web design and development. HTML 5 is already here and in use, and its use will grow over time. We try to have the site embody the conference itself as much as possible, so using HTML 5 made some sense.

2. I wanted to try HTML 5 out for myself under field conditions, to get a sense of how similar or dissimilar it is to what’s gone before. Turns out the answers are “very much so” to the former and “frustratingly so” to the latter, assuming you’re familiar with XHTML. The major rules are pretty much all the same: mind your trailing slashes on empty elements, that kind of thing. But you know what the funniest thing about HTML 5 is? It’s the little differences. Like not permitting a value attribute on an image submit. That one came as a rather large surprise, and as a result our subscribe page is XHTML 1.0 Transitional instead of HTML 5. (Figuring out how to work around this in HTML 5 is on my post-launch list of things to do.)

   Oh, and we’re back to being case-insensitive. <P Class="note"> is just as valid as <p class="note">. Having already fought the Casing Wars once, this got a fractional shrug from me, but some people will probably be all excited that they can uppercase their element names again. I know I would’ve been, oh, six or seven years ago.

   Incidentally, I used validator.nu to check my work. It seemed the most up to date, but there’s no guarantee it’s perfectly accurate. Ged knows every other validator I’ve ever used has eventually been shown to be inaccurate in one or more ways.

I get the distinct impression that use of HTML 5 is going to cause equal parts of comfort (for the familiar parts) and eye-watering rage (for the apparently idiotic differences). Thus it would seem the HTML 5 Working Group is succeeding quite nicely at capturing the current state of browser behavior. Yay, I guess?

And then there was the part where I got really grumpy about not being able to nest a hyperlink element inside another hyperlink element… but that, like so many things referenced in this post, is a story for another day.

And then, after breakfast, I fired up my feed reader and saw Simon Willison‘s link to John Resig’s nascent Sizzle project.

I swear to Ged this is how it happened.

Personally, I can’t wait for Sizzle to be finished, because I’m absolutely going to use it and recommend its use far and wide. As far as I’m concerned, though, it’s a first step into a larger world.

Think about it: most of the browser development work these days seems to be going into JavaScript performance. Those engines are being overhauled and souped up and tuned and re-tuned to the point that performance is improving by orders of magnitude. Scanning the DOM tree and doing things to it, which used to be slow and difficult, is becoming lightning-fast and easy.

So why not write JS to implement multiple background-image support in all browsers? All that’s needed is to scan the CSS, find instances of multiple-image backgrounds, and then dynamically add divs, one per extra background image, to get the intended effect.

Just like that, you’ve used the browser’s JS to extend its CSS support. This approach advances standards support in browsers from the ground up, instead of waiting for the browser teams to do it for us.

I suspect that not quite everything in CSS3 will be amenable to this approach, but you might be surprised. Seems to me that you could do background sizing with some div-and-positioning tricks, and text-shadow could be supportable using a sIFR-like technique, though line breaks would be a bear to handle. RGBa and HSLa colors could be simulated with creative element reworking and opacity, and HSL itself could be (mostly?) supported in IE with HSL-to-RGB calculations. And so on.

There are two primary benefits here. The first is obvious: we can stop waiting around for browser makers to give us what we want, thanks to their efforts on JS engines, and start using the advanced CSS we’ve been hearing about for years. The second is that the process of finding out which parts of the spec work in the real world, and which fall down, will be greatly accelerated. If it turns out nobody uses (say) background-clip, even given its availability via a CSS/JS library, then that’s worth knowing.

What I wonder is whether the W3C could be convinced that two JavaScript libraries supporting a given CSS module would constitute “interoperable implementations”, and thus allow the specification to move forward on the process track. Or heck, what about considering a single library getting consistent support in two or more browsers as interoperable? There’s a chance here to jump-start the entire process, front to back.

It is true that browsers without JavaScript will not get the advanced CSS effects, but older browsers don’t get our current CSS, and we use it anyway. (Still older browsers don’t understand any CSS at all.) It’s the same problem we’ve always faced, and everyone will face it differently.

We don’t have to restrict this to CSS, either. As I showed with my href-anywhere demo, it’s possible to extend markup using JS. (No, not without breaking validation: you’d need a custom DTD for that. Hmmm.) So it would be possible to use JS to, say, add audio and video support to currently-available browsers, and even older browsers. All you’d have to do is convert the HTML5 element into HTML4 elements, dynamically writing out the needed attributes and so forth. It might not be a perfect 1:1 translation, but it would likely be serviceable—and would tear down some of the highest barriers to adoption.

There’s more to consider, as well: the ability to create our very own “standards”. Maybe you’ve always wanted a text-shake property, which jiggles the letters up and down randomly to look like the element got shaken up a bit. Call it -myCSS-text-shake or something else with a proper “vendor” prefix—we’re all vendors now, baby!—and go to town. Who knows? If a property or markup element or attribute suddenly takes off like wildfire, it might well make it into a specification. After all, the HTML 5 Working Group is now explicitly set up to prefer things which are implemented over things that are not. Perhaps the CSS Working Group would move in a similar direction, given a world where we were all experimenting with our own ideas and seeing the best ideas gain widespread adoption.

In the end, as I said in Chicago last week, the triumph of standards (specifically, the DOM standard) will permit us to push standards support forward now, and save some standards that are currently dying on the vine. All we have to do now is start pushing. Sizzle is a start. Who will take the next step, and the step after that?

I’m sure I could have written a more elegant script (and yes, I know, your favorite JS framework would done it in half the lines and seventeen times the page weight) and I suspect there are some things I’m missing. I’ll be interested to hear what those may be. Meanwhile, if you want to try out your own arbitrary-element linking, grab a copy of the demo and edit the markup to your heart’s content. Or you could suck out the JS and apply it to your own test pages. Your call.

The demo works fine in Firefox 2, Camino 1.5, Safari 2, and Opera 9.2. I didn’t test it in anything else. It may well fail spectacularly in every other browser known to man and dog. That’s not really an issue, though. The goal here is to have a working demonstration, not a universal solution. (The latter may come later.) It’s a handy way to show people how browsers should behave in an arbitrary-link world.

The one thing that didn’t go right is the status-bar URL handling when hovering over a linked element (other than an a element) that descends from another linked element. For some reason the descendant’s URL never shows up in the status bar. I’m sure there’s an easy fix. I regard this as a minor issue. [Update 7/23: this has been fixed thanks to Allwyn Fernandez.]

The biggest thing that’s missing is simulating “visited” styles on non-a elements; in this case, turning them purple. That would require mining the history and dynamically adding classes and, well, all kinds of stuff. I’m sure it’s possible. I’m also sure that I don’t have the time right now to figure out how to do it well. Besides, ship early, ship often, right?

As I said before, I’m very interested to know what people think of the demonstrated behavior and how it might be improved. And hey, if anyone wants to contribute improvements to the JS, I’ll do my best to keep up.

One more step toward a concrete proposal…

Thanks to comments on the previous post in the series, a few elements were added to the list of those which have plausible use cases, and I added some documentation of the elements that either aren’t on the list or don’t need to be on it at the end. Eventually, the “Possible Additions” section will disappear entirely, and at that point I’ll be ready to submit it for consideration to the Working Group.

There are a few outstanding questions raised by commenters on the previous post:

1. Is there a reasonable case for linking any of ul, ol, or dl? In cases where they represent quotations of other documents, they’re be wrapped in a blockquote anyway, and I’ve already got a use case for that one. Linking li makes sense, but the whole list? There are also questions about dd—would it make sense to allow linking to the paired dd?—but I don’t see a use case for dd. The whole point there is it’s supposed to be the definition, not a shortened reference to a longer definition.

2. I was persuaded of the utility of linking video, my previous uncertainty having been based in a misunderstanding of how click-this-video worked now, but what about audio? I haven’t noticed it being common to link embedded audio clips to other sources, but maybe I’m missing something.

3. Can a table have multiple thead, tbody, or tfoot elements? If so, linking them starts to make more sense. I only wish I could find the part of the HTML5 draft that answers this one way or the other. In a like vein, I can’t decide if it makes more sense to add linking to caption or table. I’m kind of tending toward the former. Anyone have good arguments either way?

4. Should embed and object have direct linking, or is that better handled with already-extant markup patterns? (If so, using param, I would imagine.)

5. Is there a reason to link a whole pre to some other resource, other than linking part of a program to a codebase? Because in those cases, I’d probably use the <pre><code>...</code></pre> pattern, and link the code element. pre is a presentational element, really, and you’ll note that I haven’t proposed adding linking to just about any of the presentation elements, sup and sub being the exceptions.

6. There’s a list of “(Possibly) Unsuitable Elements” near the end of the document that might bear some review in case I’m missing some obvious use cases. Obvious to someone other than me, I mean.

Let me know what you think! I’m definitely moving forward with this, as I’ve received encouragement from a member of the HTML WG, but I’d like the proposal to be as solid as possible before I do so. Thanks for everyone’s help!

After that comes a much longer section which presents reasons to add linkability to various elements in the HTML5 specification. I did not consider WebForms elements, but instead the list of 91 elements found in the primary list in Simon Pieters’ excellent HTML5 Elements and Attributes guide.

The important thing in that long list is not the exact mechanism I propose, but that I was able to find use cases for 30 HTML5 elements. Each one is described briefly and accompanied by one or two markup examples. Another 18 (listed at the end of the document) seemed initially to be good candidates, but I failed to find reasonable use cases for them. The remaining 43 elements weren’t even considered, since they all seemed to be obviously poor choices. One example is video, which would likely suffer if it were a hyperlink– resolving what to do when a user clicks on the video controls was completely unclear to me.

Now, as to why I’m blogging this instead of taking it to one or another of the relevant mailing lists: I’m looking for community input in order to strengthen the document. Did I miss any alternative solutions in that first section? Are there more pros and cons for the various alternatives? What use cases did I miss in that last list of 18; or, for that matter, what are some strong use cases for the list of 30 that I didn’t include? Are there any elements among the 43 I omitted that do, in fact, have strong use cases for being linkable?

I’ll do my best to keep up with comments. Have at it, folks!

Update 11 Jun 08: I’ve updated the document to incorporate ideas from commenters, and added a few extra bits of information at the end of the document. It’s worth another look, especially since I’ve gotten some semi-official encouragement to submit the proposal to the HTML Working Group.