Subject: Browser behaviour

From: Danny Ayers <[email-masked]>
Date: Mon, 30 Jan 2006 16:42:51 +0100

The mail below is from the WordPress list, they're discussing
including stylesheet references in Atom docs. Have we got anything
like best practices or more palatable workarounds for these
circumstances? (i.e. in addition to using application/atom+xml)

---------- Forwarded message ----------
From: Pete Prodoehl <[email-masked]>
Date: Jan 30, 2006 4:24 PM
Subject: Re: [wp-hackers] XSLT: Sample implementation
To: [email-masked]

David House wrote:
> Some problems:
>
> 2) Atom support isn't there. Firefox and Konqueror (the browsers I
> tested in) get scared off by Atom's mime type and prompt the user to
> download it. They don't recognise it as XML, so they don't transform
> it. We have two options here: give up or serve as text/xml (I guess
> the latter won't be too popular). Really, browsers should recognise
> application/atom+xml as something they can parse as XML and do so.

That's why I eventually gave up using application/rss+xml and switched
to text/xml for RSS. Maybe it's time to do the same for Atom?

Pete

_______________________________________________
wp-hackers mailing list
[email-masked]
http://lists.automattic.com/mailman/listinfo/wp-hackers

--

http://dannyayers.com

---

From: Anne van Kesteren <[email-masked]>
Date: Mon, 30 Jan 2006 16:50:12 +0100

> circumstances? (i.e. in addition to using application/atom+xml)

The least they could do is use application/xml. (I'm using that at the
moment...) For the rest, bug browser people about it. Opera, for one, parses
everything +xml as XML.

-- 
Anne van Kesteren
<http://annevankesteren.nl/>

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 30 Jan 2006 17:18:30 +0100

* Danny Ayers <[email-masked]> [2006-01-30 16:50]:
>That's why I eventually gave up using application/rss+xml and
>switched to text/xml for RSS. Maybe it's time to do the same for
>Atom?

Ugh. Why does everyone insist on the `text/xml` albatross? Use
`application/xml`, at the very least.

(Of course, there is no `application/rss+xml` type, but anyway…)

In any case, -1 on returning feeds with either `/xml` type for
Atom. If it’s really necessary to work around browsers, a better
idea is to return a feed with the generic MIME type only when the
feed is requested with a `?specific_type=0` query parameter. Then
autodiscovery links and other stuff can point to the regular URL
served with the proper MIME type, and use of the escaped hatch
can be limited to links a user can actually click on.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: James M Snell <[email-masked]>
Date: Mon, 30 Jan 2006 08:23:59 -0800

+1. Serving atom up at application/xml is perfectly acceptable and will 
render in the browser. Look at Sam Ruby's feed as an example. 
http://www.intertwingly.net/blog/index.atom

- James

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Jan 2006 11:08:41 -0800

On Jan 30, 2006, at 8:23 AM, James M Snell wrote:

>
> +1. Serving atom up at application/xml is perfectly acceptable

It is *not*.  Atom has a registered Internet media type (application/ 
atom+xml); using anything else is a bug. -Tim

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 30 Jan 2006 21:16:25 +0100

> > application/atom+xml as something they can parse as XML and do so.

Why should Atom be "parsed as XML" by browsers?

If people fear that users come onto their site through a search engine
and arrive on an Atom feed, so they want their feeds to be shown in
the browser (in a fancy way if possible) so that users won't be feared
and go away (and if possible click on a link to lead them to the
site's browser-dedicated pages); those people should just use a
rel=nofollow" on the "direct links" to their feeds.

So I'd say:
 - <link rel="whatever" type="application/atom+xml; type=feed" />* in
the page header for autodiscovery
 - eventually <a rel="nofollow"></a> in the page body to allow users
to more easily subscribe in external readers (either via mime-type
dispatching or "copy link address"/paste)

And, follow those guidelines:
http://www.scottfrancis.com/blog/2006/01/21/ui-updates/

* oops, sorry, there's no "type" parameter to the application/atom+xml
type… so let's say <link rel="alternate" type="application/atom+xml"
/>

--
Thomas Broyer

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Jan 2006 12:47:00 -0800

Thomas Broyer wrote:

> ...
>
> (and if possible click on a link to lead them to the
"I don't think that means what you think it means".  At least, if you 
mean for search engines not to follow the link.  If you just want the 
PageRank of the destination feed (?) to be unaffected by the PageRank of 
the source URL, then yeah, I guess...

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Jan 2006 12:57:13 -0800

> atom+xml); using anything else is a bug. -Tim
Here's my 'best effort' suggestion that we're looking to implement at AOL:

(1) All links from within feeds go to a resource of type 
"application/atom+xml".
(2)  Header links (<link rel...>) in web pages to to a resource as in #1.
(3) Feed links displayed in web pages, which a user in a web browser 
might click on, go to a resource of type "application/xml", which 
contains exactly the same XML that would be contained in the Atom feed 
resource of type "application/atom+xml", along with a style sheet that 
causes said page to be rendered in a browser with subscribe links 
(pointing to resource #1).  The web UI tries to guide users to subscribe 
buttons first, before showing them a raw feed URL.

In other words, the application/xml content is a fallback for when 
users, despite our best efforts, end up looking at XML content inside a 
web browser.  I'd also be happy to make this behaviior browser-dependent 
so that we serve application/atom+xml to browsers which will display it 
inline with a style sheet, if there are any.

This means that users might possibly end up subscribing to something of 
type application/xml if they copy and paste URL #3... but we could also 
make this client dependent so that, for example, everything other than 
known web browsers get application/atom+xml.  Not sure about that as 
it's changing the MIME type, but I think it's changing it for a good 
reason (working around what I think is a browser problem).

Comments welcomed.

-John

---

From: James M Snell <[email-masked]>
Date: Mon, 30 Jan 2006 13:14:46 -0800

>> atom+xml); using anything else is a bug. -Tim

It's either a bug or an intentional downgrade designed to meet practical 
requirements before strict technical requirements.  I agree that Atom 
feeds SHOULD be served up with atom+xml.

In a strictly practical sense, what John describes here seems reasonable 
  (even if not ideal).

- James

---

From: Tim Bray <[email-masked]>
Date: Mon, 30 Jan 2006 13:43:05 -0800

On Jan 30, 2006, at 12:57 PM, John Panzer wrote:

> users, despite our best efforts, end up looking at XML content  
> inside a web browser.  I'd also be happy to make this behaviior  
> browser-dependent so that we serve application/atom+xml to browsers  
> which will display it inline with a style sheet, if there are any.
>
> This means that users might possibly end up subscribing to  
> something of type application/xml if they copy and paste URL #3...  
> but we could also make this client dependent so that, for example,  
> everything other than known web browsers get application/atom+xml.   
> Not sure about that as it's changing the MIME type, but I think  
> it's changing it for a good reason (working around what I think is  
> a browser problem).

Seems sensible. -Tim

---

From: Thomas Broyer <[email-masked]>
Date: Tue, 31 Jan 2006 00:09:11 +0100

> the source URL, then yeah, I guess...

Right!

How about robots.txt?
http://www.robotstxt.org/wc/exclusion.html#robotstxt

--
Thomas Broyer

---

From: Sam Ruby <[email-masked]>
Date: Mon, 30 Jan 2006 19:54:38 -0500

> atom+xml); using anything else is a bug. -Tim

I'm not sure I would stand on principle for that one if I were you.
Xhtml also has a registered Internet media type (application/xhtml+xml),
but many people (<grin>) serve up their xhtml pages as text/html.

I'd like to take a survey of what web browsers will accept and what they
indicate they prefer.

http://www.intertwingly.net/wiki/pie/AcceptHeaders

Based on the results, I will gladly start sending my feed at
application/atom+xml to those browsers that *don't* indicate a
preference for application/xml.

As well as make a change to the Feed Validator to send such a header itself.

- Sam Ruby

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 31 Jan 2006 02:24:11 +0100

* Tim Bray <[email-masked]> [2006-01-30 20:15]:
>It is *not*.  Atom has a registered Internet media type
>(application/ atom+xml); using anything else is a bug. -Tim

I don’t know that you can defend that in any way.

I see no grounds on which it can be argued that serving an XML
document as `application/xml` is wrong. Atom is XML. Hence it
cannot be said that serving Atom as `application/xml` is wrong.

It’s not preferrable – no question about that.

Regards,

---

From: "James Holderness" <[email-masked]>
Date: Tue, 31 Jan 2006 02:57:13 -0000

David House wrote:
> We have two options here: give up or serve as text/xml (I guess

I can't understand why so many people want to prevent the browser from 
passing Atom feeds on to the user's registered feed reader. When a browser 
encounters an audio/mpeg link what does it do? It passes it on to the user's 
media player. It doesn't try to display a binary dump of the file, or a 
waveform image. That would just be stupid. But for some reason people think 
it makes more sense to display a page full of XML to the user rather than 
letting them view the feed in their aggregator. I just don't get it.

Admittedly if the user doesn't have an aggregator installed, or their 
aggregator hasn't registered the application/atom+xml media type, then a 
save dialog is not particularly useful. At that point it may be more useful 
for the browser to try and display the XML inline. But that is a fallback 
situation that should only be considered if there isn't a registered handler 
for the Atom media type.

John Panzer wrote:
> (3) Feed links displayed in web pages, which a user in a web browser might 
> click on, go to a resource of type "application/xml", which contains 
> exactly the same XML that would be contained in the Atom feed resource of 
> type "application/atom+xml", along with a style sheet that causes said 
> page to be rendered in a browser with subscribe links (pointing to 
> resource #1).  The web UI tries to guide users to subscribe buttons first, 
> before showing them a raw feed URL.

Now this I can understand. Not too scary for users that don't have an 
aggregator installed, but you still provide a clickable, subscribable link 
for users that do.

Regards
James

---

From: John Panzer <[email-masked]>
Date: Mon, 30 Jan 2006 21:33:32 -0800

James Holderness wrote:

> passing Atom feeds on to the user's registered feed reader. When a 
> browser encounters an audio/mpeg link what does it do? It passes it on 
> to the user's media player. It doesn't try to display a binary dump of 
> the file, or a waveform image. That would just be stupid. But for some 
> reason people think it makes more sense to display a page full of XML 
> to the user rather than letting them view the feed in their 
> aggregator. I just don't get it.

http://feeds.*feedburner*.com/Abstractioneer

> aggregator hasn't registered the application/atom+xml media type, then 
> a save dialog is not particularly useful. At that point it may be more 
> useful for the browser to try and display the XML inline. But that is 
> a fallback situation that should only be considered if there isn't a 
> registered handler for the Atom media type.

100% agreed.  I think this is what people are actually asking for -- run 
the handler if registered, if not check to see if it's something the 
browser might be able to usefully display (xml with stylesheet, for 
example!) and only if that fails, offer to download.

>> contains exactly the same XML that would be contained in the Atom 
>> feed resource of type "application/atom+xml", along with a style 
>> sheet that causes said page to be rendered in a browser with 
>> subscribe links (pointing to resource #1).  The web UI tries to guide 
>> users to subscribe buttons first, before showing them a raw feed URL.
>
>
> aggregator installed, but you still provide a clickable, subscribable 
> link for users that do.
>
> Regards
> James
>