[whatwg] Spec comments, sections 3.1-4.7

[Aryeh Gregor]

On Sun, Aug 16, 2009 at 6:52 AM, Ian Hickson<ian at hixie.ch> wrote:
> They can follow the links (not following the links is a "should not", not
> a "must not"). Once they follow the links, they must ignore the type=""
> attribute and only take into account the MIME type provided by the server.

I was assuming that they don't want to follow unnecessary links.  For
instance, their spiders can likely only make X requests per second to
each domain (due to robots.txt or generic "don't be a jerk" policies),
and if the spiders are forced to make a large number of useless
requests then their indexing of any given site will be slowed down.

I'm not clear on what it means that you "must assume" something,
actually.  An assumption, by definition, might be discarded at any
point if more evidence comes in, so a required assumption sounds
oxymoronic.  Anyway, assumption is a state of knowledge rather than an
actual action, so I can't figure out what the requirement means in
practice.

At this point the user agent seems to have only one choice to make:
fetch the resource, or don't.  Whether to fetch the resource is, as
you point out, explicitly a "should" requirement.  So what's the "must
assume" requirement meant to add?  Are there other decisions the user
agent has to make before it has the resource available?

> For Web browsers, this problem only occurs if at least one major browser
> violates the spec. Until one does, the browsers can just refuse to render
> the site -- since all the browsers will be doing the same thing, the site
> cannot legitimately blame the browers.

Unless the problem is non-obvious to authors but significant to some
consumers (but not enough to make authors widely aware of it).  My
hypothetical scenario had authors providing an incorrect type=""
attribute.  Perhaps all browsers supported both types anyway, so they
retrieved the resource thinking it was type X, then determined it was
type Y and processed it as that with no errors being raised.  But then
if one browser (or search engine, etc.) happens to support type Y but
not type X, you get bugs.

Another example that I think you yourself have mentioned in the past
is Opera's mobile version.  It deliberately mangles display in a
nonstandard fashion to better fit on a small screen.  Again, here the
problem isn't obvious to most authors (since they didn't test on small
screens), but the implementor is able to improve experience for a
significant market of consumers if they ignore the standards.

> Probably a little (forms have been pretty successful despite a horrible
> styling story for over a decade)

Because it's impossible to achieve the same functionality as forms --
dynamically building a GET request based on user input, or any POST
request at all -- any other way without requiring JavaScript.  (Which
locks out some users, and is harder to write.)  And until a few years
ago, when XHR became widely supported, AFAIK it wasn't possible to
permit POSTs (necessary for large amounts of input, for instance) even
with JavaScript.