meyerweb.com

Yesterday, Brandy Fortune asked me on Twitter if there are “any major sites written in HTML 5 now“. I decided to throw the question to my Twitter gang, and was of course immediately deluged in answers. Also a small helping of standards politics, which wasn’t really what I was after but probably should have known was inevitable. Le sigh.

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.

I recently became re-acquainted with a ghost, and it looked very, very familiar. In the spring of 1995, just over a year into my first Web gig and still just over a year away from first encountering CSS, I wrote the following:

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.

Earlier this week I presented a talk at the Web 2.0 Expo titled “HTML5 vs. Flash: Webpocalypse Now?” which seemed to be pretty well received. That might be because I did my best to be unbiased about the situation both now and into the future, and also that the audience was very heavily weighted toward web stack practitioners. Seriously, out of 100-150 audience members, about six raised their hand when I asked who was developing with Flash.

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.

I was recently honored to be asked to be a judge for the MIX 10k Smart Coding Challenge, running in conjunction with Microsoft’s MIX conference. The idea is to create a really great web application that totals no more than 10KB in its unzipped state.

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.

I mentioned in my previous post that I “had come away with my head reeling from the massive length and depth of the often-changing specification”, which is entirely true. Printouts of the current draft of the HTML5 spec can reach, depending on your operating system and installed fonts, somewhere north of 900 pages. Yes: nine hundred. There are unabridged Stephen King novels that run shorter.

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.

Like so many others, I had tried to dig into the meat of HTML5 and figure out just what the heck was going on. Like so many others, I had come away with my head reeling from the massive length and depth of the often-changing specification, unsure of the real meaning of much of what I had read. And like so many others, I had gone to read the commentary surrounding HTML5 and come away deeply dispirited by the confusion, cross-claims, and rancor I found.

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.

Hey all, and especially those of you in the EU: I’m going to be doing an all-new one-day workshop in London in early March via the offices of Carson Workshops, for whom I’ve done workshops in the past. Previously I’ve done two-day gigs with a beginner-to-intermediate skill range, but this time we’re trying something different. I’m going to get down and dirty with some tough topics, and really push hard at the limits of what CSS and semantic markup can do.

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!

The new Gregorian year has brought a striking new Big Z design to An Event Apart, along with the detailed schedule for our first show and the opening of registration for all four shows of the year. Jeffrey has written a bit about the thinking that went into the design already, and I expect more to come. If you want all the juicy details, he’ll be talking about it at AEA, as a glance at the top of the Seattle schedule will tell you. And right after that? An hour of me talking about coding the design he created.

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.