Re: Title of the HTML5 document

Maciej Stachowiak wrote:
> 
> On May 25, 2009, at 7:17 AM, Sam Ruby wrote:
> 
>>
>> Since my beliefs were called into question, here's what I believe:
>>
>> (1) I believe that (regrettably) that the sniffing of feeds needs to 
>> be specified somewhere.  I say regrettably as I know of nobody who 
>> feels that this is an ideal situation, instead it is behavior that is 
>> interoperability being implemented by browsers to deal with reality as 
>> it exists as opposed to a Platonic ideal.
>>
>> (2) This sniffing is browser behavior.  There are a number of other 
>> user agents that don't perform this behavior.  In fact, without 
>> testing, I'm confident that the example you site ('NetNewsWire') 
>> doesn't implement this behavior.  Even if it does, I'm sure I can find 
>> countless others that don't.  Of course, those that don't have this 
>> behavior don't claim to be HTML5 compliant.  The purpose of 
>> documenting this behavior isn't to force change in those applications, 
>> but to provide an documented and interoperable alternative should the 
>> authors of those applications wish to implement it.
>>
>> (3) At the present time, I have no position as to whether or not this 
>> belongs in a separate document, but do believe that
>>
>>  (3a) whatever document it belongs in needs a suitable subtitle and
>>       abstract that covers this content.
>>
>>  (3b) ensuring that the subtitle and abstract of the current HTML5
>>       draft matches the subsequent content will make the consensus
>>       review of such content go much more smoothly.
>>
>> Is any of this not clear?  Do you disagree with any of it?
> 
> I disagree with point (2). Before I made my claim about NetNewsWire, I 
> tested. I served copies of the following documents with a text/html MIME 
> type, using a local Apache server, and also separately with an 
> application/xml MIME type:
> 
> http://www.w3.org/2000/08/w3c-synd/home.rss
> http://intertwingly.net/blog/index.atom
> 
> NetNewsWire successfully processed subscriptions to text/html and 
> application/xml versions of these feeds and let me browse the news 
> items. I don't know what exact sniffing rules NetNewsWire uses, but 
> clear it has some. Just in case I lucked out and picked the only news 
> reader with sniffing, I just now tried the following:
> 
> - NewsFire
> - Shrook
> - Vienna
> - NewsLife
> 
> They all exhibited the same behavior as NetNewsWire.
> 
> Now, perhaps your objection is that these don't follow the exact 
> sniffing rules as those proposed in the spec. But then, neither does 
> Safari, and I suspect other browsers do not precisely match these rules 
> either.
> 
> Or perhaps the point is that these newsreaders will content sniff feeds 
> served with any MIME type whatsoever. I could not rule out that 
> hypothesis with my brief experiment. It seems to me such behavior would 
> be worse than something along the lines of the spec.

The rules are different, and are likely to remain different, and the 
authors of newsreaders aren't participating in this process.

The existing section on the img element takes into account that the 
value of the @src element is likely to be an image.  Similarly, feed 
readers first tend to make the assumption that the URI entered is a 
feed.  Frankly, that's not likely to change.  Specifically, NetNewswire 
will happily process a feed served as text/plain, no matter what the 
HTML 5 specification says about the matter.

The section on Content-type sniffing: feed or HTML is intended to apply 
to browsers.  Others are welcome to follow it, but are not compelled to 
comply with it.  They may do something "better", something "worse", and 
even something "far worse".

Meanwhile, documenting the intended behavior of browsers is a useful way 
encouraging such browsers to converge on a uniform set of behavior.

That's what I was trying to say with #2 above.

> Regards,
> Maciej

- Sam Ruby

Received on Monday, 25 May 2009 16:23:53 UTC