[whatwg] Styling <details>

[Lachlan Hunt]

On 2011-04-08 23:20, Jukka K. Korpela wrote:
> Tab Atkins Jr. wrote:
>
>> On Fri, Apr 8, 2011 at 12:30 PM, Jukka K. Korpela
>> <jkorpela at cs.tut.fi> wrote:
>>> Tab Atkins Jr. wrote:
>>>
>>>> <details> is definitely something we want to make fully
>>>> author-stylable.
>>>
>>> I don’t. Who’s this ”we” you are talking about, and why do they want
>>> to make <details> author-stylable even before a single browser has
>>> _any_ support to the element, at the functional level?
>>
>> "We" being, I suspect, the browser community.
>
> Thank you for the clarification. I would prefer seeing _one_ decent
> implementatiom of <details> before considering any fine tuning.

We, Opera, have an internal implementation.  Chrome are also working on 
their implementation of it in WebKit.  We would like our implementations 
to be compatible as far as author styling is concerned, and so it is 
very useful to discuss the fine-tuning of CSS styling before we ship. 
If we did not do this, then you and every other author would most 
certainly complain when Opera and Chrome ship incompatible 
implementations that require vastly different approaches to styling.

>> If that's overreaching,
>> then I'm content to say that *I* want it to be fully author-stylable,
>
> The primary question, as I see it, is to get decent implementations in
> the first place. I don’t see crowds of authors yelling for
> author-stylability.

Authors have been yelling for author-styling in relation to many other 
elements in the past.  In particular, fieldset and legend are 
paticularly troublesome because their default appearance and the effect 
of applying various CSS properties is literally impossible to express 
using CSS or XBL right now, and differnet implementations have slightly 
different behaviour in some cases.  This severely limits what authors 
can do with those elements.  Authors have also been yelling for more 
ability to style form controls.

As far as details elements are concerned, our developer relations team 
at Opera have been discussing these new HTML features with the web 
developer community for a long time, and styling is absolutely among the 
the top concerns that they pass on to us.

>>> Does it? Why do you imply the visual concept of a ”disclosure
>>> triangle”, and how does that relate to the behavior proposed for
>>> ”::marker” in some draft?
>>
>> I don't understand the question.
>
> Why does <details> need to have any ”disclosure triangle”?

The default appearance needs a disclosure widget of some kind, either a 
triangle or plus symbol or whatever.  However, since these default 
appearances will not suit all needs, it is essential that authors be 
able to change this freely in their pages, which is why we need to 
discuss the finer details of how the default styling is defined.  This 
includes defining suitable 'list-style-type' values for the open and 
closed states ('disclosure-open' and 'disclosure-closed'), which authors 
may override.

>> However, the default visual behavior of <details> is suggested in
>> the HTML spec.
>
> ... And I would not take it as more than a suggestion in a work in
> progress, which is what it really is.

Yes, it is a suggestion. But as we are now implementing it, we are 
trying to ensure that the spec can be made clearer and more accurate.

>>> I know that many CSS property names are misleading. But
>>> list-style-type, as defined in published CSS recommendations, isn’t
>>> bound to any ”::marker”.
>>
>> It certainly is, in the Lists spec.
>
> Please cite the recommendation by its official name and/or URL.

http://dev.w3.org/csswg/css3-lists/#marker-pseudoelement

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/