Fwd: native elements versus scripted

Sorry, I forgot the cc the list. I've been wary of hitting reply all lately.

Shelley


---------- Forwarded message ----------
From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, Apr 6, 2010 at 3:52 PM
Subject: Re: native elements versus scripted
To: Jonas Sicking <jonas@sicking.cc>


On Tue, Apr 6, 2010 at 3:29 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
>

I have to assume that most of the people who are doing the hand rolled
work are doing so because they want to play with the technology on
their own, or they did the work before the libraries existed.

But I'm not sure why you consider this on the cost side of the scale.

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

Well, I would say that the progress element is pretty useless whether
it's built-in or created via a library.

In fact, I'd rather you focus specifically on cost and benefits
perhaps related to the elements in my change proposals? I can't help
this would focus the discussion on specifics.

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

Are you talking about modifying the markup? Or inserting a date picker
into the DOM and associated it with the element?

Did you go look at the jQuery date picker example I pointed out?
There's a line of code where you pass it the identifier of the element
that has an associated date picker and that's it. Other libraries have
used a class name instead.

This is actually extremely common for most well designed libraries.

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

An HTML editor wouldn't. This isn't a HTML element. The elements to
make up the datepicker are inserted into the DOM, not markup. I would
say that's how Opera works now, but we don't have direction access to
the components.

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

In my opinion, and I'm not an accessibility person, I read this more
along the lines of: where it makes sense to have a new element, they
would rather people used the new element, with built in semantics. If
no element exists, then use ARIA. What matters is that accessibility
be covered.

What we're talking about now, is whether the new elements being added
into HTML5 are meaningful and useful -- for all purposes and all
people and all uses.

If not, then it does no good to bank on them for accessibility because
the use of these element will be very limited.

If an element is very meaningful, nothing else works as well, then not
only is it the preferred approach for accessibility, it's the
preferred approach for every other group, purpose, and what have you.

But I believe the statements being attributed to WAI-ARIA in this
regard are being misinterpreted. I doubt the originators of these
statements would expect them to be used to justify elements no one
really cares for, or is particularly in using. Especially if there's
no clear description and course for how accessibility is to be
incorporated into the element.

So I don't think we can really put the WAI-ARIA statements on the
benefit side of the scale, not when we also have ARIA being built into
many libraries -- and with increasing the awareness of ARIA for
developers.

Regardless of how many widgets we want to built into HTML5, we will
always have to increase awareness of ARIA among the developers. We
can't use widgets to try and bypass teaching developers good
development practices.

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

As I noted, the CSS WG is not chartered to cover the new form
elements. The CSS WG is not chartered to cover the old form elements.

I believe that trying to style native form elements is going to be
much more difficult than your statement would imply.

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

Again, though, these elements are part of the DOM, and can be styled.
The Date picker components are not accessible by us. All we can do is
cast a CSS styling over the whole thing, which unfortunately has
negative consequences on the actual date field, whether the date
picker is supported or not.

You may not have seen my following up emails on this.

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

Thanks for the comments Jonas.

I'd really love to hear your take on benefits and costs that you see
associated with the elements I'm covering in my active change
proposals. I don't want to stop people from discussing any of the
other new elements in this regard, I think it's a good exercise, but I
also need specific feedback related to the change proposals.

Thanks again

Shelley
> 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 21:00:00 UTC