Re: DI element [Re: html 5 and accessibility issue]

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