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 >> <firstname.lastname@example.org> 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/