Re: Implementor feedback on new elements in HTML5

Ian Hickson wrote:
> On Fri, 4 Sep 2009, Bruce Lawson wrote:
>> On Fri, 04 Sep 2009 09:43:50 +0100, Ian Hickson <ian@hixie.ch> wrote:
>>> On Mon, 31 Aug 2009, Maciej Stachowiak wrote:
>>>> - Elements requiring changes to <legend> parsing: <figure>, 
>>>> <details> These elements seem quite useful, but they will be 
>>>> unusable on the public Web until all browsers are updated to change 
>>>> how they parse <legend> and the new versions are widely adopted. 
>>>> [snip] We will consider fixing our parsing of <legend> outside 
>>>> <fieldset> soon, so that we're not the blocker. But it seems like it 
>>>> would be easier to change the elements that carry the label/caption.
>>> These elements aren't especially critical, so if people would feel 
>>> like it was less of an issue to just not include them in this version, 
>>> but to still fix the parsing of <legend>, and then to introduce them a 
>>> few yeards down the road, once the parsing is fixed, then I'm fine 
>>> with doing that
>> Isn't that throwing the baby out with the bathwater? The details element 
>> is especially useful (I've seen sites pull in the whole jQuery library 
>> just to make an expanding/ collapsing "details" div) and figure would be 
>> very welcome to associate image captions with images.
> 
> It's more like throwing out the soap with the soap dish. Waiting another 
> few years is not a problem, especially since people are already working 
> around the problem successfully.

Given the half life of old browsers (particularly IE 6 which has a 
marketshare of something like 25% [1] some 8 years after it was 
originally released) and the fact that designers avoid features that 
don't work in 95% of UAs by marketshare, a "few" years here is probably 
a decade or more. I don't think we should be designing features that we 
know will not be widely adopted for such a long time. Sure the long 
lifetime of IE6 might be a special case but I don't really see any 
evidence that the long tail of slow upgrades is going away; there will 
always be corporate intranets with "special" requirements and 
conservative IT departments that are reluctant to deploy new browsers.

>> Why not abandon the idea of reusing legend and use <c>, <description> or 
>> some other such element?
> 
> Because the problem with <legend> is temporary, whereas the problems 
> introduced with a new element would be permanent.

Reusing <legend> in this way seems to be a purely aesthetic preference 
for not minting a new element name. This seems like a weak argument 
since HTML5 already introduces a large number of new elements. Anne's 
argument about compatibility seems like it applies to any other markup 
introduced in HTML5 that is intended to alter browser behavior e.g. an 
author could use <input type="color"> with a javascript widget that 
produced an HTML5-incompatible colour format, and a server-side script 
that rejects input from a conforming HTML5 browser. Therefore, whilst 
this argument should be given some consideration, I don't see that it 
deserves more weight when applied to <details><legend> than in any other 
case.

On the other hand, reusing an element that breaks in all major extant 
browsers is a clear violation of the "degrade gracefully" principle [2]. 
  None of the arguments presented so far in favour of the current design 
seem like compelling reasons to break the principle in this case but not 
in all the other situations where it had been used to guide the design.


[1] http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
[2] http://dev.w3.org/html5/html-design-principles/#degrade-gracefully

Received on Monday, 14 September 2009 12:15:48 UTC