18988 2012-09-24 13:10:41 +0000 Allow explicit grouping of <dt> and <dd> elements 2015-06-26 05:38:34 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED WONTFIX P3 enhancement --- 1 Dave.Sparks dave.null Dave.Sparks eoconnor mike public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 74352 0 Dave.Sparks 2012-09-24 13:10:41 +0000 I have a problem which would be best solved by an element, analogous to <tbody>, which could optionally be used to explicitly group <dt> and <dd> elements. One of my pages includes a list of events, which I would like to describe using microdata. The details of each event are spread across a <dt> element and several <dd> elements. No one element in the page includes all, and only, the details of a single event. My first attempt to add microdata used the itemscope and itemtype attributes on the <dt> element, with an itemref attribute referencing the several <dd> elements. Not only is this cumbersome, but Google seems to ignore itemref. I now use <meta> elements, and an empty <a> element, in the <dt> element, for the microdata I want to present to Google. This means that data is needlessly duplicated. An alternative would be to use a separate <dl> element to enclose the details of each event, but this obfuscates the underlying structure. The page in question is at <http://www.potoc.dandasparks.org.uk/txt/events.html>, or more readably at <http://potoc.dandasparks.org.uk/txt(raw)/events.html> 74357 1 eoconnor 2012-09-24 16:57:36 +0000 *** This bug has been marked as a duplicate of bug 18287 *** 74359 2 Dave.Sparks 2012-09-24 17:11:15 +0000 bug 18287 was resolved as "If there's a limitation with the styling, we should fix CSS". That doesn't apply to this bug. Maybe the limitation should be addressed in the microdata specification, but that's still an HTML5 issue. 85604 3 robin 2013-04-05 14:07:23 +0000 This mentions microdata, but it really is an HTML bug. 121089 4 mike 2015-06-16 12:04:30 +0000 This has been discussed years ago and it's clear there's never going to be sufficient implementer interest in this, nor have there been other commentors weighing in to voice support. So there's not much point in continuing to keep an issue for this open here.