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/