Subject: IE7 Feed Rendering Issue

From: "James Yenne" <[email-masked]>
Date: Wed, 8 Mar 2006 11:10:16 -0800

IE6 and FF render Atom/RSS feeds as html using the xml-stylesheet directive,
however, IE7 Beta 2 drops the feed's xml-stylesheet directive, if one
exists, and replacing with IE7's own stylesheet containing the gray to blue
gradient background with the MS RSS extensions for navigation/collation.
This rendering is all pre subscribe, so the feed has not been converted to
RSS yet.  I had an email conversation last week with Sean Lyndersay about
this, and his take is that "this is a feed intended for rendering in an
aggregator" and "Publishers' don't have control over the look of their feed
in" other readers.  
 
My counterpoint is that this is non-standard approach because the
xml-stylesheet directive is a standard XML directive, and IE7 (the reader,
not the browser) is essentially saying that RSS/Atom are not first of all
XML and should be handled in some proprietary way through IE's
display/navigation layer.  Feeds that use the xml-stylesheet to provide
custom navigation are now in IE7 required to use the IE7 navigation xsl,
which is not standard.  The solution, I believe, is that the IE7 proprietary
rendering (and xml-stylesheet removal) be the default ONLY when none is
provided, which is probably most cases.
 
I would call IE7 dropping xml-stylesheet directives a data lose issue.  So
my question is, what is the right thing for the browser to do?  When is a
browser a feed reader, and thus (I guess) simply can drop elements from the
feed at will?  Can a browser just drop xml-stylesheet directives at will? 
 
Thanks,
James

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 8 Mar 2006 20:36:28 +0100

* James Yenne <[email-masked]> [2006-03-08 20:30]:
>I would call IE7 dropping xml-stylesheet directives a data lose
>issue.

Neither desktop nor online aggregators (such as NetNewsWire and
Bloglines) have ever paid attention to such directives. What is
your opinion on that?

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

---

From: "David Nesting" <[email-masked]>
Date: Wed, 8 Mar 2006 14:57:03 -0600

On 3/8/06, James Yenne <[email-masked]> wrote:
>
> My counterpoint is that this is non-standard approach because the xml-stylesheet
> directive is a standard XML directive, and IE7 (the reader, not the browser)
> is essentially saying that RSS/Atom are not first of all XML and should be
> handled in some proprietary way through IE's display/navigation layer.
>

I'm going to have to side with Microsoft on this one.  When you provide
information in an XML format, you're providing information, not a web page.
You may desire to have it rendered a certain way when it's rendered by a web
browser, but the consumers of your data can do whatever the heck they want
with it.  The use of xml-stylesheet is not actually part of the proper XML
standard and there is no requirement that any implementation honor it.  It's
merely a suggestion.

David

--
Apologies in advance if this e-mail messes with your clients.  This is my
first post to the list using Gmail and I'm not entirely sure how
mailing-list-friendly it is.

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 00:43:38 -0700

>> When you provide information in an XML format, you're providing
information, not a web page.  You may desire to have it rendered a certain
way when it's rendered by a web browser, but the consumers of your data can
do whatever the heck they want with it. <<

I'm sorry, but you're wrong.  What you have just stated suggests that its
not at all up to the consumer how he/she wants to view a particular file,
and its not up to the author of that content either.  While you are correct
that it is up the the client application to determine whether or not to
render a feed based on a PI directive, when the existing version of that
software chooses to render the file based on the directive, and in the
follow-up, that capability that has become common place suddenly disappears,
that presents a problem.

The way to solve this problem is not to hand the controls over to MS and
suggest that "hey, do whatever you want, whats important is that you're
happy" and instead "you've supported this feature now for over 5
years.  People expect this capability to work.  If the developer specifiies
a separate xml-stylesheet PI, whether that be CSS or XSLT, then one of two
things should happen:

1 - Respect the directive, and use this instead of the internal rendering
engine.
2 - Render the feed with the internal rendering engine, but provide a
clearly marked message, and link that will allows the user to choose the
directives as the author specified to be used, and then to make this the
default selection the next time this file is accessed.

If we do not send a clear message to Microsoft that its *NOT* okay to simply
ignore the specified directives, choosing instead to render them however
they might see fit, then whats next... should they ignore imported CSS or
Javascript files, or rewrite these files to a language/markup/scripting
language of their own choosing/preference?

BTW... the correct answer should not be an argument suggesing that the
specifications for these technologies do not allow for such optional
behavior, therefore my point is null and void.  The reason is not an attempt
to be disrespectful to anyones opinion (if in fact this were their opinion)
and instead to stand firm that its not about optional or required, and
instead about consistency, and common sense.

> "[The] doctrine has no place in the modern world. The air is a public
> highway, as Congress has declared. Were that not true, every
> transcontinental flight would subject the operator to countless trespass
> suits. Common sense revolts at the idea. To recognize such private claims to
> the airspace would clog these highways, seriously interfere with their
> control and development in the public interest, and transfer into private
> ownership that to which only the public has a just claim."

  Mr. Justice DOUGLAS : UNITED STATES v. CAUSBY et ux.  Decided May 27, 1946
  Original source and link: Lawrence Lessig, Free Culture : Introduction :
Paragraph 6 :
http://libreria.sourceforge.net/library/Free_Culture/intro.html

There are justifications and reasons why an application, for example, an XML
development tool; should ignore these directives.  To require that an
application MUST adhere to the directives set forth would obviously be a bit
silly when an application is designed for developing/editing instead of
rendering.  IE is a rendering tool.  It renders content specified by the
author of that content.  To suggest that MS should be given the freedom to
take control of a document and disregard that in which they have
consistently supported for 5 years, without even so much as offering a
choice, is both assanine and ludricous.

If this is to be the chosen course, then what will end up happening is that
MS will be placed on the Top 1 most wanted list, again, after working as
hard as hey have to try it improve their image.  What will also happen is
that folks, like myself, will find legal ways around the system in which
they have chosen to implement.

As such, theres not a whole lot of point in creating bad publicity for
something that will simply be circumvented and implemented as the author
original specified.

Is there?

On 3/8/06, David Nesting <[email-masked]> wrote:
> display/navigation layer.
> >
>
>

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 00:57:42 -0700

btw... to be perfectly clear, your statement includes the word "consumers"
which, if thought of in terms of the end user, then in fact your point could
be seen as valid; or in other words "It should be the end users choice to
use the internal viewer, or the directives set forth by the author.

However, the implication is not that "consumers" refers to end users, and
instead applications, in this case, Internet Explorer.

If, in fact, what you mean by this *IS* that its the end users choice, then
I would tend to agree... as long as the option exists.  If there is no
option provided, and simply "its our way and only our way... deal with it"
then we will be left to deal with it just as mentioned: find legal ways
around the system, and publishing/promoting these work arounds via the
various means that the folks who feel such information is necessary to
promote have at their disposal.  I know at least a couple hundred folks
myself that I know would be happy to publish such information as long as
this information stayed within the confines of the end user and developer
licensing agreements.  Which it would.

On 3/9/06, M. David Peterson <[email-masked]> wrote:
> If we do not send a clear message to Microsoft that its *NOT* okay to
> simply ignore the specified directives, choosing instead to render them
> however they might see fit, then whats next... should they ignore imported
> CSS or Javascript files, or rewrite these files to a
> language/markup/scripting language of their own choosing/preference?
>
> Paragraph 6 : http://libreria.sourceforge.net/library/Free_Culture/intro.html
>
>
> There are justifications and reasons why an application, for example, an
> XML development tool; should ignore these directives.  To require that an
> If this is to be the chosen course, then what will end up happening is
> that MS will be placed on the Top 1 most wanted list, again, after working
> as hard as hey have to try it improve their image.  What will also happen is

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 01:38:21 -0700

""this is a feed intended for rendering in an aggregator" and
"Publishers' don't have control over the look of their feed in" other
readers."

WHAT???  Are you kidding me...  If by other readers you are choosing
to exclude those that do, then thats just lame....

Take for example, your own Dare Obasanjo's RSS Bandit (See attached
screen shot) or, hitting even closer to home, Windows Live and
Start.com, which both allow the ability to build gadgets than can
render data feeds however you might see fit. There are TONS of
examples of feed readers that provide AMPLE capability for user
definable rendering of a web feed.  I hope these two are enough, but
if you, in fact, would like to see more, I would be happy to write
provide just such a report for you.

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 01:48:40 -0700

Aristotle,

Both of these are services, not browsers.  As a service, its
understandable...  Limited server resources would justify this, as would the
need to cache the data feed, and the related transformation or css files.
However, when the client accesses the feed directly from the browser, the
resources are no longer an issue, as your dealing with a one-to-one
relationship between user and machine, and your also dealing with a browser
that has always rendered the XML files as specified the PI directives, as
long as those files are valid XSLT and/or CSS files in which IE supports.
While you could argue that CSS support is dodgy at best, XSLT support is
quite the opposite.

Please don't take this the wrong way... this isn't a lash back against you,
and instead an attempt to try and separate what can be seen as a service
provider who has never provided support this this, and an application in
which has for the last 5 years.

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 02:13:04 -0700

> for user definable rendering of a web feed.

and publisher definable.  Sorry, what I said, was in fact, not inclusive of
your point regarding publisher control.  There are plenty of feed readers
that offer this level of control.  For example, IE 6, Fx, Opera, and Safari
-- yes, they are browsers , and yes this is stretching things... but not
really, when you consider how many feed readers use a browser interface to
their system.  If a browser can not be seen as a feed reader, unless it were
programmed as such, then all of these service providers must also be
excluded from the feed reader list.

On 3/9/06, M. David Peterson <[email-masked]> wrote:
> issue.  So

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "David Nesting" <[email-masked]>
Date: Thu, 9 Mar 2006 07:59:25 -0600

On 3/9/06, David Nesting <[email-masked]> wrote:
> > If, in fact, what you mean by this *IS* that its the end users choice,
> > then I would tend to agree... as long as the option exists.
> >
>
> That was, actually, what I was trying to say.
>

Oops, I quoted the wrong thing.  I was, in fact, trying to say the opposite:
it's up to the consuming applications (feed readers) to decide how they want
to render your feed.  You cannot exert control over 100% of feed readers'
presentations of your feed, since many of them will not resemble a web
browser in any way.  Therefore it is unreasonable for you to expect to have
100% control over feed readers that are also web browsers.

That being said, as I noted in my earlier e-mail, I do agree that this IE
behavior change breaks some non-traditional web sites (including some of my
own), and that some sort of workaround is going to be needed.

David

---

From: "David Nesting" <[email-masked]>
Date: Thu, 9 Mar 2006 07:58:39 -0600

> then I would tend to agree... as long as the option exists.

That was, actually, what I was trying to say.  You are publishing an XML
feed, not a web page.  You are publishing data, not a brochure.  You cannot
control how your feed renders in non-web browser feed readers.  These
readers may not resemble a web browser in any way.  Feed aggregators are not
going to preserve your style sheet.  Your feed, within these aggregated
feeds, is not going to look remotely like you intended.  It won't look the
same when converted to other feed dialects.  There is no requirement in Atom
that the xml-stylesheet be preserved.  I don't think it is reasonable for
one to expect that feed readers (built into web browsers or otherwise) are
going to be keen on abandoning their own user interface guidelines because
you'd prefer your entries to be formatted a particular way.

If you want a web page, write your feed as an HTML page.

I will, however, concede that IE has changed its behavior, and the behavior
change is arguably something to get irritated about.  Some of us build sites
not with HTML, but with XML of various forms, and rely on xml-stylesheet to
make our data-oriented site presentable in web browsers.  In the past, users
could click on links between, e.g., FOAF-as-HTML and Atom-as-HTML and their
experience wouldn't be too different from any other web page.  Now when they
follow that link, they'll get a "page" that looks nothing like we intended.
This is a bad user experience.

So the real question is: How can site authors instruct a web browser-feed
reader hybrid when it should treat an application/atom+xml document as a web
page (via xml-stylesheet) and when it should treat it as a consumable feed?
Perhaps it is reasonable for these types of applications to work like this:

1. If the feed is requested in the context of a "web" link, and it has an
xml-stylesheet directive, treat it as a web page
2. If the feed is requested within the context of the feed reading component
of the application (thus no web "context"), or would simply be rendered as
raw XML due to the lack of an xml-stylesheet processing instruction, treat
it as a raw feed and present it subject to the feed reader UI guidelines.

If there is no option provided, and simply "its our way and only our way...
> deal with it" then we will be left to deal with it just as mentioned: find
> legal ways around the system, and publishing/promoting these work arounds
> via the various means that the folks who feel such information is necessary
> to promote have at their disposal.  I know at least a couple hundred folks

Could content negotiation work here?  Publish both your
application/xhtml+xml feed and a pre-transformed text/html variant under the
same URL.  I'm not too familiar with IE's feed reading capabilities here,
but does it at least do enough to vary the Accept request header to make
this work?

David

---

From: Klaus Johannes Rusch <[email-masked]>
Date: Thu, 09 Mar 2006 15:15:17 +0100

David Nesting wrote:

> So the real question is: How can site authors instruct a web 
> browser-feed reader hybrid when it should treat an 
> application/atom+xml document as a web page (via xml-stylesheet) and 
> when it should treat it as a consumable feed?  Perhaps it is 
> reasonable for these types of applications to work like this:
>
> 1. If the feed is requested in the context of a "web" link, and it has 
> an xml-stylesheet directive, treat it as a web page
> 2. If the feed is requested within the context of the feed reading 
> component of the application (thus no web "context"), or would simply 
> be rendered as raw XML due to the lack of an xml-stylesheet processing 
> instruction, treat it as a raw feed and present it subject to the feed 
> reader UI guidelines.

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).

-- 
Klaus Johannes Rusch
[email-masked]
http://www.atmedia.net/KlausRusch/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 07:19:27 -0700

behavior change breaks some non-traditional web sites (including some of my
own), and that some sort of workaround is going to be needed. <

And thats the key I think we both agree on.

You right about the feed readers in general.. Thats simply not the norm, so
it cant be expected.  However, Sean's point that other feed readers dont
allow customization was a bit of target as some actually do.

The thing that seems to bother both you, myself, and several other folks is
not that IE is adding feed reading support, but that they seems to have
forgotten that there are a lot of folks out there who see IE as a web
browser and expect that when the move to IE6 to IE7 begins to take place,
things will not break in any way, shape, or form.  In fact, there is a post
on the IE7 blog that speaks directly to this general fact, and is why I am
probably a bit more agitated that I would be had they not made it point to
bring the "not break existing customers apps" out as a priority:

> Compatibility and our updated CSS behavior
>
> Obviously, we have heard the feedback asking us to be more
> standards-compliant in our rendering behavior. We must balance this ask with
> the need of our customers (and end users) to have their pages not be broken.
> To find a balance we introduced a strict mode in IE6 that lets authors opt
> in into the more standards compliant rendering (and, if you're putting in a
> modern DOCTYPE declaration, you're being opted in automatically). Pages
> authored under non-strict mode (or "quirks mode") will not change behavior
> in IE7 – so the fixes we've done to be more CSS compliant won't appear under
> quirks mode. However, if your content is under "strict mode", our behavior
> is more standards compliant, and your pages may break - for example, if you
> use some of the CSS hacks or rely on our old incorrect overflow behavior. We
> understand the pain this might cause in the short term but we believe a move
> to a more standard compliant implementation benefits everyone in the long
> run.
>
> Last but not least, big thanks to the community: here on the blog (yes, we
> are paying attention to the comments), the WASP team and those out on the
> web reporting CSS issues with IE. We know we have a long road ahead but I am
> very excited with the progress we are making.
>
> - Markus Mielke
>
source: http://blogs.msdn.com/ie/archive/2006/02/02/523679.aspx

Does this smell a bit off to anyone else to see such opposing viewpoints?  I
realize in large companies this will happen.. one person will say one thing
for one team, another for another, and they dont necessarily contradict each
other.

It seems maybe that the IE7 and RSS teams need to decide what the message is
overall, and then speak to that point once they have...

On 3/9/06, David Nesting <[email-masked]> wrote:
> > On 3/9/06, M. David Peterson <[email-masked] > wrote:
> >
> > >  If, in fact, what you mean by this *IS* that its the end users
> > > choice, then I would tend to agree... as long as the option exists.
> > >
> >
> Oops, I quoted the wrong thing.  I was, in fact, trying to say the
> opposite: it's up to the consuming applications (feed readers) to decide how
> they want to render your feed.  You cannot exert control over 100% of feed
> readers' presentations of your feed, since many of them will not resemble a
> web browser in any way.  Therefore it is unreasonable for you to expect to
> have 100% control over feed readers that are also web browsers.
>

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 07:23:32 -0700

Lets try that again, to everyone this time:

 I think we are both on the same page.  I'm glad to see that.   I was
suddenly beginning to feel like I had missed something somewhere as it
seemed that a lot of folks were making comments that seemes off target from
there normal perspective.

Regarding XML/XSLT, both client and server, in fact that is a strong area of
expertise that has, as of late, become somewhat of specialized field.  While
the title itself is in what I would call Limbo as between Simon St. Laurent
and myself we try and decide what the best direction is for the client-side
XML title I have been working on (the Ajax craze kind of killed the market
at all the wrong times for a client-side XML title, and the addition of
Opera's XSLT support and the yet to release IE7, the timing needs to be
adjusted accordingly and, for now anyway, part of what already exists may
find its way into a new product effort they are working on that I dont think
I can really talk about yet,... so to be safe, I probably better not.

On the other side of the fence, Kurt Cagle and I are working towards
finishin out this title >
http://www.amazon.com/gp/product/159059536X/ref=pd_sbs_b_1/104-8254139-4166325?%5Fencoding=UTF8&v=glance&n=283155
<
of which I can speak with a bit of confidence in suggesting that the Mozilla
folks, while struggling a bit as of late, are definitely making the right
decisions to ensure that the needs of their user base are best served based
on the user feedback.  A lot of good thing are beginning to unfold in the
XML space as a whole... I think this is a good thing for all of us...

It seems like there might be a need for us to set up a separate forum or
list server specific to client side browser XML processing... is there
enough interest in something like this to warrant the set up?  Actually, the
setup takes all of about 10 minutes for the forum software I would recommend
using, so if the overall interest in such a forum exists, let me know, and I
will get it set up.

Thanks for helping clarify things!  I feel MUCH better now!

On 3/9/06, David Nesting <[email-masked]> wrote:
> I will, however, concede that IE has changed its behavior, and the
> behavior change is arguably something to get irritated about.  Some of us
> build sites not with HTML, but with XML of various forms, and rely on
> xml-stylesheet to make our data-oriented site presentable in web browsers.
> In the past, users could click on links between, e.g., FOAF-as-HTML and
> Atom-as-HTML and their experience wouldn't be too different from any other
> web page.  Now when they follow that link, they'll get a "page" that looks
> nothing like we intended.  This is a bad user experience.
>
> component of the application (thus no web "context"), or would simply be
> rendered as raw XML due to the lack of an xml-stylesheet processing
>   If there is no option provided, and simply "its our way and only our
> > way... deal with it" then we will be left to deal with it just as mentioned:
> > find legal ways around the system, and publishing/promoting these work
> > arounds via the various means that the folks who feel such information is
> > necessary to promote have at their disposal.  I know at least a couple
> > hundred folks myself that I know would be happy to publish such information
> > as long as this information stayed within the confines of the end user and
> > developer licensing agreements.  Which it would.
> >
>

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "David Nesting" <[email-masked]>
Date: Thu, 9 Mar 2006 09:30:26 -0600

> (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

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 08:33:37 -0700

FYI.... just added a Browser-based Atom & RSS section to
UnderstandingAtom.com (which UnderstandingRSS.com points to as well) Trac
instance.  Please, by all means, if you have understanding in paricular area
of this side of the web feed processing world, add this to an existing
section, or something more specific to this area.

And if you have need for SVN, Darcs, + several other repos, hosting for your
Atom or RSS related project this server has been setup specifically for this
purpose.  No ads, no fees... but it needs to be related to Atom or RSS in
one form or another.  Thats all I ask...

http://trac.understandingatom.com/wiki/BrowserBasedAtom%26RSS

On 3/9/06, M. David Peterson <[email-masked]> wrote:
> Regarding XML/XSLT, both client and server, in fact that is a strong area
> of expertise that has, as of late, become somewhat of specialized field.
> While the title itself is in what I would call Limbo as between Simon St.
> Laurent and myself we try and decide what the best direction is for the
> client-side XML title I have been working on (the Ajax craze kind of killed
> the market at all the wrong times for a client-side XML title, and the
> addition of Opera's XSLT support and the yet to release IE7, the timing
> needs to be adjusted accordingly and, for now anyway, part of what already
> exists may find its way into a new product effort they are working on that I
> dont think I can really talk about yet,... so to be safe, I probably better
> not.
>
> http://www.amazon.com/gp/product/159059536X/ref=pd_sbs_b_1/104-8254139-4166325?%5Fencoding=UTF8&v=glance&n=283155 <
> > browser-feed reader hybrid when it should treat an application/atom+xml
> > document as a web page (via xml-stylesheet) and when it should treat it as a
> > consumable feed?  Perhaps it is reasonable for these types of applications
> > to work like this:
> >

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Sean Lyndersay <[email-masked]>
Date: Thu, 9 Mar 2006 07:51:29 -0800

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-masked] [mailto:[email-masked]] On Behalf Of David Nesting
Sent: Thursday, March 09, 2006 7:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: IE7 Feed Rendering Issue

On 3/9/06, Klaus Johannes Rusch <[email-masked] <mailto:[email-masked]> > wrote:

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.

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

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 09:10:33 -0700

>> 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). <<

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

On 3/9/06, Sean Lyndersay <[email-masked]> wrote:
>
>  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).
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *David Nesting
> *Sent:* Thursday, March 09, 2006 7:30 AM
> *To:* [email-masked]
> *Cc:* [email-masked]
>
> *Subject:* Re: IE7 Feed Rendering Issue
>
>
>
> On 3/9/06, *Klaus Johannes Rusch* <[email-masked] > wrote:
>
> 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.
>
> 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/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 10:38:19 -0700

couple notes: (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).

In fact, yes, this is true, but its easy to circumvent by using a bootstrap
file.  A simple application/xml MIME-type used against a standard non-web
feed xml files (e.g. http://mdavidpeterson.com/SessionConfig.aspx ) will
allow you to then to circumvent the auto detection mechanism when you then
call an atom feed from within the imported XSLT file. It seems to be this
way, anway...  is this, in fact the case?  I guess thats more a question
geared towards atom files that are served as application/atom+xml that are
called internal to XSLT via the document function or external via
javascript/XMLHTTP, etc... I am almost certain theres nothing that would
connect the two processes (MSXML and the IEFrame.dll which seems to be the
entry point for data feeds(yet another question I am unsure the answer to,
but reading the registry seems to suggest this to be the case, and I'm not
sure that gaining any sort of confirmation to this really matters all that
much))

I guess some quick code would answer that question quite easily.  I'll do
just that and post the code and results to the UnderstandingAtom.com site
for reference.

Thanks Sean!

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 9 Mar 2006 19:44:42 +0100

* Sean Lyndersay <[email-masked]> [2006-03-09 17:05]:
>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.

+1

>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).

+1

>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).

+1

Regards,

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 9 Mar 2006 20:02:15 +0100

Hi David,

* M. David Peterson <[email-masked]> [2006-03-09 10:00]:
>>>I would call IE7 dropping xml-stylesheet directives a data
>>>lose issue.
>>
>> Neither desktop nor online aggregators (such as NetNewsWire
>> and Bloglines) have ever paid attention to such directives.
>> What is your opinion on that?
>
>understandable... Limited server resources would justify this,
>as would the need to cache the data feed, and the related
>transformation or css files.

No, one of them (NetNewsWire) is a desktop application. Like all
desktop aggregators, it throws away any styling information
associated with the feed via XML means. Many of them will even
filter away (some of) the styling information transmitted in the
body of an entry using HTML’s provisions, for security reasons.

>However, when the client accesses the feed directly from the
>browser, the resources are no longer an issue, as your dealing
>with a one-to-one relationship between user and machine, and
>your also dealing with a browser that has always rendered the
>XML files as specified the PI directives, as long as those files
>are valid XSLT and/or CSS files in which IE supports. While you
>could argue that CSS support is dodgy at best, XSLT support is
>quite the opposite.

This is a question of semantics: is IE7 a browser, or is it a
combined browser and aggregator? If you see it as the latter (I
do), it follows that it has the same freedoms as every other
desktop aggregator: that is, to ignore the styling information
associated with feeds at the feed level.

James Yenne seems to be advocating a third option: that the
behaviour should differ depending on whether the feed in question
in being viewed before or after subscribing. To me, that feels
like combining the worst of both worlds. Interface inconsistency
that depends on a remote part of the application state seems like
really bad design from the user perspective, and throws away the
opportunities opened up by combining browser and aggregator in a
single interface.

Regards,

---

From: James M Snell <[email-masked]>
Date: Thu, 09 Mar 2006 11:07:44 -0800

+1, As an alternative, Feed Readers can provide publishers with a way of
specifying optionally applied styling for feeds and entries.. e.g.,

<feed>
  ...
  <link rel="stylesheet" type="..." href="..." />
  ...
  <entry>
    ...
    <link rel="stylesheet" type="..." href="..." />
    ...
  </entry>
</feed>

- James

A. Pagaltzis wrote:
>[snip]

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 12:28:59 -0700

Hey Aristotle,

Thanks for the reply!

On 3/9/06, A. Pagaltzis <[email-masked]> wrote:
> body of an entry using HTML's provisions, for security reasons.

Ahhh... I should have done my homework better.  Thats my bad... thanks for
clarifying.

> associated with feeds at the feed level.

I agree.  My orginal concern was that IE7 simply not break existing data
feeds that are rendered with CSS/XSLT via PI's.  One of the options that
seemed reasonable was to allow the user the ability to switch between both
the IE view and the PI directives view.  While the solution they have chosen
is to instead allow the user to turn the rendering behavior on or off, that
still fits into the definition of user choice.  In reality, I was confusing
what I agreesively stand for (users choice) with something that was really
directed at not breaking applications, but was instead packaged as publisher
choice.

I recognize now this was a mistake.  And via Sean's reply, I no longer have
any concerns.  The user will be given the choice, and thats all that
matters.  Again, my apologies for mixing to very separate view points...
didnt really think this one through to the point of realizing my mistake.

> opportunities opened up by combining browser and aggregator in a

I didnt not realize this.  Okay, I can see your point.  Based on my own user
experience with IE7 it seems to me that the moment that the orange icon is
clicked is the moment I should expect a consistent UI in regards to feed
viewing and subscription. *IF* there existed a scenario in which an XML feed
should be rendered based on publisher specification, it would be if and when
that feed was accessed by ckicking a link internal to a document, or
accessing the feed directly via the address bar.  However, it seems I am not
the first to point this out, and in fact, I'm not certain that this really
should be the case.  If the user can turn the behavior off, and expect a
consistent experience, now matter how they access the feed, this is a good
thing.  The same is true when the behavior is on -- consistency.  It would
seem to me that your derived conclusion through all of this is, in fact,
spot on.  As such, I retract all of my concerns, as they are no longer
needed nor valid.

Thanks to both you and Sean for helping me work through this.  It seems to
me that the questions raised were valid when a full context was
unknown and/or not completely understood.  With this in mind, it seems there
are now some resources to gather together that can be pointed at to help
answer what are bound to be more questions in this specific area for others
as well.

Thanks again!

Regards,

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Antone Roundy <[email-masked]>
Date: Thu, 9 Mar 2006 12:40:31 -0700

On Mar 9, 2006, at 12:07 PM, James M Snell wrote:
> As an alternative, Feed Readers can provide publishers with a way of

Given my opinion on the use of the link element, I suppose I should  
propose an alternative:

<ext:style type="text/css">
	...
</ext:style>

or

<ext:style src="http://..." />

Either method permitted, like how we do atom:content.  'type="text/ 
css"' optional, or is it needed?  Warning to those daring to try the  
second that some feed readers won't bother downloading the external  
file.  Warning to publishers that if they specify styles for "body",  
for example, some readers may say "there's no body element in the  
content, so I'll ignore this rule" (so put the content in a container  
with an ID or class and set the style for that instead), and others  
may say "how dare you try to take over the styling of the body when  
the body element isn't allowed in the content, I'll ignore this  
rule", and others may just ignore all or some of it for whatever  
reason they wish.  Can be at feed or entry level and be intended for  
application to its siblings and their children (those with textual  
content only--and of course, some clients may not apply it to all  
siblings and children even if they are textual).  If we really want  
to get fancy (big if), we could add @apply-to="content", but then you  
get into the qnames in attributes problem...  Or we could specify  
that it only applies to atom:content and perhaps atom:summary (and  
any extension element that explicitly specifies that it applies).

Well, that's enough off the top of my head.

Antone

---

From: "James Yenne" <[email-masked]>
Date: Thu, 9 Mar 2006 11:50:00 -0800

There is no doubt publishers will want some style control over feeds... You
can be sure advertisers will when they get in there.   The only practice I'm
advocating is that if I want my feed to be formatted in the browser as I
have declared using xml-stylesheet, it should be allowed.  If I don't have
one, and 90% don't, then by all means, use the Microsoft IE7 stylesheet.  I
want to present to the user, for example, the tie dye background (not the
blue to grey gradient) and I think it maybe reflects my site better, and
will result in a subscribe click.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of A. Pagaltzis
Sent: Thursday, March 09, 2006 11:02 AM
To: [email-masked]
Subject: Re: IE7 Feed Rendering Issue

Hi David,

* M. David Peterson <[email-masked]> [2006-03-09 10:00]:
>> Bloglines) have ever paid attention to such directives.
>understandable... Limited server resources would justify this, as would 
>the need to cache the data feed, and the related transformation or css 
>files.

No, one of them (NetNewsWire) is a desktop application. Like all desktop
aggregators, it throws away any styling information associated with the feed
via XML means. Many of them will even filter away (some of) the styling
information transmitted in the body of an entry using HTML's provisions, for
security reasons.

>However, when the client accesses the feed directly from the browser, 
>the resources are no longer an issue, as your dealing with a one-to-one 
>relationship between user and machine, and your also dealing with a 
>browser that has always rendered the XML files as specified the PI 
>directives, as long as those files are valid XSLT and/or CSS files in 
>which IE supports. While you could argue that CSS support is dodgy at 
>best, XSLT support is quite the opposite.

This is a question of semantics: is IE7 a browser, or is it a combined
browser and aggregator? If you see it as the latter (I do), it follows that
it has the same freedoms as every other desktop aggregator: that is, to
ignore the styling information associated with feeds at the feed level.

James Yenne seems to be advocating a third option: that the behaviour should
differ depending on whether the feed in question in being viewed before or
after subscribing. To me, that feels like combining the worst of both
worlds. Interface inconsistency that depends on a remote part of the
application state seems like really bad design from the user perspective,
and throws away the opportunities opened up by combining browser and
aggregator in a single interface.

Regards,

---

From: "James Yenne" <[email-masked]>
Date: Thu, 9 Mar 2006 12:06:38 -0800

>>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.
>
>+1
>

While I agree in principle, my concern is that as Microsoft moves forward
with this reasonable tact for IE and on behalf of the web feed community,
Mozilla, Safari and others will have their own solution which is different
and also "consistent".  The published SSE extensions are a good step in
making this consistency stick, but will these others use SSE or yet another
solution.  Why can't I publish my own stylesheet and use these Microsoft
elements for collation, background, etc.  This Microsoft stylesheet should
be replaceable.

>>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).
>
>+1
>
>>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).
>
>+1
>

Sure, serving XHTML is just a one off for my app, but part of my goal is to
clarify this behavioral standard for the browser / feed reader / aggregator
community.
  
The publisher is thus henceforth locked into the IE browser's look and feel
for the subscription & presentation page, which works fine of course.  This
is a browsers becoming a reader and an aggregator, and it's tricky.

-James

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 13:28:14 -0700

* Why can't I publish my own stylesheet and use these Microsoft
elements for collation, background, etc.  This Microsoft stylesheet should
be replaceable. *

I would say this is a quite valid question.

Is this capability planned and has simply not been implmented at this
stage?  I realize the look and feel of the browser itself will be handled
via the standard Windows Themes interface when this, in fact, is changed by
the user.  Will this stretegy be the primary strategy moving forward?

Of course, the ultimate question James has posed is most particular to the
web feed itself.  It's simple enough to go in and play with the DOM via the
various GreaseMonkey clones for IE, so obviously where theres a will, the
way has already been paved.  But this is obviously not an IE strategy, and
instead a vendor hack.

Of course, it seems to me that the piece that is missing has nothing to do
with all of this... the piece that is missing is maybe our own realization
that there is an RSS API that, from what I understand (lloks like a new item
will be added to my study list for the week :), allows the ability to
develop a completely different rendering engine all together that ties into
the RSS backbone such that no matter what interface is use, IE-based,
XAML-based, WinForms-based, etc.... each can stay consistent with the same
set of data.

Thats actually pretty cool when you think about it.  Would be cooler if it
had a more snazzy name to the backend system... something like "AtomicRSS"
but then again, theres nothing stopping me or anyone else from building just
such an interface that could act as the Atom-enhanced version of the of the
RSS backbone...

I sure do love the idea of extensions, I tell ya ;) :D

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 13:40:21 -0700

NOTE-TO-SELF: Hmmm.... I'd bet the XML-MVP's would be a good interface into
the Microsoft channel.  They do have the legal clearance for various
activities, and they have already relicensed the XML-MVP library back to MS
for redistribution... I'd bet they would be a pretty logical group of folks
to approach regarding the development of a community-based Atom API that
would be OSS, allowing for what could easily be seen as the newer, better,
more refined interface into the RSS backbone -- of which the community could
continue to make the code base faster, more reliable, more secure, more
capable, and could continue its development pace at the speed of OSS rather
than the speed of MolasseS.

Lucky for me several of these folks are close personal friends who could
make this happen in a flash.

Wait, did I just say this all out loud? Ooops!  Please disregard.. you didnt
hear anything from me, k? ;) :D

On 3/9/06, M. David Peterson <[email-masked]> wrote:

> > >* Sean Lyndersay <[email-masked] > [2006-03-09 17:05]:

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "'A. Pagaltzis'" <[email-masked]>
Date: Thu, 9 Mar 2006 23:44:26 +0100

* James Yenne <[email-masked]> [2006-03-09 20:55]:
>The only practice I'm advocating is that if I want my feed to be
>formatted in the browser as I have declared using
>xml-stylesheet, it should be allowed.

That means your feed will have to be missing UI features that
other feeds have. I hope I don’t need to explain why that is a
bad idea for a user interface.

Maybe there could be a button “View with publisher look” when the
feed provides styling information, but it should definitely not
be the default.

>If I don't have one, and 90% don't, then by all means, use the
>Microsoft IE7 stylesheet. I want to present to the user, for
>example, the tie dye background (not the blue to grey gradient)
>and I think it maybe reflects my site better, and will result in
>a subscribe click.  

Or they will be irritated because it’s different and the usual
sorting controls and navigation are missing?

Regards,

---

From: "'A. Pagaltzis'" <[email-masked]>
Date: Thu, 9 Mar 2006 23:41:17 +0100

* James Yenne <[email-masked]> [2006-03-09 21:10]:
>>>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).
>>
>>+1
>>
>
>Sure, serving XHTML is just a one off for my app, but part of my
>goal is to clarify this behavioral standard for the browser /
>feed reader / aggregator community.

I think that feeds should behave like feeds. Try to differentiate
on the content, not the looks, if you want more readers.

Regards,

---

From: "James Yenne" <[email-masked]>
Date: Thu, 9 Mar 2006 15:45:12 -0800

Yes, I guess I don't know what important UI feature my feeds would be
missing if they didn't use the IE7 stylesheet?  (feel the shame for asking
:)  I have my own feed entry navigation, thank you kindly, and yes, I (will)
use the SSE extensions.  The educational box describing what feeds are with
the big subscribe button optional, thanks.  All I care about is the
subscribe button, I'll do the rest.  

Why shouldn't the publisher stylesheet be the default if the publisher wants
it to be in the browser/aggregator app?  IE7 is dsiplaying the Atom content
tags afterall.  This is not just the My Yahoo box with feed links (title and
link href) to pages contain news stories, but IE7 is rendering content tags
in the browser.  I want my psychedelic tie dye background when displaying my
content tags!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of 'A. Pagaltzis'
Sent: Thursday, March 09, 2006 2:44 PM
To: [email-masked]
Subject: Re: IE7 Feed Rendering Issue

* James Yenne <[email-masked]> [2006-03-09 20:55]:
>formatted in the browser as I have declared using xml-stylesheet, it 
>should be allowed.

That means your feed will have to be missing UI features that other feeds
have. I hope I don't need to explain why that is a bad idea for a user
interface.

Maybe there could be a button "View with publisher look" when the feed
provides styling information, but it should definitely not be the default.

>Microsoft IE7 stylesheet. I want to present to the user, for example, 
>the tie dye background (not the blue to grey gradient) and I think it 
>maybe reflects my site better, and will result in a subscribe click.

Or they will be irritated because it's different and the usual sorting
controls and navigation are missing?

Regards,

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 17:35:04 -0700

James, Heres the thing that Aristotle nailed on the head, that should have
been painfully obvious to me as this is something I learned when I was just
a wee little thing running around building 5 of MS campus, a part of MS
termed the "Old M.S. Campus" (not to be confused with the "Old Old MS"
building over by Burgermaster for those keeping score) as, if not obvious by
the number 5, this building was among the frist 5 buildings in
which represented MS campus back in the "old" days (early 90's for those
keeping score.... still).

What was it that I learned?  Setting aside "A LOT!" I learned one very
important thing... The User Interface MUST be consistent.  The success and
failure of many-o'-software products can be directly attributed to
"revolutionary design."  For example, Windows 95* and MS Bob, respectively.

While web pages represent individual structures of a large set of elements
randomly scattered throughout a file, data feeds represent an element
structure that adheres to very strict rules and guidelines.  Because of
this, the significant majority of web feeds serve one specific purpose.
Blog content, web site content, comments, etc... and related meta-data.  Can
these same feeds represent more than just these things?

We both know the answer to that, but for most people, thats exactly what
they do represent and will represent.  There are ways around this... for
example using a bootstrap xml file to call an Atom feed using the document
function in XSLT.  Thats how you solve your problem.  Its as simple as that.

But youre not going to convince a company who has proven time and time again
that MS Bob, tie die or no tie die, just isnt going to fly.  Sorry.  But the
world is a lot bigger than you or me, or anybody else who would like to have
things our way.  The good thing about folks like us is that when someone
tells us we can't, we instead find a way to say "Oh yes I can!"  Which is
what I just gave you in detailed description.

"Okay, everyone smile for the camera!"

Click. Snap.

The end. :)

* For those crying foul over using the term revolutionary to describe the UI
of Windows 95, please count the number of installs of Windows 9x ++ there
are in the world.  Now count the rest.  Which one is more?  Thats why
Windows 95 can be termed revolutionary, as it started a new revolution in
User Interface design that, for the most part, still exists today. (e.g.
same Start button, layout, etc...)  Of course someone is going to clame it
was stolen from someone else, but, whatever.. no big deal.

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: Tim Bray <[email-masked]>
Date: Thu, 09 Mar 2006 17:02:05 -0800

On Mar 9, 2006, at 7:51 AM, Sean Lyndersay wrote:

> I hope this helps make the reasoning behind IE’s behaviour with  
> feeds and stylesheets a little less murky.
I don't really have an opinion as to whether this is the ideal  
behavior.  But there is no doubt whatsoever that that Sean's software  
is entirely within its rights.  It is almost never possible nor  
desirable for the transmitter of a general-purpose data format like  
most of those based on XML to try to impose behavior on the  
recipient.  In the big picture, this is one of the big advantages of  
open data formats.

  -Tim

---

From: Sean Lyndersay <[email-masked]>
Date: Thu, 9 Mar 2006 17:12:03 -0800

This is off-topic, but I'll answer quickly. If someone wants to go into this in more detail, contact me offlist.

Given that we've re-done the look-and-feel of the built-in stylesheet about 3 times since Beta 1 (it's changed again in the next beta release), it obvious that people have lots of opinions about what looks right for them.

So, in some future release (not IE7) we will definitely add the ability for the user to customize the look-and-feel of feeds in IE.

As for the API, the documentation for the RSS API is here: http://msdn.microsoft.com/library/en-us/feedsapi/rss/overviews/msfeeds_ovw.asp
There's an sample app here: http://blogs.msdn.com/rssteam/archive/2006/02/28/540319.aspx

Thanks,
Sean

________________________________
From: M. David Peterson [mailto:[email-masked]]
Sent: Thursday, March 09, 2006 12:28 PM
To: James Yenne
Cc: A. Pagaltzis; [email-masked]; Sean Lyndersay
Subject: Re: IE7 Feed Rendering Issue

Is this capability planned and has simply not been implmented at this stage?  I realize the look and feel of the browser itself will be handled via the standard Windows Themes interface when this, in fact, is changed by the user.  Will this stretegy be the primary strategy moving forward?

Of course, the ultimate question James has posed is most particular to the web feed itself.  It's simple enough to go in and play with the DOM via the various GreaseMonkey clones for IE, so obviously where theres a will, the way has already been paved.  But this is obviously not an IE strategy, and instead a vendor hack.

Of course, it seems to me that the piece that is missing has nothing to do with all of this... the piece that is missing is maybe our own realization that there is an RSS API that, from what I understand (lloks like a new item will be added to my study list for the week :), allows the ability to develop a completely different rendering engine all together that ties into the RSS backbone such that no matter what interface is use, IE-based, XAML-based, WinForms-based, etc.... each can stay consistent with the same set of data.

Thats actually pretty cool when you think about it.  Would be cooler if it had a more snazzy name to the backend system... something like "AtomicRSS" but then again, theres nothing stopping me or anyone else from building just such an interface that could act as the Atom-enhanced version of the of the RSS backbone...

On 3/9/06, James Yenne <[email-masked]<mailto:[email-masked]>> wrote:

>* Sean Lyndersay <[email-masked] <mailto:[email-masked]> > [2006-03-09 17:05]:

-James

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/

---

From: "M. David Peterson" <[email-masked]>
Date: Thu, 9 Mar 2006 19:20:19 -0700

Of course I wish I hadn't made such a damn fool of myself in taking such a
strong and -- I guess extended would be an appropriate word :) --
response this morning when I chose to write the Master Thesis I never quite
got around to during my college years regarding the reasons "they" were
wrong and "I" was right.  Way to far into the drama side of things that I
myself complain about in other groups.

Obviously this was my own personal mistake, and I think Sean has been more
than gracious in looking past the muck and providing real answers to the
questions presented.

My apologies Tim, and to the rest of you for my silliness.

Sean, thanks for the links!  Question:  I think developing various samples
and such would obviously help in understanding how the RSS API works in
general.  There are obvious reasons why it would be impossible for you to
provide privileged information to anyone who is not covered under an
existing non-disclosure and/or other legal agreement.  With this in mind,
would you recommend that the XML-MVP group would be an appropriate contact
point in which any ideas for extended API's could be properly filtered
through, and as such gain a proper (and legal) understanding of where the
needs for such API's will exist and where they will not?

Thanks in advance for your help with all of this, and for putting up with my
misguided mockery of the purpose of this mailing list.  My heart was in the
right place.  My mouth obviously was not.

On 3/9/06, Tim Bray <[email-masked]> wrote:
> > I hope this helps make the reasoning behind IE's behaviour with

--
<M:D/>

M. David Peterson
http://www.xsltblog.com/