Re: Styling of form controls

Maciej++

I totally agree with you, it would be really good to standardize how
to do the styling of form elements.

I have two questions though.

1) How do you suggest we deal with popups, such as the contents of a
select popup, which currently works very differently on a desktop
browser and let's say the iPhone. It seems that in Chrome, Google are
actually painting the popup using WebKit and supports styling, which
we for instance do not do for the Qt version of WebKit.

2) Background color vs native theming. In new input tags such as
type=email, it is possible to change the background to red if the
email address entered is invalid. As the author didn't style the input
element it will be shown as a native input field as expected, but most
toolkits do not support background color, thus writing a wrong email
might make the form change from native to CSS styled widget on the
fly, which is not very user friendly. How should we handle cases like
this?

Cheers,
Kenneth

On Wed, Apr 7, 2010 at 3:03 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> Hello www-style,
> I recently posted a message on public-html about styling of form controls,
> in which I call for CSS fully defining how it works. The main focus was the
> form controls that already exist in HTML4, but these concerns may become
> even more important with some of the new form controls and interactive
> elements in HTML5. The CSS standards community may want to mull over these
> ideas.
> -----
> 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.
> Regards,
> Maciej
>



-- 
Kenneth Rohde Christiansen
Technical Lead / Senior Software Engineer
Qt Labs Americas, Nokia Technology Institute, INdT
Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org

Received on Wednesday, 7 April 2010 13:49:50 UTC