Nine Into Five

Published 15 years, 1 month past

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.

Comments (21)

  1. Well said Eric.

  2. Great post.

    Although I’ve spent more time poking fun at the process of HTML5 rather than the substance, some aspects of it have had me concerned.

    The main one was in fact, footer. I’ve personally ran into the issues with the footer element several times already and was frustrated by it’s apparent intended use versus what an average designer would want from it. I think your proposed solution is a great one to help it’s function match the expectations.

    And yes, the time element has been bothering me as well.

    It’s comforting to hear that a band of talented experts in the “author” category (as the W3C names such things) have examined HTML5 and determined that by and large it’s a good thing. Hopefully your recommendations will be accepted to help streamline those hiccups that exist.

    Also, Super Friends? Awesome.

  3. I am normally a person who feels very strongly in following standards (with exceptions for adding things such as ARIA where I believe we are just in a state where we have not yet figured out how one should indicate this to validators). But I am firmly opposed to the current definition of footer. My believe is that it is so backwards that it will be misused so much that ANY user agent will have to also accept the definition proposed here. I do not believe that the current method is going to last so I am designing my sites with footers at the bottom of pages with an id of footer. All my style rules are applied to #footer. If the definition changes then great, I don’t need to do anything else. If not then all I’ll need to do is swap the footer element to a div and it’ll work exactly the same.

    Another disagreement: headers. I understand what they’re trying to get across. I think for coding by hand they are great. But how the heck am I supposed to manage a CMS that way? I’m putting the editable areas inside of a section, but they are obviously going to want to do their own headers and thus it’s h1-h6 to the rescue. There is absolutely no way a CMS could be designed to insert sections and make it just-work for a small business using the CMS to manage their Web site which is secondary to their primary job.

    In regards to the Super Friends: which one of you is Gleek, and who are the Wonder Twins? :)

  4. “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.”

    “the more I study the direction HTML5 is taking, the better I like it”.

    “The specification itself is daunting, especially to those who might remember the compact simplicity of the HTML2 spec.”

    Reply:
    I think you had it right the first time. Hasn’t anybody noticed that complexity is a bad thing? With something _this_ complicated it takes stupendous effort to get almost _anything_ right.

    And the reason is not so difficult to discover. Right now someone is typing a response in defense of gratuitous complexity.

  5. Another possibility for time would be to add an optional scope attribute. (y|m|d|h|m|s).

    As for complexity, I’m reminded of a few things…

    First lies the issue of what will actually be implemented. If HTML5 is anything like HTML4, there are parts that will be neglected. This begs concern about the question of vendor buy-in.

    Then there’s the question of necessity in opposition to capability. In the absence of forms I can limit the working markup vocabulary of a site to roughly 20 elements without running too far afoul of best practices. Ideally users of HTML5 would also be in a position to settle for a basic vocabulary.

    On the other hand, there’s the question of being careful what you wish for. Excellent though microformats may be, they are really just a clever process hack that wouldn’t be necessary if we had a mechanism for quickly anticipating, extending, and supporting the namespace of HTML. In the meantime, we have the kitchen sink.

  6. A bit of a tangent, but is HTML5 basically adding more structural elements to the markup and basically trying to standardize the way in which we typically use CSS markup together with class attributes? I know a lot of interesting goodness can be brought about by a standardized semantic dictionary (in HTML5) as opposed to per-site customization (via CSS and attributes), but at what point is HTML trying to just do too much?

    With early HTML, we already saw the complete breakage of the design via developers who favored ease of implementation over sticking to the rules, which then triggered the browsers to have to be more lenient and “quirky”. It worked it you did it right, but also worked even if you didn’t.

    Is HTML5 trying to design itself in a way where HTML6 will not be a necessity? Making a play for the end game in web content structure? Or if css is still a necessary “evil”, then isn’t all the semantics of markup definitions and usage wasted if people just wont bother to comply with the overtly complex rules?

  7. I hope that when you remember the comparative simplicity of HTML2-4 you keep in mind that that simplicity was achieved by omitting most of the details needed to achieve interoperability.

  8. I’m particularly thrilled that this group took on the task to get together and do what you all did. Many thanks from those of us expecting to learn loads in the coming months and years (yet do not have the opportunity to do deep dives into the spec). We look forward to great usage examples as the spec emerges into being.

    And I really like the color blue of that t-shirt you were wearing.

  9. I’d thought of a scoping attribute as well, Ben, but I’m not sure that’s really the right answer. Maybe it is. I think just loosening up the value restrictions would be enough.

    Robert, I do have that very much in mind, and that will probably be the subject of my next post.

    Thanks, Bob. My wife really likes that shirt, too.

  10. Robert, yeah, OK, maybe. But just once I’d like to read that something got simpler. When I see someone write that his head is “reeling from the massive length and depth of the often-changing specification”, that’s a big red flag. I believe him.

  11. Please don’t forget to actually send your feedback to one of the lists, or to use the bug reporting widget on the spec itself, or to e-mail me directly with the feedback. Feedback in blogs gets lost easily and is hard to directly respond to.

  12. “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.”

    Is the address element as currently specified in HTML 5 an improvement?

  13. Complexity in designing something from scratch as a bad thing is a commonly understood part of design process. But HTML5 is not from scratch. It represents everything that HTML as a mark-up language up to this point is capable of, and extends it into richer territory.

    The specification does not just serve us web developers as page authors. It serves the browser vendors — _any_ browser vendor, now and in the future — in building a rendering engine that behaves compatibly with the open web. That is a complex problem, and requires depth and precision in specification to be achievable. The process is made harder because a lot of this detail work was never produced for features of HTML3 and HTML4, so it’s happening now.

    The way I would expect this to play out is as follows: The HTML5 specification as a single document will not be the document that serves front-end developers directly. It won’t be the go-to reference in the way that HTML4.01 is. Once HTML5 is stable (perhaps when it reaches Last Call in October) separate, companion documents will be produced. “HTML5 for Content Authors”, you might call it. It will cover the content of HTML5 at the correct depth and breadth for developers.

    I think a lot of people are concerned that the huge HTML5 spec is going to be their only reference. It won’t be. Either from the working group itself or from enterprising others, audience-focused but no-less accurate reference works will come. But, you must understand, such documents cannot be produced accurately or in an efficient use of the author’s time until HTML5 itself is stable. For now, whilst HTML5 is still in active development, it is necessary that you go to the extra effort — as the HTML5 Super Friends have done — to consume a spec that is in part “not for you”.

    Kudos to those who do take the time.

  14. I”d thought of a scoping attribute as well, Ben, but I”m not sure that”s really the right answer. Maybe it is.

    Why do you think this isn’t the right answer? Just want to hear what you’ve been thinking.

    I’ve been mulling over time this week, and the one thing I keep coming back to is that ISO 8601 and RFC 3339 are tuned to handle hyper-specific points in time (down to the millisecond with RFC 3339). RFC 2445, from which iCalendar and hCal follow, uses ISO 8601 to define machine-readable dates and times.

    So I’ve been left wondering if we’re at cross-purposes with time. The HTML5 spec wants it to work for calendaring, where minute-level accuracy would be important. The general community wants a tag to semantic mark up specific dates, even if they’re these general dates (or even those pesky estimations, like “c.1000”). But if we’re being governed by these ISOs and RFCs around dates, those general dates just don’t work. We’d either need to revise ISO 8601 to take non-specific dates, or we’d need to kludge something from the patterns encased in ISO 8601 and hope that the calendaring programs would know what to do with them (or just ignore them).

    I worry, like with calendar, this is going to be a completely misunderstood tag. time will either need a very specific definition (i.e. only for calendaring) or a very open one (i.e. open to months/years/ranges), and each definition appears to contraindicate one of the two possible usages.

  15. dw, I think my dubiousness about a scoping attribute has to do with what you lay out: that the general community is more likely to want to use the time element for any measure of time, no matter how (im)precise it might be. People will assume it goes around “Seven minutes ago” as well as “March 7th, 1967, 10:27:31am EST”. It’s easy to scope the latter, but not the former.

  16. Steve: it’s no different as of right now. This doesn’t surprise me, actually, nor does it very much concern me. The element’s been around forever. It’s the new stuff coming up that I’d like to get right, so we don’t revisit the same ground.

  17. Couple of minor typo’s/mistakes in the super friends guide itself, if you’re interested:

    The yellow bit, the sentence of ‘Proposed Solution’ in the ‘Review of Data Section’ reads ‘If that is the body than the footer is secondary content to the document as a whole.’ and should probably read ‘If that is the body, then the footer is secondary content to the document as a whole.’

    The first sentence of the last paragraph ‘ABSENT ELEMENTS AND ATTRIBUTES’ reads ‘….even if their loss makes some us feel rather….’ and probably should read ‘…even if their loss makes some of us feel rather…’

    Thanks,
    Dunc

  18. Pingback ::

    HTML5 Redefines Footer – Jeffrey Zeldman Presents The Daily Report

    […] Meyerweb: Nine Into Five […]

  19. The proprietor writes:

    It”s easy to scope the latter, but not the former.

    …But the latter can and should be stored as a precise datum, because in all likelihood its apparent format will be implemented programmatically.

    Of greater concern to me are ranges and approximate timestamps — to the extent that I share your skepticism, it’s because I’m not entirely certain that those use cases can be easily contained within the value of a single attribute.

  20. Pingback ::

    HTML5 in the News - withoutnations - Mark Mitchell

    […] Nine into Five, Eric Meyer […]

  21. From my understanding HTML5 is still in its drafting stages. Will these discrepancies be worked out in the future? Also, what will HTML5 mean for browser compatibility in web design? There needs to be a markup that is universal.

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>

if you’re satisfied with it.

Comment Preview