native elements versus scripted

I wanted to write a follow up post related not just to a couple of my
change proposals (progress[1] and meter[2]) but to all of the new form
elements, especially those packaging more complex behaviors.

Earlier, Steve addressed the issue of ARIA and accessibility built
into native elements[3]. He brought up a point that led into a tangent
that occurred off this list. What he said was:

"Furthermore, until native controls of any type are styleable to suit
developers desires, they will continue to just make things out of
elements that suit their visual styling needs and so many natively
available controls will still not be used in some situations, as
developers will prefer custom controls. Again, in these cases ARIA
makes the difference between a control being usable or not by people
with disabilities.

Even when ALL elements are stylable to suit developers needs, they
will still create custom controls that are not part of HTML5's tool
set, so again ARIA will be useful in helping to make these controls
understandable for AT users."

Off this list, Doug Scheper focused on the ability to style form elements[4]

"Your concern about styling is a real one.  So, rather than focus energy
on removing these new controls, why not devote some time and energy on a
proposal to the CSS WG on how to style all form controls, including
these new ones?  There are lots of new CSS features being implemented
which could be repurposed for that cause, like the corner rounding in
the borders spec, gradients, animations and transitions, etc.
Basically, any effect you can apply to create a "custom control" with
the look and feel you want should be applicable to actual form controls.

What is needed for this is a detailed compendium of the various possible
parts that any form control would be comprised of; for example, there
were some proprietary Microsoft scrollbar-styling properties
(scrollbar-base-color, scrollbar-track-color, scrollbar-face-color,
scrollbar-highlight-color, scrollbar-3dlight-color,
scrollbar-darkshadow-color, scrollbar-shadow-color,
scrollbar-arrow-color) that I used on one of my earlier sites, and I got
a lot of positive comments on it.  Naturally, not all UAs would have all
the same parts in their own controls, but a defining a superset would
let designers get at the vast majority of them (possibly as
pseudo-elements, for ease-of-use with selectors).  A good place to start
is to look at the various custom controls that script libraries define,
and see what parts of those are stylable in each of those libs.

How much nicer for designers and developers would it be for them to use
the CSS skills they already have to style their controls than to have to
buy into one or more custom libraries to build them?"

To which Tab Atkins responded with[5]

"Officially, form controls are "out of scope" for the CSSWG.  But it's
quite obvious that browsers *do* apply CSS to form controls, and there
is some interest in the CSSWG to specify precisely which properties
apply and how.  We still can't get *too* precise about it, because
browsers need the ability to innovate the display and manipulation of
controls on specialized devices (frex, I love Opera Mini's display of
<select multiple> - much better than any display of such on current
desktop browsers!).  But we can certainly do *something* for this."

Perhaps there will be follow up, but we've not have the ability to
style form elements[6] in the past, only apply CSS to those aspects
related to background and font color, border, font, and size. Of
course, with the previous form elements, this is actually sufficient.
The elements are simple, uncomplicated devices. The same, however, can
not be said for the new elements, such as progress and meter, or the
even more complex form elements, such as range, and the date and color
pickers.

Even now, when we have two implementations of range to compare,
Webkit's[7] and Opera[8], we can see that unlike check boxes or
buttons, there is significant differences in the visual rendering of
the elements. Also unlike check boxes or buttons, very little of these
elements can't be styled, because many aspects of the element are not
accessible via the DOM. It's unlikely we'll be able to change the
overall structure of the element, the thumb control (color or style),
even the color of the tick marks.

The same applies with progress and meter, though there is no
implementation of these yet. There is a description of the elements in
the HTML 5 spec:

"When the progress binding applies to a progress  element, the element
is expected to render as an 'inline-block' box with a 'height' of
'1em' and a 'width' of '10em', a 'vertical-align' of '-0.2em', and
with its contents depicting a horizontal progress bar, with the start
on the right and the end on the left if the 'direction' property on
this element has a computed value of 'rtl', and with the start on the
left and the end on the right otherwise.

User agents are expected to use a presentation consistent with
platform conventions for progress bars. In particular, user agents are
expected to use different presentations for determinate and
indeterminate progress bars. User agents are also expected to vary the
presentation based on the dimensions of the element."

There is very little in this about how progress bars are rendered
other than default size, which we should be able to change. And that
the presentation should be specific to the platform, though as I
showed with Opera and Webkit and the range element, this leaves open
the door for a great deal of interpretation.

Still, there are aspects of these elements we can style, such as size.
They are, after all, part of the DOM. However, other elements have
components that are not part of the DOM.

Taking a look at Opera's date picker[9], the object that opens when
you click on the input field is not the object that is part of the
DOM. In documentation for Opera, I could find no way of attaching a
new font to this object, increasing its size, changing its colors,
changing its position, or any other aspect of its visual appearance.
Not using CSS. In fact, not at all.  Currently, the font is very hard
to read, the object is very plain, and crowded, the appearance
underwhelming, the location crowds the field. Even the appearance of
the input field is misleading: you're expecting a drop down, not a pop
up.

This isn't the same as what we have, now, with date pickers. For one
thing, we can select among a variety of date pickers, finding the one
that provides both the visual rendering pleasing to us, as well as the
behavior. Even with jQuery, there is more than one date picker plug
in. In addition, the date pickers are based on elements created within
the DOM, and therefore every last aspect of these date pickers can be
styled. The date picker as part of jQuery UI[10] is not only is
completely keyboard accessible, it can also be customized. You can
change month names, what day starts the week, and a host of other
options, and every last bit of it can be individually styled. You can
even download pre-packaged themes to style the object.

There's also behavioral characteristics. There are no new events for
date and color pickers, other than what impacts on the element,
itself, such as the value changing. Since the library variations are
based on the DOM, any event that can be triggered on, say, a span, a
link, or a div, works with the library date and color pickers.

There's also little we can do to change behaviors. Returning to the
HTML5 form element page that Bruce Lawson put together[13], and which
forms the basis for my screen shots, if you don't put a value in the
first field that is supposed to be required, and then submit the form,
the form element field gets colored red, and blinks, and a box with an
error message opens underneath[11]. We can't control the message box
appearance, change the message, or control whether the required field
blinks, the color it blinks, and how many times it blinks.

The reason I want to bring this up is that there may be
misunderstandings about how much we can customize the native variation
of these elements. There really is little we can do with these
elements, other than use as is. Even the data values for these
elements are constrained. We can't support an rgb or rgba format with
the color picker, because all it knows is hexadecimal. It certainly
doesn't understand the alpha value. Custom libraries recognize this,
which is why they typically provide options for what type of
formatting is used with the returned value.

So, who cares? After all, if people want something more, something
they can customize, they can continue using the libraries. And if
people don't want to use libraries, and they don't care what these
form elements look like, or how they behave, they can use the native
elements. So, who cares? It's a win/win.

We should care. There is an associated cost with every new element we
add to the HTML5 specification. I believe that Ian Hickson once said
each new element costs a billion dollars or some such thing. I can't
remember the quote or find it. I don't think the actual cost will be a
billion dollars, but the cost is very real.

Existing WYSIWYG editors have to incorporate these new elements, into
bars that are already becoming over crowded. Vlad Alexander, who
created XStandard, wrote a post titled "Why do WYSIWYG editors hate
HTML5?"[12]. In it, he discussed the concerns WYSIWYG editors have
about the existing HTML5 specification--the confusing directions to
follow, the context dependencies, and also the sheer number of
elements being added. I can't remember the count, but I believe
there's about 30-35 new elements. On paper that may sound trivial but
to a tool developer, that's an enormous number of elements they have
to incorporate into their tools.

Tools that validate, that debug, that create, or that build all have
to be edited and updated for the new elements. We can't ignore, then,
that there very real costs to each of these elements. We can't just
blow off these costs with a "So what".

There's also costs for applications. True, Content Management Systems
(CMS) use libraries today, and it is very unlikely they'll incorporate
the new HTML5 elements into their admin pages in the future. So
there's no cost to them, at least for form elements.

Not.

There is a real cost for them for some of the other new structural
elements. Now, they'll have to consider providing variations of
themes: one for HTML5, one not. How content is automatically generated
in a template system may have to change, perhaps even drastically,
adding significant complications. In addition, many CMS tools also
provide ways for people to build forms for adding new types of data.
So even with form elements, there is a cost to CMS tools, and to the
various module and plug-in developers that provide add-ons for these
systems.

There's a host of tools that provide validation and correction, such
as htmLawed and others. Each of these will have to be edited to
include all of the new elements, in all their various HTML/XHTML
serialization glory. I expect an significant increase in application
size and complexity when HTML5 support is added.

We also have costs in how some of these new JavaScript-less elements
should behave. Right now, the user has control over the page, and can
turn off JavaScript and Flash. They do no have this control over a
declarative element, such as details, or a progress element, or form
validation. There could be related problems with figuring out what
happens to the elements when the page is printed? What happens if the
person turns off JavaScript and isn't expecting any collapsed
sections?

Some would consider all of this a benefit. After all, we can still
validate the page even with JS turned off, and save a round trip to
the server. Others will consider this a definite cost, in that we're
breaking user expectation, as well as introducing declarative elements
and animations into an environment without necessarily understanding
the impact of doing so.

There's a cost on the human side, too. Additions and changes to our
favorite editors seems trivial but it is a cost, both in having to buy
a new version, as well as learn the changes. There is cost associated
with having to update various libraries, books, documents, and what
not. I'm not adverse to being able to sell new books, but throughout
the web publication environment, there will be significant costs
associated with each new element.

In the discussion, Laura mentioned another factor, in that we've been
telling designers and developers for 15 years now to separate
presentation from function from structure[14]. Reversing this trend
does send an complicated message to the web development/design
community. There is a cost, in credibility, if nothing else.

I hesitate to open the door with mentioning accessibility, but there's
also an additional cost associated with built-in elements. The
accessibility folks will now have to work with each browser's
implementation of the built-in objects to determine how it provides
accessibility. There is no consistency to how the browsers implement
the objects, such as a date picker, other than the minimal constraints
specified in the HTML5 spec. However, the accessibility for each has
to be consistent, so this is going to be an interesting mapping
exercise. That's not to say that I don't understand that there's a
perceived benefit for having a built-in control--not having to depend
on the pesky developers--but there's also a cost.

These elements are supposed to "free" us from JavaScript, if I
understand their purpose, but it's unlikely that they'll completely
"free" most web application pages from the having to use any
JavaScript. There are still form fields that need validating that
aren't an email or color value. More importantly, we still have to
validate the data on the server side, regardless of what happens on
the client. We still have to provide pages that display errors found
on the server. Good design principle requires that we provide these
pages regardless of support for JavaScript on the client or not, and
adding these JavaScript free options isn't going to change this.

I find it very unlikely that anyone will mix the built-in HTML5
elements with elements from a library, and probably not use the
validation routines when they're using a JavaScript library. Why?
Because they're going to want consistent error handling, and there's
no way they have any control over the built-in error handling.

In addition, something like the progress element still needs
JavaScript. In fact, there's nothing about the built-in progress
element that simplifies the use implementing a progress element in our
applications using an existing library. It's definitely not a true
form element--it was only added to the form elements because Ian
wanted to use label with it. This element seemingly adds very little
when we compare it to the cost associated with adding it to the
specification.

Imagine a scale, with the new HTML5 elements on one side, and the
costs on the other. I'm not privy to all discussions about the new
elements, but I sometimes get the impression--and yes, it could be a
wrong impression--that we perceive the HTML5 elements as cost free,
and therefore the cost side of the scale is empty. Or we assume that
the only cost is to the browser companies, and if the browser
companies are willing to create these elements, then everyone else
should be willing to adapt.

There is a cost, though, and beyond just to the browser companies.
"The more the merrier", isn't necessarily a design paradigm we should
be following.

Just from a purely personal perspective, I look at something like the
color picker and when I put it up on that cost scale, it fails. Why?
On the one side you have something built in, which is nice. No need
for a library. But on the other, you don't have any ability to style
the object, control its behavior, or even control the type of data
format, or the data itself (no alpha).

I then consider how often color pickers are used and in what types of
environments, and these are mostly used in applications that are
either extremely JavaScript intensive, or built in Flash. Stores don't
use color pickers for their online catalogs. In fact, there is rarely
a business need to provide a color picker. We can't choose from
millions of colors for that new car, new shoes, or even a new toaster.
Theming engines make use of color pickers, but they also make use of
JavaScript for other purposes, and have no qualms about using a color
picker built into their libraries.

So the scarcity of implementation is tossed on to the cost side of the
scale, in addition to my estimation of how much this will cost in
terms of having to implement it in WYSIWYG editors, HTML editors, CMS,
validators, debuggers, HTML sanitizers, and so on. In the scale in my
mind, the cost side for the color picker is far heavier than the
benefit side.

The same applies to the progress element, which is a change proposal
I've submitted. Both the built-in element and library versions require
JavaScript--a progress bar has to be updated to provide progress. So
there is no benefit for not having to use JavaScript with the progress
bar.

There's no real benefit in ease of use, either. Most progress bars are
uncomplicated beasties, especially if we use a library version. A
function call to update the value, that's it. The same applies to the
progress element. However, what I can do with the custom progress
elements is that I can control most aspects of their appearance. The
same cannot be said for the built-in.

The progress element is also another scarcely used element, and again
is typically part of an existing application that makes extensive use
of JS, or is built in Flash. It isn't as scarce as the color picker,
but it definitely wouldn't be widely used.

I compare all of this with the cost to WYSIWYG editors, validator
tools, sanitizers, form generations tools (there's a whole host of
these that will have to be modified), online and offline form
documentation, and so on, and again, to me the costs outweigh the
benefits.

Our mileage could vary, though. In the scales of your minds, you see
the scale soundly tipped on the side of the benefits of the elements.
But I'd like to read what's on the scales in your mind.  I believe
that we'll make better progress, and with less passion and acrimony,
if we discuss these items in terms of detailed lists of costs and
benefits, rather than as platforms on which to stand when marching
forth to do battle.

I can add all of this to my change proposals, but felt it might be
best to, first, send it as an email, for discussion.

(I apologize ahead of time, for all the typos I missed in this long writing.)

Shelley


[1] http://www.w3.org/html/wg/tracker/issues/96
[2] http://www.w3.org/html/wg/tracker/issues/97
[3] http://lists.w3.org/Archives/Public/public-html/2010Apr/0113.html
[4] http://lists.w3.org/Archives/Public/www-style/2010Apr/0076.html
[5] http://lists.w3.org/Archives/Public/www-style/2010Apr/0083.html
[6] http://www.456bereastreet.com/archive/200410/styling_even_more_form_controls/
[7] http://img.skitch.com/20100406-cyijmdghher3abneptuxjrex4p.jpg
[8] http://img.skitch.com/20100406-879r7ckcg26jn26urfwu6twnrh.jpg
[9]  http://skitch.com/shelleyp/n7xcm/operadatepicker
[10] http://jqueryui.com/demos/datepicker/
[11] http://img.skitch.com/20100406-kkxdidqi1sifkekkr8kup1mkq1.jpg
[12] http://rebuildingtheweb.com/en/why-do-wysiwyg-editors-hate-html5/
[13] http://people.opera.com/brucel/demo/html5-forms-demo.html
[14] http://lists.w3.org/Archives/Public/public-html/2010Apr/0124.html

Received on Tuesday, 6 April 2010 16:45:31 UTC