W3C home > Mailing lists > Public > public-html@w3.org > April 2010

Re: ISSUE-93 Change Proposal

From: Shelley Powers <shelley.just@gmail.com>
Date: Tue, 6 Apr 2010 15:26:34 -0500
Message-ID: <k2k643cc0271004061326g1e825f70n3d633e5f92266ceb@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:07 GMT