- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 6 Apr 2010 13:29:15 -0700
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>
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