Re: ISSUE-93 Change Proposal

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.

Regards,
Maciej


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:24:50 UTC