New W3C working group to improve HTML

It has been almost seven years since HTML was last updated, and the general belief has been that it would be replaced by XHTML and never be updated again. That has now changed. In the blog post Reinventing HTML, W3C Director Tim Berners-Lee acknowledges that HTML needs to be kept alive and updated. Making people use XML failed, in large part because of overly forgiving Web browser software:

The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn’t work. The large HTML-generating public did not move, largely because the browsers didn’t complain.

Maybe getting the world to switch to valid HTML 4.01 Strict would have been a better, or at least easier, first step?

The W3C’s plan is to start a new HTML working group that will work on HTML and XHTML at the same time, making incremental updates to both.

It’s hard to tell if this is good or bad, and when we will see a new version of HTML. And after a new version (HTML 4.02? 4.1?) has been published there’s the long wait for browsers to catch up before it will have any practical influence on the daily lives of web developers. But at least it will mean something is happening.

So, what do we want from the next version of HTML? Just off the top of my head, here are a few things I’d like to see:

  • User agents should not be required (or even allowed) to render quotation marks around the content of q elements.
  • New attributes that will make forms easier to validate: required for input, textarea, and select elements, maxlength for textarea elements.
  • The list of allowed type attribute values for input elements extended with search.
  • A caption element that can be used to group an image with caption text.
  • The reappearance of the start and value attributes for ol and li elements respectively.
  • Stricter, XHTML-like syntax: make lowercase required for all element and attribute names, make quoted attribute values required, require all end tags that are currently optional.
  • The menu element brought out of deprecation.
  • Require user agents to render 5px wide borders around all cells in table elements that lack semantics (i.e. only consist of table, tr, and td elements).

Ok, that last one isn’t entirely serious, but it sure would reveal most layout tables pretty quickly.

Other voices on this:

What does everyone think? Is this good or bad? Does it matter? And what would you like to see in the next version of HTML?

Posted on October 30, 2006 in (X)HTML, Web Standards

Comments

  1. The reintroduction on the LH element. :)

  2. I agree that moving to HTML 4.01 Strict would be the best first move anyone could make… Oh well.

    I think the biggest question is whether/when the browser makers will even catch up to all current standards, let alone incorporate any new updates to the HTML spec.

    It’s nice to hear TBL saying that he wants to hear from web developers, but from what he’s said, it appears he’s only listening to a subset of developers and not looking at what many people are actually trying to accomplish.

  3. October 30, 2006 by Paul D

    “User agents should not be required (or even allowed) to render quotation marks around the content of q elements.”

    It seems to me that ideally, the default rendering of q elements includes quotation marks appropriate to the language and level of nesting. That way, if various bits of content are tagged with the right language, you don’t have to worry about making your own complex quotation styles; the browser will use the correct typography.

  4. Although it might be against the nature of the element, it would be nice to make input elements into block-level elements. That way, your form still looks good and will be (in my opinion) way more usable when CSS is turned off.

  5. The menu element brought out of deprecation.

    Totally agree on that, I don’t understand why it was depricated in the first place. In the concept spec of xhtml2 there will be a “new” tag: (navigation list) maybe a better name than menu?

    I’d also like to see Web forms 2 included.

  6. October 30, 2006 by Martin

    Re-inventing HTML in increments could be bad for web accessibility software to catch up quickly unless they are adaptable to HTML evolving quickly.

    If only HTML is a dictionary full of words (100,000 words including p and q) and therefore no more updates, all finished, final - we may be able to read web pages just like real documents!

    P.S. I’m just rambling on, so carry on :)

  7. If we did all of those things, it would sound more like an XHTML 1.2 to me than an HTML 5.

    Couldn’t they develop them in parallel? That is, the same feature set (I would kill for some stupid simple things, like a menu element or input type=”email”), but have HTML be the non-strict version and XHTML be the strict one?

  8. “Require user agents to render 5px wide borders around all cells in table elements that lack semantics.”

    Good one, Roger! :-)

  9. I have understood his announcement as giving incentives for switching to XHTML. Introduce a XHTML 2.0 feature like the role attribute as a XHTML 1.1 module. Continue to increment improvements step by step through XHTML 1.1 modules, such as allowing the href attribute on all elements. You see, if developers want the new and cool stuff, they have to switch to XHTML…

    Thus browser or screen reader vendors could implement functionalities one at a time. Firefox 1.5 and Window Eyes already support the role attribute. Why not enhance IE7 in such a way and ship the new functionality with another Windows update?

    These small steps are far better than working behind closed doors for several years on a new gigantic version of (X)HTML.

  10. I believe it’s good. At least, in theory. My son has got this quote on his MySpace page: “I want to move to Theory. Everything works in Theory.”

    I take sardonic amusement - after reading mail-lists and articles - in the reactions by most standardistas. They wanted W3C change; they got change but are not pleased. The W3C is far too byzantine to expect commonsense or miracles.

    I’m still curious about XHTML 1. WIll the W3C abandon it? And, if they do, will they offer an apology for introducing an obsolete markup language into the history files, e.g., HTML 3? which most new sites and progressive web developers use?

    I believe I’ll move to Theory.

  11. Not that I work on the W3C or anything but surely we should be happy to hear that things actually ARE happening…..

    Certainly while any developments should be good it is going to rely more on the UI developers to ensure that what they made is actually implemented quickly enough to be usable (as in proper XHTML sent as XML not text)

    But yay - at least people are talking about improvements; and I am sure they are listening to us too (at least some of us)

  12. I think I agree with Joe Clark in that HTML works the way it is. This might be a lack of imagination thing on my part, though. I can’t think of anything else I want to do that I can’t, except maybe an easy way to do column-based layouts with standards.

    That said, Joe’s suggestions for additional tags and block-in-block markup (esp. OLs in Ps) are reasonable. I like your suggestions except the stricter syntax. I like the idea of strict syntax if I’m writing the page. However, when someone else is writing the content, it gets frustrating. For example, I don’t have comments enabled on my site because I don’t want to deal with potential validation errors or certain tags that propagate down if they aren’t closed (e.g. Bs and Is and H*).

    So, maybe I do have an idea for a tag. It would be a tag that could hold “bad grammar” and not have any effect on the validation (sort of like a document.write from JavaScript) and would terminate all unclosed items at the end of the element (like TDs tend to do).

  13. The menu element brought out of deprecation.

    I would like to see that, I also don’t understand why it was deprecated.

    I would like to see an expansion of the type attribute on input elements. For input fields we currently have checkbox, password, radio and text. I’d like to see combo (optional text with a drop down list), date, time, email, int, long, unsigned, float, number, currency, url… While we’re at it, why not add, format, min, max and minlength attributes. Why should I do the validation, shouldn’t the browser do this for me?

    And most of all I like to see a standards compliant WYSIWYG editor for things like comments. That way I wouldn’t have to worry about a comment invalidating my page.

    What do you think?

  14. I like the “required” option on form elements. I would also extend that to include some content validation.. data=”numeric”, or data=”date”, or data=”alpha”

  15. After much soul-searching and deep throught, I’ve arrived at an opinion which I think many others will agree - the BLINK element needs to be returned to it’s former glory.

  16. October 30, 2006 by Benjamin Hawkes-Lewis

    Roger,

    User agents should not be required (or even allowed) to render quotation marks around the content of q elements.

    Do you think quotation punctuation should be generated purely by CSS? If user agents are not allowed to render quotation marks, what happens when there is no stylesheet or author stylesheets are disabled? And if you think punctuation is “content” and therefore should be added directly as text by the author, how do you propose to accommodate quotation punctuation that occurs on each new line of an inner nested quotation (for a discussion see Problem C in my query to W3C on CSS and quotation typography ). And if, like the current XHTML 2 specification, you think both text and CSS should be used, don’t you think that might make it a little difficult to parse reliably?

    The list of allowed type attribute values for input elements extended with search.

    I’ve got nothing against doing this; but can you explain how this would help? How does a search input differ from an ordinary text input?

    Stricter, XHTML-like syntax: make lowercase required for all element and attribute names, make quoted attribute values required, require all end tags that are currently optional.

    Why not just use XHTML? This will face some of the same compatibility issues that XHTML already faces, without actually being XML.

    Martin,

    Re-inventing HTML in increments could be bad for web accessibility software to catch up quickly unless they are adaptable to HTML evolving quickly.

    Assistive Technology doesn’t seem to adapt to HTML evolving slowly either. For example, JAWS seems not to support Q, introduced in HTML 3.2.

    Tanny O’Haley,

    And most of all I like to see a standards compliant WYSIWYG editor for things like comments. That way I wouldn’t have to worry about a comment invalidating my page.

    I think the whole notion of a WYSWIG editor for (X)HTML is fundamentally misconceived and leads to abominations like B (bold) buttons that generate STRONG elements. (X)HTML is not about what you see; it’s about what you think. Which is not to say end users ought to be faffing around with angle brackets and ampersands.

  17. Semantics or not is what we should care about. Forcing people to add slashes is just silly. Tim: STOP IT!

  18. User agents should not be required (or even allowed) to render quotation marks around the content of q elements.

    What about quotation marks for languages other than English? Should the browser not do this using the OS language settings?

  19. Punctuation is part of the content. Quote characters should be in the HTML whether markup indicates it’s a quote or not. Now stop arguing about it already! :P

    For what it’s worth, this standardista is actually very happy about the announcement. Especially the stuff about involving lots of stakeholders being involved in the process. There’ll be well equipped to deal with vampires, if nothing else. ;)

    Anyway, yay for W3C!

  20. October 31, 2006 by R. Mason

    I guess I don’t know my stuff. I thought XHTML was to replace HTML entirely and that HTML was “obsolete”. What will become of XHTML stuff like
    when using just HTML again?

  21. I agree with most of your suggestions, but I tend to lean more toward old-style html. I like the fact that I can leave off optional end tags. I also really like leaving quotes off of attribute values that are either numeric (size=12) or an enumeration (think the type attribute on the input element ). Not to mention that no matter what they do, my existing sgml tools can still process it. I also don’t like the insinuation that valid HTML is tag soup. There is a difference between HTML that conforms to a DTD and one that does not. Wow, I feel like I’m ranting now, but I’d like to see a lot of changes in the DTD area of HTML, better typing, etc. Ok, I’ll crawl back into my dark hole now.

  22. October 31, 2006 by Isaac Lin

    Paul, Dave, since the appropriate quotes to use are those following the conventions of language of the text doing the quoting, the author should know what types of quotes to use. In my opinion, the quotes used are part of the content and so should be in the text proper. To take another example, I wouldn’t want to have an “interrogation” element introduced that would contain questions with no terminating (or prefixing) punctuation, leaving it up to the browser to use language-specific conventions to fill in the appropriate interrogatory marks.

    Roger, though new attributes to support form validation would be nice, unfortunately it would not relieve the form handler of the responsibility to validate the data and send back appropriate error responses, both for security and to handle browsers that don’t understand the attributes. Of course having these kinds of attributes available will allow browsers to be enhanced to provide a better user interface for filling out forms.

  23. … after a new version (HTML 4.02? 4.1?)

    The next version of HTML will be known as HTML 5. By the way, XHTML 2.0 is a separate beast that needs to be slain (like HTML 3.0 was).

    New attributes that will make forms easier to validate: required for input, textarea, and select elements, maxlength for textarea elements.

    See Web Forms 2.0. Those and more are already included and mostly supported by Opera 9.

    The list of allowed type attribute values for input elements extended with search.

    I disagree. A search feild is just a text box, not a different control. However, clearly identifying the search form could be useful for accessibility. Could you elaborate on the specific use cases for it, why it would be useful and what benefits it provides to users?

    A caption element that can be used to group an image with caption text.

    This has already been discussed and will be added. The difficulty is in working out exacly how to so. There are practical problems with just using the caption element outside of table elements, since they don’t appear in the DOM in current browsers.

    The reappearance of the start and value attributes for ol and li elements respectively.

    These are already included in HTML 5. See the ol element and li element.

    Stricter, XHTML-like syntax: make lowercase required for all element and attribute names, make quoted attribute values required, require all end tags that are currently optional.

    For HTML 5, there will both HTML and XML serialisations available. The HTML serialisation must be served as text/html and the XML serialisation must be served using an XML MIME type like application/xml or application/xhtml+xml.

    For authors that choose the HTML serialisation, the syntax is inspired by HTML 4, but is no longer considered an application of SGML. For the XML serialisation, known as “XHTML 5”, XML rules apply. Using XML-only syntax (e.g. for empty elements) in the HTML serialisation will be forbidden.

    The menu element brought out of deprecation.

    The menu element is already back in HTML 5 and is being given a serious face lift.

    Require user agents to render 5px wide borders around all cells in table elements that lack semantics (i.e. only consist of table, tr, and td elements).

    LOL! That would certainly be a way to stop people using tables for layout! :-)

    Other voices on this:

    My response to Joe Clark.

    trovster wrote:

    The reintroduction on the LH element. :)

    What’s the specific use case? Why would this be useful and what benefits does it provide? I’m not saying it wouldn’t be, but we need to know that kind of information before introducing any new element.

    Martin wrote:

    Re-inventing HTML in increments could be bad for web accessibility software to catch up quickly unless they are adaptable to HTML evolving quickly.

    I don’t understand what you mean. It will be quicker for accessibility tools to implement incremental improvements to HTML, than to implement a whole new, non-backwards compatible language like XHTML 2.0. HTML needs to improve and the incrmental approach is best.

    Martin Kliehm wrote:

    Introduce a XHTML 2.0 feature like the role attribute as a XHTML 1.1 module.

    See the XHTML Role Attribute Modele.

    allowing the href attribute on all elements.

    The problem with doing that is that it isn’t backwards compatible and browser vendors have concerns about implementation difficulty.

    You see, if developers want the new and cool stuff, they have to switch to XHTML…

    No, that is not true in HTML 5. (see above statements about the HTML and XML serialisation)

    RB wrote:

    I can’t think of anything else I want to do that I can’t, except maybe an easy way to do column-based layouts with standards.

    See the CSS3 Layout module and XBL 2.0. Both of these will provide mechanisms for that, and I’ll be covering XBL Templates on my blog shortly in my series on XBL.

    Alan wrote:

    but I’d like to see a lot of changes in the DTD area of HTML

    DTDs are considered obsolete due to their limitations and the fact that HTML 5 is no longer an application of SGML. There will not be an official DTD for HTML 5, but rather more rigourous conformance requirements and much more useful conformance checkers.

  24. The menu tag is much more semantic than using plain old unordered or ordered lists. I agree Roger, I hope they bring it out of deprecation.

    However, I don’t know that I agree with the expansion of the type attribute for input tags. It would definitely be useful for Javascripting, but IMO it would also encourage developers to leave validation to the browser, and forego validation on the server-side, where it is really necessary.

  25. Lachlan Hunt wrote:

    This has already been discussed and will be added. The difficulty is in working out exacly how to so. There are practical problems with just using the caption element outside of table elements, since they don’t appear in the DOM in current browsers.

    I thought I heard a long time ago that img was going to be dumped for object. (I might be dead wrong, though.) That would allow long descriptions to be encapsulated between the object tags. I’m not sure about backwards compatibility, but I’d love to see something like that employed with the img tag, now that I think about it. It’d be much more manageable than the longdesc attribute.

    I’m not sure if the original intent of the idea for the caption element was for accessibility or ease-of-use, though. If it was for the latter, then my idea is bunk unless the :after content could make use of it…

  26. October 31, 2006 by Roger Johansson (Author comment)

    Neil:

    I think the biggest question is whether/when the browser makers will even catch up to all current standards

    Yes, it’s quite astonishing that browser makers haven’t bothered to implement full support for HTML 4.01.

    Paul D, Benjamin, Dave: Ben and Isaac explained the problem with browsers rendering quotation marks - they are part of the content, just like other punctuation.

    Tanny:

    While we’re at it, why not add, format, min, max and minlength attributes. Why should I do the validation, shouldn’t the browser do this for me?

    Yes, I just mentioned the first few form element additions that came to mind. Having the browser automatically do client-side validation would be a great help. As others have mentioned you would still have to validate incoming data on the server though.

    And most of all I like to see a standards compliant WYSIWYG editor for things like comments. That way I wouldn’t have to worry about a comment invalidating my page.

    I would love that too. I’m not so sure that’s the W3C’s job though. They produce the specs, and somebody else can create an editor whose output conforms to those specs.

    MojoMark: Good suggestions.

    Phil: Don’t forget about marguee!

    Benjamin, Lachlan:

    Adding a search type input field is perhaps not really all that useful. After reading your comments I started thinking, and no, I can’t really give you an example of when it would help. So you can take that one off my list ;-).

    Benjamin:

    Why not just use XHTML? This will face some of the same compatibility issues that XHTML already faces, without actually being XML.

    Because it would encourage authors to write better markup without having to get into the debate about XHTML served as application/xhtml+xml or text/html.

    Isaac:

    Roger, though new attributes to support form validation would be nice, unfortunately it would not relieve the form handler of the responsibility to validate the data and send back appropriate error responses

    Of course not, but as you mention it would relieve us of a lot of time consuming JavaScripting.

    Lachlan:

    The next version of HTML will be known as HTML 5.

    The W3C HTML or the WHAT WG HTML? ;-)

  27. November 1, 2006 by Benjamin Hawkes-Lewis

    Roger,

    Ben and Isaac explained the problem with browsers rendering quotation marks - they are part of the content, just like other punctuation.

    I fear this is an unsustainable position from both a pragmatic and a theoretical perspective. I’ve already pointed out a very serious and unaddressed practical problem (punctuation recurring at the beginning of each line), so if you can forgive my dwelling on this point I’d like to look at the philosophical underpinnings and ask why such punctuation should be considered “part of the content”.

    A paragraph remains a paragraph whether it is visually represented by a new line that is indented, a new line with extra leading, or an actual pilcrow; or whether it is aurally represented by pause, or a change of voice, or the spoken words “new paragraph”. There is thus a difference between the essential idea of a paragraph and its presentation, and the same goes for unordered list items, questions, exclamations, and quotations.

    Now some of these ideas happen to be mapped, however imperfectly, by HTML, as with paragraphs, unordered list items, and quotations, and some are not, as with questions and exclamations. Ideas that are not represented by the markup language must be intuited through a deep knowledge of the language and culture of the non-markup content. Such intuition is subjective, error-prone, and hard to automate.

    But when such ideas are mapped, we are generally content to rely on user agents to represent them clearly, with the odd CSS tweak. Can you recall anyone insisting that their particular representation of paragraphs or unordered lists is “part of the content”? And if you can, were you persuaded?

    Q is the odd one out, with people insisting either that the element itself is superfluous or that quotations should be doubly implied in an HTML document - once clearly by the markup and once ambiguously by in-markup punctuation. This contention seems to be premised on an assumption that quotation punctuation is relatively fixed, like (say) question punctuation, when in fact it is closer to bullets in its variety and ephemerality.

    Consider the case of quotation punctuation in British English. If you quote material that itself includes a quotation, do you faithfully preserve the quotation punctuation present in the source as if it were content? No, on the contrary it is traditional to replace the original punctuation with quotation marks that match the language and style of the host document.

    Most publishers stipulate the use of single quotation marks for outer quotations and double quotation marks for inner quotations, but some publishers do the opposite. When an author is republished by a new publisher, while her full stops and commas and question marks and exclamation marks and semicolons are generally reproduced, are her quotation marks carefully preserved too? No, on the contrary her quotation punctuation is typically revised in line with the publishers’ house rules.

    Moreover, most publishers dispense with quotation marks altogether when an inline quotation grows beyond an arbitrary short length, say 50 or 60 words, and turn it into a “displayed quotation”. (Unlike the Q/BLOCKQUOTE distinction in HTML such style rules have nothing to do with whether the quotation includes paragraphs.)

    Given that printed media take such liberties with quotation punctuation, how can we possibly maintain that any particular form of quotation styling is an intrinsic part of the content, except in cases where the typography is itself essential content? And in such cases, aren’t SVG or PDF more appropriate formats than HTML?

    The idea of quotation is universal, but its traditional presentations often obfuscate as much as they reveal. There would be nothing intrinsically wrong with a document viewer that chose to disambiguate all quotations in a uniform manner. It would be handy when dealing with languages that sometimes omit quotation punctuation altogether, as with Turkish and could help circumvent the conflation of source and host material by style rules that bring punctuation belonging to the host sentence within the quotation punctuation, as is common in US English.

  28. Roger, by all accounts, the work going on at the WHATWG will probably be a joint effort between them and the W3C. That work will be known as HTML 5. The W3C will apparently also have a separate XHTML 2.0 working group, though I’m not sure why, nor how much integration there will be between the 2 groups.

    Regarding the type=”search” idea, I found out that Safari has already implemented it with some nice features.

    Another feature I found, which is commonly simulated using JS in search fields, is the placeholder attribute, which is used to provide text like “Enter search” or “Google” or whatever default text should be rendered in the field. That feature is commonly implemented using JS to clear the text field onfocus. That attribute is not present in the current draft, but is planned for Web Forms 3.0. Try this out in Safari.

    <input type="search" placeholder="Search">
    

    The placeholder attribute also works for text and password fields as well.

  29. November 1, 2006 by Roger Johansson (Author comment)

    Benjamin: Your arguments seem very good. Let me think about it for a bit. I may end up agreeing with you after all.

    Lachlan: Safari’s implementation of type=”search” is where I got the idea. It renders the search field in a visually distinct manner, making it very clear that it is a search field and not an ordinary text input.

  30. IMHO, all deprecated elements should be dropped from the Transitional DTD, which can be allowed to keep its unclosed elements. Then the only difference between Transitional and Strict will be whether or not closed elements are required like in XHTML.

    Death to the font element!

  31. November 1, 2006 by Isaac Lin

    I agree there is a practical problem with identifying contents that need to have a prefix at the start of each line that may need semantic support to assist.

    From an author’s point of view, I believe the choice of how to punctuate forms part of the message being conveyed and so is part of content.

    I can see that from an automated text processing point of view, allowing the punctuation transformations to be done automatically would facilitate the arbitrary quotation of text, particularly across languages. However, I see difficulties in trying to define appropriate algorithms without having to resort to marking up every sentence. For example, how should the following sentences be marked up unambiguously?

    “I’m hungry,” Tom explained.

    “So am I.” Mary sighed.

    Without marking up each sentence, the following would seem appropriate, but cannot determine if the two components in each line form part of the same thought or are two separate thoughts:

    [q]I’m hungry.[/q] Tom explained.

    [q]So am I.[/q] Mary sighed.

    From a practical perspective, until the time when punctuation algorithms can be described in the style sheet for a document that will handle all of the required changes (including moving of punctuation within quotation marks, transformations of periods to commas, possibly a literal mode to be used for clarity in user documentation, and nested quotations), the advantages of a simplistic algorithm (i.e. rendering quotation marks around the quoted element) may not be important enough, particularly if the markup will have to change anyways when more complex algorithms are available.

  32. November 8, 2006 by ptrdo

    Lest we forget, the quaint <object> tag could use refreshment.

  33. November 9, 2006 by Dream Maker

    Why are we making the web browser and the document markup language the center of everything? Is it not possible to have a web browser just that a web browser, why does it have to be a self-contained computing environment. Most of the things that get done within that space are only a security problem anyway, it is the route into computers by which most viruses and malware enter.

    We have moved over from using tables to layout our content and this would have been a good thing, if only the replacement mechanism in the CSS system was a capable as that of the original tables. Consider an example, with tables it was simple to place text so that it would always be at the bottom of the browser window if the content was smaller than a single browser windows worth. With the CSS system this easy system was removed and we are left with a nightmare of hacked programming and tricks to give the same result. How was that a step forward?

    It is important that when we create new tags and make things ‘better’ that there is genuine improvement and that things that are commonly done are still done. Was it an abuse to use tables for layout, of course, but it was the best solution at the time and the replacement was not ready for prime time, yes was supposedly ‘the best’ way of doing things and was considered best practice. Yet, how can it be best practice when it requires kludges.

    When making changes to the standards, it MUST be easily possible to do all the things that are currently done in a clean and simple manner, the goal should be increased efficiency for the designer and the renderer, if this is not happening then the solution must be rethought. Most people do not care about simple tag design, they have to use the tags in the real world day in day out, and this is where the efficiency arises.

    Have a clean slate, mandate the exact spec and have the browser makers sign up and adopt it. Stop trying to make a one size pleases all solution which is compatible with html 0.9.

  34. I want a new rel-attribute or some kind of other technique that says: “Hide me from screen layout but tell screenreaders that I’m important”. Some way to avoid “display: none;” when I want to hide something from the actual CSS layout. I’m fed up with HTML-classes like “hideme” or “screenreadersonly”.

  35. November 16, 2006 by S. Marshall

    Require user agents to render 5px wide borders around all cells in table elements that lack semantics (i.e. only consist of table, tr, and td elements).

    Honestly, I think this is an excellent idea. And in my opinion, I think that most of the angry responses to this change would be a direct result of human nature. To be specific, our natural anxiety and resistance to change in general.

  36. Gerrit, I’m sure that’s already possible using the aural media type.

  37. Nope. Not for plain text. (You can, however, queue an audio file.)

    See http://www.w3.org/TR/REC-CSS2/aural.html or http://www.w3schools.com/css/cssrefaural.asp.

  38. Ya know what I would love in HTML forms? A “restrict” attribute (or something) on inputs, etc. to limit the characters they would accept. That way zip codes, for example, could accept only numbers and dashes, or phone numbers similarly, or user names, etc. There would be all sorts of great applications for that.

    Something helpful and kind of similar (but that I would hardly expect to happen) would be the ability to limit the filetype or file extension that file inputs would accept.

  39. The menu tag is much more semantic than using plain old unordered or ordered lists. I agree Roger, I hope they bring it out of deprecation.

    However, I don’t know that I agree with the expansion of the type attribute for input tags. It would definitely be useful for Javascripting, but IMO it would also encourage developers to leave validation to the browser, and forego validation on the server-side, where it is really necessary.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.