Current Mood: Thorough
Ok I just went ahead and spent far too long reading critique of WHATWG, the new W3C HTML WG and the xHTML WG, and recommended changes. Some people have some interesting ideas, but then also some bad ones. It goes to show how much disagreement there is out there revolving the evolution of (x)HTML.
Ideas I like:
- Save the cite tag! (or at least make sure you provide equivilent functionality) [the cite tag has been dropped from the xHTML2 spec] Personally I would like it to be included within the quotes tags it is citing, if it is siting a quote.
- It's high time (x)HTML had footnotes. I thought this was already being included, but perhaps I was wrong.
- The HTML5 aside element
- The caption element should be able to apply generically to both tables and figures
- Ban tables for layout (I think this has already pretty much been accomplished in xHTML, but I guess there might be a few holdouts who haven'y gotten the message)
- rowgroups for tables
- User agents shouldn't be required to render quotes around q or blockquote elements, and they should probably be discouraged from doing so (as they are now) but they shouldn't be prohibited in the spec. Rendering should be basically left up to the browser.
- The revival of the start and value elements in lists.
- I was skeptical at first but Josh made an excellent point. Almost every page, everywhere, has what would be considered in most documents a header and a footer. Headers and footers should be too. It's also interesting to note that the address element, when it was introduced, basically wounnd up being used as a footer on the rare pages where it was used. Although it's still a good element to keep around to designate addresses.
- For some crazy reason I thought xHTML2 already included a column element. Yet I research, and it does not seem to. But it would be good to add, and seems to be highly requested. (one of the most highly requested elements to add, actually)
- A smarty named boen_robot posted recommending that a schema language be used to hide the DTD. A namespace + a schema location would be much easier to remember than the ugly DTD line. Most editors/templates hide the DTD ugliness from the user so it's not a big deal, but every slight iimprovement helps, right? And this would be completelly standards compliant and easy to do. Heck, it could probably be done with a custom schema even without any standardation!
- A few people posted requesting a foot element be added to the markup language to execute scripts and such (for example I could picture it holding metadata too) after the body loaded. Sounds lika good idea to me
Ideas I'm against
- Keeping xHTML2 semantics backwards compatible w/ HTML simply for the sake of preserving compailbility [why should HTML4 ever be forced to convert to xHTML2 if the semantics don't match?]
- TBL Ignoring what seem to be rampant complaints about the Web Accessibility WG- this seems to be a tough issue because accessibility is a convoluted and somewhat specialized field that many people believe holds a great deal of potential for defining future user interfaces for everyone. Even within the disabled community different people have different priorities- furthermore individuals with disabilities are limited in how they can particiapte in the working group, for various reasons. Given all that it's not surprising that things have gone badly
- WHAT WG's inclusion of elements for samp, var, and kbd. Personally this is the sort of thing that I think can be handled by a microformat where needed- technically they're all types of quotes, and could be represented by specializations of the q tag.
- Adding elements for formatting conventions such as "deks" and "ledes" to (x)HTML just because newspaper people can't figure out how to layout their elements in CSS
- Adding additional elements for annotation to (x)HTML - that's what the Annotea Project is for! Unless there are serious reasons to believe that the semantic web based Annotea project is too unweildy, or inadaquate for (x)HTML annotation, I think we should give preferance to Annotea. On the other hand, many many web sites have already incorperated commenting on the server side, and HTML already has an element for insertions. Maybe the best solution would be do add semantic web hooks into (x)HTML ins elements to identify commenters? Much the way there are microformateque hooks to add Dublin Core data to HTML meta tags.
- Making HTML5 case sensitive or xHTML case insensitive (I've seen people arguing for both)
- The WHATWG HTML5 article element sounds good on first blush but I can't see why it couldn't just be a subsection?
- I haven't looked over the WHATWG's exact plans but I question the need for new elements for bibliographies and tables of contents. There are already ways of adding these sorts of metadata. Are the new proposals that much better?
- More generic nonstructural elements to group things together or seperate things apart- specifiically this is in reaction to the proposed nonstruct element
- A formula element (there's already a ML just for Math, and ways to add such markup language to xHTML documents- why add a new HTML element for it?)
- Allow fragment identifiers to start with any ASCII character; it doesn't sound TOO bad but they can already start with numbers and letters, how much more do you need? Special characters may be reserved for unidentified future uses. I don't know. I have to err on the W3C's side here... if they object to certain characters, I have to assume they had a good reason to do so (though maybe I'm just to trusting!)
- I've heard people as repuditable as Norman Walsh advocate allowing repeated ids in the same document- but that is a big big no-no as far as I am concerned. Allowing repeated ids in any XML applicationeffedctively prevents ids from being used as unique identifiers in any XML application, which (to my mind) is an exetremely bad idea. And the danger of this is raised by an order of magnitude if you allow the same thing with the xml:id attribute . Now, on the other hand, I would be in favor of resurrecting the name attribute, not as an !ATTLIST ID (or whatever the equivilent is in the schema language of choice) but just as a regular attribute, to take the place of ids when indicating multiple elements is desired (for example, for label elements). This would be impossible to allow in a DTD, but since xHTML2 will probably never be successfully implemented with a DTD who cares! In cases where there's an element with an id as well as a name value equal to the fragment identifier, the id would be selected, but in cases where there's no id or xml:id equal to the fragment identifier, the UA defaults to the element(s) with the specified name attributes Personally I think this solution should satisfy everyone.
- Reviving embed. Why would anyone want to do this? Object is a semantically meaningful tag that accomplishes everything the embed, applet and img tags did, and more. People who want embed are living in the past.
- That goes double for people who want to revive the dir and menu elements. It would be confusing to revive dir, dir is used as an atribute to represent the direction of the text. As an aside, I used to have a friend who used dir tags to indent paragraphs. Do you really want to bring that back? We now have a navigational list to do what those tags used to do. (Personally, I would have been satisfied reviving the menu element to do what the navigational list element does, but really, now that we have a nl, why bother with menu?)
- I have know problem, really, with WHAT WG forking HTML and giving the W3C some friendly competition, but for the love of all that's holly, use your own namespace!
- Why deSGML HTML5? With rigerous conformance checkers, it probably wouldn't be a bad thing, but what's the point? What's to stop someone from creating a SGML DTD just for the heck of it?
- I thought the img element was going to be done away with?? Why is it being included in xHTML2? (and not even depreciated?) Is it really that difficult to convert everything to objects? And the h1...h6 elements are redundant now that we have sections!