- From: Shelley Powers <shelley.just@gmail.com>
- Date: Tue, 6 Apr 2010 11:44:57 -0500
- To: HTMLWG WG <public-html@w3.org>
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