[whatwg] Spec comments, sections 3.1-4.7

[Ian Hickson]

On Sun, 2 Aug 2009, Aryeh Gregor wrote:
>
> 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?

Currently they're all just judgement calls currently; there aren't any 
tests listed for most features. Feel free to change the annotations if you 
feel they are wrong (alt+double-click a section to edit it's marker).


> 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?

Cookies are out of scope of the HTML5 spec. This is being discussed in the 
http-state mailing list.


> 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".

Fixed.


> 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.)

This section is just defining the semantics of text that is directly in 
flow elements other than <p> elements. It's only really theoretically 
useful for people doing semantic processing of HTML documents. In practice 
it's useful for people who have debates about what HTML documents mean.


> 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?

Yes.


> 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.

Because otherwise we don't get interoperable behaviour. That kind of 
reasoning is how we ended up with the crazy content sniffing behaviour we 
have now, with its assorted security issues.


> In 4.6.1:
> 
> "suports" -> "supports"

Fixed.


> 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?

The point of <progress> is to add progress bars. Right now people hack 
them in highly non-accessible ways using images and all kinds of crazy 
things. This lets them avoid that while also getting a platform-native 
look and feel.

The point of <meter> is to make sure people don't abuse <progress> for 
showing meters.


> 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.

Yeah, styling of complex widgets like progress bars and other widgets is 
somewhat dependent on us deploying a technology like XBL2. This is 
something that we need to resolve in general. Once we have more 
implementation experience, I expect we'll add some pseudo-elements and 
define how the CSS model applies.


> 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.

This is again basically aimed at the pedants who like to argue about 
exactly how to mark up particular semantics. You'd be amazed how often I'm 
asked how to mark up that kind of thing.


> 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.

Are F-sigma and G-delta variables?


> 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.)

As far as I can tell, tooltips are always used for information that can't 
be accessed any other way -- their usual use is, indeed, "tool tips", that 
is, tips for using tools (in UIs). I would expect someone using title="" 
for footnotes to also style titled elements specially, so I don't think 
the styling issue is critical (and there's nothing saying non-CSS UAs 
can't highlight elements with title attributes). Semantically, it seems 
like a good fit.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'