- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 06 Apr 2010 22:49:47 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: HTMLWG WG <public-html@w3.org>
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