<4DA05F1E.6070504@lachy.id.au>
Current votes: None.
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@cs.tut.fi> wrote:
>>> Tab Atkins Jr. wrote:
>>>
>>>> <details> is definitely something we want to make fully
>>>> author-stylable.
>>>
>>> I don=E2=80=99t. Who=E2=80=99s this =E2=80=9Dwe=E2=80=9D you are talk=
ing 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=20
their implementation of it in WebKit. We would like our implementations=20
to be compatible as far as author styling is concerned, and so it is=20
very useful to discuss the fine-tuning of CSS styling before we ship.=20
If we did not do this, then you and every other author would most=20
certainly complain when Opera and Chrome ship incompatible=20
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=E2=80=99t see crowds of authors yelling for
> author-stylability.
Authors have been yelling for author-styling in relation to many other=20
elements in the past. In particular, fieldset and legend are=20
paticularly troublesome because their default appearance and the effect=20
of applying various CSS properties is literally impossible to express=20
using CSS or XBL right now, and differnet implementations have slightly=20
different behaviour in some cases. This severely limits what authors=20
can do with those elements. Authors have also been yelling for more=20
ability to style form controls.
As far as details elements are concerned, our developer relations team=20
at Opera have been discussing these new HTML features with the web=20
developer community for a long time, and styling is absolutely among the=20
the top concerns that they pass on to us.
>>> Does it? Why do you imply the visual concept of a =E2=80=9Ddisclosure
>>> triangle=E2=80=9D, and how does that relate to the behavior proposed =
for
>>> =E2=80=9D::marker=E2=80=9D in some draft?
>>
>> I don't understand the question.
>
> Why does <details> need to have any =E2=80=9Ddisclosure triangle=E2=80=9D=
?
The default appearance needs a disclosure widget of some kind, either a=20
triangle or plus symbol or whatever. However, since these default=20
appearances will not suit all needs, it is essential that authors be=20
able to change this freely in their pages, which is why we need to=20
discuss the finer details of how the default styling is defined. This=20
includes defining suitable 'list-style-type' values for the open and=20
closed states ('disclosure-open' and 'disclosure-closed'), which authors=20
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=20
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=E2=80=
=99t
>>> bound to any =E2=80=9D::marker=E2=80=9D.
>>
>> 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
--=20
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/