- From: Keryx Web <webmaster@keryx.se>
- Date: Sun, 04 Oct 2009 11:13:00 +0200
2009-10-03 21:47, Tab Atkins Jr. skrev: > 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. > > etc In what way is the SYNTAX different? We seem to agree on this: First and foremost, in <dl> the order is all important. Here it would not matter. In <dl> one may have several <dd> for each <dt> (or several <dt>'s in a row), here one may not. You call this "minor", I say confusing. But we have in fact created a new syntax - why is that better than creating new elements? In what way is the SEMANTICS different? > 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>*. Well, that is not what the SPEC says is it? > I mean, would you complain about using <title> or <caption> or <label> > or <legend>... in <details>? Yes, I would. I am arguing in favor of introducing a new element, which would be the zero cost solution, since <details> is new anyway. + No hacks besides those that we already use to get details working as such in legacy browsers. + When implementing details the browser vendors will not have a harder time using a new element than they would using dt/dd. + We would keep the several meanings per element count down, which from a teachability POV is more important than keeping the total number of elements down. And from that POV nuances are often harder to pick up than anything else. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Received on Sunday, 4 October 2009 02:13:00 UTC