Have your say about the future of HTML

This article has been written on behalf of the Web Hypertext Application Technology Working Group (WHATWG) and has been cross posted on The Web Standards Project, Lachy’s Log, Molly.com and 456 Berea Street.

There’s been a lot of discussion about the W3C’s recent decision to continue the development of HTML around the web lately. Blog posts, and messages sent to mailing lists and posted on forums, revealed many questions and misconceptions about the future of HTML (including HTML 5 and XHTML 2), the WHATWG and the W3C’s new HTML Working Group.

Some people asked for new features; others were wondering if formerly deprecated elements would return; some had comments and criticisms about the decision itself, the WHATWG or W3C process; and a few raised concerns about the WHATWG and W3C ignoring the needs of particular groups. The WHATWG, who are in the process of developing the next version of HTML (called HTML 5), feel that it’s important to not only listen to all of this feedback, but to actively seek it out and respond so that we can develop a language that meets your needs.

There are many ways in which you can participate. The most direct approach is to make your voice heard by subscribing to the mailing list. However, not everyone has the time to participate or keep up with the high volume of messages sent to that list. Some people feel that the current drafts of HTML 5 (Web Applications and Web Forms) are rather daunting. Others feel that because they can’t afford the substantial W3C membership fees, they wouldn’t be listened to anyway.

If, for any reason, you feel that you either cannot participate, or would be uncomfortable in doing so, that certainly doesn’t mean you shouldn’t be heard. The WHATWG needs to hear from you and wants to know what you think about HTML.

  • Are there any limitations with HTML that you would like to see fixed?
  • Do you have any ideas for new features?
  • Is there anything you can do now in HTML, but would like to see improved?
  • Do you have any concerns about the development process?
  • Do you have any feedback about the new features in the current drafts?
  • Do you have any questions about HTML 5?

Any questions, comments, criticisms, complaints or feature requests are welcome. Now is the time to speak up. No comment is too dumb; no question is too hard or too simple; no criticism is too harsh. If you have anything at all to say, we are listening.

Please leave a comment or post a link to an article you have written. You will be heard and we will try to respond.

Posted on November 7, 2006 in (X)HTML

Comments

  1. November 7, 2006 by Jeff Cutsinger

    Just wanted to say: great work with HTML 5 and Web Forms 2.0. I think I’d be happy just having those implemented.

  2. Thanks for posting this.

  3. November 7, 2006 by literary_user

    Well, I would like to see some standard solutions for marking up poems and other literary texts in a semantically rich way. There should be other ways than using <pre>.

  4. Who has written this article? All the ones that posted it? Or the WHATWG?

  5. Robert, the article was written by Roger, Molly and I, and reviewed/approved by Ian Hickson.

  6. Lachlan,

    Thank you. It wasn’t that clear.

  7. I guess my main concern is what is going to happen with the continued divergence between HTML 5 and XHTML 2. If HTML 5 is to become the new de-facto standard, then I’d like to see XHTML 2 abandoned. It really doesn’t matter to me either way, but it would be nice if in this era of Web Standards if we actually standardized around one or the other. :)

  8. I would like to see a means of making semantics scalable and allowing user innovation within a universal framework. Difficult I know!

    This for me is the major limitation of (X)HTML at the moment. Modular semantics is nigh on impossible. Microformats have gone some way to addressing this but it could go further I think.

    HTML works very well for documents but we are now beginning to see scenarios where HTML can effectively be used as an API. This is very exciing and I would like to see (X)HTML use modular semantics to support and enhance this innovation.

  9. I’m in two minds about what I’d like from HTML 5.

    On the one hand, doing something like CSS 2.1 where you clarify what the original spec meant, update it to reflect current implementations and maybe extend it a little. That would useful for authors and implementers and maybe could be done quite fast.

    This would be more like HTML 4.1 rather than HTML 5, though.

    On the other hand, a big step forward with the markup like the one from HTML 3.2 to HTML 4.0 would help to provide a standard framework for current and near-future innovations. It could also include better user agent conformance guidelines so the new markup would be more interoperable for the next generation of browsers and be more future-proof.

    This is my understanding of what the WHAT WG’s HTML 5 project is intended to be.

    Given the Web API activity taking place at W3C, I think the latter approach to HTML makes more sense.

    My only worry is that the new HTML WG will become so blinkered with their own vision of what the next HTML should accomplish that it won’t reflect the needs of real authors and real implementers. But given TBL’s statements about avoiding that this time around and this new outreach initiative, my feeling is things will probably turn out alright. :)

  10. I agree with George’s comment about “modular semantics.”

    It’s great that there are standard sets of tags and standard ways of styling them…but what about standard ways of USING them? A progression of Microformat-support nudged along by a new spec would be wonderful.

    It’d also be nice to have some clear, concise documentation for the new standards — documentation that any Dreamweaver-idiot can read, understand, and use.

  11. My article written days ago: http://www.revolucao.etc.br/archives/reinventando-o-html-o-futuro-da-linguagem-de-hypertexto/

  12. The things I wanted already got planned, and this a long time ago. When I first heard about Web Forms, I was thrilled: built in form checking making all of our lives easier.

    Another thing I stumbled upon a few months ago was that I wanted to group some dt and dd elements without defining new dl elements. After googling a bit, the di element popped up; being planned in XHTML 2

    Yet I cannot quite follow on the whole HTML5 vs. XHTML 2 stuff. If Web Applications 1.0 are extensions to HTML and the DOM to make it more suitable for application development, also sometimes called “HTML5”., then what is being planned for XHTML 2? Will it be a “port” of these extensions? If so, then why build 2 roads to a city, if one can only drive on one at the same time? And what about Web Forms 2.0 vs. the XHTML 2 XForms Module.

    I always ‘thought of’/’was taught that’ XHTML ‘being’/’is’ HTML “but only neater, more logic and stricter”; but that seems to be biased after reading this all, doesn’t it?

    To me it now appears that it’ll be a battle comparable to ASP vs. PHP (both being the best by their users — don’t shoot me on this, just an example); but then created by the same authors.

    Bramus.is.confused.right.now.

  13. think there should be more printing hints e.g. for print pages using advanced css selectors, bit like on the alistapart article from a while ago on printing a book from a web page.

    the sort of thing I am thinking is a page break or columns marked up in the html

    I am saying this only for print previews and strongly suggest against this for main page views.

    sounds from your posts that the blockquote errors in IE need hammered out so that they are properly working

    would finish by say that anything that is being marked up in microformats probably could do with having an html equivalent (there wouldnt be a need for microformats if the html supported the properties)

  14. Bramus! wrote

    If so, then why build 2 roads to a city, if one can only drive on one at the same time?

    I think this is a pretty relevant point, though what I’m about to say uses it as a jumping point.

    As I read Bramus’ reply, I realized that, as far as for-public-use, xHTML is much better suited for web apps because of the strict syntax requirements. Web apps are usually very structured and accept distinct user input (e.g. enter the product code) rather than free-form input (e.g. enter your blog post some HTML accepted). Certain restrictions on platforms can be reliably made (e.g. your browser must understand content served as application/xml+html). This sort of structure is good for web apps, where, in my experience, it’s not good for more public sites (e.g. forums, blogs, and other areas where user input can potentially break requirements).

    I wouldn’t mind seeing xHTML go towards web apps and HTML staying more in the public area.

    I keep going back to the Full Belly Project where the maker purposefully made his tool as something that could be jerry-rigged since finding parts for it may be difficult. There is beauty in a strict syntactical environment that fails without all the perfect pieces, but that doesn’t mean a contraption is ugly. They can be well designed, too.

    It’s about having the right tools for the right job.

  15. As I can only surmise it from Tim Berners-Lee’s article, Reinventing HTML, which was published not two weeks ago, the reemphasis on HTML seems due to XHTML being too ambitious in retrospect. Apparently lower-case, quote marks, back-slashes and the sort were simply of too little concern to most since “browsers didn’t complain.”

    With regard to WHAT WG, Mr. Berners-Lee’s writes:

    “An issue was the formation of the breakaway WHAT WG, which attracted reviewers though it did not have a process or specific accountability measures itself.”

    It’s hard to say if that’s an outright dismissal of the WHAT WG, but he goes on to say, apparently with reference to the W3C:

    “The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together. We have strong support for this group, from many people we have talked to, including browser makers.”

    It sounds to me like the W3C is going to be revitalizing their own HTML activities.

    A bit more from Mr. Berners-Lee:

    “There is also a plan for a separate group to work on the XHTML2 work which the old “HTML working group” was working on. There will be no dependency of HTML work on the XHTML2 work.”

    Hence, now the two specs will run in parallel with their own dedicated charters, I guess, with HTML taking baby steps in the direction XHTML went. It’s like throwing the fish net again but using a smaller mesh this time around to catch more of the school.

    On a different note, someone commented on the complex documentation that the W3C is known for. In fact, a relationship has been established between the W3C and the STC for producing more mass-friendly documentation. Just so you know, the STC is a professional organization in existence for over 50 years now, and it’s member base is largely technical writers. Projects I know STC is working on in collaboration with Ian Jacobs, Head of Communications for W3C, are XHTML 2.0, XForms, and SVG 1.2, though there may be others.

  16. Ah, the section Shouldn’t this work be done at the W3C or IETF? at WHATWG suggests a more collaborative relationship exists between them and the W3C, so maybe the new HTML efforts are not so disparate after all.

  17. November 8, 2006 by Martijn van Turnhout

    I agree with a couple of users. Either focus on HTML 5 or XHTML 2.0, but don’t try to please all the developers with different preferences.

    • Are there any limitations with HTML that you would like to see fixed?

    I’d say a couple of new tags, like “navigation” or “footnote”, while getting rid of a couple of others which are not used as much, like e.g. “samp”. Or a simplification of doctypes so you don’t need auto-completion to use them. Then again, it takes so long for these things to be adopted into pages and browsers that it’s probably better to not fiddle with this.

    • Do you have any ideas for new features?

    As above…

    • Is there anything you can do now in HTML, but would like to see improved?

    Keep it simple… most improvement seems to be necessary within CSS, not HTML. Other improvement should be made in getting the word out about using all those cool features of HTML, like say, form labels, which are still missing in 90% of web forms, it seems.

    • Do you have any concerns about the development process?

    Listen to outside voices, this is a good start…

    • Do you have any feedback about the new features in the current drafts?

    Don’t know enough about that…

    • Do you have any questions about HTML 5?

    Hmmm, I’ll be using XHTML2, not HTML5, at least if XHTML2 is downwards-compatible to way old browsers (which means it mustn’t enforce a true XML http header, for one thing, which is unfortunate, but I don’t like to create pages which I know won’t work on browsers from 10 years ago — it defeats the whole purpose of having a universal, timeless language).

  18. I’d like to see a nice semantic way of marking up key-value pairs. The current solution seems to be to use either a definition list or a two column table, neither of which is quite right. This may not be so important for your typical website, but when you’re trying to write webapps that display information about a device or system it becomes more important.

    Any suggestions on a good way to do this now would be great too.

  19. I think XHTML 2 and HTML 5 have different purposes. Clearly HTML 5 is more intended for web applications, whereas XHTML 2 wants to stay in the realm of markup and integration with other XML languages.

    I’ll likely use both when they are both out of working draft mode.

  20. Whereas it may be true that WhatWG is hearing people needs for HTML5, it is also true that are not hearing entire comunities.

    A few days ago i was subscribed to WhatWG and emphasized problems with mathematical markup. Most of people at the list (including Hakom from CSS) agreed in our nice proposal for mathematical markup. Editor agreed, a draft was even discussed then and part of it approved by a Mozilla guy. Finally, they decided break with us and did not heard comunity said them in the list.

    Some time ago, they decided go further with an isolated mathematical proposal and presented to the MathML list. The proposal from Mozilla and WhatWG is being rudely critized at MathML list as technically flawed, inventing new problems, is being designed to be incompatible with MSIE, with namespaces prefix, and with near 100 tools working today.

    They are not hearing, are not replying technical issues even when are asked many times since October, are banning some people from posting at the WhatWG list [1], and are reinventing the wheel and doing it square.

    I am not more perplexed than Soiffer when heard from WhatWG that MathML is a DOM [2]

    Links:

    [1] http://lists.w3.org/Archives/Public/www-math/2006Nov/0051.html

    [2] http://lists.w3.org/Archives/Public/www-math/2006Nov/0049.html

  21. It’s all said done and well, but at the end of the day, how long are we to expect the software businesses like Microsoft, Mozilla and Opera to properly implement these new standards? They don’t all fully support the current standards so what is the point in starting something they will not adhere to until five or more years down the line.

    However, as a suggestion to the future, I believe that namespaces should be preserved, as in XML. I know this is more about the data, which isn’t necessarily HTML/XHTML, but it’s still a valuable feature.

  22. November 9, 2006 by Darcy

    Personally, I’d like to see one standard instead of two. Either HTML or XHTML, but not both.

  23. November 9, 2006 by Nathan Rutman

    Has anyone ever talked about a universal src attribute on any element that would allow a client-side include model? I’m using a UL-based element structure for navigation (very common). It would really be awesome if I could say <ul src=”menus.html”> where menus.html contained all the child (LI) elements for the list items. You could do that with DIV’s and other elements in order to make code more reusable while still maintaining document structure and without relying on a JavaScript/XML or a server-side approach. Something like “client-side includes” sounds like good sense in order to continue bringing good markup/coding practices to the large-scale website. Comments? Suggestions? Am I off my rocker?

  24. (This is the essence of a blog post I did on this subject, though in the post I do mention something about draconian error handling…)

    To me, the recent proposal to evolve HTML incrementally seems like a good path to follow. Though this has to be done in such a way that browser makers actually implement support for the new developments. Furthermore I clearly see XHTML as the future, so in my opinion a long term goal should be a merger of the two specifications. Doesn’t matter if the resulting standard is named HTML 6 or XHTML 3, as long as we get there.

    In addition to a lot of the stuff from Web Applications 1.0 and Web Forms 2.0 drafts, here’s a some specific items I especially would like to see developments on in future revisions of HTML;

    • A “Rich Text” form/input field, something that could better facilitate the creation of a standards compliant (WYSIWYG) RTE. This could be made by adding an attribute to the “textarea” element (example; mode=”rich”), thus backwards compatibility would be ensured.
    • Some standardization of accelerator keys. Especially which should be made available to developers, or possibly give developers a method to override or cancel the actions of the already mapped keys.
    • New/more elements for different types of structured data. Such as a new list element of sorts that works with pagination (which isn’t necessarily just a ordered list).
    • Better tools to describe/indicate dialog, quotes, notes, side-notes, footnotes, headers, footers and the like. Methods to assign author, origins, timestamp, etc would also be needed.
    • Deprecating “img” in favor of “object”, with better methods of creating titles, captions and object-not-supported information. For the image subset of the object, there should also be a simple method to indicate that something is a thumbnail with easy linking to the full version.
    • Possibly not the place to specify this, but having a “DOMisLoaded” event would be really appreciated.

    Though my one highest wish for “the future of HTML” is really something you can’t put down in a specification, furthermore it’s undoubtedly the hardest task any working group or organization can undertake when it comes to HTML standardization. Obvious as it might be, my single most important wish is for the future of HTML is; Ensure browsers support the established standards.

  25. Do you have any concerns about the development process?

    Looks like it has started at the wrong end.

    Regardless of how many wishes/improvements we site-designers/-developers can get into a future version of HTML, it will be of little use if the UA-developers don’t follow up on it.

    You should get all UA-developers in on the team before going any further, or else all efforts going into development of an improved HTML-version may just be a waste of time.

    Are there any limitations with HTML that you would like to see fixed?

    I’ll go with Ben’s request for Better lists.
    The rest of Ben’s thoughts are also quite near my own, so I won’t repeat them.

  26. I may be being simplicistic and I do know why there is a HTML and XHTML, but one language to do all just would be so much better. Either camp settled in don’t have an issue - but in these days it’s just not good enough to keep the confusion. Bar a proper standardisation, top of my list are text styling tags, expanded list functionality I do agree with and also for me the browser level ground being reached would also be a biggie.

    I just think it’s so wrong that there are 2 camps on language variations and so many camps on browser variations - the phrase ‘can’t we all just agree and get along’ comes to mind. One camp supporting all now that’s a camp and html with or without letter in front of it I’d love to be in.

  27. As if having to deal with the release of IE7 and its quirks was not enough… :D

    Personally, and this is just my opinion of course, I think tables should be looked at in terms of understandable syntax. Tables, of course, are typically only used for data—as they should be—in modern web design; however, they still have a place definitely. There is nothing more annoying to me than swimming through seas of <tr> and <td>.

    Yes, it’s obvious that TR means “table row” and TD means “table data” (that’s maybe not so obvious to some), but seeing these two similar items nearby, especially in a large table, will make you go cross-eyed. It makes it hard to edit if you’re going to be handwriting your data, vs. having it generated.

    I’ve always wondered why something more obvious hasn’t been put in use, like <row> and <col>. Perhaps there’s just been something I’ve not understood. I admit to not keeping up with the W3C beyond using standardization tools. :P

    This has little to do with the need for it for average people. Unlike with the case of B and I for emphasis vs. STRONG and EM, this would be purely to help out designers, as I don’t think any browser has much trouble rendering tables.

    Just my two cents. Not a terribly important issue, but one that annoys me, nonetheless.

  28. @ RB : Good point you make there. Elaborating a bit further on your idea: Maybe that can make the difference between “someone who can work with Dreamweaver” (plain html) and “a webdesigner/webdeveloper” (xhtml2)?

    @ John Magnus : Very nice suggestions!

  29. @Bramus!: I’m not in the HTML is for beginners and XHTML is for pros camp. So, your thoughts are a departure from mine. I just wanted to clarify why I said what I said some more.

    I can and have done XHTML pages, but I stopped using them. I don’t want to start the mime-type debate, but that is a large part of why I don’t use XHTML. At least one major browser still only has “beta” support for real XHTML, which means real XHTML is not ready for prime time.

    Assuming that real XHTML mime-types worked properly across the board: While HTML is great for beginners because it is forgiving, it’s also great when people are putting stuff on your site that may or may not be valid or may break the page. I read an article that suggested a scenario where an XHTML blog page with a proper mime-type contained a comment that had a invalid character in it would break the page. So, a user entered a character not in the specified character set, and the page is no longer usable. This would be a case where the designer is a “pro” but XHTML worked against him.

    If the designer used HTML, there would be no problem. I feel like a good designer would say, “what solution would work the best for my users / clients?” instead of “i’m using XHTML because it is the latest and greatest / my ideology suggests i ought to.”

    I think people forget that standards compliant, well-formatted, semantic code is achievable through HTML.

    So, my point was that in scenarios where designers have discreet users or have strict programatic control over the data entered to their page (or if no data is entered at all), XHTML would be a great tool. I see these pages as being non-blog non-guestbook pages, pages that don’t accept user input, or web applications. On the other hand, HTML is great for the types of pages XHTML isn’t good for.

    The web still needs a forgiving markup language.

    FYI, this page is valid HTML 4.01 strict. Not XHTML.

  30. @ RB: I indeed was freewheeling a bit further on your idea. Your points about the XHTML are valid and correct. It did in fact cross my mind that users by definition break everything, yet not to the extent that even a simple character could break it.

    The web indeed needs a forgiving markup language, but most browsers are a bit too forgiving imo (incorrectly nested tags and such will still render): Being too forgiving will never increase the quality of something/someone.

    And yes I know this page is HTML 4.01 strict. No matter what version used (HTML 4.01 / XHTML) the strict part is most important to me … it says something about the author of the code (and it’s not even that hard to do either).

  31. Well, I would like to see some standard solutions for marking up poems and other literary texts in a semantically rich way. There should be other ways than using <pre>.

    Slightly off-topic, but you should check out TEI-Lite, a markup language developed specifically for literature. In particular, the tag set for verse.

    What I would like to see from future versions of HTML is better interoperability with other markup languages, such as TEI and MathML, rather than adding new tags to HTML to solve problems already handled by those languages.

  32. Oops, I gave the wrong link. Sorry! Here is the TEI tag set for poetry.

  33. Congratulation, Great effort to develop…

    Thanks…. because this is the great opportunity to develop our community.

  34. November 16, 2006 by Stevie D

    Better tools to describe/indicate dialog, quotes, notes, side-notes, footnotes, headers, footers and the like. Methods to assign author, origins, timestamp, etc would also be needed.

    Footnotes is one feature that would be really helpful. You could insert Text of footnote in the body of text, which would autonumber the footnotes, provide the text as a tooltip on the reference number, and repeat the footnote at the bottom of the page.

    I’ve always wondered why something more obvious hasn’t been put in use, like and .

    Hindsight is great, but and are so ingrained in HTML now that it would be a mistake to replace or replicate them.

    But, as others have said, the real battle is to get all the features properly implemented in the browsers. And I don’t need to mention any names here. The best hope we have is to get the new specs completed in time for it to be built into a new version of the OS.

  35. Although technically not HTML - Internet Explorer has something called STYLE FILTERS - that can be used to give Image-like effects to Text and Images and DHTML

    They are Attractive, fast loading and SEO friendly - they really should be expanded and developed :-)

  36. These would have my life a whole lot easier:

    1. The ability to position elements relative to non-parent elements.
    2. The ability to set the css rules for an element using the css rules of other elements. In other words, the ability to set the height of B, to the height of A. Pseudo code: div#B {height: reference(div#A[height])}
    3. Combo select/input text box: a version of a select element (”drop down box”) that allows users to enter their own text in addition to the options listed.
    4. A css rule that allows parent elements to always expand to completely surround all its children.
    5. Better Border and Corner support. Web designers, love rounded corners, but frankly, there’s no 100% reliable or simple way to implement them. The ability to set background images for just for the borders and corners of elements would be a nice solution.
    6. footer, masthead, and navigation elements: new HTML elements with robust semantic value.
    7. SVG support built-in to browsers: Flash-smooth graphics without plugin hassles
    8. Regular browser rendering engine updates. 3 or 4 times a year.
  37. Discovering some old patent on HTML rendering engines that means every browser out there has to use the same one or none at all would be nice!!!

    Sorry, a little off topic. But seriously, I hope a new version of HTML manages to motivate the big players into improving the sorry state of affairs we’re in right now as far as rendering goes. I mean, are we as developers seriously prepared to spend the next decade+ working around the inconsistencies? Heh.

  38. WHATWG versus W3C?

    Is this the same procedure as in the beginnig of 1995? It’s seems for me that a new war is born, like the browser war between IE and Netscape.

    I think, it’s better to close all discussions about that and force all Web Designers to use one Web Standard. But most Web Designers will not use Web Standards. Why? Is it possible that the preferred design is not valid?

    Most new sites have the only sense to get visitors, not to make the site accessible for all browsers and also for persons with disabilities.

    So a new Standard will born and the Web Designer can to what he will.

  39. “panta rei” says an ancient saying, everything is in motion, and so it’s the right decisison to continue the development of HTML, I just hope that it’s focussing more on the mobile web aspects.

  40. It would be nice to replicate some of the layout niceties that are lost in the transition to divs, such as:

    • multiple cells in a row evenly fitting a percentage width, even when the window width changes, and all having equal height that matches the tallest content (perhaps divs could size relevant to a container div and use fraction widths rather than decimal percentages);

    • and easy on the eye form layouts without excessive divs or spans.

    Improved styling for form elements (which I think might already be coming) would also make life easier, not to make them completely unrecognisable, but it would be great to be able to adjust margins, padding, and colours (and have it fully browser supported!)

    And the ability to set rounded corners!!! (maybe even blunted/angled corners) for tables, borders, scrollbars, form elements, etc.

    Some of this might be more CSS than HTML, but it’s all got to work together - and it’s just my inexpert 2 pence worth of first thoughts.

  41. The predefined class names scheme in the WHATWG HTML5 spec as it currently stands is a complete mess, a current muddle, and a future nightmare. There is a good idea behind this. Somewhere.

    But all good people should get together to ensure that it gets strangled before birth. (Can something be strangled before birth? Probably not.) Anyway, stop it, quickly.

    It clearly: breaks the web; it is not future-proof; is not i18n-friendly, and, oh I don’t know how many other things are wrong with it, but I’ll be more than delighted to let you know if anyone is interested. It breaks I don’t know how many Golden Rules, it’s just, gaah!

    Although the proposal is fatally flawed I, think it can in fact be fixed.

    But doing nothing at all is far, far better than making this mistake.

  42. May 22, 2007 by Peter Rosti

    I am going through the HTML5 specification with care. I am responding here to a comment embedded in Section 1.4.1, which reads: “Generally speaking, authors are discouraged from trying to use XML on the Web, because XML has much stricter syntax rules than the “HTML5” variant described above, and is relatively newer and therefore less mature.”

    This is ill-conceived and self-serving. It ignores the brilliant generality of XML, and tries to sweep away its potential by claiming that it’s too young or too complicated. The vision of a truly flexible page description language (and related scripting language) that can support tags defined on the fly, with attributes correspondingly flexible, is undermined, and replaced by a “reality” that is “more of the same”, albeit somewhat evolved: more fixed structure, more fixed rules - ever-more-complicated rules. The elegant vision of an XML-rendering browser that can consult a namespace, and then render arbitrary tags (using an interpreter that reads something like XML Formatting Objects) is pushed further into the future, to the detriment of all.

    The argument that XML has stricter syntax rules, so it should be “avoided” is simply naive. Javascript, as a comparable example,is loosely typed (honest thanks to Brendan), making coding easier for authors, than say Java (as in core Java, and JSP, etc.) But once strong typing becomes available in Javascript, we wont expect to hear complaints that the syntax is becoming “too strict”. We’ll just be able to do more with it, and do so more efficiently. Likewise, the stricter syntax of XHTML (vs. HTML) is a benefit, but carries the minor overhead of having to write cleaner code. That’s a blessing, not a curse - it enables unambiguous interpretation, and sets the stage for that more elegant vision where more powerful XML can be rendered with fewer specialized browser rules. Let us not lose this vision in a cloud of specialized detailed rules developed incrementally. A vast collection of detailed rules WITHOUT GENERALITY eventually overburdens a language, and HTML5, for all its benefits, is nonetheless heading in that direction.

    Please forward my comments to whatwg.org as appropriate.

    Peter Rosti

  43. It would be nice to replicate some of the layout niceties that are lost in the transition to divs, such as:

    multiple cells in a row evenly fitting a percentage width, even when the window width changes, and all having equal height that matches the tallest content (perhaps divs could size relevant to a container div and use fraction widths rather than decimal percentages);

    and easy on the eye form layouts without excessive divs or spans.

    Improved styling for form elements (which I think might already be coming) would also make life easier, not to make them completely unrecognisable, but it would be great to be able to adjust margins, padding, and colours (and have it fully browser supported!)

    And the ability to set rounded corners!!! (maybe even blunted/angled corners) for tables, borders, scrollbars, form elements, etc.

    Some of this might be more CSS than HTML, but it’s all got to work together - and it’s just my inexpert 2 pence worth of first thoughts.

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.