[whatwg] Spec comments, sections 3.1-4.7
ian at hixie.ch
Thu Aug 27 16:48:21 PDT 2009
On Sun, 16 Aug 2009, Aryeh Gregor wrote:
> 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?
Sure. For example, the UA might want to display the list of resources to
the user. In such a UI, if the UI includes types, it would have to use the
type="" attribute's value as the type.
> > 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.
I guess I don't understand what you're asking for the spec to do. Do you
want to drop the type="" attribute altogether?
> > 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
> 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
People use forms now, still, despite this situation having changed.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg