Re: native elements versus scripted

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