[whatwg] The new content model for <details> breaks rendering in MSIE5-7

[Ian Hickson]

On Wed, 14 Oct 2009, Michael(tm) Smith wrote:
> Ian Hickson <ian at hixie.ch>, 2009-10-14 03:41 +0000:
> >
> > As far as I can see the options are as follows:
> > 
> >  1. Drop support for <details> and <figure> for now, revisit it later.
> > 
> >  2. Use <legend>, and don't expect to be able to use it in any browsers 
> >     sanely for a few years.
> > 
> >  3. Use <dt>/<dd>, and don't expect to be able to use it in old versions 
> >     of IE without rather complicated and elaborate hacks for a few years.
> > 
> >  4. Invent a new element with a weird name (since all the good names are 
> >     taken already), and don't expect to be able to use it in IE without 
> >     hacks for a few years.
> > 
> > I am not convinced of the wisdom of #4. I prefer #2 long term, but I see 
> > the argument for #3.
> 
> In terms of the Priority of Constituencies principle, it'd seem to me 
> that between #2 and #3, #2 will -- in the long term -- ultimately have 
> lower costs and difficulties for authors, though higher costs and 
> difficulties for implementors in the short term.
> 
> I would think a big red flag ought to go up for any proposed solution 
> that we know will lead to introducing complicated and elaborate hacks 
> into new content. For one thing, we know from experience that due to 
> cargo-cult copy-and-paste authoring, such hacks have a tendency to live 
> on in content for years after the need for them in widely used UAs has 
> disappeared.

We tried <legend>, and the complaints were more concrete than those for 
<dt>/<dd>. Unless there's a really compelling reason, I don't really want 
to flip-flop back to the <legend> idea.


On Wed, 14 Oct 2009, Dean Edwards wrote:
> On 14/10/2009 04:41, Ian Hickson wrote:
> > On Tue, 29 Sep 2009, Dean Edwards wrote:
> > > 
> > > It's going to take a while for IE7 to go away. In the meantime it 
> > > becomes an education issue -- "You can start using HTML5 except 
> > > <details> which will look OK in some browsers but completely break 
> > > others."
> > 
> > ...and except for<canvas> which will be slow or not work in IE for the 
> > forseeable future, and the drag and drop model's "draggable" attribute 
> > which will only work in new browsers, or the new controls which will 
> > look like text fields in legacy UAs, or... how is<details> different?
> 
> The other things you mentioned don't work but don't break anything. 
> Using <details> can potentially break entire pages.

<style scoped> can break entire pages. Using any of the new APIs can too. 
Using "draggable" can make something work in one browser but do something 
quite different in another, potentially with poor behaviour.

There are workarounds for all these issues, some are more painful or risky 
than others. I think it's not significantly more difficult to educate 
authors about <details><dt> hacks than about the other hacks.


> > > Can't we just invent some new elements? We've already created 20 new 
> > > ones. Two more won't hurt. :)
> > 
> > We have more than a dozen elements whose names would be appropriate 
> > here. Inventing entirely new elements to do the same thing again just 
> > to work around a very short-term problem is just silly.
> 
> I don't think it is silly to prevent severe rendering problems in 30% of 
> installed browsers.

Consider what this argument would sound like 30 years from now.


On Wed, 14 Oct 2009, Remco wrote:
> 
> So what you'd expect is that #3 would take about 4 years to completely 
> fix itself, and #2 would take about 5 years. With such a small 
> difference, I'd just choose the best option in the long term.

I think the numbers are more like 10 years for #2 and 5 years for #3.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'