Re: native elements versus scripted

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.  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?

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:26:14 UTC