- From: Jukka K. Korpela <jkorpela@cs.tut.fi>
- Date: Mon, 11 Apr 2011 11:00:54 +0300
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/
Received on Monday, 11 April 2011 01:00:54 UTC