This article has been superseded. It’s here for historical reasons only. <details> now uses a <summary> element; <figure> uses <figcaption>.
You may recall that I blogged about legend not being so legend as the heading element for details or figure. After enough noise was made the spec was changed so that the heading and contents of these elements can now be marked up using the dt/dd combo.
Although not immediately obvious why it’s the right choice, it appeared to work for our needs…at first. Of course now, it’s been discovered that it’s actually a pretty bad idea.
How we got here
In short, details and figure solve a common design pattern and provide nice new semantic tags to solve that problem. A figure could be an image you’re referring to in an article or chapter of a book, and the details element allows the user to interactively show and hide the details of some piece of information.
Both elements can contain a heading element to label up the contents. For some reason, beyond this author’s understanding, these two elements, completely different in meaning, have been historically tied to using the same solution solve the problem how to markup the heading.
As I mentioned earlier, originally the proposed solution for the headings was to use the legend element, which proved to completely break in every browser (in new and interesting ways).
Skip forward to mid-September, and Jeremy Keith proposes that we solve the legend issue with the dt/dd combo, and Ian Hickson says:
That’s not a bad idea actually. Ok, done.
Before this was proposed there was lots of discussion about why we couldn’t introduce a new element to solve this problem, and Ian points out already 18 (or 22, I forget!) elements that represent some sort of heading. This is the argument for not introducing another new heading type element to solve the details and figure problem.
The problem with dt/dd
Ironically the problem isn’t with the dt part of the solution, it’s actually with the dd.
Dean Edwards (genius behind some very cool JavaScript and something that will soon blow your minds) has been testing these elements in detail and found a very serious issue with the dd in, guess what, IE6 & 7. I want to explain and draw attention to what Dean has found.
Styling a dd within details or figure (and probably other elements) bleeds to the next element.
By styling a dd red, and only the dd, here’s what it should look like (and does in IE8):
Where as in IE7 (and IE6), the red style bleeds in to the following p element (note the “this paragraph shouldn’t be red”):
What’s more, if you look back at the screen shots you can see the last paragraph says “Contents of first <dd>”. The result of that test is being generated by the following JavaScript:
document.getElementsByTagName('dd')[0].innerHTMLNotice how in IE7, the contents of the first dd‘s innerHTML is empty.
The problem here is that:
- IE7 and below can’t style a
ddproperly without it breaking and the style bleeding in to adjacent elements. - JavaScript, randomly, can’t see the contents of the
dd.
Is there hope?
There is a hack that fixes this issue. It’s pretty mad, but it does fix the styling issue. However the side effects from this hack are outright unacceptable and are so serious I would argue that the hack solution itself is a bug.
The hack is over at the public-html of W3.org, and involves stuffing an open object tag just before we close the head tag.
This isn’t a clean solution for including in HTML by hand, authors won’t remember or might get it wrong, so it needs to be perhaps automated as part of the HTML5 enabling script, right? It would have to be inserted using document.write() as the last part of the head element.
Dean went on to test this, and he found:
There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the <head>. If there are any scripts following the document.write() then they are not executed.
The really freakin’ important bit:
If there are any scripts following the document.write() then they are not executed
So, to answer the question: is there hope? No, not for the dd/dt combo. It can’t be styled properly and hacks will break JavaScript.
We want the details
We, as authors, want to make use of details and figure today. Waiting for IE7 to fall out of circulation before we start using these elements (as it’s been proposed a number of times on the IRC channel and mailing boards) is outright not going to happen. IE6 & 7 are going to be around for a good more number of years, certainly IE7 (IE6 has at least another 5 years in the beast).
We are going to start enabling the details interactive UI pattern using JavaScript whilst we wait for vendors bake it in to the browser, so the final proposed markup needs to work in all the browsers, including IE6 and IE7.
What are our current options?
- Give new meaning to an existing element (as we’ve already tried to),
legend,labelanddt/ddhave been tried, tested and failed. What else could we use? - Repurpose one of the existing new elements (keeping in mind that the dt/dd was repurposed so it should be a consideration).
- Create another heading element to solve this problem.
The problem is that the conversation seems to have lost steam (or certain Dean was starting to see the conversation go in circles). If you want to see these two elements make it the final spec, and correctly, head over to either the IRC channel or the mailing list, and get heard.
23 Responses on the article “dd-details wrong again”
[…] This post was mentioned on Twitter by html5doctor. html5doctor said: New post: dd-details wrong again, from Dr @rem – http://tr.im/Bwyv […]
Microsoft’s zombie children strike again!
I wonder if XHTML2.0’s <h> header element might be worth considering. If a suitable existing element can’t be found it’d be a nice element to add, as we’d get the added benefit of <section> plus <h> instead of ‘<h1> everywhere’ for new-style headings.
Following the thread of Oli’s comment, couldn’t the header and footer elements serve the purpose? If I’m remembering the spec properly, it says they can bopth be used repeatedly throught a doc to provide additional info about an element, no? Not perfect, but a thought…
Atg
Couldn’t agree more about waiting for IE to die. If you have to “adjust” the spec for IE6/7s problems then you might as well adjust for problems in other browsers, too. Otherwise, these are Microsoft’s own issues and no one elses. Why does the WG have to rescue them from the hole they dug themselves into?
For IE7 and below, as a fix would it not be better to wrap the dt and dd in a dl container?
e.g. if using conditional comments
<details>
<!--[if lte IE 7]><dl><![endif]-->
<dt>This is the legend of a <code>details</code> element.</dt>
<dd>This is the content.</dd>
<!--[if lte IE 7]></dl><![endif]-->
</details>
Semantically we lose the association of the heading with the content.
Thank’s for keeping this topic alive Remy. The discussion on the WHATWG mailing list seems to have petered out. I got the feeling that it was only myself and one or two others that are concerned about this issue.
I’m not against redefining existing elements in principle but in this case it causes too many side-effects. I think this can only be solved by creating at least one new element (probably two). Either that or drop
detailsandfigurefrom the spec.@Rob – sadly IE will never die, and tbh I’m cool with that, we’re working with the hand we’ve been dealt. What I wanted to do was kick this conversation back in to life and make sure that details and figure survive the spec. The reason for ensuring it works in IE is obvious – they have browser dominance, but equally when the legend element didn’t work in the other browsers, the model was changed.
@fofr – I don’t agree it would be better. Can you imagine in 5 or 10 years time explaining to a newbie why we have to innerwrap details and figures in dl elements for IE7 (which will still be around then). Baking hacks in to our markup, I personally feel, is a bad idea and we’re at the point in time where we can avoid it.
@Dean – no problem, I was carefully watching the conversation in the mailing list and I notice you seemed to hit a brick wall on getting the message through. The people I speak to and myself included really want to see details and figure make it in the spec, so it’s a case of being able to find the right solution. Thanks for finding the issues in the first place!
@aarontgrogg I quite like the idea of <header> with no headings as the rubric for figure and details. Or just a new <rubric> element? After all, now bb, dialog and datagrid have gone from the spec, there’s room for one more element ….
@dean I’d be really really pissed off if we had to drop those new elements from the spec. details especially is too useful. (I was wishing just today I could use it.)
There’s two bugs, a tracking issue, and an assigned action for this topic at the W3C HTML WG:
http://www.w3.org/html/wg/tracker/issues/83
You didn’t explain why we should care what happens in IE7 and IE6.
And if we care about those browsers, then why not remove the abbr element from HTML altogether while we’re at it? That element does not exist in those browsers and you have to hack around it just like you’d have to hack around dt and dd in this case.
Me, I hold out absolutely no hope at all for an HTML5-compliant renderer from Microsoft. I think Google Chrome Frame is going to be the hit of 2010 once it is out of beta. I’m working on a site right now that simply won’t run in IE without Chrome Frame and the publisher is very happy with that because it shaved 50% off the development costs and they are getting animations and all kinds of stuff that makes users go wow and business people who are stuck at 2001 era terminals with IE6 are not nearly on the radar like people who bought a computer that was made in this century.
So what do IE6 and IE7 have to do with the state of HTML5?
@Hamranhansenhansen – because IE6, 7 and 8 are a significant majority of the world’s user agents. I don’t like it. You don’t like it. But it is inconveniently true.
Chrome Frame may make your life easier, and site development cheaper, but it makes the browser an “accessibility black hole” and locks out visitors with disabilities. http://www.paciellogroup.com/blog/?p=444
@Hamranhansenhansen – yes, I did:
By that, I mean that since I’m an author, and IE have dominance in the market, we will care about how it renders.
Then you compared the JavaScript to enable styling the abbr element to these hacks. I’ve already explained in the article, but I’ll do it again. Doing a simple
document.createElement('abbr');to enable me to style the element is a no brainer. On top of which it’s included by default in the HTML5 shiv which is easy for authors to include as part of their HTML5 templates.The hacks that allow you to style the dd element are so obscure that authors won’t remember to include (creating a conditional open object element just before the head) – which is in fact why we’re using including a single script to solve the shiv problem. So, the answer is to include the dd fix in the HTML5 shiv, right? Wrong, including the
<object>hack to enable us to style the dd element in IE6 & 7 causes all scripts after that point in the markup not to be executed.So as you can see, there’s a huge difference between using
document.createElementto hack IE5-8 to enable styling, and the problem we currently face with the hacks to style the dd element.The HTML5 mantra is “pave the cowpaths”, it’s approach it to support the majority (if not all) the browsers on the market right now, and IE as you’ll know hold the majority of the market share. An honestly, if you think that users who are stuck on IE6 (who are usually going to be in corporate environment or some grandma that’s the extreme techo illiterate), who can’t and won’t upgrade to IE8, are suddenly going to be able to install a plugin to their machine that causes the browser to act differently, I’d suggest you’re kidding yourself (sure, some will, but most, I personally doubt in that category will), let alone the whole accessibility issues that Bruce points out above!
The bottom line is that we have time now to solve this particular problem without the use of hacks. We should do.
So what’s wrong with this?
<figure>
<header>This is the figure's header.</header>
<p>This is the content.</p>
<footer>This is the figure's footer.</footer>
</figure>
And only one of <header> and <footer> are required.
@Alejandro – thats pretty much what I was arguing in the IRC channel here: http://krijnhoetmer.nl/irc-logs/whatwg/20091013#l-554
However I understand the problem with this – and I’ll be posting a follow up blog post here shortly explaining how to style up figure and details and how to treat it.
Okay, let’s not use dt/dd. The hack is very, very ugly. And the reality is, we have to make some allowance for IE6 and 7. We do. We don’t like it, but we do.
Can anyone tell me what would be so heinously wrong with just marking up a the content of detail and figure with an h5 or h6 (indicating suitable subordination to the doc as a whole) and a paragraph? Must every title-like thingie and accompanying content have a special contextual tag, or can we just be simpler about things?
Or is that just CRAZY talk? ; )
Couldn’t <figure> and <details> be treated just like <section> and simply indent and continue the document outline with <h1>-<h6>? Think of it as just another <section> but with additional semantics.
The problem is with the last part of it, whatever it is. Just swapping
dtandddin the example seems to fix the problem withddstyling… until we try to style dd as well.This is the common problem of old IEs (7 and before) — they completely ignore the closing tags for all sort of list items (
li,dtordd), closing them only implicitly, when the opening tag of the next list item or the closing tag of the list itself appears. I guess that it was done to ensure that the lists contain only allowed elements as direct children (for making the tag soup parsing easier).And IMHO this is the reason not to reuse any list-related tags in any context other than lists…
Just a thought: Microsoft is still supporting IE6 and IE7 and actively patching (security) issues in those browsers. Wouldn’t it be possible to ask Microsoft to patch this particular issue in IE6 and IE7 and distribute that patch the same as other patches for IE6 and 7? Chances are that people who will still be using IE6/7 some years from now will at least use a patched version, so imo it’s not too late to solve this problem at the source.
I am just about ready to give up on this. I have been arguing that dt/dd is bad since it changes the semantics as well as the syntax from its usage in dl, which is really bad from a teaching POV. To deaf ears. Dean Edwards et al have been arguing that the solution is bad from a technical POV. To deaf ears.
I really, really wish that something that actually was untested and thrown out like an “hey, this is an interesting idea” would not be carved into stone as it apparently has.
I think the problem is smaller than it seems. Why do you want to style the dd element? The only logical reason is probably to remove the margin on the left. It isn’t a huge problem if this style is bled to the parent since the parent probably doesn’t have a margin anyway.
For all other cases, you can either insert a span element inside the dd element and style the span, or put the figure or details element inside a div and style that div.
Appearantly, there’s a very simple solution to this problem. Yes, much simpler than the solutions presented here.
Read about it on my blog:
http://blog.jeroenvandergun.nl/7-html5-figure-and-details-do-not-break-in-ie
Since 30th January, the heading element for figure is now “figcaption”, replacing DT. DD is simply dropped from figure. The body of figure is everything inside the figure element except for figcaption and its contents.
Details is changed similarly, with the heading element for details becoming “summary”.
What about simplifying caption/legend/summary/figcaption by inventing *one* new element (e.g.
<h>, or if that causes problems with XHTML2,<cap>or whatever) and use it for the new elements, but also make it optionally equivalent to the old ones?So, e.g. you can use
<table><caption>or<table><h>equivalently and<details><h>as well.That way you have a standardised element for “inner headings” and have only *one* new element (and not two) and can potentially get rid of two more later on (or even now?).
Leave a Reply to Bruce Lawson