Thank you Sean. While theres still more to read, thats the only part I needed to hear, and now my mouth is official shut.
Thanks for the explanation. Your transparency has once again proven to be the difference between a whole bunch of ???? and acceptance that you have obviously set the users ability to decide at the forefront of your deciosn process.
Excellent!
BTW... Regardining my offfline emails... did you actually get those,,, After the second "your email has been blocked because of ...." that suggested there was something contained inside it thought may have been offensive, I decided I best not try for a third as I simply couldnt figure out anything that seemed to fit the criteria the response mail suggested. If you did get it, then cool. Nothing to worry about.
Thanks again for the explanation! Truly appreciated :D
I've been meaning to respond to this in the original thread (and to David Peterson's offline questions publicly), but got caught up in some other things.
There are a few principles we used to decide how to approach this problem (and it's not a straightforward issue with an easy decision matrix):
First, while the feed itself is data (as David points out ), the entries are the content from the publisher. The publisher has complete control over how each item in the feed looks (using (X)HTML). Entries can, of course, be re-mixed and shown in different contexts, losing their original feed context.
It is worth noting that no other aggregator maintains the publisher's look and feel on a feed. RSS Bandit and some others allow the user to control how a feed looks, and it requires custom, app-specific XSLs. If Safari has a way to turn off its feed view, I haven't found it yet.
To build on this idea, there is real value on a consistent view of feeds for the user, helping the user understand what they are looking at, and the context in which they can use the data. In fact, that's part of the promise of RSS – consistency.
For example, because the feed view is part of the client, instructions explaining what a feed is, and why subscribing is a useful and interesting thing to do are presented in the user's system language, regardless of the language of the feed. If the user chooses, they can turn off the IE feed view completely (starting from the next beta update).
Finally, we think that feeds+stylesheets exist as a stopgap measure to help users avoid the nasty XML view in browsers that don't support feeds (yes, this is a generalization, and some people are building web sites that are built in a more complicated way, but in the vast majority of cases, it's true). Now that the browsers support viewing feeds natively (this will be all major browsers, with the release of Firefox 2.0), this stop gap should be retired, or continue to exist only for older browsers.
There is a reasonable argument that this is a change in browser behaviour, and there's mention in another email that this is counter to the IE7 CSS promise of compatibility with sites.
The reality is that browsers have a nightmare process of dealing with millions of websites that have a near infinite set of permutations of how they use HTML. This is a side effect of the somewhat haphazard evolution of HTML in the 90s. I think it would be a complete mistake to repeat that here. The feed is nowhere near as large as the HTML community, and the opportunity exists to correct behaviour and do the right thing.
Yes, it's a change in browser behaviour, but that should not be the only argument. Since we are still at the cusp of the explosion of RSS/Atom into the mainstream, we should be deciding what is the right thing.
I argue that the right thing for a publisher is to serve HTML when they want control over the look and feel of the entire set of content, and to serve RSS/Atom when they want their data consumed as a feed (which has always meant surrendering the look-and-feel to the particular client the user chooses).
To address another implied point – we are not doing this out of some evil intent to screw the publisher or other clients. We have gone into this with the explicit intent of not only providing a decent feed reading experience in IE, but also to make sure that the entire community of aggregator and services is catered to – we have built and published extensive support for other aggregators and services to hook into the feed discovery experience and to synchronize with the Common Feed List that ships with IE. When a user subscribes to a feed using IE, he's not limited to using IE to read that feed. Any aggregator can build support for the publicly documented APIs to read and write to the Common Feed List, and any service can build support for synchronizing that feed with their service (and in both cases, several are doing so right now).
I hope this helps make the reasoning behind IE's behaviour with feeds and stylesheets a little less murky.
Thanks,
Sean
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of David Nesting
Sent: Thursday, March 09, 2006 7:30 AM
To: [EMAIL PROTECTED]
Cc: atom-syntax@imc.org
Subject: Re: IE7 Feed Rendering Issue
On 3/9/06, Klaus Johannes Rusch <[EMAIL PROTECTED] > wrote:
Unless the "context" is stored with the feed, the user experience will
be different when a user follows a link from another page (rendered as
Web page) and later loads the same link again from the bookmarks
(rendered as an XML feed).
If this is just an issue with the example rules, that's solvable by adapting the rules to match expectations. Maybe browsers would be willing to store some sort of context along with the bookmark.
But really the underlying point is that browsers and/or feed readers can choose to render the feed however they want. The Atom syntax does not require xml-stylesheet support nor does any part of the Atom specification require that feed readers be web browsers, or that feeds be rendered as web pages.
It's important to remember here that we would be in exactly in the same position if any other non-Microsoft feed reading application registered itself as the handler for the application/xhtml+xml media type. IE and Firefox would dutifully pass the file to this 3rd-party application, which probably would not be a web browser, and the feed would be rendered in a reader-specific way, with zero attention paid to xml-stylesheet.
The behavior we're used to seeing is basically a fallback handler for arbitrary XML content. It's expected to be overridden when a real application steps up to say that it will handle content of that type. The IE feed reader case is somewhat distinct, but the implications are the same. The problem is that IE and Firefox's default behavior is actually useful, and a desirable alternative to applications legitimately stepping up to act as handlers for these media types.
If this is what we're trying to "fix", I think this is out of scope for this mailing list.From the Mozilla/Firefox perspective, you may find these bugs interesting:
https://bugzilla.mozilla.org/show_bug.cgi?id=57342 - Add "View as Text/HTML/..." option for unknown mime content-type
https://bugzilla.mozilla.org/show_bug.cgi?id=194351 - General module to show widespread XML formats: WML, RSS, DocBook, OpenOffice.org etc.
The comments within the first bug also include discussion of overriding the web server's media type and/or the browser's behavior in response to it to permit content to be viewed using the browser's built-in text, HTML, or XML handling mechanisms. The discussion thus far seems to be just a variation of this, with a little automation (context) helping to make that decision.
David
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
