Hi,
I'm currently writing tests in preparation for Opera's implementation
of <details> and <summary>. In relation to this, I have a few questions
about issues that, as far as I can tell, are currently undefined in the
specification.
The spec says:
"If there is no child summary element [of the details element], the
user agent should provide its own legend (e.g. "Details")." [1]
How exactly should this legend be provided? Should the user agent add
an implied <summary> element to the DOM, similar to <tbody>, a
pseudo-element, or a magic non-element behaving differently from both
of the above? In the current WebKit implementation[2], the UA-provided
legend behaves inconsistently from from an author-provided <summary>
in the following ways:
* Although it can be styled with rules applying to <summary>, it does
not respond to :hover or :first-child.
* With regards to text selection, it behaves more like an <input
type='submit'> than a user-provided <summary>. Text within this
implied element may only be selected _together_ with the text
preceding and following it.
* A different mouse cursor is used.
This indicates that it is slightly more magic than I would prefer. I
believe a closer resemblance to an ordinary element would be more
convenient for authors - a ::summary pseudo element with "Details" as
its content() might be the cleanest approach, although that would
require a few more bytes in the author's stylesheet to cater to both
author- and UA-defined summaries:
summary, ::summary {
color: green;
}
Furthermore, the rendering spec says:
"The first container is expected to contain at least one line box,
and that line box is expected to contain a disclosure widget (typically
a triangle), horizontally positioned within the left padding of the
details element." [3]
For user agents aiming to support the suggested default rendering, how
should the disclosure widget be embedded? Ideally, graphical browsers
should all do this in a similar manner, and in a way that allows authors
to style these elements to the same extent as any other element.
There are several options:
* A ::marker pseudo element[4].
* A default, non-repeating background image positioned within
the recommended 40 pixel left padding.
* A method similar to list-style-type or list-style-image.
* A magically embedded, unstylable widget.
I prefer the first, if possible. The default rendering could be something
like:
details summary::marker {
content: "▸";
color: black;
}
details[open] summary::marker {
content: "▾";
}
RTL might add some additional complexity here, however.
The spec also says:
"The user agent should allow the user to request that the details
be shown or hidden."[5]
Given, still, a user agent aiming to support the suggested default
rendering, with a pointing device (mouse, touch) available, which parts
of the <details> or <summary> element should be clickable?
The spec only says:
"[The disclosure] widget is expected to allow the user to request that
the details be shown or hidden.
That's a rather small clickable area, which might get troublesome to hit
on a fuzzy touchscreen or for someone with limited motor skills. I suggest
the whole block area of <summary>, too, is made clickable - as if it was
a <label> for the ::marker.
The behaviour for a JavaScript click() on the <details> and <summary>
elements should also be defined.
Whether or not the answers to the questions above should be part of the
spec or not, I do not know. But browser vendors should try to come to
some sort of a consensus here, to limit the pain of style-minded authors.
[1] :
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element
[2] : Tested in Google Chrome 12.0.712.0
[3] :
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-details-element-0
[4] : http://www.w3.org/TR/css3-lists/#markers
[5] :
http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element
--
Wilhelm Joys Andersen
Core, Opera Software
