Re: native elements versus scripted

On Tue, Apr 6, 2010 at 9:09 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

Is it time, though?

We have the ability to create custom controls now that are completely
stylable and without having to introduce potentially dozens or more
new CSS attributes. All for implementing something natively that we
can already implement now.

If there was interest in doing this before, why is only now people are
asking these questions?

>
> Regards,
> Maciej
>


Shelley

Received on Wednesday, 7 April 2010 02:33:45 UTC