Re: [whatwg] details, summary and styling
On Mon, 11 Apr 2011, Jukka K. Korpela wrote: 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. It is required. That doesn't force authors to do anything, though. 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. Making it required doesn't help user agents deal with pages where it is omitted. 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. It's easy to wrap them in an element for fallback purposes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] details, summary and styling
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/
[whatwg] details, summary and styling
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
Re: [whatwg] details, summary and styling
On 03/29/2011 03:27 PM, Wilhelm Joys Andersen wrote:
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?
FWIW I think that, from a spec point of view, it should just act as if
the first block box container in the shadow tree contained some
UA-provided text i.e. no magic parser behavior.
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;
}
::summary could be defined to just match the first block box element in
the details shadow tree. That way you could just write
::summary {color:green}
for both cases. I note that optimising for the non-conforming case seems
a bit unnecessary, however.
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.
Making the whole ::summary clickable would seem consistent with the rest
of the platform where labels are typically clickable.
Re: [whatwg] details, summary and styling
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
