Re: native elements versus scripted

On Apr 6, 2010, at 10:26 PM, Doug Schepers wrote:

> Hi, Maciej-
>
> I agree with your take on this, and appreciate your drafting up your  
> rationale for revisiting the styling of controls.
>
> I think at this point, it might be more useful to discuss this in a  
> CSS context, rather than an HTML one.

That's a good point. I posted this as background material for HTML WG  
discussions, but this information should go to the CSS WG as well.

>  Regardless of whether or which new controls are included in HTML5,  
> I would like to see the control styling discussion continue in the  
> CSS WG.  Maybe you could raise this issue with the CSS WG, in your  
> capacity as HTML WG co-chair, if this group agrees it's an  
> interesting avenue?

I can definitely raise it on www-style as an interested individual,  
and ask Apple's reps to the CSS WG to bring it up in meetings. I don't  
know if I would feel comfortable saying it in my capacity as HTML WG  
co-chair, because I don't want to imply that my views here are  
endorsed by the HTML WG as a whole

I will repost my thoughts below to www-style and the conversation can  
continue there.

Regards,
Maciej

>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>
>
> Maciej Stachowiak wrote (on 4/7/10 12:55 AM):
>>
>> On Apr 6, 2010, at 7:33 PM, Shelley Powers wrote:
>>
>>>>
>>>> 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?
>>
>> Let me set the new elements under discussion aside for a moment,  
>> because
>> my intent here is to provide background, not wade into the debate.
>>
>> For classic form elements, like buttons and text fields, I think it  
>> is
>> definitely time to define clearly how styling works. Let me comment
>> below on why now.
>>
>>> 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?
>>
>> 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.  
>> Certainly
>> in the late '90s, when HTML4 was developed, this was the thinking. In
>> addition, in the late '90s and early 2000s, it was not really clear  
>> at
>> the time whether rich styling of form controls was even compatible  
>> with
>> browser implementation strategies. Some browser engines, including
>> WebKit in the early days, directly embedded true widgets from a  
>> platform
>> native toolkit. And heavily customizing buttons or other form  
>> controls
>> was seen as gimmicky and poor UI design. Since then, a number of  
>> things
>> have changed:
>>
>> 1) Convergent evolution has led browser engines to support more and  
>> more
>> styling. Four years ago, we went through a major effort to make form
>> controls highly styleable in WebKit. We abandoned use of true Cocoa
>> controls in exchange for rendering all controls primarily with the
>> engine's own layout and rendering code. Here is a blog post from that
>> era that shows just how customizable text fields were, even in those
>> early days: <http://webkit.org/blog/51/text-fields/>. Although I am  
>> not
>> privy to the internals of all browser engines, I believe all browsers
>> have some degree of custom code for form controls, because it is  
>> more or
>> less required for various aspects of Web compatibility. Market  
>> pressure
>> and convergent evolution mean that the basic approach and degree of
>> styleability have become more popular over the years.
>>
>> 2) Building rich, interactive applications making heavy use of the  
>> Web's
>> client-side technologies has become a really big deal. Form  
>> controls are
>> no longer just for queries or actions to be taken on a server - they
>> have become part of a toolkit for building applications, rich  
>> documents,
>> and content that spans the divide between documents and applications.
>>
>> 3) Use of custom appearance for certain controls has become more  
>> widely
>> accepted as a valid approach to HI design. This has been partially
>> driven by the Web, where sites have their own individual look and
>> flavor; partly by the evolution of native applications for Mac OS X  
>> and
>> Windows 7; and partly by new platforms like iPhone OS and Android.
>> Having a custom look for a button is no longer a gimmick, it is a
>> critical piece of the basic toolkit for application development.
>>
>> 4) Popular sites are applying a great deal of custom styling to form
>> controls. One example page we love to use here is <http:// 
>> google.com/>.
>> If you take a peek in, say, Safari or Firefox, you can see that  
>> Google
>> has put a lot of custom styling on the text field and the two <input
>> type=submit> buttons on their home page. This lets them have a custom
>> look while still working in old or obscure browsers, or in browsers  
>> with
>> script disabled, and to provide good accessibility while maintaining
>> fairly compact markup. But by styling form controls at all, they  
>> are in
>> a no-man's land in terms of standards. We need to bring this  
>> technique
>> into the real of interoperable-specified behavior.
>>
>> 5) Innovation in client-side Web technologies has gradually re- 
>> emerged
>> from a state of partial dormancy over the mid to late 2000s. The core
>> client-side technologies of the Web are all under active development,
>> not in maintenance mode as they have been for years.
>>
>> 6) While in theory you can build your own buttons and text fields  
>> using
>> <div>s, JavaScript, CSS, ARIA and contentEditable, that's a big  
>> cliff to
>> fall off of for a little bit of custom appearance. And it means  
>> that you
>> need to completely shift your whole implementation when you change  
>> your
>> mind about wanting a platform-native look vs. a custom look. A good  
>> UI
>> toolkit gives you the raw materials you need to fully build your own
>> controls from scratch, but also provides common built-in controls  
>> with a
>> good amount of customizability. Right now, we're not doing as well  
>> as we
>> could be for buttons and textfields, the most basic of all controls,
>> because you either rely on nonstandard behavior or fall off a steep  
>> API
>> cliff when you want a custom look.
>>
>> 7) Styling has evolved from a nice little enhancement to a key factor
>> that is critical to the experience of many websites.
>>
>> So that's my thought about why the HTML4 set of controls, at least,
>> should have fully defined custom styling.
>>
>> This is not necessarily in itself an argument for or against new
>> elements and new <input> types in HTML5. But I believe that to the
>> extent we add new controls, the same considerations apply and we  
>> have to
>> figure out how to style them. I hope this background information is
>> useful to the discussion.
>>
>> Regards,
>> Maciej
>>
>>
>>
>
>

Received on Wednesday, 7 April 2010 05:50:21 UTC