Category: Standards

Summary

Remove the srcdoc attribute.

Rationale

The original bug report for removing srcdoc provided the following change request[1]:

This recent entry does not have universal acceptance, and the group was still discussing it when the editor added it to the specification.

The supposed use case for this attribute is weblog comments, but concerns about HTML security have been resolved with weblog and other application comments years ago. In addition, support for this attribute could give the impression that online sites don’t need any other security, which is false. Script injection is only one aspect of security related to weblog comments, and considered a fairly trivial one at that.

This needs to be removed from the specification.

The rationale given by the HTML5 Editor for keeping this attribute:

Rationale: I’m happy to remove this attribute from the W3C HTML5 specification if that’s what the working group wants. The last time I removed a feature based on a bug report such as this, I started a minor war, however, so I suggest that you raise this via the change proposal process if you really feel this way.

According to the HTML5 editor, there is no rationale for keeping this attribute. That made this change proposal more difficult to write, because I had to base my arguments on guesses and scraped email messages.

There was a great deal of contention about this attribute before it was added. It spawned another issue (Issue 103) because of concerns about escaping the markup in the attribute, especially for XHTML. That this caused some difficulty for members of this group, who are defining the next version of HTML/XHTML, should give us pause, because knowing what must be escaped is going to be that much more difficult to the average web developer[2][3].

When asked the purpose for srcdoc, the HTML5 Editor replied that the use case for the attribute is weblog comments[4]. Because the srcdoc attribute works within a sandboxed context, the use of the attribute would prevent script injection in comments. Since this change was targeted to a specific use related to weblog software, I asked Matt Mullenweg[5], the creator of WordPress, one of the more popular weblogging tools in use today, about the usefulness of this attribute. He responded with[6]:

We haven’t had any HTML-level problems in comments in a while.

We use and maintain a library called KSES that we use for all sanitation, and it has served us well.

I brought Matt into the discussion for two reasons. The first is that I wanted to bring in an “implementor”, and demonstrate that an implementor, in the case of weblog comments, is the the group or individual responsible for the weblogging software. Too often this group is focused purely on browser developers as implementors, forgetting that browsers are not the only application group impacted by HTML5 changes.

The second reason was to demonstrate that no one from the weblogging community has asked for this, and it is very unlikely that many, if not most, of the weblogging community will use this uncomfortable, awkward attribute. The weblogging community has long had to deal with security problems, and has devised sophisticated tools and techniques to not only protect against script injection, but also SQL injection, the greater hazard for weblog comments, and even the accidental wayward insertion of a non-printing character in XHTML.

In point of fact, relying on something such as srcdoc can make a site less secure rather than more, because it only touches on one vulnerability, when we’re faced daily with a host of new and ever more sophisticated threats[7].

So the use case is heavily flawed. What are the other issues associated with srcdoc? I’ve already mentioned the concerns about escaped characters, and how this will differ between HTML and XHTML, which in itself will discourage its use with most applications like Content Management Systems. Are there other issues?

Another issue is when something like srcdoc can be used, and if the restrictions of the use are such as to defeat its use. This attribute can’t be used effectively for potentially years in the future, because web browsers don’t print out what’s contained in the attributes—not unless specifically directed to do so[8]. Until then, the fallback is used, which is the iframe’s src attribute. In the meantime, our existing applications that do provide security become more sophisticated, more capable, more tightly integrated, until by the time we could use srcdoc effectively, few of us will even remember what it is, and fewer still, would be interested.

An alternative to srcdoc was suggested in the discussion surrounding this attribute. Instead of embedding markup in the attribute—something that has been actively discouraged for some time— we can use a data URI with the src attribute, getting the same functionality that can be more quickly usable and won’t require us to embed markup in an attribute. However, the data URI has its own challenges, specifically the fact that the data would be printed out without the security controls in legacy browsers [9]. Again, though, using a data URI in an iframe src attribute would most likely never be used for weblog comments. I find it unlikely that any approach related to the iframe and sandboxing will ever be used with weblog comments, so it might be best if another use case is used to attempt to defend this attribute.

One use case that does come to mind are the plug-ins we drop into our web pages. The source of the plug-in comes from an external site, which could be cause for alarm. However, plug-in security is not related to the srcdoc attribute, so I have a hard time determining what use case would apply. Perhaps there are none, in which case, there’s even more of a reason to remove this potentially harmful, most definitely problematic attribute.

Details

Remove all references to the srcdoc attribute from the HTML5 specification. If such a removal results in a gap in coverage, consider following one of two paths: remove whatever other material is necessary to eliminate the gap or work with the W3C HTML WG to come up with an alternative approach, if one can be found.

I would also strongly suggest finding another use case, if you want to pursue this type of functionality.

Impact

Positive

Removes a confusing, potentially harmful, and not really usable attribute, either forcing us to re-address the issue, or to consider dropping this particular subset of web page security from the HTML5 specification. Perhaps there are some aspects of the web that cannot be managed by browsers.

Negative

Requires some of the Editor’s time to make the change. Could potentially leave a gap in coverage, if this subset of security is still of interest. Would require more work in the HTML WG. However, counter proposals to this proposal might be able to provide effective alternatives. Or not, if none really exists.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8818

[2] http://www.w3.org/html/wg/tracker/issues/103

[3] http://lists.w3.org/Archives/Public/public-html/2010Mar/0431.html

[4] http://lists.w3.org/Archives/Public/public-html/2010Jan/1193.html

[5] http://lists.w3.org/Archives/Public/public-html/2010Jan/1223.html

[6] http://lists.w3.org/Archives/Public/public-html/2010Jan/1337.html

[7] http://lists.w3.org/Archives/Public/public-html/2010Jan/1318.html

[8] http://lists.w3.org/Archives/Public/public-html/2010Jan/1325.html

[9] http://lists.w3.org/Archives/Public/public-html/2010Jan/1346.html

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¹ 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 other 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. It 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 so on.

Details

Based on the March 4th draft of the HTML5 specification, remove Section 4.11.1, which defines the detals 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, tools, and so on.

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, we can do so without having to use JavaScript if we don’t wish 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

Summary

Summary: Remove the progress element.

Rationale

In the bug associated with this issue[1], the HTML5 editor, Ian Hickson wrote as rationale for turning down the change request:

Rationale: <progress> fixes a serious accessibility problem with dynamic apps, and accessibility is important.

I have to make a guess about what serious accessibility problem progress solves, since the editor did not specifically state it. I’m assuming the problem is the fact that the information given visually by the progress bar is not vocalized by screen readers.

According to the HTML5 specification, there are two types of progress element: indeterminate, like a throbber, and determinate, like a progress bar. The indeterminate progress element is like the many we’ve seen in web pages—it’s a simple animated graphic that basically implies, “working…”. The determinate progress bar is like those we’ve seen where a bar is filled in from let to right, the amount filled in representing the completion status of a task.

Something like a progress element is useful, which is why we’ve had graphical and JavaScript/CSS based progress indicators for over ten years now. I created my first progress bar using a small GIF element and a timer close to 15 years ago for my first book on JavaScript.

Addressing the individual types of progress element, beginning with the indeterminate, there are indeterminate progress graphics that spin and pulse, and twitch about, all with an alt text along the lines of “The task is in process”, or the like. There is absolutely nothing that the indeterminate state of the progress element provides that we don’t already have, and yes, which is accessible, too. More accessible, as there is nothing in the specification about the element that specifically addresses accessibility. If we want more, though, we can also annotate the progress indicator with WAI-ARIA values, as discussed next.

I’m assuming that the greater concern about progress indicators is related to the second of the progress element types, the determinate progress bar, which provides indication of how far along the task is, and how far it has to go. As Mozilla demonstrated[2] some time ago, though, we’ve had accessible progress bars for some time now, thanks to the WAI-ARIA effort. In particular, the use of role=”progressbar”[3], with associated ARIA states, aria-valuenow[4], aria-valuemin[5], aria-valuemax[6], and the optional aria-valuetext[7], provide all the information that’s necessary to ensure that the progress of the task can be tracked by those using a screen reader.

From an accessibility perspective, using the progress element isn’t simpler than the ARIA values. The min and max values, whether ARIA or progress element, are statically assigned in the associated element, and the current value is updated based on the progress of the element. What does differ is that the progress element does have a visual indicator that is automatically updated. Unfortunately, though, it’s a visual indicator we have no control over. What we see, is what we get. It will differ based on operating system and user agent. We only have minimal control over how the element can be styled.

Compare that to the options we have available in various libraries today. There are sites that provide the ability to create our own throbber (indeterminate progress)[8], as well as dozens if not hundreds of existing images freely available on the web that we can use. Annotate with a little ARIA, and we’re set.

As for indeterminate, there are too many available libraries for this functionality to list, but I wanted to specifically point out the jQuery UI progress bars[9], as jQuery UI does have ARIA accessibility built into the library. Dojo’s widget library Dijit has promised complete ARIA integration, and already made strides in that direction, especially with the progress bar[10]. So has the YUI 2 ProgressBar[11], as well as other popular libraries.

A decade ago, when HTML4 was newly released, something like progress would have been welcome. At that time, support for JavaScript and CSS was limited, and accessibility support was non-existent. That was years ago. Now, there are several progress bar options available that are well designed, fast, efficient, accessible, and which we can use as easily as we use CSS now. They are truly plug-and-play simple. Not only do these libraries and plug-ins and packaged widgets provide the progress element’s functionality, they do a superior job, both from an accessibility perspective, and the fact that they work now. They also provide user options for styling and behavior far beyond what we could ever have with the progress element, and how we style the progress bar packaged widgets transcends both browser and operating system, to provide a nicely consistent appearance and behavior.

Details

Based on the March 4th, 2010 draft, remove Section 4.10.16 and Section 10.4.13 and any references to either and to the progress element.

Impact

Positive Effects

Removes another new element in the rather large pool of new HTML5 elements. This reduces the burden on all user agents, including browsers, editors, and so on. It’s important for the HTML WG not to introduce new elements that are redundant considering the state of supporting technologies today, such as CSS for styling, JavaScript for behavior, and ARIA for both semantics and accessibility (and even Canvas and SVG, if we want to get fancy with graphics). We shouldn’t be creating single-purposed elements unless there is no existing functionality that can serve the purpose of the element, and that’s definitely not true with progress bars.

Negative Effects

Will require some of the Editor’s time to make the change. Since the element has not been implemented in any browser or other user agent (that I’m aware of), there should be no cost associated with having to remove support for the element other than editing the specification.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552

[2] http://www.mozilla.org/access/dhtml/progressbar

[3] http://www.w3.org/TR/wai-aria/roles#progressbar

[4] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuenow

[5] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuemin

[6] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuemax

[7] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuetext

[8] http://www.ajaxload.info/

[9] http://docs.jquery.com/UI/Progressbar

[10] http://docs.dojocampus.org/dijit/ProgressBar

[11] http://developer.yahoo.com/yui/progressbar/

Summary

Summary: Remove the meter element.

Rationale

The rationale given by the HTML5 editor[1] for keeping the meter element is:

Rationale: We have to have <meter> if we have <progress> because otherwise people will abuse <progress> to get gauges, leading to bad accessibility.

It’s difficult to write a change proposal asking to remove the meter element, because there’s so little justification for keeping it. That we need to have a meter element because people supposedly will use the progress element incorrectly means we either have not defined the progress element well enough, or we’re trying to prevent people from using what seems to them to be the natural element to use.

The problem associated with the HTML5 meter element is that it is almost identical to the progress element: a long flat rectangle that has a minimum and maximum value and a current value, with the bar filled in up to that current value. However, if you search online on the term “gauge widget” almost all cases reflect a circular gauge, not a progress bar-like object.

Most gauge widgets online are also created from various libraries and toolkits, such as Google’s Visualization API[2], the Dojo Toolkit Analog Gauge[3], or the Dojo Bar Gauge[4], which does have a bar-like image. All have a more sophisticated interface that what we could expect from a built-in HTML5 widget. In fact, the HTML5 built-in gauge could be created using one div nested in another, with a different color of background, and with a sized width equal to the gauge percentage.

As for the semantics and accessibility of the widget, I would imagine that the ARIA role of “progressbar”[5] and associated state values indicating the low and high values, and the current value, could be as usable for this type of bar gauge, as they would be for a progress bar. After all, the way to tell this type of bar gauge from a progress bar is the context of the use. In fact, the text description of the gauge that’s recommended for the HTML5 meter element would also work for any of the gauge libraries.

Regardless, if the current ARIA progressbar role is not appropriate, or the text description is not sufficient, it’s better to work with the WAI-ARIA folks to derive the appropriate role and states, because a gauge such as the HTML5 meter specification is no different than a gauge that can be created in something like SVG, or other graphical environment. The need for accessibility in a gauge does not end with just HTML.

Details

Based on the March 4th version of the HTML5 specification, remove Section 4.10.17 and Section 10.4.12, and any references to these sections and the meter element.

Impact

Positive

Removing meter removes another element from the fairly large number of elements and attributes added with HTML5. In addition, it removes an element whose sole purpose and seemingly sole use case, is to ensure that another element was not used incorrectly. This, to me, is not a strong case for adding an element to HTML5, especially considering how much work each new element generates for browsers, HTML editors, and so on.

In addition, not creating a new element encourages people to use any number of the existing libraries and packaged widgets already available for use, and that have been available for use for many years. The meter element welds structure, behavior, and style into a single purposed element. Such single purposed elements are counter to the direction the web has been going for the last decade. Especially now, when we have so many new graphical possibilities, with the new support for SVG inline in HTML, and increased support for the Canvas element. It’s better to encourage people to use existing graphical technologies such as CSS, SVG, and Canvas, and existing semantics and accessibility technologies, such as ARIA, RDFa, Microformats, and Microdata, and leave the structure to HTML.

Negative

This change will require some of the editor’s time.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8555 [2] http://code.google.com/apis/visualization/documentation/gallery/gauge.html

[3] http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/widget/tests/te…

[4] http://docs.dojocampus.org/dojox/widget/BarGauge

[5] http://www.w3.org/TR/wai-aria/roles#progressbar

Summary: Split the material related to the browsing context into a separate specification, reducing the existing HTML5 to covering HTML, XHTML, and the DOM, only.

Rationale

The following is my initial request that led to this issue[1]

Currently the HTML5 specification contains a section, Section 6, devoted specifically to browsers. The section also notes that though it is focused on browsers, requirements in the section apply to all user agents, not just browsers, unless otherwise noted.

Though browsers are a major user agent for HTML/XHTML, they are not the only user agents. In particular, ebook technology is dependent on XHTML, and forms a completely different class of user agents than browsers. In addition, there are email applications that exist outside of browsers that also make use of HTML/XHTML, in addition to some word processing software.

Though the section does provide a good reverse engineering of browser technology, the section has little or nothing to do with HTML, in general. In addition, it also has little to do with the Document Object Model, which is based on the HTML syntax, not objects implemented by various browsers.

Including this section greatly extends the HTML5 specification beyond the charter, and beyond boundaries one can reasonably expect from an effort focused on HTML, both the XML serialization and non-XML serialization, and the DOM. In addition, by focusing the specification primarily towards browsers, we are limiting the usefulness of the HTML specification for other uses, both now, and in the future for ebooks, as well as other new technologies.

This is counter to good, technology practices. Consider how a programmer creates an application. They look for opportunities to create reusable objects, which they then use to create any number of applications, not just one. We should follow the same philosophy when creating a new version of HTML: restrict our effort to a new version of HTML, its serialization in XML, and the DOM. This will include new elements, such as video, which may not be useful for all variations of user agents, but the concept behind the new elements still fits within our perceptions of what we would reasonably expect from an HTML specification.

Simplifying the HTML5 specification in this way will greatly increase its usability by many user agents, not just browsers. A standardized BOM (Browser Object Model) can reference the HTML, true, but so can other specifications, such as ePub (for eBooks) and so on.

In addition, browser technology expands at a faster pace than that for the underlying HTML specification. By separating Section 6 out, it can then be incorporated into a new effort that can be focused specifically on the class of user agents, browsers. This new effort won’t then be dependent on the same release cycle as HTML.

I can see no negative ramifications from this change. Not only would it reduce the boundaries of the HTML5 specification to those that that one would reasonably expect, the separated section could then be used to seed a new, more targeted effort. As there is work on an ePub specification, there could also be work for the equivalent browser specification.

The end result of this request was a odd sequence of events where the HTML5 Editor split apart the W3C version of the HTML5 specification, but not specifically along lines of browsing context and not. This is also when the WhatWG version of the HTML5 specification began to strongly diverge from the W3C version.

The split apart parts were put back together again, but then the original Section 6 was split into two sections, Section 5 and 6. No rationale was given for not meeting my request, so I can’t reproduce here.

The concept of a Browser Object Model is not new. If you search on the term, you’ll find hundreds of references, including discussion about how it, unlike the DOM, is not defined within any formal specification. A formal specification is needed, though, and I agree with the work begun in this group. I just don’t believe that the HTML5 specification is the place for this work, because the BOM, which includes objects like Window, History, Navigator, Timers, and so on, is specific to HTML, XHTML, or the DOM. SVG is also dependent on the BOM, as is any script enabled document that could potentially be opened in a browser-like object.

Splitting out the non-HTML/XHTML/DOM bits isn’t going to be easy, because there’s a great deal of interwoven coverage of these items all throughout the specification. We could make the split based on script-enabled agent versus not, but this doesn’t make a lot of sense if the DOM is a valid component of the HTML5 specification. A split along the lines of requirements for scripting-enabled user agents, as compared to all user agents, is also not a matter of moving a couple of sections. For instance, in Section 3, titled Semantics, Structure, and APIs of all HTML documents, subsection 3.1.2 states:

User agents must raise a SECURITY_ERR exception whenever any of the members of an HTMLDocument object are accessed by scripts whose effective script origin is not the same as the Document’s effective script origin.

It is obvious that such a stricture is targeted solely to those user agents that support scripting, and is completely and totally irrelevant for those that don’t. This makes this stricture a good candidate for removal to the separate scripting User Agent document, yet isn’t in the target sections first referenced in the bug and issue.

Why does it matter to do this kind of split? Because the more unrelated material non-scripted user agents have to wade through to find their relevant bits, the more likely they’ll miss something important because it’s entangled with all sorts of browser or other user agent specific instructions. Conversely, burying browser context material in with HTML makes the material harder for user agents to update, and may hide this crucial information from web page developers, who aren’t expecting this type of information to be included in an HTML specification.

An additional concern is that many of the specifications related to the browsing context aren’t specific to just HTML/XHTML. They can also apply to other document types, such as SVG, MathML, and whatever the future brings.

I don’t think this type of split would be contentious, but I do think it will be a lot of work. It is definitely a group effort.

Details

OK, I’ve listed out the problem. Now what is a solution?

Rather than split the document based on whether the user agent is script-enabled or not, look for material relevant to the browsing context, whether stated or not, and mark it as a potential candidate for movement to a separate document. Once all are marked, then it’s a matter of determining whether the section should be split or not. That’s where the group effort comes in, because frankly, the more the relevant audience is involved, the better job it will be.

This work does amount to a major refacturing of the HTML5 specification. However, after so many changes in the last year, so many components split out, and the ongoing discussions about whether author guidelines should be included or not, the specification is overdue for this type of operation. You don’t have to spend too many hours going through the document to see the fragmented nature of the material, and that a good, solid edit is needed. Sometimes it is better for progress to stop, look, and think, rather than continually move ahead.

I didn’t have the time to go through the many pages of the HTML5 specification, but did go through Sections 5 and 6, in the March 4th published HTML5 spec. The following list of candidate items is not by any measure complete or comprehensive, but it is a start.

• Section 5.1 on browsing contexts. Much of this material is Window related, and I feel comfortable that this section can be split, in its entirety. Reworded, this could become an intro for a new document. It does need some clean up, as it jumps about, and the text is a little hard to follow. Some collapsing of multiple sentences into paragraphs, rather than one sentence-one paragraph could help the readability.
• Section 5.2 on the Window object. This one is an excellent candidate, and is pretty easy to follow, so wouldn’t need much in the way of editing.
• Section 5.3 on Origin. There’s nothing about the origin that’s pertinent to HTML, XHTML, or even the DOM. It’s really specific to the location, and security based on the location, which is outside the scope of markup or a Document Object Model. It is important material, but would be best served in the separate document. For instance, I would say there’s much in this section that would be relevant to an SVG document.
• Section 5.4 on Session history and navigation. Again, another excellent candidate for removal to the new document.
• Section 5.5 on Browsing the Web. Even without the title, you can tell that this section is a particularly strong candidate for removal to the new document. I have to question, though, the number of algorithms given in the text in this and other sections: are these really so necessary? Or are we really overspecifying, which can be just as harmful as underspecifying? This might be a question to ask when doing this split. There are also discussions of events, that could be considered borderline for movement, but the events really are related to the browsing context, not necessarily the HTML/XHTML/DOM. It might be best to define the actions and events in the separate document, and then ensure the section is referenced in the HTML5 specification.
• Section 5.6 on Offline Web Applications. This is another that’s a given. There’s nothing about HTML, XHTML, or the DOM that is application specific. Something like offline web application cache is specific to the browsing context, not the markup or the object model. This is also the last subsection in Section 5, so all of Section 5 could be moved, with appropriate back and forth links, and editing of the moved material.
• Section 6.1 on Scripting should be a candidate, though this move might require minor tweaking. There are references to DOM methods that probably should be pulled out of the moved material and incorporated into the HTML5 spec. Either that, or removed as unnecessary, since these methods are defined in another W3C document. There is a section on event handlers, but most of the section is focused on how the user agent should process the event, not on how the event handler is defined within HTML. The event handler section could potentially be split, part to the browsing context document, part to remain in the HTML5 spec. Also again, there does seem to be a great deal of overspecification in this section, but perhaps it is necessary.
• Section 6.2 on Timers. Oh, most definitely split to the browsing context document. We know this is just as pertinent to SVG as HTML.
• Section 6.3 on User Prompts. Again, a good candidate, as relevant for SVG as HTML.
• Section 6.4 on System state and capabilities is really about the Navigator object, and is definitely part of the browsing context. And this is the last subsection in Section 6, so this section could be moved. Again, there is some editing that needs to be done, and cross-reference links.

My first inclination was also to include Section 7.10 on the Undo History, but this section is related to the DOM. However, Section 7.8 on Spelling and Grammar checking should also be moved. The object referenced is the document object but the usage is pure browsing context. I also think Section 7.9 on Drag and Drop could be a potential candidate for movement. I don’t want to lose the section, but I think it fits within the domain of “browsing context” more aptly than in the domain labeled “HTML/XHTML/DOM”. Hard to say.

Section 7.11, the Editing APIs is a tough one. It is definitely specific to browsing context, especially in the examples, but the document object is the focus. I think the better way of looking at this is, if the section is more pertinent to interacting with agents outside the page, then it probably better fits within the browsing context. If this is for toolbars and extensions, then it definitely does work better in browsing context.

There are other sections, but this is a start, and I’ve run out of time to go more in-depth into the document.

Though I’m a big believer in doing business on the email list, I strongly believe this activity would be better done at a face to face meeting, including all of the browser companies, at a minimum. This is, in a way, the browsing company’s business model.

Impact

Positive

As painful as the amount of work seems, we would have a superior set of documents as a result. If we move the browsing context to a separate document, it would decrease the size of the HTML5 specification, but also focus the audience within the newly separated document. If we were to further split out authoring guidelines, and refocus the HTML5 specification purely on HTML, XHTML, and the DOM, we’d also be ahead, but that’s outside the scope of this effort.

This type of major movement is also an excellent time to do a general readability edit— to ensure a consistent audience focus in each section, and to work on the flow. We can get so caught up on stating rules that we end up overwhelming the reader, even a highly technical reader. When we do, they will unconsciously tune out the flood of rules, and could miss very important data.

Negative

Time. This is a major work, though it doesn’t have to be an overwhelming work. If the group participates in the exercise, the work can be split among many. In addition, a face-to-face could easily work through some of the more problematical areas.

I have a feeling that in the end, the specification will progress more swiftly making this move, than not.

Risks

This is a major work, and we’re already a relatively burned out group. I think, though, a smaller task group, consisting primarily of reps from the browsing companies, and some members from the other communities, could progress quickly with this task. I do not think it needs day to day oversight by the larger group.

References

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365