Re: native elements versus scripted

On Apr 7, 2010, at 12:37 AM, Tantek Çelik wrote:

> On Tue, Apr 6, 2010 at 9:55 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>>
>> Historically, the CSS WG has shied away from defining styling for  
>> form
>> elements. This was seen as the province of browsers, and an area  
>> where
>> consistency with the platform trumped control by the author.
>
> I need to clarify a bit of history here - as this sounds like there
> may be a few  misconceptions.

Clarifications are appreciated. I think we largely agree on the  
ultimate goals, which is to make all form controls fully stylable with  
CSS.

>
> I don't think it's accurate to say that historically the CSS WG  shied
> away from defining styling for form elements - quite the opposite in
> fact.
>
> Frankly, it's more like, styling of form elements was explored and
> specified by the CSS WG to a point beyond where browsers were at the
> time, into a Candidate Recommendation[1], and then we (in particular
> those of us in the CSS WG who were very interested in using CSS to
> style form controls) waited for browser vendors to catch up.
>
> [1] http://www.w3.org/TR/2004/CR-css3-ui-20040511/

I previously thought that a lot of this module is actually the  
converse of what is discussed here, I think. It defines an  
"appearance" property which can make anything look like a button, but  
doesn't describe how ordinary CSS properties apply to something that  
already is a button, except in the case where you explicitly give it  
"appearance: normal". However, nearly every browser will allow some  
degree of styling of a button without explicitly specifying  
"appearance: normal". WebKit and Gecko at least will drop all  
trappings of the normal button appearance if you set enough of the  
right CSS properties, in fact. And this is what <http://google.com/>  
relies on, it does not use the appearance property at all. Similarly,  
it sets some CSS properties on the text input. Looking closer at the  
spec though, it has a start on suggestions of what CSS properties  
should apply when appearance is not normal.

I also think the basic UI module has some stuff that's not really  
relevant to HTML form controls, such as the "window", "desktop",  
"workspace", "document" and "dialog" apperance values, the icon  
property, and the icon value for the content property, among others.  
WebKit implements a lot of the properties in this module, but not  
those aspects, and I am not sure we will be interested in that kind of  
stuff. I am also dubious of specifying keyboard focus order in CSS  
instead of in markup.

Perhaps the right thing to do is to update and refocus the CSS3 Basic  
UI module. We also need support for styling compound controls. I'm not  
sure if that is better done by extending Basic UI or as a separate CSS  
module.

Regards,
Maciej

Received on Wednesday, 7 April 2010 07:54:22 UTC