- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 27 Aug 2009 23:48:21 +0000 (UTC)
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 > 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. 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. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 27 August 2009 16:48:21 UTC