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

[Wilhelm Joys Andersen]

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