- From: Ben Boyle <benjamins.boyle@gmail.com>
- Date: Mon, 2 Jul 2007 20:58:21 +1000
- To: "Andrew Ramsden" <andrew@irama.org>
- Cc: "Andrew Sidwell" <takkaria@gmail.com>, "aurélien levy" <aurelien.levy@free.fr>, public-html@w3.org
I have a use case for this, from a while back where I found it difficult to apply the hCard microformat to content marked up with DL [1] Sample HTML: ... <di class="tel"> <dt class="type">Fax</dt> <dd class="value">#### ####</dd> </di> ... Take away the <di> and it becomes necessary to use all kinds of redundant tags (or as I was told on the microformats wiki, "don't use definition lists in this manner".) ... <dt>Fax</dt> <dd class="tel"><span class="type">Fax</span><span class="value">#### ####</span</dd> ... That's my use case. I never said it was great :) Let us consider the issue behind the <di> element... 1. Authors need to be able to express semantic relationships, and build on those expressions with styling, behaviours (scripting, or browser add-ons), extract semantic relationships etc. The <di> grouping is implied. There is no conforming markup that can express this grouping. Or is there? There may be workarounds with @class ... there is definitely no parent element allowed. This is inconsistent with aspects of HTML, e.g. <tbody> is available within table. It's optional. Authors may use it at their discretion. There's plenty of guidance about when we should (outside of HTML: WAI stuff, tutorials, etc.) I think <di> can be of similar benefit. A similar difficulty exists with associating headings (h1-h6) with the content around them. HTML 5 has tackled this with improved semantics through <article> (and more) to explicitly define where the groups are. The groupings within definition lists are much simpler than headings and their siblings, but <di> would still simplify the structure where it was provided. I don't really see the necessity of requiring it everywhere. I do see the usefulness of having such a feature in the language. I would use it today, if it were available. [1] http://microformats.org/wiki/hcard-issues (search for 2006-01-21) On 7/2/07, Andrew Ramsden <andrew@irama.org> wrote: > > Fair enough, as it was pointed out, this particular case is fairly well > understood under HTML 4 and will be clearly defined under 5, but as > Robert Burns so artfully phrased the issue: > "providing rich hierarchical structured mechanisms within the languages > will also facilitate use-cases we can't think up" > > DI may not actually change the semantics of groups of <dt>s and <dd>s > but it will make it harder for content authors to mis-interpret, and > provide a more robust/flexible language for the future (as <dl>s without > <di> groups could then be deprecated). > > This is not a radical idea, its stolen straight from the pages of XHTML2 > (http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_di), and as pointed > out by Thomas Broyer, has been discussed previously > (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-March/003160.html) > > On the whole the idea seemed fairly well received on the list, I'm not > sure why it didn't make it in at that point. > > > Bottom line is: It takes the /implied/ semantics of definition lists and > makes those relationships /explicit/, at no harm to content authors, > user-agents or you! > > > I think its worth a rethink. > > > Thanks for discussing the idea. > Cheers, > Andrew Ramsden > > > > Andrew Sidwell wrote: > > Andrew Ramsden wrote: > >> This may be off-topic for "html 5 and accessibility", but I agree with > >> your assertion that a di element would clarify the semantic relationship > >> between dt and dd elements. > >> > >> The specific use-case of dl that I see as ambiguous without a di element > >> is: > >> <dl> > >> <dt></dt> > >> <dt></dt> > >> <dd></dd> > >> </dl> > >> > >> Does this represent a two terms (one without a definition), or a single > >> term with two possible term variations? > > > > In what way is it a definition term if it's not used as part of a > > definition? The only common-sense answer is that both terms share the > > same definition. > > > > Andrew Sidwell > > > > > > >
Received on Monday, 2 July 2007 10:58:40 UTC