Burningbird

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

The biggest mistake associated with the HTML5 specification is also the only mistake that can’t be corrected: the charter. The charter allowed the group to create an HTML and XHTML serialization, as well as an associated DOM. Unfortunately, the interpretation of this charter was such that all three tasks have been combined in one document, and that’s been a problem with both scope and audience, ever since.

In the past, the HTML document has been separate from the XHTML serialization, and from the Document Object Models. By being separate, the documents are kept small, and the audience is well defined. A web page author or designer would feel comfortable reading the HTML4 document, directly, and not be confronted with material focused at web developers, or worse, User Agent developers.

We in the HTML WG know this, and seemingly don’t. We’ll include any amount of author information in the HTML5 specification on the one hand, but on the other, make statements about how the web page authors won’t actually read the document—they’ll go to some tutorial or guide. We seem to have a difficult time making up our mind as to the HTML5 spec’s audience.

I think we’ve gone beyond being able to split the HTML, XHTML, and DOM into separate specifications. Unfortunate. Our next best option is to ensure that whatever is in the specification is only related to HTML, XHTML, and the DOM. We can start by splitting out the User Agent specific material, currently included in Sections 5 and 6, as we split out Microdata and the Canvas 2D API.

If we’re successful in splitting out the browsing context, a second step is to consider moving out much of the author guidelines into a separate specification. This would allow us to expand on these guidelines, while also helping to trim the 600 or so pages that currently make up the HTML 5 specification.

Of course, this isn’t going to work while the HTML5 spec and most of the split off sections are still controlled by one person. This is an unhealthy situation. A situation that, unfortunately, can’t be fixed by filing a bug, or raising an issue.

Summary

Summary: Replace too-simple and somewhat odd example table and verbose text unrelated to the table element, with one example table, derived from real world data that best demonstrates the table element. Refocus the text specifically on the table element.

Rationale

In the bug[1] related to this issue, the HTML5 Editor’s rationale for not make this change was:

Rationale: Given how bad the current situation is regarding authors providing explanatory text for tables, I think we should given them as much information as possible, in as many places as possible. We do AT users a disservice if we pretend that their needs aren’t important enough to include advice on how to best serve them in the spec.

The current table element section provides one very small and inadequate table example, with a great deal of prose basically telling people what to put in text surrounding the table. None of this prose is related to the purpose and interoperable use of the table or its child elements, and seemingly added to the section only as a way of justifying removing the summary attribute. I hate to use cliches, but this seems like a true case of the tail wagging the dog.

Throwing lots of irrelevant text at authors does not make the table element any clearer, or ensure they use the element in the proper way. What’s needed is a good, succinct example, with a clear explanation of the element, and the table’s only unique attribute, summary.

What people incorporate into the text surrounding an HTML table is not the business of the W3C HTML Working Group. Such over-specification only adds to the noise, and if you throw enough noise at people, all they’ll do is tune out the important bits.

The space would be better used by providing a table listing that uses all of the table child elements, demonstrating how the elements work together, and then providing a screenshot of the table. By creating a listing, people can see how the table is put together; the figure demonstrates the visual rendering of the table.

Details

Replace the existing table element description section with the following (replace the URL for the img element in the figure with one local to the W3C, image can be copied, link table model):

The table element represents data with more than one dimension, organized into non-empty columns and rows. It is the primary component of the table model.

Tables are used for data display, only, and should not be used for layout purposes. In particular, users of accessibility tools like screen readers are likely to find it difficult to navigate pages with tables used for layout.

The only unique attribute for the table element is the summary attribute. This attribute is optional, and should only be used with complex tables, in order to provide a visual description of the structure of the table—making the table easier to navigate when rendered non-visually. The summary may also include a brief description of the purpose of the table, if such purpose is visually apparent when viewing the entire table, but may not be apparent traversing the table, cell by cell. An example of a complex table is shown in Listing Table-1. Figure Table-1 is a visual rendering of the table.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Example Table</title>
<style>
table
{
  border: 1px solid #ccc;
  border-collapse: collapse;
  margin: 0 20px;
}

td, th
{
  border: 1px solid #ccc;
  padding: 10px;
}

.female
{
  background-color: #ffc;
}

tfoot
{
  font-size: smaller;
}
</style>
</head>
<body>
<table summary="First row is column headers separated into year and degree programs 
                (bachelor, master, graduate). Each degree program is further split into 
                biology and technology fields on second line. Each topic field is separated into 
                male and female graduates on third row. Years are listed in first column.">

   <caption>
      <p>Degrees in the biological and biomedical sciences compared with degrees 
         in technology conferred by degree-granting institutions, by level of 
         degree and sex of student: Selected years, 2002-2007.
      </p>

   </caption>

   <colgroup span="1"></colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />

      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />

   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>
   <colgroup>
      <col class="male" />
      <col class="female" />
   </colgroup>

   <thead>
      <tr>
         <th rowspan="3">Year</th><th colspan="4">Bachelor's Degrees</th>
         <th colspan="4">Master's Degrees</th>
         <th colspan="4">Doctor's Degrees</th>
      </tr>

      <tr>
         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th>
         <th colspan="2">Biology</th><th colspan="2">Technology</th></tr> 
      <tr>
         <th>Male</th><th>Female</th><th>Male</th><th>Female</th><th>Male</th><th>Female</th>

         <th>Male</th><th>Female</th><th>Male</th><th>Female</th><th>Male</th><th>Female</th>
      </tr>
   </thead>
   <tbody>
      <tr>
       <td>2002</td><td>22,918</td><td>37,186</td><td>41,950</td><td>15,483</td>

                    <td>2,981</td><td>4,009</td><td>13,267</td><td>6,242</td>
                    <td>2,804</td><td>2,289</td><td>648</td><td>168</td> 
      </tr>
      <tr>
       <td>2003</td><td>23,248</td><td>38,261</td><td>44,585</td><td>14,903</td>

                     <td>3,227</td><td>4,430</td><td>13,868</td><td>6,275</td>
                     <td>2,804</td><td>2,438</td><td>709</td><td>200</td> 
      </tr>
      <tr>
       <td>2004</td><td>24,617</td><td>39,994</td><td>42,125</td><td>11,986</td>

                    <td>3,318</td><td>4,881</td><td>13,136</td><td>5,280</td>
                    <td>2,845</td><td>2,733</td><td>905</td><td>214</td>
      </tr>
      <tr>
       <td>2005</td><td>26,651</td><td>42,527</td><td>37,705</td><td>9,775</td>

                    <td>3,654</td><td>5,027</td><td>12,470</td><td>4,585</td>
                    <td>2,933</td><td>2,842</td><td>1,109</td><td>307</td>
      </tr>
      <tr>
       <td>2006</td><td>29,951</td><td>45,200</td><td>34,342</td><td>7,828</td>

                    <td>3,568</td><td>5,179</td><td>11,985</td><td>4,247</td>
                    <td>3,221</td><td>3,133</td><td>1,267</td><td>328</td>
      </tr>
   </tbody>
  
   <tfoot>

      <tr>
         <td colspan="13">Data from Institution of Education Sciences National Center
                for Education Statistics, derived from two tables: 
                <a href="http://nces.ed.gov/programs/digest/d08/tables/dt08_298.asp">
                Table  298. Degrees in the biological and biomedical sciences conferred by degree-granting 
                institutions, by level of degree and sex of students; selected years, 1951-52 through 2006-07
                </a> and <a href="http://nces.ed.gov/programs/digest/d08/tables/dt08_302.asp">
                Table 302. Degrees in compueter and information sciences conferred by degree-granting 
                 institutions, by level of degree and sex of student: 1970–71 through 
                 2006–07</a></td>
      </tr>
   </tfoot>
</table>
</body>
</html>

Other changes:

For each of the table element children in the listing—tr, th, col, colgroup, caption, tbody, thead, tfoot—reference the existing example in Listing Table-1, and remove any other example table. One example should be sufficient to demonstrate all of the table model elements.

Though this is more related to Issue 32, it’s still relevant: remove the warning about the summary attribute, and remove the attribute from the “obsolete but conforming” section. We’ve beat this horse so much that it’s practically glue. Time to open the gates and let it loose. Time to move on to other things.

Impact

Positive Effects

Replaces an unbelievable table example, with one that is believable, using real data. In the spec, we should avoid contrived and made up examples, as much as possible, as they can undermine the credibility of the section, and distract from element(s) being demonstrated.

The change also clarifies the section and puts the focus back on the table element, rather than anything but. The example also demonstrates how to use all of the table elements, as well as making a correct use of the summary attribute. Linking all of the table child elements back to the table element section and the listing allows people to see how these elements are used, especially in context.

Negative Effects

Will take some of the editor’s time to make this change. The use of labels such as Listing Table-1 and Figure Table-1 may not fit it within the writing style of the rest of the specification (adjust as necessary). The listing is also a little large, though as a demonstration of a family of elements, not overly so.

References

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