On Sat, Oct 3, 2009 at 12:03 PM, Keryx Web <webmas...@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.