[whatwg] Spec comments, sections 3.1-4.7

[Aryeh Gregor]

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