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

[Jukka K. Korpela]

Wilhelm Joys Andersen wrote:

>    "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?

Since the situation raises implementation difficulties, it would be best to 
make the summary element required in a details element, i.e. to force 
authors to provide a summary. Later the requirement might be relaxed. But it 
appears to be an undue burden to require browsers to provide a default 
legend, which would need to be different for different languages. (Many 
browser vendors might not care, and then there would be an undue burden to 
_users_.) In general, anything that requires software to provide default 
widget texts is a much bigger problem that you might think if you have grown 
up in an English-only world.

>    "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.

As I wrote previously, the current wording is _overspecified_, not 
underspecified. What it describes should be treated just as a preliminary 
suggestion, while waiting for people around the world develop better ideas.

A key issue with the details element is that it does not degrade well. It's 
difficult to say how much this could be improved. In any case, the fact that 
the details themselves - the content of the details element excluding the 
summary element - do not constitute an element makes things rather 
difficult.

One might try to get _some_ decent rendering of the details element on 
non-supporting browsers by setting the height of the elements to something 
corresponding to one line (say 1.3em if your line-height is 1.3) and 
overflow-y: scroll (or its emulation, for browsers not supporting the 
overflow-y property). You could then add the scripted feature that on 
mouseover (or on clicking), the you don't really get the contents scrolled 
but instead the entire contents of the details element gets displayed in a 
box "layered" over the normal content (and closeable somehow). This would be 
based on the idea that people who browse the Web know what scrollbars are 
and realize that they indicate availability of additional information on 
request.

But maybe the very idea of the details element is really aimed at providing 
tools for widgets commonly used in application programs and system 
utilities, like opening and closing subtrees and items in directory listings 
or settings. The examples as well as the "expected" rendering seem to 
suggest this, but the definition proper says "The details element represents 
a disclosure widget from which the user can obtain additional information or 
controls." Saying that the element is not appropriate for footnotes seems to 
say indirectly (exception proves the rule in cases not excepted) that the 
details element _is_ appropriate for any other situation where an author 
wishes to make some information or controls disclosed on request only - even 
for something that we might alternatively use a parenthetic note in the 
text, or a link to additional information. But in such usage, would a 
disclosure widget, typically a triangle, in the left padding of the element, 
be appropriate.

My point is that if the details element has a fairly limited scope of 
intended use, this should be said clearly. And if it is meant to have a 
broad scope of use, its implementation might need to be quite different.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/