...or; What I want for the future of HTML
There's been a lot of talk lately about the future of HTML, what, by who and how any new developments should be implemented. The discussion escalated with the realization that we still need HTML and the WHATWG asking for comments. These are my initial thoughts on the subject...
First of all; Thanks to the WHATWG for posting this and inviting us into this process. For some of us mere mortals, contributing through the regular channels can be truly daunting. As such, having a more informal way of contributing is really appreciated (at least to me).
Where should HTML go?
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.
I also think we'll have to live with an option/attribute in XHTML that tells the browser not to do draconian error handling. Not because I think it's a bad idea altogether, I clearly see situations were halting on errors is the desired result, but because it hurts adoption (due to site owners being afraid of it) and most of all because it's less than user friendly. Most applications (documents/sites) will work sensibly with some broken markup, so having an option to display with errors makes sense to me. Maybe this should be an option to tell browsers to automatically fall-back to HTML on errors. That way an application won't cause any harm by continuing past the point of error, whilst users gets some (possibly useful) output sent to their browser.
In addition to a lot of the stuff from Web Applications 1.0 and Web Forms 2.0 drafts, here's a small selection of specific items I especially would like to see developments on in future revisions of HTML;
- A "Rich Text" form/input field (which sounds like a hell-of-a-lot of work), 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. Further it could also be specified that what actually gets posted is the markup (as the value of the <textarea> form field), thus no servers should be broken and CMS authors could easily add support for it. This might already be covered by Web Forms 2.0 and/or Web Applications 1.0, though having it in the HTML specifications seems (at least to me) to better the chances of it being implemented by browser makers.
- 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 (a reasonable subset of) the already mapped keys. Although a scary though at first, with reasonable limitations (eg don't allow remapping of close/exit commands etc) this could be done i a way that benefits users and developers.
- 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. This should also lead to the deprecation of some of the elements we use for these purposes today.
- 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. As a side note deprecating the <img> element should lead to better support for <object>, which in turn should have the added benefit of better support for other objects than just plain images (such as SVG).
- Possibly not the place to specify this, but having a "DOMisLoaded" event would be really appreciated. As this is something I often use to fix browser issues/shortcomings, this could be ignored if everything is fixed by browser makers.
That's what springs to mind, though I'm sure there's more. I can see that the above list is heavily influenced by stuff I'm currently working on (which are <objects>, an RTE and pagination). Well I guess the things I'm missing always can be suggested for inclusion in the next increment of HTML!... :-)
Get with the program
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.
- on the 10th of November 2006 @ 03:43
- in Code the web