Re: Implementor feedback on new elements in HTML5

Tantek Celik wrote:
 > Re: spec on form control styling:
 >
 > http://w3.org/TR/css3-ui

That doesn't address the questions that actually tend to need addressing 
in form control styling, like "how do I style the dropmarker for a 
combobox" (which might not even be present) or "what does the 
'vertical-align' property actually do when applied to a text input" or 
"what should the 'padding' property do when applied to a checkbox".

It does define a number of interesting features, but doesn't help with 
the problem of it not being clear how existing CSS2.1 features should 
interact with form controls.

So part of the reason progress on CSS3UI is slow is that it's not 
solving the problems that really need to be solving.  In my opinion. 
It's certainly why I personally don't prioritize CSS3UI work higher.

 > ...., how much of CSS3UI does Mozilla implement?

Modulo bugs:

* Sections 4.1.1-4.1.5 (though a lot of this is only relevant
   for XForms for now; once we start implementing Web Forms we can
   apply things like :valid or :in-range to HTML too).
* Section 4.1.6 with a -moz prefix.
* Most of sections 5.1 and 5.2 with a -moz prefix, and with a
   very different behavior (e.g. setting background-* properties
   drops the native appearance instead of ignoring the
   background-* properties).
* Section 5.3
* Section 7.1 with a -moz prefix and an extra padding-box value.
   This section is likely to need substantial expansion to actually
   be able to leave CR; it leaves far too much underdefined.
* Chapter 8.
* Section 10.1

So what we _don't_ implement are:

1) ::value, ::choices, ::repeat-item, ::repeat-index pseudo-elements.
    Of these, only the first two are relevant to styling HTML, and even
    then only if the HTML spec defines what parts of HTML form inputs
    they match.
2) Chapter 6 (element icons).  Most of this can already be accomplished
    with content:url(), I think, so demand has not been high for this
    functionality.
3) Chapter 9 (resize property).
4) The CSS replacement for tabindex and such in section 10.2.  Less of
    an issue in HTML, where tabindex exists; section 10.2.2 could be
    useful, in HTML, of course.  Note that the interaction of tabindex
    and nav-index seems to be undefined in the spec; should tabindex just
    be treated as a preshint setting nav-index?  That seems to fall
    through the cracks between the specs.

-Boris

Received on Tuesday, 1 September 2009 17:12:09 UTC