Re: native elements versus scripted

Here's a bit of info on how control styling works, and the WebKit  
approach to it. This is provided solely as technical input for others  
to make their own judgment.

On Apr 6, 2010, at 9:44 AM, Shelley Powers wrote:

>
> Perhaps there will be follow up, but we've not have the ability to
> style form elements[6] in the past, only apply CSS to those aspects
> related to background and font color, border, font, and size. Of
> course, with the previous form elements, this is actually sufficient.
> The elements are simple, uncomplicated devices. The same, however, can
> not be said for the new elements, such as progress and meter, or the
> even more complex form elements, such as range, and the date and color
> pickers.

Relatively simple form controls, for example <input type=button>,  
<button>, <input type=text> or <textarea> are quite styleable. At  
least in WebKit and Gecko based browsers, you can completely control  
the appearance and literally any CSS property will work. I lack the  
visual design skills to give an attractive example, but border-radius,  
gradient backgrounds, text shadow, box shadow and border-image are  
among the many CSS presentational effects that will work. There is not  
much reason to use <div> soup for these.

Some controls, such as radio buttons and checkboxes, are less  
styleable by default, for reasons of Web compatibility. However, at  
least in WebKit, you can always drop into full custom styling via - 
webkit-appearance: none. Note that for even for buttons, we will try  
to recolor and otherwise adjust the native look until you either style  
it too much, or explicitly set -webkit-appearance: none.


>
> Even now, when we have two implementations of range to compare,
> Webkit's[7] and Opera[8], we can see that unlike check boxes or
> buttons, there is significant differences in the visual rendering of
> the elements. Also unlike check boxes or buttons, very little of these
> elements can't be styled, because many aspects of the element are not
> accessible via the DOM. It's unlikely we'll be able to change the
> overall structure of the element, the thumb control (color or style),
> even the color of the tick marks.

WebKit actually lets you style the thumb control separately. In fact,  
this is what we have in our UA stylesheet for input[type="range"]:

input[type="range"] {
     -webkit-appearance: slider-horizontal;
     padding: initial;
     border: initial;
     margin: 2px;
}

input[type="range"]::-webkit-slider-thumb {
     -webkit-appearance: sliderthumb-horizontal;
}

If you override those -webkit-appearance properties, you can use  
whatever custom appearance you like for the range slider and its  
thumb, using the full power of our CSS engine. You could even use SVG  
images to render the individual pieces.

In fact, essentially all WebKit form controls are going to end up this  
way, because we draw all controls with our layout engine, only using  
OS services to draw the default platform look of the individual  
control pieces.

The key to allowing flexible styling of controls with multiple moving  
parts, or "compound" controls, is defining pseudo-elements for the  
independent pieces of the control. In addition, controls with distinct  
states also need pseudo-classes.

For <progress>, the way we would likely approach it is to have a  
pseudo-class for the indeterminate state, and a psuedo-element for the  
currently filled portion. Our <progress> implementation is still a  
work in progress, so it doesn't allow quite that level of flexible  
styling yet.

The CSS WG has traditionally shied away from specifying how CSS  
properties apply to form controls. I think it may be time to revisit  
that decision. Custom styling of form controls is an important  
feature, and we will deliver a real benefit to authors if it works in  
a consistent way across browsers.

Regards,
Maciej

Received on Wednesday, 7 April 2010 02:10:07 UTC