- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 29 Mar 2011 19:15:15 +0000 (UTC)
On Tue, 29 Mar 2011, Wilhelm Joys Andersen wrote:
>
> 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?
In the rendering.
> Should the user agent add an implied <summary> element to the DOM,
> similar to <tbody>,
No, that would be described in the parser section.
> a pseudo-element,
Not sure how that would work.
> or a magic non-element behaving differently from both of the above?
A better analogy would be the default text of an <input type=submit> when
it has no value="" attribute.
> 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.
Since there's no <summary> element, that's clearly a bug. Please file a
bug.
> * 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.
For text selection it should work like any other browser-provided text,
e.g. a list item number.
> * A different mouse cursor is used.
Odd, but I guess that's up to the UA.
> 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.
The disclosure widget is expected to work similar to form control parts,
or indeed the implied summary text.
> 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.
The intent is for it to be implemented as an XBL shadow tree.
> I prefer the first, if possible. The default rendering could be
> something like:
>
> details summary::marker {
> content: "?";
> color: black;
> }
>
> details[open] summary::marker {
> content: "?";
> }
That would be compatible with the idea of using XBL, assuming the binding
declares a ::marker.
> 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?
Depends on platform conventions.
> 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.
On Mac OS X it seems the label and the triangle can both be used to open
or close the details. I haven't tested other platforms. (IIRC, on Windows
the usual convention is for the triangle and summary to be a button, or
some such.)
> The behaviour for a JavaScript click() on the <details> and <summary>
> elements should also be defined.
It is (nothing happens except event dispatch, since those elements are
not defined as having acivation behaviours).
> 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.
Yeah. The same applies to all the other form controls. I was hoping to
define this in much more detail with XBL, but since XBL hasn't been
implemented it makes it harder to do that. I continue to hope that we can
do something with XBL or a derivative in the future to address this.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 29 March 2011 12:15:15 UTC