Re: native elements versus scripted

I agree that libraries could be used to add a lot of functionality
that is missing from HTML and add ARIA to make this accessible.

However relying on that still seems to have a few problems:

1. A lot of people don't use libraries. I still see lots of websites
that use hand rolled date pickers (for example using 3 <select>s) and
aren't otherwise using libraries.

2. What do you do in non scripted environments, such as HTML UAs other
than browsers?

3. You can't use scripting libraries to insert a date picker directly
in the markup.

4. How would a HTML editor insert a date picker? If it inserts a pile
of <div>s with ARIA, will another editor understand how to handle
this? While retaining styling etc?

5. This seems to go against the advice of ARIA which says [1]
"It is expected that, over time, host languages will evolve to provide
semantics for objects that previously could only be declared with
WAI-ARIA. This is natural and desirable, as one goal of WAI-ARIA is to
help stimulate the emergence of more semantic markup."

Do note that I certainly agree that styling is important. And in order
to reach its full potential, I think that we'll need a good bit of CSS
support for these new elements and controls. I suspect that figuring
out a good set of CSS pseudo elements would go a long way towards
where we need to be.

However I will note that <select> and <input type=checkbox> are
largely unstylable, but still have seen quite a success on the web
today. And I'll also note CSS is already powerful enough to style the
hidden attribute and the <figure> and <aside> elements. So I don't see
that lack of styleablility could be an argument to remove those.

[1] http://www.w3.org/TR/wai-aria/introduction#co-evolution

/ Jonas

On Tue, Apr 6, 2010 at 9:44 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> 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 20:30:11 UTC