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

[Tab Atkins Jr.]

On Sat, Oct 3, 2009 at 12:03 PM, Keryx Web <webmaster at keryx.se> wrote:
> 2009-10-03 00:51, Tab Atkins Jr. skrev:
>
>> <dt>/<dd>  only have parsing problems in IE6 and IE7.  Both of them
>> *are*, finally, actually dropping off the radar.  Windows 7 will
>> accelerate this as people upgrade with an OS that runs IE8 by default.
>>  Give it 2 years or so and most places will be able to justify
>> ignoring IE7 (many/most sites already ignore IE6).
>
> The IE6/7 problem is not the only one. A number of people, myself included,
> have expressed dissatisfaction from a semantic and teachability viewpoint.
>
> It is not better to let dt/dd have three (or perhaps 2) different meanings,
> and different syntactic rules depending upon the parent element than it
> would be to have 2 more elements.
>
> And if the use cases for details and/or figure is so weak, that they would
> be dropped JUST BECAUSE they would introduce yet 1 or 2 additional elements
> to make them work, than we might as well drop them.
>
> Do it right or do not do it at all!
>
> If an element has (1) a whole new semantic meaning in one place than it has
> in another place, and (b) different syntactic rules in one place than it has
> in another place, it is NOT THE SAME ELEMENT by definition.
>
> Let's not kid ourselves. We ARE introducing new elements here. It just so
> happens that they share the same name as 2 old ones. Or at least the same
> abbreviated name, since some people suggest that they would be expanded to
> "details type" and "details data", when used with details.
>
> What further proof do you need to understand that we are de facto
> introducing new elements, even if we confusingly, re-use old names?

Well, no amount of proof would do so; only a convincing enough
argument.  I, personally, do not feel that <dt>'s semantics change
between <dl> and <details>.  Nor do I feel they have different syntax
at all - <dl> and <details> do have slightly different syntaxes, but
it's very minor and pretty much bound up in the fact that <dl> has
multiple name/value pairs while <details> has only one, so <details>
doesn't *have* to worry about ordering in the same way that <dl> does.

You see, I've authored lots of internal applications for myself and
others in my company.  Tree structures figure prominently, since these
application are often relatively thin layers over the database
structure.  Looking back, I appear to be split evenly and arbitrarily
between using nested <dl>s to handle this structure and using nested
headings/sections to handle it.

There really doesn't appear to be much rhyme or reason behind my
choice of one or the other.  Either would be appropriate.  The only
thing I can see is that possibly the pages I saw more as lists I used
<dl>s for, while the pages I saw more as documents I used
headings/sections for.

So, in my mind, <dt>/<dd> do *not* hold some special meaning that
locks them into only ever being used in <dl>.  <dt> is a heading
element, nothing more, effectively equivalent to <h1>*.  <dd> is a
sectioning element, nothing more, effectively equivalent (though used
slightly differently) to <section>.  Both <dt> and <h1> declare the
name for some body of data contained in <dd> or <section>.  Thus using
<dt> and <dd> in <details> to fulfill the same purpose (wrapping the
"name" and the "data") is completely natural to me.  That's not to say
that other solutions wouldn't also be natural, but I find nothing
wrong with the status quo on semantic or usability concerns.

I mean, would you complain about using <title> or <caption> or <label>
or <legend> or what-have-you in <details>?  The change in semantics
and syntax would be as great or greater than <dt>/<dd>.  It so happens
that all of those are *worse* from a rendering perspective than
<dt>/<dd>, so we've discarded them as solutions.  But none of them are
privileged as 'closer' to the syntax or semantics of the toggler and
data elements of <details>.

~TJ

* I know that the equivalence is not complete - <h*> has an effect on
the document outline that <dt> does not.  But aside from that, they're
equivalent in my eyes.