Re: native elements versus scripted

On Tue, Apr 6, 2010 at 9:55 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

I need to clarify a bit of history here - as this sounds like there
may be a few  misconceptions.

I don't think it's accurate to say that historically the CSS WG  shied
away from defining styling for form elements - quite the opposite in
fact.

Frankly, it's more like, styling of form elements was explored and
specified by the CSS WG to a point beyond where browsers were at the
time, into a Candidate Recommendation[1], and then we (in particular
those of us in the CSS WG who were very interested in using CSS to
style form controls) waited for browser vendors to catch up.

[1] http://www.w3.org/TR/2004/CR-css3-ui-20040511/


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

Again I have to disagree.  Certainly in the late late 90s (1998,
1999[2]) and early 2000s, styling of form controls and specification
thereof was being vigorously pursued by the CSS WG (and XForms WG) and
multiple browser vendors.

[2] http://www.w3.org/TR/1999/WD-css3-userint-19990916

At the time successive releases of both Internet Explorer and Firefox
showed quite a bit of promise with allowing more and more aspects of
form controls to be styled as specified.

> Some browser engines, including WebKit in the
> early days, directly embedded true widgets from a platform native toolkit.

WebKit was the exception at the time.


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

I was (and am) very happy to see that this shift in opinion occurred in WebKit.


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

Depends on the browser and the control.  I can state that in Tasman we
got some controls to render purely with CSS (UA style sheet etc.).


> Market pressure and convergent
> evolution mean that the basic approach and degree of styleability have
> become more popular over the years.

Yes, this has also been very good to see.


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

Agreed. And some designers never saw it as a gimmick in the first
place, but rather, completely valid method of presenting a consistent
experience across their site or sites (rather than whatever
platform/device happened to be viewing the site).


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

Agreed.


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

Fully agreed.


> 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

Thanks for this background and perspective Maciej - it's quite useful.

I for one welcome the new <input> types in HTML5, and would very much
like to see them fully stylable when implemented by browsers.

Obviously the CSS3 Basic UI spec predated the new HTML5 controls and
couldn't not have taken them all into account.

However, I do think that quite a few aspects of styling form controls
ARE specified/handled by the CSS3 Basic UI spec (with a few selectors
in the Selectors spec itself) - likely due to many of these controls
being previously explored in the XForms specification - and thus
recommend that anyone that has an interest in styling of native form
controls *please* read CSS3 Basic UI and understand the capabilities
that we've already specified before making proposals for how to style
form controls.

http://www.w3.org/TR/2004/CR-css3-ui-20040511/

In particular take a look at the already defined CSS pseudo-classes
for styling form elements in various states (like :valid, :invalid)
and pseudo-elements for styling *parts* of form elements, especially
the more complex compound form elements.

I am also interested in hearing from the various browser vendors what
their level of support is for CSS3 Basic UI (which properties, values,
selectors), and what problems/challenges they encountered when trying
to implement them.

Thanks,

Tantek

-- 
http://tantek.com/

Received on Wednesday, 7 April 2010 07:38:22 UTC