- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 16 Sep 2009 20:49:59 -0700
- To: Shelley Powers <shelleyp@burningbird.net>
- Cc: Smylers@stripey.com, public-html@w3.org
On Sep 15, 2009, at 12:48 PM, Shelley Powers wrote: > > If we're redefining semantics, which is the exact same thing as > saying we're rejecting semantics, then why not at least use > something that is meaningful? Such as caption? > > Why on earth are we using such inappropriate elements, when there's > one to hand that at least sounds about right? [...] > This was such a bad decision. No thought either, just throw > something out because some "super friends" had a hissy about legend. > I agree by the way, about the use of legend, but their suggestion > was for "label". I've been a longtime advocate of moving <details> and <figure> away from <legend>, and I even suggested <caption> and <label> as possibilities. In the past, we've found that most of the existing HTML elements that mean something like "label" or "caption" have technical difficulties. For the record, here's a summary of past discussion. Note that most of these arguments are originally due to other people than me, I am just repeating them. caption: - Gets stripped by browsers outside of a table. This would make <details> and <figure> unusable until all browsers updated their parsing. - Inside a table, <caption> pops the parser out of the current cell into the top level of the table. This would make it impossible to use <details> or <figure> inside a table. Worse yet, the popping out behavior of <caption> can't be changed, for Web compatibility reasons. legend: - Causes different undesirable behavior in all browsers (WebKit drops it, Gecko adds a fieldset, IE adds two empty elements named "legend" and "/legend"). This would make <details> and <figure> unusable until all browsers updated their parsing. label: - Is associated as the label for any controls inside it; probably not a big deal for <details>, but it's totally plausible to have checkboxes, radio buttons, text fields or other form controls in the caption of a <figure>. Think about the flickr UI for editing a photo caption, or sites like "Am I hot or not", or a UI to check the photos you like best out of a set. - Cannot ever receive keyboard focus; this is more of a problem for <details> than for <figure>, since it is an interactive element. - Apparently, a fair number of pages have existing style rules for "label" that are not further qualified, intending them only for form control purposes. Adding a <figure> or <details> to such a page would cause styling oddities in the caption, unless all existing label CSS rules are changed to qualify them further. h1: - Extremely likely to be styled by the site in a way that's not appropriate for a figure/details heading. - Would interfere with attempts to infer an outline for the page. title: - Can only contain plain text, not markup. - Gets moved to <head> in at least some current browsers when it appears in <body>. If it were not for these technical difficulties, my first choice would be <caption> for <figure> and <label> for <details>, based on natural English usage. But I think these technical objections are stronger than matters of taste. I think the only known options that avoid technical problems are using <dt>, or adding one or more new elements. Reusing <dt> and creating a new element (that means something similar to the many heading/title flavored elements we have already) both have their downsides from an aesthetic perspective. It's hard for me to declare one option clearly better than the other. Personally, I can buy into the idea that the <dt>/<dd> pair always creates a label/item association, but the exact nature of that association is defined by the containing element. But I can also see that writing <figure><dt> might not be very mnemonic. Regards, Maciej
Received on Thursday, 17 September 2009 03:50:40 UTC