- From: Wilhelm Joys Andersen <wilhelmja@opera.com>
- Date: Tue, 29 Mar 2011 15:27:58 +0200
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
Received on Tuesday, 29 March 2011 06:27:58 UTC