[whatwg] <details>, <summary> and styling

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'