- From: Gray Zhang <otakustay@gmail.com>
- Date: Mon, 5 Mar 2012 17:06:57 +0800
<dl> (and <di> in this discussion) refers to **definition**, but in most cases above, it should be a key-value pair rather than a term-description pair, the former is more general in semantic, so I think we should have a general purpose key-value pair element such as <pair>, <pn> (pair name) and <pc> (pair content), in such case a user info form could be: <pair> <pn>Username:</pn> <pc>John Smith</pc> </pair> <pair> <pn>Birth:</pn> <pc>2011-01-01</pc> <pair> ... This is more symantically structural correct, <pn> should be a phrasing element while <pc> is a flow element so you can put flow/phrasing content in <pc>. Although styling <pair> to aligned vertically/horizontally is a matter of CSS but HTML gives a more definitive tag name On Mon, Mar 5, 2012 at 2:56 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote: > On Mon, Mar 5, 2012 at 12:09 AM, Ian Hickson <ian at hixie.ch> wrote: > > The only thing it adds to the grouping is the ability to have a > subsection > > that is then followed by more content from the subsection's parent > > section. You couldn't do that with <hx> alone. However, for <section> > > that's more of a negative than a positive, really (it makes more sense > for > > <aside>, <nav>, and <article>; <section> only allows it for consistency). > > In what ways is that a negative? > > > The spec doesn't generally include design rationale. (If anyone would > like > > to help maintain our rationale documentation, please let me know. We're > > always in need of volunteers there.) > > What type of work is involved? > > > <di> doesn't exist. The ability to have multiple types of authoring style > > isn't the reason for <section>'s existence. It's just a side-effect of > now > > having two different ways to mark up sections. It's not actually a good > > thing in language design to have multiple ways to do something (despite > > what Perl might have us believe!). > > HTML is full of multiple ways to do things: a run of text can avoid > <p> and be the child of a <div> if the author prefers, a <footer> can > be at the bottom or top of a section, authors can continue to use > Microformats despite the existence of microdata, etc. If language > idealism was a tenable goal on the Web then the WHATWG wouldn't exist > and we would all be using XHTML 2 right now (which had <di>, for that > matter). > > > <section> wasn't introduced as a stop-gap measure. > > > > There's no such thing as a stop-gap measure on the Web. We can't add > > something then remove it. Once we've added something, it's part of the > > platform, forever. That's why we have to be careful to only add things > > that make sense on the long term. > > I only said "stopgap" because you posited CSS grouping as the ideal we > should be striving for, when this method would work today. I actually > don't think this should be taken out at a later time, as CSS grouping > only addressing the issue of styling. It does not address the fact > that?as I outlined in my original post?it is impossible with <dl>'s > current parsing model to specify a named value followed by an unnamed > value, since the unnamed value would be subsumed into the preceding > group and be interpreted as an alternate value for it. The converse > (an unnamed value followed by a named value) *is* possible. The spec > claims that the order may or may not be important, yet this forces the > author to write things in a specific order, which may violate what > data they are trying to describe, or in what way. To illustrate: > > <dl> > <dd>Nameless value</dd> > <dt>Name</dt> > <dd>Value</dd> > </dl> > > <dl> > <dt>Name</dt> > <dd>Value</dd> > <dd>Nameless value? Nope, alternate value for Name.</dd> > </dl> > > Whereas wrapping either or both Name/Value and Nameless value in <di> > would mirror what is already allowed, but free the author up to use > the appropriate order rather than compromising semantics with multiple > <dl>s or non-<dl>s. > -- ??? GrayZhang ???http://www.otakustay.com ???http://www.weibo.com/otakustay ???otakustay at gmail.com
Received on Monday, 5 March 2012 01:06:57 UTC