- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 2 Aug 2009 14:34:13 -0400
First, a general remark: what's the difference supposed to be between "PASS" and "BUG"? Firefox and WebKit are listed as PASS and BUG in these two cases respectively, for instance: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactions-with-xpath-and-xslt http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#controlling-the-input-stream The descriptions just say "passes all the available test cases for this feature", and "has nearly complete support for this feature, but does not yet pass all the relevant test cases". But in both cases, it says "Tests: 0". I guess this is an error in the XPath/XSLT section, since all the other parts with no tests list browsers as BUG rather than PASS? In 3.2.3: "This specification does not define what makes an HTTP-only cookie, and at the time of publication the editor is not aware of any reference for HTTP-only cookies. They are a feature supported by some Web browsers wherein an "httponly" parameter added to the cookie string causes the cookie to be hidden from script." Why doesn't the spec define them? In 3.4.1.7: "When a pointing device is clicked, the user agent must run these steps: "1. Let e be the nearest activatable element of the element designated by the user, if any. "2. If there is an element e, run pre-click activation steps on it. "3. Dispatching the required click event. . . ." The third item's grammar doesn't match the first two. Probably it should be "Dispatch" instead of "Dispatching". In 3.5: I'm not certain what the point of 3.5 is. What agents are supposed to keep track of paragraph boundaries, and what are they supposed to do with them? They don't affect the DOM or rendering as far as I can tell; what do they affect? Should browsers care about them? Conformance checkers? What should authors be aware of, other than not straddling elements across paragraph boundaries? (And why should they care about that? That's not clearly explained either.) In 4.2.3: "If there are multiple base elements with href attributes, all but the first are ignored." "If there are multiple base elements with target attributes, all but the first are ignored." Why are these notes, and not normative? Do they duplicate normative requirements elsewhere? In 4.2.4: "If the attribute is present, then the user agent must assume that the resource is of the given type. If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type." Why "must" and not "should"? Perhaps the user agent has some good reason to think the attribute is wrong. In 4.6.1: "suports" -> "supports" 4.6.11 and 4.6.12: Most new elements in HTML 5 either add clear functionality (e.g., <video>) or provide convenient styling hooks (e.g., <article>). <progress> and <meter> seem to do neither. What's the point of these elements, from an author's perspective? Or even from anyone's perspective? What use cases do they fulfill? In particular, it seems like authors would be reluctant to use <progress> and <meter> if they couldn't style them. I don't think there's any obvious way to really control the styling of these controls with CSS, so authors would be stuck with whatever color scheme and general feel the UA happens to support. That seems like it would look ugly compared to manually-constructed elements that serve the same purpose. In 4.6.16: "<p>To make George eat an apple, select <kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd> </p>" That seems excessively baroque. While it's a matter of taste, I guess, I think it would be better if the spec didn't go out of its way to encourage markup that's so excessively nested and unreadable for no apparent purpose. In 4.6.17: "When the sub element is used inside a var element, it represents the subscript that identifies the variable in a family of variables." While this is often what subscripts are used for in variable names, it doesn't have to be. For instance, F_\sigma and G_\delta are used in real analysis to refer to a countable union of closed sets and a countable intersection of open sets, respectively. \sigma and \delta here denote "somme" and "Durchschnitt" respectively, and don't serve as identifiers in a family of variables in any meaningful sense: they represent the operation of taking countable unions/intersections. This statement should either be removed, or weakened ("usually" or such) and made informative. In 4.6.26: I don't think it's a good idea to recommend the use of the title attribute for annotations or footnotes. User agents do not normally provide any visual cue if a title attribute is present, to the best of my knowledge, except on abbr elements. Even if some cue is provided, it's unlikely that many users will actually recognize the cue as a suggestion to hover over the element. The large majority of users probably won't realize there's a tooltip. IMO, tooltips should never be used to provide information that's not accessible in some other way. An example of a good use is to provide a preview of the contents of a link. Users who know about the tooltip can save themselves a click, but others can just click to get the content. Moreover, in this case users will tend to move their mouse over the link to click on it, so will likely discover the tooltip if a certain type of link consistently has it. I would ask you to add some note to the spec saying tooltips shouldn't be used for information that's not discoverable in some other way, but sadly, I have no data, just my intuition. Does anyone have any hard data on the usability of tooltips? (Granted, UAs might implement titles as something other than tooltips, but generally they don't.)
Received on Sunday, 2 August 2009 11:34:13 UTC