- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Sun, 16 Aug 2009 10:15:07 -0400
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.
Received on Sunday, 16 August 2009 07:15:07 UTC