- From: Shelley Powers <shelley.just@gmail.com>
- Date: Tue, 6 Apr 2010 15:26:34 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: HTMLWG WG <public-html@w3.org>
On Tue, Apr 6, 2010 at 3:24 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > Thanks for providing a Change Proposal for this issue! The chairs are > reviewing Change Proposals to ensure that they meet the required structure. > Here is our feedback on this Change Proposal (actually the version > subsequently uploaded to the wiki): > > (1) This Change Proposal includes all of the required sections with > appropriate content. The Rationale and Details sections seem sufficient. > > We believe this Change Proposal is well-formed and ready for consideration > by the Working Group. > > As a side note, be aware that a Change Proposal cannot stop anyone from > proposing any additional drafts they want. A Change Proposal can only change > existing drafts or propose new drafts. Thus, the following sentence cannot > be fulfilled by adopting a Change Proposal: "Do not spin it off into another > specification, or wrap it in a specification of its own." We suggest > removing this sentence for clarity. If this Change Proposal is adopted by > the Working group without that sentence being removed, then that specific > sentence will be considered inoperative. > Good point. I can make that edit. > Regards, > Maciej > Shelley > > On Mar 31, 2010, at 6:10 AM, Shelley Powers wrote: > >> Summary >> >> Summary: Eliminate the Details element, completely. Do not spin it >> off into another specification, or wrap it in a specification of its >> own. >> >> Rationale >> >> The HTML5 specification states: >> >> The Details represents a disclosure widget from which users can >> obtain additional information or controls. >> >> Two examples of the use of Details are given: one where additional >> information is hidden; the other, where form elements are hidden >> within a set of details elements. Whether the details body is shown or >> not is based on the presence (or absence) of the boolean open >> attribute. If open is present, the body is displayed; if not, the body >> is not displayed. User Agents are supposed to respond in some way to a >> user request to open the details element by setting this boolean >> attribute, and to respond to a user request to close the details >> element by removing this attribute. >> >> The purpose for the element, as provided by the editor, Ian Hickson, >> in the initial bug to remove it [1] is: >> >> "The <details> element is needed to provide an accessible way of >> reflecting a common application widget in HTML-based applications >> without requiring authors to use extensive scripting, ARIA, and >> platform-specific CSS to get the same effect." >> >> Before I address the Details element, generally, and the editor's >> stated purpose for the element, specifically, I want to discuss the >> state of the art of this type of behavior as it exists today. >> >> This type of behavior is well known and variously labeled a tabbed >> page, an accordion widget, or a sliding/collapsible menu/form/page >> section. The existing technology supporting this behavior is very well >> understood: >> >> * All widgets feature a caption/label and associated section pair, >> that may, or may not be enclosed within another container element. >> >> * A tabbed page widget typically features a layout where all of >> the labels are grouped and clicking a label displays its associated >> page. The first page is displayed, by default. >> >> * An accordion widget typically features a layout where all of the >> labels displayed next to each other, and clicking a label opens the >> label's section either directly beneath it, or to the side of the >> label. >> >> * An accordion widget also typically only has one section open at a >> time. >> >> * A collapsible widget, whether used in a menu, sidebar, or form, >> has a label and a section, and the section is display or collapsed >> only when the label is clicked. The collapsible widget's page section >> is not displayed, by default. >> >> * Control of the behavior for all three types of widgets is >> implemented with a combination of JavaScript and CSS. >> >> * For all widgets, clicking the caption displays or expands the >> body element if it is hidden or collapsed. >> >> * For the tabbed page, clicking the label for a new page also >> hides the previously opened page. >> >> * For the accordion widget, clicking the label to display a new >> section typically collapses the currently opened section. >> >> * For the collapsible widget, clicking the label when the widget >> is in the open state, collapses or hides the body section. >> >> * There's usually a visual element representing the state for an >> accordion or collapsible widget element—sometimes a triangle reflects >> the state of the body element, other times, a plus or minus sign is >> used >> >> * There's usually a visual element representing the state for a >> tabbed page widget—the background color of the tabbed page's label >> differs from the background color for the other labels. Other visual >> indicators may also apply. >> >> * For an accordion or collapsible widget, clicking the caption or >> label may display the body immediately, or it may trigger a timed >> event, whereby the body element is displayed in smooth incremental >> steps. >> >> * For an accordion or collapsible widget, when the widget is in a >> collapsed or hidden state, the body section does not take up page >> space. When expanded or displayed, content following the expando or >> accordion section is pushed down (or over, if the element is a >> vertical widget), making way for the content. >> >> * Best practices dictate that when JavaScript is turned off, all >> tabbed pages for a tabbed widget are displayed by default, and the >> labels either hidden by default, or aligned with the tabbed pages as >> headers. >> >> * Best practices dictate that when JavaScript is turned off, all >> accordion sections are displayed by default; the section labels may, >> or may not, be hidden by default. >> >> * Best practices dictate that when JavaScript is turned off, a >> collapsible widget's body section is displayed by default; the >> collapsible widget's label may, or may not, be hidden by default. >> >> >> As you can see, the tabbed page, accordion, and collapsible widgets >> are more complex and richer than one would assume from reading >> something such as the Details element. That's because in the current >> state-of-the-art for these types of widget, where such behavior is >> implemented with CSS and JavaScript, we have a higher degree of >> control over every aspect of the widget. >> >> Focusing specifically on the existing widget with behavior closest to >> the Details, the collapsible section, following is a comparison of >> control between how this behavior is implemented today, and how it >> would work with the details element: >> >> * The visual indicator representing the state of the widget can be >> modified using the JavaScript/CSS approach. At this time, the visual >> indicator for the Details element is controlled by the User Agent. >> >> * Expanding the collapsed portion of the widget can be implemented >> incrementally with the JavaScript/CSS approach. Tthe expansion of the >> collapsed portion of Details has two states: fully open, fully closed. >> There are no JavaScript controls to incrementally implement the state. >> >> * The expansion and collapse of a JavaScript/CSS collapsible >> section is totally under the control of the web page developer and >> whatever scripting libraries used. The details element is under the >> control of both the browser and potentially the web developer, though >> there is no way to cancel the details element's default behavior. >> >> * By default a well designed web page expands all hidden page >> sections if JavaScript is turned off; users have come to expect this >> encouraged behavior. By allowing an expandable section to exist >> regardless of scripting, we're introducing a new and possibly >> unwelcome web state. Moreover one, unlike Flash, Ads, or JavaScript, >> or even CSS, the user can't control. >> >> * By default, a well designed web page expands all hidden page >> sections if the page is printed (typically by providing a web page >> where all of the elements are present, as defined in the web page, but >> the JavaScript files have been removed). There is no way to turn off >> Details, as well as turn off JavaScript. In fact, we would have to use >> JavaScript to add the open attribute to the element in order to offset >> the default behavior for the element. >> >> * The details element is not accessible— there is no support for >> the element in any of the screen readers. There is WAI ARIA support >> for the collapsible section. In fact, ARIA support is currently built >> into many of the popular UI libraries, such as jQuery UI and the Yahoo >> YUI ARIA menu plugin, the Google Web Toolkit, and so on. >> >> >> By continuing the trend that has been established for the last decade >> when it comes to widget (dynamic application) development, we have a >> much greater control over every last aspect of how this widget >> behaves. Moreover, this control does not come at the cost of >> accessibility. If anything, with recent efforts related to WAI-ARIA, >> we're seeing a greater integration of accessibility into dynamic >> effects. >> >> So, the details element is not superior to the current >> state-of-the-art for this type of functionality. In addition, >> implementing a well defined and well understood JavaScript/CSS/ARIA >> behavior as declarative animation built into the HTML specification >> introduces the potential for explosive growth in HTML. >> >> Earlier, I listed several forms of web space widgets: tabbed pages, an >> accordion, and a collapsible section. Only the last option is an >> equivalent JS/CSS behavior comparable to the Details element. However, >> it is feasible to list all three because if there's justification for >> adding a declarative equivalent for one, there's equal justification >> for adding a declarative equivalent for the other two...or for the >> dozens of other commonly used, packaged JavaScript/CSS behaviors. >> >> Once we've opened this declarative element door, it becomes >> increasingly difficult to justify shutting it, again. This action >> could lead to a never ending set of behaviors being integrated into >> the existing and future versions of HTML—incorporating as elements >> that which was gracefully handled by JavaScript and CSS. Taking this >> action impacts not only browser makers, but also HTML editors, Content >> Management Systems, validators, and other tools, which have to >> increasingly expand and add new items, new objects, new behaviors. >> >> More importantly, there is no graceful way of integrating this new >> declarative elemental behavior in with existing JavaScript/CSS >> application development. The existence of a Details element fractures >> the clean separation between behavior, style, and structure that had >> existed to this point, and has served us well, as witness the many and >> sophisticated applications we use today. >> >> We have to return, then, to the question of why are we adding this new >> element? The HTLM5 editor has stated the reason is because of >> accessibility, but as I demonstrated, we have applications, tools, >> libraries, plug-ins, and widgets that already provide accessible >> collapsible sections. Not only is the details element not >> complementary to the existing implementations, we're sending a >> confusing message about what direction web developers and designers >> are supposed to follow. Do we encourage people to continue using >> JavaScript, CSS, and ARIA? Or do we provide hit and miss declarative >> animations—one element here, another element another time— that tell >> people that yes, use JavaScript/CSS/ARIA for this, but not for that, >> and maybe use them today, but not tomorrow? This very inconsistent >> direction will not only not support accessibility, it could very well >> generate a great deal of pushback against incorporating accessible >> solutions. >> >> Another rationale given in support of the details element is in the >> comment section for the bug that led to this issue: web designers can >> add collapsible web sections to web pages without having to get help >> from developers. However, designers can do this now, with any number >> of packaged libraries, using the same elements and attributes that >> they would use for a section that isn't animated. More importantly, >> the designers can do so now, and still have control over not only the >> appearance of the collapsible sections, but even aspects of the >> widget's behavior--choosing a library that allows the section to >> expand and collapse slowly, as compared to one that does so all at >> once. >> >> A third rationale for the details element is that it doesn't require >> JavaScript, and so we don't have to burden our pages with large >> JavaScript libraries. Well, I'm not sure what folks are expecting but >> I've not found libraries such as jQuery or Prototype to be >> prohibitively large. In fact, their use is so integrated into today's >> web world, that most CMS applications, such as WordPress or Drupal, >> include these libraries by default. Yes, and provide widgets in order >> to easily add collapsible menus, sidebar items, footer elements, and >> so on. All one has to do is typically pick an option from a list. >> >> Another aspect of the existing implementations, too, is that most >> libraries and widget developers understand well the importance of >> progressive enhancement. Based on this underlying concept, when script >> is turned off, and the page is opened, the widget is set to be >> expanded by default. So the individuals using these widgets never have >> to touch JavaScript, or modify their page elements based on whether >> scripting is enabled or not. The widgets just work, right out of the >> box. >> >> This same cannot be said with Details. Either the web page designer >> has to define a secondary page for use for a non-scripted, >> non-interactive environment, such as printing, or the designer is >> going to have add their own JavaScript to close all Details left as >> open, by default. >> >> The details element, and others like it, such as progress, are the >> wrong direction for the W3C to take, and for the HTML WG to pursue. >> WAI-ARIA is to accessiblity, as behavior is to JavaScript, as CSS is >> to style, as RDFa/Microformats/Microdata is to semantics, as HTML is >> to page structure. This separation of domains works, and by the >> proliferation of Ajax-like functionality we see today, it works well. >> I cannot see giving up the direction we've been following for the last >> decade, for the promise of a few elements now, and hundreds of >> single-purpose elements to come around in HTML 6, 7, 8, 9, and so on. >> >> To summarize, the rationale for removing the details element includes: >> >> >> * The type of behavior encompassed with details is well >> understood, and simple to implement with existing technologies. >> >> * Existing implementations of this type of behavior allow for an >> amazing number of variations in how the behavior is applied, giving >> web developers far greater control over the behavior. >> >> * There is WAI-ARIA support for this type of functionality, but >> there is no accessibility support for details >> >> * There are dozens possibly hundreds of widgets, libraries, >> plug-ins, and so on support this behavior, and can be as simple to >> implement as adding a class name to an element. >> >> * Many Content Management Systems, such as Wordpress and Drupal >> provide built-in support for these types of widgets >> >> * Introducing declarative animation into HTML also introduces >> problems with printed pages and other environments where scripting is >> disabled and the expectation is that such elements would be open, by >> default. >> >> * Introducing declarative animations as replacements for >> JavaScript/CSS/ARIA behaviors now, opens the door for a proliferation >> of such elements in the future, not only adding to the processing >> burden on browsers, but also adding to the complexity of HTML editors, >> CMS, WYSIWYG tools, and others. >> >> >> Details >> >> Based on the March 4th draft of the HTML5 specification, remove >> Section 4.11.1, which defines the details element, and all other >> references to it within the HTML 5 specification. This includes >> removing Section 10.4.3, containing a description of the details >> rendering. >> >> Impact >> >> Positive Effects >> >> Removing the details element allows us to continue to progress with >> our use of JavaScript, CSS, and ARIA to create interesting, diverse, >> and accessible dynamic behaviors. It also prevents a possible >> explosion of such declarative animations in the existing and future >> versions of HTML, which will adversely impact on browsers, HTML >> editors, validators, and other tools. >> >> We're free to continue using the tools we have now, rather than having >> to stop and change direction. And since this type of widget/behavior >> is so well understood and supported (through the concept known as >> progressive enhancement), we can turn off JavaScript if we don't wish >> the web pages we visit to use JavaScript, but still be able to have >> finite control over the behavior, as well as appearance of the widget. >> Best of all, because ARIA is being incorporated into these existing >> tools, we're adding accessibility to our web applications without >> having to change one line of code, or one line of markup. >> >> We're removing the potential conflict that something like the details >> element introduces. Today users have the ability to turn off Flash and >> JavaScript, but we don't have any way to control declarative >> animations. Taking control away from the users is not a direction I >> think we want to take in the HTML WG. >> >> Negative Effects >> >> This change will take some of the HTML5 editor's time to implement. In >> addition, if we wish to incorporate collapsible sections into our web >> pages, we will have to use JavaScript. >> >> References >> >> >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=8379#c13 >> >> >> http://test.cita.illinois.edu/aria/tabpanel/tabpanel2.php >> >> >> http://drupal.org/node/99973 >> >> >> http://docs.jquery.com/Plugins/Validation#Example >> > >
Received on Tuesday, 6 April 2010 20:27:07 UTC