- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 07 Apr 2010 01:26:12 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: HTMLWG WG <public-html@w3.org>
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