Hello everyone. I'm sorry if this is poor etiquette, but I'd like to call everyone's attention to a particular BUG in Firefox. The developers have asked we move the "debate" here. The debate appears to be that many people feel this is a bug, and the Firefox devs feel that it's proper browser behavior.
Here's the jist of it: If Firefox encounters an RSS feed, it applies its own simple styling to it, even if the developer has specified a valid XML stylesheet via the <?xml-stylesheet command, which is the proper valid way to style XML.
Here are the arguments:
Pro: The Firefox devs feel as though RSS is really intended to be read by a feed reader, and therefore, for the sake of standards and ease, always apply a consistent UI.
Con: Firefox simply ignores developers' wishes altogether. What's next - ignore CSS to apply the CSS the Firefox devs like best? If a feed reader reads the feed, style doesn't matter anyway. But if a developer intends a feed to have style, why on earth would an application choose to override it. To add insult to injury, the default stylesheet for RSS is ugly and hard to read. It's hard to even figure out where one entry ends and another begins. At least make your style look as nice as IE7's.
Proposed solutions: 1. Sniff the doc for <?xml-stylesheet and respect it. Mozilla doesn't get to override a developer's code.
2. Display feed with default style with a warning message across the top of the screen (below the subscribe to this feed box) that says: "This XML feed has an associated stylesheet. Click here to view the feed with style" or something to that effect.
3. Put an option in Tools > Options that is something like "Use associated style with XML feeds" and default it to ON. If it's not ON, forget it.
4. Possible the best option - obey the stylesheet, but insert a "div" at the top of the page above it with the same "subscribe to this feed" dialog that exists in the 2.0 style.
Tip: If you have RSS that you would like styled, there is NO CURRENT WAY of overriding Firefox's display, even on the client side. There is no such option in Firefox. The only thing you can do, which is absolutely a HACK - is to pad your feed with over 512 bytes of nonsense, as I've done here: http://firsttube.com/rss.php
View the source to see how to get around Firefox 2's mishandling of RSS.
Adam Scheinberg wrote: > Con: > Firefox simply ignores developers' wishes altogether. What's next - > ignore CSS to apply the CSS the Firefox devs like best?
Don't construct strawmen, it just weakens your argument :)
We already ignore developers' wishes in lots of cases we think we know better. Popup blocking is one common example; defeating tricks that cause security issues (spoofing chrome, stealing user data, etc.) is another.
The question is what developers want, and why. Why style the RSS feed? RSS is not just "any old XML"; it has a particular meaning, and that meaning is not necessarily "to be viewed, as a page, in a web browser". A pair of rhetorical questions: If the goal is to maintain control over presentation, why use RSS at all? Why not present that styled data as HTML? It's at least worth debating whether developers should reasonably expect to have their cake and eat it too with RSS. The position that RSS is not directly-user-facing content and the UA can do what it wants with it (so as to make the user experience consistent) seems plausible to me.
> Proposed solutions: > 1. Sniff the doc for <?xml-stylesheet and respect it. Mozilla doesn't > get to override a developer's code.
This obviously breaks users' ability to easily subscribe with the feed reader of their choice, unless the feed display contains some option to do so; since the content author can't be expected to know what feed readers should be listed or which one the default should be, this seems like a non-starter to me.
> 2. Display feed with default style with a warning message across the > top of the screen (below the subscribe to this feed box) that says: > "This XML feed has an associated stylesheet. Click here to view the > feed with style" or something to that effect.
Too geeky for normal folks, who have no idea what XML, feeds, styles, or stylesheets are.
> 3. Put an option in Tools > Options that is something like "Use > associated style with XML feeds" and default it to ON. If it's not ON, > forget it.
Again, too geeky. This isn't the kind of option most people would care about having, the benefit is outweighed by the clutter it adds to the options dialog.
> 4. Possible the best option - obey the stylesheet, but insert a "div" > at the top of the page above it with the same "subscribe to this feed" > dialog that exists in the 2.0 style.
This is indeed the best option of your four. The biggest concern I would have with this is with pages easily being able to turn off or modify the appearance of this div, or somehow sniff the data in it (to determine what feedreader the user has defaulted to, for example). If those sorts of things can be prevented, this may be worth trying.
> Too geeky for normal folks, who have no idea what XML, feeds, styles, or > stylesheets are.
Yes, I think it is important to remember that people who don't care about the stylesheets or like what Firefox2/Safari2/IE7 do will be underrepresented in these debates.
The most common criticism we get is that our feed preview doesn't display the same quantity of knobs and dials that Safari and IE7 do. Ignoring stylesheets makes it possible to present a more feature rich subscription interface--something a lot of users want. All of the ideas regarding stylesheets have a large cost, in implementation complexity, usability, and security (much bigger attack surface).
To some degree, I expect this is a bit of tension that will disappear in time, as web authors change their page flow to present an HTML page that serves the same purpose the XSL sheets currently do. This will happen because of IE7's default behavior.
It might be better to write some extensions and see what clicks with users instead of turning this into a debate centered on ill-defined and controversial terms.
> The only thing you can do, which is absolutely > a HACK - is to pad your feed with over 512 bytes of nonsense, as I've > done here: http://firsttube.com/rss.php
Ironically this feed looks worse than what any of the feed handling browsers would have to offer: * HTML is not correctly rendered but presented as tags (in Firefox at least, IE7 works correct) * several lines look like a link but aren't clickable/functional * contrast is pretty low for the article text * there's no additional functionality added over displaying the unstyled XML * it doesn't even fit in with the rest of the site as for the styling.
To sum up: kinda confusing and less functional. Why don't you want users of Firefox 2, IE7 or later Safari versions to subscribe to your feed?
On 11/2/06, Simon Bünzli <zen...@gmail.com> wrote:
> Adam Scheinberg schrieb am 02.11.06 19:20: > > The only thing you can do, which is absolutely > > a HACK - is to pad your feed with over 512 bytes of nonsense, as I've > > done here: http://firsttube.com/rss.php
> Ironically this feed looks worse than what any of the feed handling > browsers would have to offer:
His point, which you have not addressed, is that he (as the web designer) wants the page to look like that. There is no additional security risk involved in respecting his wishes (beyond the risk presented by any other XML document retrieved over HTTP, transformed with XSLT, and styled with CSS).
The argument you need to make is not whether his page looks ugly, but why you are requiring him to resort to hacks and workarounds to make his page appear as he has wishes just because his XML document starts with the magic string "<rss".
> > The only thing you can do, which is absolutely > > a HACK - is to pad your feed with over 512 bytes of nonsense, as I've > > done here: http://firsttube.com/rss.php > Ironically this feed looks worse than what any of the feed handling > browsers would have to offer: > * HTML is not correctly rendered but presented as tags (in Firefox at > least, IE7 works correct) > * several lines look like a link but aren't clickable/functional > * contrast is pretty low for the article text > * there's no additional functionality added over displaying the unstyled XML > * it doesn't even fit in with the rest of the site as for the styling.
> To sum up: kinda confusing and less functional. Why don't you want users > of Firefox 2, IE7 or later Safari versions to subscribe to your feed?
> My blog is read via another source which syndicates it via... RSS.
Don't you already concede the point with this one? You don't expect people to look at that XSL styling of yours but at your content.
You just happen to be opposed to different styling in the case of 3 particular feed readers (Firefox, IE7, Safari) while not caring about the rest...
Anyway, my point was that in this particular case me as a user would have been better off with the default styling. In case you just wanted to make an academic point, you need not worry though... ;-)
Mark Pilgrim wrote: > His point, which you have not addressed, is that he (as the web > designer) wants the page to look like that. There is no additional > security risk involved in respecting his wishes (beyond the risk > presented by any other XML document retrieved over HTTP, transformed > with XSLT, and styled with CSS).
> The argument you need to make is not whether his page looks ugly, but > why you are requiring him to resort to hacks and workarounds to make > his page appear as he has wishes just because his XML document starts > with the magic string "<rss".
Assuming for the moment that the document really is Atom/RSS and not something which we have wrongly detected as atom/rss: we have a choice:
1) our feed UI is better 2) the designer-provided UI is better 3) we can mix our subscription UI with the designer CSS presentation
I don't think that any of these options is outright wrong. The choice between 1) and 2) would need to be made based on statistics of feeds with <?xml-stylesheet?> PIs. 3) is IMO the best choice, but by far the hardest.
But our goal is to provide the best UI for the user. If that conflicts with "a faithful rendition of what the web designer wanted", then the user wins. The real question is whether our current choice is a win or a loss for our users.
> His point, which you have not addressed, is that he (as the web > designer) wants the page to look like that.
And my point was that me as a user would have preferred Firefox' styling in this case -- so he had better look for a more realistic example, unless he just wanted to start an academic discussion.
On 11/2/06, Simon Bünzli <zen...@gmail.com> wrote:
> Anyway, my point was that in this particular case me as a user would > have been better off with the default styling. In case you just wanted > to make an academic point, you need not worry though... ;-)
(The latter includes the 512-byte-whitespace hack, and it *is* in fact meant to be read by a human in a browser -- I do so every day. It is also happens to be an Atom feed. It is generated by this software: http://www.intertwingly.net/code/venus/ )
Benjamin Smedberg wrote: > But our goal is to provide the best UI for the user. If that conflicts with > "a faithful rendition of what the web designer wanted", then the user wins. > The real question is whether our current choice is a win or a loss for our > users.
I agree, and this says what I was trying to get at better than I did.
One reason we "respect designers' wishes" for web pages in general is that, in most cases, the designer is in a better position to know what's good for the user than the browser is. However, when the browser thinks it can make life better, it does so; this principle is already established and is not new with RSS handling in Fx2. There is no magic principle that says designers are always right and we will obey them even when we think we can do better.
Following from that, the question that I wanted to get at in my original post is what designers wish to accomplish with RSS styling. This was not an academic question: thoughtful designers who want to do this are probably trying to improve their users' experience in some way that it would be nice to allow, while malicious designers might want to modify their users' experience in ways it would be nice to prevent (what's to prevent the maker of some major feed reader from styling RSS on their site in a way that makes it hard to view in any feed reader but theirs? What if that manufacturer then pays other sites to do the same?).
The goal is the best user experience. My concerns about respecting designers' wishes are not born from a hatred of designers but a wish to make sure the user experience is always consistent, usable, intuitive, and in keeping with the users' wishes. Clearly, some of those goals may conflict with each other, which is why it's hard to address this issue properly.
> But our goal is to provide the best UI for the user. If that conflicts with > "a faithful rendition of what the web designer wanted", then the user wins. > The real question is whether our current choice is a win or a loss for our > users.
Another issue is that the presence of an xml-stylesheet PI is not necessarily an indication that the designer really desires an override. Many of them are basically "oh, you shouldn't be looking at this in a browser" messages. We considered providing a way to indicate the difference, but didn't want to extend the xml-stylesheet standard without support from other browser vendors.
Personally, I would much rather we devote engineering effort to a sanitizing CSS sink, much like we did a sanitizing HTML sink for Firefox 2. That way, feed authors can have richer content in their feeds in all Mozilla-based feed products.
> But our goal is to provide the best UI for the user. If that conflicts with > "a faithful rendition of what the web designer wanted", then the user wins. > The real question is whether our current choice is a win or a loss for our > users.
Conceded. But I'd add that on a case by case scenario, you'll find that sometimes the default style is better and sometimes the developer's style is better, and there's no "best solution" for every instance.
In your 3 scenarios, a toggle (even hidden in about:config) is necessary, because why would you want to force the user or the developer to use what was deemed better "most of the time." By not allowing someone to access my stylesheet properly, you have not introduced choice, but rather, restricted it. They are never forced to use my style (thanks to a nice option under View >Page Styles). But an inserted "subscribe div" seems like a nice median.
> > His point, which you have not addressed, is that he (as the web > > designer) wants the page to look like that. There is no additional > > security risk involved in respecting his wishes (beyond the risk > > presented by any other XML document retrieved over HTTP, transformed > > with XSLT, and styled with CSS).
> > The argument you need to make is not whether his page looks ugly, but > > why you are requiring him to resort to hacks and workarounds to make > > his page appear as he has wishes just because his XML document starts > > with the magic string "<rss".
> Assuming for the moment that the document really is Atom/RSS and not > something which we have wrongly detected as atom/rss: we have a choice:
> 1) our feed UI is better > 2) the designer-provided UI is better > 3) we can mix our subscription UI with the designer CSS presentation
> I don't think that any of these options is outright wrong. The choice > between 1) and 2) would need to be made based on statistics of feeds with > <?xml-stylesheet?> PIs. 3) is IMO the best choice, but by far the hardest.
> But our goal is to provide the best UI for the user. If that conflicts with > "a faithful rendition of what the web designer wanted", then the user wins. > The real question is whether our current choice is a win or a loss for our > users.
Mark Pilgrim wrote: > On 11/2/06, Simon Bünzli <zen...@gmail.com> wrote: >> Anyway, my point was that in this particular case me as a user would >> have been better off with the default styling. In case you just wanted >> to make an academic point, you need not worry though... ;-)
Both of which are more difficult for me to use and figure out how to put into my reader of choice than if they were simply styled consistently the way I'd gotten use to seeing everything else. (I say this after trying to read both of them.)
Again, the question is, _why_ is this an improvement for users? What makes this kind of thing compelling for a UA to support? "Because it's how the designer wanted it shown" does not address that question.
Peter Kasting wrote: > The question is what developers want, and why. Why style the RSS feed? > RSS is not just "any old XML"; it has a particular meaning, and that > meaning is not necessarily "to be viewed, as a page, in a web browser".
But surely you'll acknowledge that "not necessarily" isn't equal to "never"?
> A pair of rhetorical questions: If the goal is to maintain control > over presentation, why use RSS at all? Why not present that styled data > as HTML?
Answers: simplicity and lack of duplication. E.g., the USGS and the State of California both publish collections of public alerts using the Common Alerting Protocol, with the currently-active messages indexed as an RSS or Atom file. Those indices may be consumed by feed readers. They're also consumed by various automated alert-distribution systems. And they're also styled so folks can get a useful summary of the current warning activity.
Why should those publishers be forced to rework these simple, elegant services to duplicate the content, in HTML as well as in XML, just to serve the preferences of browser programmers?
>It's at least worth debating whether developers should reasonably expect >to have their cake and eat it too with RSS.
Absolutely. Why shouldn't they? In fact, they were until browser developers started imposing additional constraints on sevices that were a) standards-compliant, and b) already established.
> > 4. Possible the best option - obey the stylesheet, but insert a "div" > > at the top of the page above it with the same "subscribe to this feed" > > dialog that exists in the 2.0 style.
> This is indeed the best option of your four. The biggest concern I > would have with this is with pages easily being able to turn off or > modify the appearance of this div, or somehow sniff the data in it (to > determine what feedreader the user has defaulted to, for example). If > those sorts of things can be prevented, this may be worth trying.
Agreed, except that instead of the full feed-subscription div, which is still large enough to substantially displace the styled content vertically, why not a small gray bar that invites the user to "Subscribe to this feed?" and if clicked opens the subscription div.
On 11/2/06, Peter Kasting <pkast...@google.com> wrote:
> One reason we "respect designers' wishes" for web pages in general is > that, in most cases, the designer is in a better position to know what's > good for the user than the browser is. However, when the browser thinks > it can make life better, it does so; this principle is already > established and is not new with RSS handling in Fx2.
Feedburner's own rendering (via XSLT+CSS) provides more aggregator choices by default than Firefox (via chrome). Why is restricting end user choice better for the end user?
I'm confused by the concept of styling an RSS feed. RSS isn't a visual presentation format; it's intended to provide raw data to be interpreted by the client software. Adding styling information to a feed is totally contrary to the purpose to the format; it should be left up to the client to determine the presentation format.
Eric Shepherd Developer Documentation Lead she...@mozilla.com
> Following from that, the question that I wanted to get at in my > original post is what designers wish to accomplish with RSS > styling. This was not an academic question: thoughtful designers > who want to do this are probably trying to improve their users' > experience in some way that it would be nice to allow, while > malicious designers might want to modify their users' experience in > ways it would be nice to prevent (what's to prevent the maker of > some major feed reader from styling RSS on their site in a way that > makes it hard to view in any feed reader but theirs? What if that > manufacturer then pays other sites to do the same?).
Simon Bünzli wrote: > Adam Scheinberg schrieb am 02.11.06 22:07: > > My blog is read via another source which syndicates it via... RSS.
> Don't you already concede the point with this one? You don't expect > people to look at that XSL styling of yours but at your content.
> You just happen to be opposed to different styling in the case of 3 > particular feed readers (Firefox, IE7, Safari) while not caring about > the rest...
> Anyway, my point was that in this particular case me as a user would > have been better off with the default styling. In case you just wanted > to make an academic point, you need not worry though... ;-)
> Both of which are more difficult for me to use and figure out how to put > into my reader of choice than if they were simply styled consistently > the way I'd gotten use to seeing everything else. (I say this after > trying to read both of them.)
To each his own. That *is* my aggregator, and I read it every day. And when I upgraded to Firefox 2, I had to put in workarounds so that it would display the way I intended.
> Again, the question is, _why_ is this an improvement for users? What > makes this kind of thing compelling for a UA to support?
Your question is poorly phrased. Firefox 1.5 already supported this. Firefox 2 added a bunch of code to do an end-run around that support, which forces web authors to use workarounds to generate the original standards-compliant behavior. And yes, this is a standards discussion. FF 1.5 saw XML+XSLT and displayed it according to standards; FF 2 content-sniffs and decides to get it wrong.
That's a bug in Firefox' stylesheet (just compare it with IE7's) which should be fixed for all users and all feeds -- and not just this particular instance.
Allow me to suggest that people make less of a fuss about this in Safari and IE7 because it, at a minimum, *adds additional functionality* to RSS feeds, such as filtering by category. In Firefox, unfortunately, you're presented with a style that is, often times, uglier, or rather, "plainer" than what a designer might whip up in a simple stylesheet.
This doesn't change our core difference: I don't believe the user should be forced to view a website I code in a way intended to "benefit" him without an option to view it as I - the developer - intended and he - the client - might want. So this relationship is now played by developer's rules. Sounds familiar... it's one of the reasons I switched to Phoenix from IE over 5 years ago. I think that is the problem here - you think that what is an optimum experience for you is the same for others. I'm not accusing, I'm just trying to extrapolate what I'm reading.
The argument that goes "I think I know what he wants to do with an RSS feed, so I'll guide him there" is silly, because it doesn't address the problem, which is that code that has always worked and is fully compliant no longer works as intended, there are people out there unhappy about it, and the general attitude *appears to be* "we know better, and you haven't given us a good enough reason."
This is much like the debate that ensued when Gnome released a version that forced spatial view in the file manager with no option to turn it off (except one hidden deep in GConf). The developers insisted they knew better because they were trying to help the user. Know how this one ends? We now have easily accessible options and it's regularly shipped OFF in distros today.
People love choice. But even more than they love it, they hate when they lose it.
Peter Kasting wrote: > Mark Pilgrim wrote: > > On 11/2/06, Simon Bünzli <zen...@gmail.com> wrote: > >> Anyway, my point was that in this particular case me as a user would > >> have been better off with the default styling. In case you just wanted > >> to make an academic point, you need not worry though... ;-)
> Both of which are more difficult for me to use and figure out how to put > into my reader of choice than if they were simply styled consistently > the way I'd gotten use to seeing everything else. (I say this after > trying to read both of them.)
> Again, the question is, _why_ is this an improvement for users? What > makes this kind of thing compelling for a UA to support? "Because it's > how the designer wanted it shown" does not address that question.
Peter Kasting wrote: >"Because it's how the designer wanted it shown" does not address that question.
I'll confess I'm baffled by that assertion. What then is the purpose of a browser but to allow the user to see what the publisher wants to show? The alternative seems like a return to an AOL model, where the intermediary becomes the actual publisher.
Mark Pilgrim wrote: > Feedburner's own rendering (via XSLT+CSS) provides more aggregator > choices by default than Firefox (via chrome). Why is restricting end > user choice better for the end user?
Feedburner's choices may not reflect the aggregators the user has added via the WHAT-WG registerContentHandler method. The user needs to control which aggregators feeds can be easily routed to. For example, you could add your own Planet site as a handler. This is far more empowering than any site-supplied stylesheet.
Additionally, I think it's important that site authors be able to preserve the status quo behavior, where older browsers show the stylesheets and newer ones don't. This is the behavior I would prefer, as an author.
On 11/2/06, Eric Shepherd <esheph...@mozilla.com> wrote:
> I'm confused by the concept of styling an RSS feed. RSS isn't a > visual presentation format; it's intended to provide raw data to be > interpreted by the client software. Adding styling information to a > feed is totally contrary to the purpose to the format; it should be > left up to the client to determine the presentation format.
You're right, though: RSS and Atom aren't visual presentation formats. They're raw XML data. Raw XML data + XSLT + CSS = visual presentation format. At least, that's the theory. Many individuals and some companies were putting this standards-based approach to good use before IE 7 and Firefox 2 came along and decided they knew better.
No, it isn't. Show me the standard that dictates this behavior. I can't imagine it says "User-agents with back buttons and address bars MUST use the supplied stylesheet. User-agents without back buttons and address bars are not required to do so."
|
