Also, there’s a problem with your solution with switching the display for the elements inside the details element which would make it have problems with elements that wouldn’t have a default display of block. The WHATWG recommendations specifies the default look for details like so:

details {binding: details; /* is a replaced element, thus technically has no style by default */}
details > _legend_wrapper {display: block; /* also has the arrow triangle thingy, but I won't write that here */}
details > _contents_wrapper {height: 0; overflow: hidden; /* everything inside details except the first legend element is to be wrapped in a virtual block (hence my div) which is then what has it's style changed when you expand/contract the details. The actual contents of the details stay untouched. */}
details[open] > _contents_wrapper {height: auto; overflow: auto;}

the DOM would then be:

details
..legend
..p the actual details

but what is getting styled would look like this:

details
..block_legend_wrapper (invisible to DOM)
….legend
..block_contents_wrapper (invisible to DOM)
….p the actual details

The legend is already a block element, so I just use that, but I emulate the contents wrapper with a div inside the details element which works, but is visible to the DOM of course.

Anyway, here’s where it doesn’t quite work: remove the wrapping div from the entire solution, and you’ll see Firefox trigger the vomit bug. Here’s a demo of that happening. Check out the markup delivered to Firefox, then check the rendered DOM (in Firebug), you’ll see they’re completely different. ;-(

Close, but interesting that the vomit bug doesn’t trigger if the details and legend element aren’t a direct decedent of the body element.

{details}
{legend}{span class=”legend”}Details{/span}{/legend}
{div}
{p}Detailed contents go here. They must be nested in a div unless I figure out a reliable way to move the original contents of the details element into a new div dynamically created. If you can help with that, I will be thankful; it’ll cut down on the extra markup required.{/p}
{/div}
{/details}

Once I am done with my solution, I will post a link to it here.

1. The open=”open” is valid, I suspect you had open=”true” or just ‘open’ as an attribute. It’s boolean, but not in the sense of it should be equal to true or false, it just needs to be present.

2. Firebug is showing me the rendered DOM which is what is being styled. So, the source code is one thing, the rendered DOM is the actual thing we’re interested in, and using Firebug, or the IE developer toolbar, we can see that the browser has changed the DOM to suit it’s parsing rules – hence this whole mess with the legend element.

@Lars Gunther – thanks for testing with the HTML 5 parsing turned on – and you’re right, it’s not going to be on by default until FF 3.5 has died out, ignoring IE for the minute – that’s going to be a long while! Which is what takes me back to using another element other than legend. Sending XHTML is fine, but not suitable for IE, and IE still and will continue to, have majority market – so we, as authors, need a solution that truly does pave the cowpaths.

Regarding the querySelector and querySelectorAll – I expect it to run against the rendered DOM, rather than the source. Keep in mind that this would then break if we modified the DOM, say changing the ID of an element, and ran querySelector – it should query the latest version of the DOM, and not the original source code that was delivered to the browser.

@Adam – the closest I was going by the description in the specs, but I’m no browser vendor, so I wouldn’t like to say! I’m assuming it looks like a normal p element with a triangle to the right that rotates when it’s open (again, this is going by the spec). Either way, without the triangle, it should appear, something like the normal legend + fieldset combo (I think!)