Re: native elements versus scripted

--------------------------------------------------
From: "Doug Schepers" <schepers@w3.org>
Sent: Tuesday, April 06, 2010 10:26 PM
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "HTMLWG WG" <public-html@w3.org>
Subject: 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?
>

About "more useful to discuss this in a CSS context"...

I see input-styling problem as rather belonging to DOM than to anything 
else.
Consider select element with dropdown list

<select size=1>
   <option>...</option>
   <option>...</option>
</select>

De-facto this element consist (or can be thought as such) as having 
following:

<select>
   <caption>...</caption>
   <button>...</button>
   <menu>
       <option>...</option>
       <option>...</option>
   </menu>
</select>

<caption><button> and <menu> are "shadow" elements (AFAIR David's Baron 
term)

Now let's imagine that CSS has a selector that allows to select such 
"shadow" elements.
Something like:

select (caption) {  background:yellow; }
select (button) {  background:url(os:button-normal); }
select (menu) {  border: 1px solid black; flow:horizontal-wrap; }

If to think this way then from CSS we need just "shadow" CSS selector.
And the rest (recommended list of shadow elements our inputs are made of)
should be defined in HTML or HTML/Forms documents.

-- 
Andrew Fedoniouk

http://terrainformatica.com



> 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 06:47:55 UTC