[whatwg] Spec comments, sections 3.1-4.7

[Aryeh Gregor]

On Wed, Aug 12, 2009 at 3:08 AM, Ian Hickson<ian at hixie.ch> wrote:
>> 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.

Consider a search engine that can only index certain types of content.
 If a type attribute is provided on a link, and the type indicates a
non-supported type of content, the search engine would be required to
assume that the resource is not supported.  So say it does this, but a
major site emits incorrect type attributes for some links.  The
authors of the search engine spider become aware of this and are
unable to persuade the authors of the site to change their markup.
Should they have to still refrain from following the incorrectly
marked-up links?

Well, I guess I can answer my own question.  If authors produce markup
that's invalid, such that a user agent that followed the standard
would not be able to process the markup correctly, and those authors
are important enough that the implementers of the user agent can't
afford to process their markup incorrectly, then the implementers
would reasonably be expected to willfully violate the standard as much
as is strictly necessary to serve their purposes.  Like IE7
Compatibility Mode, say.  This is prohibited by the standard and does
make the user agent non-conformant in that respect, but it's not
useful to add a generic clause to the standard saying "you can ignore
everything if you really have to" to handle this case.  That's
implicit in the fact that the standard isn't mandated by law or
whatever.

So I withdraw the suggestion.

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

I see.  I guess if you're using a screen reader or have images
disabled, loading bars in some web apps would be completely absent.  I
haven't noticed many progress bars on the web, but I guess if I used
web apps other than Gmail more then maybe I'd see the need for this
better.

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

Hmm, okay.  I don't think pretty much anyone will be using these
elements until something like this is in place, though.  And possibly
not after that if it's not easy enough to use.

(I notice Gmail doesn't appear to even use form buttons.  Inspecting
the Send button on this page shows a stack of several nested divs with
various obscure classes and styles applied.  And, indeed, it seems
like that's so they could change the appearance.)

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

I think that <kbd>File | Eat Apple...</kbd> or <samp>File | Eat
Apple...</samp> would be a better recommendation in this case.  It's
really unlikely that you'd need such excruciating precision in the
markup here.  It's pretty ugly, and violates the general principle
that if your markup isn't easily readable in a text editor, you're
using too much of it.

Actually, in real life I think the best recommendation would be to
just not use <kbd> or <samp> at all, and use <code> or something
instead unless there's some special reason you want to distinguish
user input from other types of code, like style (in which case <kbd>
or <samp> would be more convenient than using a class).  I'm guessing
that these elements are only present in the standard because they were
in previous versions of HTML and there's no good reason to actively
remove them?  They strike me as drastically less useful than many
other tags that would be rejected for having an insufficient use-case.

> Are F-sigma and G-delta variables?

Well, strictly speaking I guess they're constants, if you want to make
that distinction.  Is <var> inappropriate for marking up symbolic
constants?  They're normally treated identically to variables in
typography.  The semantic distinction can be rather blurry at times as
well, at least in mathematics, where the same symbols are often varied
and held fixed by turns while representing the same quantity.  It
seems like if you can't use <var> for constants, you'd have some
rather silly markup, like:

int <var>i</var> = 0;
const int <span class=const>max_iters</span> = 30;

Anyway, if you do think there's a difference, there are other examples
of subscript being used for things other than indexing.  The first
that comes to mind is Newtonian partial derivative notation.  If f(x,
y) is some arbitrary differentiable function of two variables, then
f_x can be used to denote its partial derivative with respect to x.  f
is one variable that represents a single thing (not a collection), and
f_x is a different variable that represents f with a particular
operation applied to it.  This isn't indexing in any sense.  I suppose
you could say that it should be marked up
<var>f</var><sub><var>x</var></sub>, but I think
<var>f<sub><var>x</var></sup></var> seems as appropriate.  f_x is
itself a single variable, arguably.

There are other examples too, I'm sure.  Subscripts are used to jam
stuff into whenever it's convenient.  Mathematical notation follows
almost no hard and fast rules, only trends and guidelines.  Many math
papers invent some notation that ends up solely being used in that
paper to describe concepts that the paper introduces, and that can
follow any imaginable convention.  Plus some that would have been
pretty hard to imagine.  :)  I don't think a normative statement
limiting the purpose of something like subscripts is a good idea.

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

Which usually duplicate documentation, at least.

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

Well, I have no data, so I can't really argue.