[whatwg] Spec comments, sections 3.1-4.7

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'