User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060517 BonEcho/2.0a2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a2) Gecko/20060517 BonEcho/2.0a2
I am currently remaking my web site using XML and XSLT (don't worry, I will make HTML versions for accessibility and search indexing). I decided to offer RSS and Atom feeds to my web site and I also wanted to display the feeds by transforming them using an XSLT stylesheet. However, with the recently added Feed View, I was worried that it would override my stylesheet, and unfortunately it does. So instead of seeing my home page with links and all, I see that pretty useless (in that context) feed view. It's very annoying and not inviting. This behaviour doesn't show up on local files (file: protocol) and the XSLT stylesheet is used as expected.
Steps to Reproduce:
1. Browse to http://fragag.ifrance.com/xml/index.xml or directly to the feeds, http://fragag.ifrance.com/xml/rss.xml and http://fragag.ifrance.com/xml/atom.xml.
2. Note that the XSLT stylesheet should be used instead.
Feed view is used instead of the XSLT stylesheet defined in the XML document.
The emerging workaround for this problem (which isn't new to us, since we're using the same heuristic that IE7 betas have been using for months) is to put in a comment ranting about the evils of sniffing web content and overriding the desires of web developers which is long enough to move "<rss" or "<feed" out of the first 512 bytes, since that's all we sniff.
There's no way we can tell the difference between XSLT intended to style a feed into something that's not a feed, like yours, and XSLT intended to just keep people with earlier browsers from having to look at raw XML, so I think this is WONTFIX. With more than 99% of the feeds with stylesheets just trying to do what we're doing, but without the knowledge of what aggregators the user actually uses and without the chrome privileges to subscribe them, not using our transformation on feeds that have a stylesheet would just make for a worse and less consistent experience for our users.
I was aware that some web sites use XSLT or CSS to decently present feeds. I think the workaround is too easy :). I now have 4 files to fill with some uselessness :).
I replaced the original page with the working version: http://fragag.ifrance.com/xml/rss.xml. The old behaviour can be observed at http://fragag.ifrance.com/xml/rss2.xml. Thanks for the workaround. Now you can decide what to do with this issue (I'm happy now, but I'll come back if my site is broken again...).
I would rather there be an option, in the view menu, about what style is being applied to the page.
There is nothing about the first X bytes of xml being so hugely special, and xml is a linear document ... It is a bit presumptuous ...
But I think it is fine, by default, for firefox to nicely style xml that is probably an rss feed. As a practical matter, that is what most authors intended to happen. However, if firefox has chosen to do its styling on that feed, or done so in complete error by having is sniffer screw up in misidentifying a page as a feed (this is a rare but inevitable eventuality), then have the option for the user of applying the page's specified styling in a VIEW menu entry.
For example View menu--> Use Style --> None || default || page author's specified style 1 || page author's specified style 2 (...) || maybe some other user specified styles (...)
One might even rename "default" to "feed view" since that's what people here seem to be calling this view :) .
Or am I wrong that what firefox is doing to the feed is considered Styling?
Also, note that choosing: use Style --> None , I think, ought to show the feed's xml without styling. Instead it shows what looks like an alternate style page for the "feed view", with an (empty) error message (was this put there for debugging purposes?). Please note that view source (correctly, in my mind) shows the url's source, not the Feed View's source.
for another reference page (that has a style of its own) --> http://www.atomenabled.org/atom.xml
If the only way to subscribe to a feed is the brittle sniffing of content, then
we have bigger problems.
Relying on hacks like 512 bytes to be implemented in a cross-browser fashion is
evil, too. I doubt we're using "the same heuristics as IE7 betas", I would expect
that to be full of license and IP problems ;-).
In general, if a site wants to use our styling instead of theirs, they can add
content negotiation stuff. If the document has styling information, that's a human
decision, and that should overrule any software heuristics at all times.
(In reply to comment #4)
> I doubt we're using "the same heuristics as IE7 betas"
Welcome to the new browser world. See section II of http://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx
> If the document has styling information, that's a human
> decision, and that should overrule any software heuristics at all times.
Please share with us the results of your spidering the web and then investigating the actual content of client-side styled RSS and Atom feeds. Personally, I know of quite literally tens of millions of feeds which are styled for one and only one reason: to keep browsers from showing either raw XML or a helper app dialog to puzzled users (human decision? yeah, for the millions of Blogger feeds I think the human was Jason Shellen). I would guess that feeds which are intentionally styled in a way that the publisher would rather have shown despite it providing a puzzling experience for users who expect their browser's own view are in the low thousands at the most, but I'd be happy to see your results.
Also, could you explain in more detail how it's a good thing to have our users puzzled by inconsistent behavior when they click on a feed, in order to enable publishing content which cannot be seen by users of pretty much any other browser? The feed in the reporter's URL gets browser-styled not just by us, but by IE7 and Safari, and prompts for subscription and then gets no display in Opera.
Maybe there could be a processing instruction (PI) to tell the browser to use the stylesheet rather than the "feed view", or a non-official pseudo-attribute for the existing <?xml-stylesheet?> PI, which could be named "force" or something like that. There is, for the people that wouldn't know, the specification for <?xml-stylesheet?>: http://www.w3.org/TR/xml-stylesheet/. This would prevent the use of "content sniffing"; I actually believe that the file should be parsed instead, and the method I propose wouldn't be difficult to implement.
do you mean that the content sniffer would now look for one sort of declaration within the first 500 (or whatever) bytes, and if it sees it, to look for second declaration within the first 500 bytes, and if it sees it, do something else? GEB.
how is this going to help authors of content erroneously sniffed as a syndication feed? (eg, who had no clue their content would be "positively" sniffed? ). This is the rare case ... They wouldn't have added this declaration.
I don't think content producers need to do anything more here than they do already.
Everything is fine with regards to content now. No need to tell people to change their content, or add a bunch of things they shouldn't need or necessarily want to add.
The content sniffing is good. This discovers nearly all syndications.
Most syndication authors intend them to be viewed in syndication readers, even including those authors that include stylesheets and other xml.
Content authors that don't want their feeds read by the syndicating agent can serve their content as xml and use the 500 byte rule.
What I'd just like to have is, if mozilla is using the feedviewer view, some user selectable method in the browser to see the content
a) styled as feedview (the default)
b) without style (not possible right now, as this now results in showing feed view, without style + some style added after, for whatever reason :p ), instead of the raw xml at the uri shown in the uri field.
c) with the style specified in the xml page (if any, as if the feedviewer never existed).
d) perhaps other options.
It is best to accept that by default feedview is going to show things that mozilla thinks are feeds, or, are in fact feeds. This is proper, in my mind, from a user's perspective, and for 99.99% of content producers.
I think what ought to be discussed is the best way of implementing user interfaces to allow user to disable feed view, and show methods a, b, c and d metioned above.
One method I think is the view menu options.
A second method might be an option somewhere on the feedview itself. Like the lower right or left corner.
I think this bug merits a discussion in mozilla.dev.apps.firefox, if there's not one there already. I'll make sure to get the ball rolling on that discussion if it has not already been done.
I have read all of the discussion in the newsgroup and here in this bug.
My decision is as follows:
We will continue to override site supplied XSLT stylesheets, because:
- The design goal of the preview feature is to provide a brief, consistent "preview" of feed content prior to subscription.
- We want to make this experience as useful and efficient as possible
- I (and others) believe allowing site supplied stylesheets to be used here will detract from this because of the variance, inconsistent messages to the users, etc.
- Alternative apis for forcing a site supplied stylesheet are only useful if other browsers choose to implement them, and it is unlikely that Apple would ever do this with Safari, for starters.
- We continue to find and fix bugs with our detection (sniffing) logic.
All of this said, there is nothing stopping an extension from implementing this.
You know, this made me realize that using RSS or Atom feeds as a front page wasn't that much a good idea. I decided to put the news of my website on another XML document and to let the feeds behave as they are designed to do, because otherwise it breaks the functionality. For those who'd like to see the feeds, here they are:
* http://fragag.ifrance.com/xml/rss.xml > This is the real feed I am serving.
* http://fragag.ifrance.com/xml/rss2.xml > This is what I wanted the feed to display. This one is much heavier than the previous one, because the RSS content and the website content are separate. It pushed the <rss> start tag beyond the first 512 bytes.
(In reply to comment #9)
> I have read all of the discussion in the newsgroup and here in this bug.
> My decision is as follows:
Mind making a closing comment on the thread on the newsgroup, too?
> All of this said, there is nothing stopping an extension from implementing
A rough outline would be helpful. Not that the argument really counts to me,
as this is a per-site issue, not a per-user.
*** Bug 344584 has been marked as a duplicate of this bug. ***
If Firefox can "sniff" an XML documents to determine whether it's a feed (looking for "<rss" or "<feed"), why can't it just "sniff" for "<?xml-stylesheet" too?
I fail to see how it's a good idea for an application that claims to empower its users to override, without warning, another developer's code, and furthermore, refuse to provide a better workaround than "pad your code with 512 bytes of nonsense."
Please reconsider "WONTFIX."
As has been written above, even authors that include stylesheets usually expect their feeds to be read by feed readers. The stylesheet is often an alternative for browsers that don't understand what a feed is, and would otherwise display raw xml. One can't divine always what an author wants, and there is nothing in practice that says a stylesheet is so important that it over-rides other considerations of how info is displayed. If an author puts a lot of information in style, they must accept the consequence that it is not likely to be uniformly interpreted across clients.
Those are very good reasons to close the issue on whether the feedview style should be the default view, regardless of what style information an author includes.
Just to repeat myself three times, it wouldn't be bad to have a switch in the feedview interface, or the rest of the interface, to interpret the feed as xml, using whatever stylesheets the author (or the user) wants. It was suggested that an extension could help to do this. Maybe I think it is a bit more important than that (but I'm biased due to the poor way mozilla has been handling atom feeds (which is presently being fixed)).
*** Bug 356126 has been marked as a duplicate of this bug. ***
I use infoRSS for a quick glance at my website statistics via
Firefox (after clicking on the infoRSS status bar line to show
the RSS in Firefox), and now with Firefox RC2 my CSS specified
layout is completely messed up because Firefox RC2 does not
apply CSS to online XML files (whereas is does apply CSS to
local XML files!?). It is my biggest disappointment with
Firefox RC2 so far, because all of this worked flawlessly when
using infoRSS and the Feedview extension on Firefox 1.5, and I
cannot see the logic of not applying CSS that is specified and
even having different behaviour for online versus local files
(it works as intended on local files). I believe this is ugly,
inconsistent and ought to be fixed.
OK, the 512 byte workaround indeed works, and I have now adapted my
RSS feed generator to automatically add a 512+ byte comment ranting
about this problem with Firefox RC2. I still hope it will be fixed
*** Bug 358273 has been marked as a duplicate of this bug. ***
*** Bug 358291 has been marked as a duplicate of this bug. ***
As commented elsewhere, this seems like a software-induced violation of net neutrality. The arguments for it seem to be a) Firefox knows best re user experience, and b) only a few people care, so what's the big deal? I'd say that sounds more like Microsoft than Mozilla speaking... but even IE gives it's users a choice on how styled feeds get displayed, so maybe that's unfair.
This is an evil design choice that badly needs to be reconsidered.
I disagree with the wontfix resolution. This behavior totally breaks feedburner.com which practically every major blog uses to serve up its rss feed.
The nice thing about feedburner is that they have a much larger choice of web-based readers to choose from. Firefox only lets you pick between bloglines, yahoo and google. What if you use Rojo or Pluck? Yes I know that you can edit this in about:config, but can we really expect average users to do this?
This is a bug for me and it needs to be fixed - it is impossible that a browser take the control about how a side is displayed over the site owners display wishes. All my feeds now are looking very ugly with this default styling, Firefox applies to them.
A nice compromise would be to have a way for the user to turn off the firefox styling by clicking a "show raw rss feed" button, or by clicking an X at the top of the yellow field. You know, its also possible to show the yellow firefox subscribe area AND then put the rest of the users stylesheet below this. Best of both worlds.
Offering an opt-out from the browser-imposed behavior seems like the very least that should be done. But even that would put an additional burden on the non-technical user. Might it make more sense to respect a stylesheet if one is present, and give the user an opt-in client-side styling (e.g., "would you like me to format this for easy reading?") where no style is provided.
In any event, arbitrarily munging site content in the browser is just wrong. This bug really should be reopened and fixed.
An optional opt-out buried in preferences, or - God help us - about:config, is insufficient. The only acceptable solutions are as follows:
1. Sniff the doc for <?xml-stylesheet and respect it. Mozilla doesn't get to override my code as a developer.
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.
Anything less than one of the above is bad browser behavior. This decision has quite literally destroyed the practical use of the RSS/XML standard in Firefox, by deprecating a fairly common routine - the whole concept of styling XML is ruined if it's not respected.
To add one more bit: the above replies hint that the VAST majority of RSS is intended to be read by a feed reader and this is therefore unnecessary and unimportant. My reply is: then why is it an issue? Why not allow the stylesheets to work as intended? If most feeds aren't read by humans, why would you override developers who INTEND for their feeds to be read by humans? And what of pheedo and feedburner, who not only style their feeds, but include additional content??
There are plenty of legitimate reasons to reopen this bug, so I am doing so.
I think it's more important for feeds to be consistent with other feeds and offer useful subscription options than it is for feeds to be consistent with the rest of the site. After all, if you wanted the look of the site you'd just go to the front page of the site. Given that, and the huge number of feeds with XSLT feeds provided by someone other than the author of the blog, I vote for wontfix.
#4 in comment 26 is clever, though. I wonder how hard it would be to show Firefox's subscription options above an XSLT-styled feed, while making scrolling work correctly. Perhaps it could be done by showing a special "information bar" with condensed subscription options above XSLT-styled feeds.
(In reply to comment #28)
> I wonder how hard it would be to show Firefox's subscription options above
> an XSLT-styled feed, while making scrolling work correctly. Perhaps it could
> be done by showing a special "information bar" with condensed subscription
> options above XSLT-styled feeds.
Off the top of my head, this could be potentially be accomplished via a frame, or a floating div, or a non-scrolling absolutely positioned div that just stays at the top. It could be acheived via a popup window, although that seems undesirable. The point is - there are certainly options.
(In reply to comment #28)
First off, thank you Jake for reopening this item.
> I think it's more important for feeds to be consistent with other feeds and
> offer useful subscription options than it is for feeds to be consistent with
> the rest of the site. After all, if you wanted the look of the site you'd just
> go to the front page of the site.
Respectfully, I have to ask "important to whom?" Are we prioritizing the web publishers' needs, or some imaginary standard user's, or our own? And what if the front page of the site, or at least part of it, IS a styled feed? Is it really appropriate, or necessary, to dictate that RSS and Atom can never again be used in creative and (to us) unforeseen ways?
Seems like there may be an underlying assumption here that all feeds are functionally equivalent. That's not always the case, however, particularly in the case of Atom feeds. RSS is still fairly narrowly designed for indexing HTML pages, but Atom takes a much broader view of things, allowing indexing of all sorts of content. For example, http://capnorth.oes.ca.gov, operated by the California Office of Emergency Services, uses its Atom feed to publish a current collection of XML documents in the standard Common Alerting Protocol. This feed is used both by human readers (via XSL styling) and by automated processes other than ordinary feed readers. Maybe we need a broader view of this technology than that it's only and always for what we currently think of as "feeds."
It seems like a simple way to accomodate everybody would be to sniff for stylesheets on feeds and honor them where they exist, inserting only a narrow bar at the top with a link saying "Would you like to subscribe to this feed?" If clicked, that bar could expand to the current feed-subscription bar. If not, the damage done to the site designer's work would be minimized. And if there's no styling, the current implementation remains unchanged.
How hard would that be to do?
I find myself in the situation of being the user of a web application that *used* to provide a set of XML data to me in a lovely color-coded table. Now, I get a stupid list that doesn't tell me half of what I used to get.
Further, I am trying to look at pages maintained by internal corporate folks who don't actually care a whit that Firefox is broken, and who will just happily tell me to use the corporate standard (IE) rather than put in even the most trivial Firefox-specific hacks. So, any "solution" that requires the web site maintainer to do something won't help me a bit.
It might be different if their site was broken (not conforming to standards, or whatever). But this is different -- It is Firefox that is broken (not conforming to standards). What makes it worse is that Firefox is ARROGANTLY broken.
For now, I'm willing to fire up IE just to view that one site's data. That's going to get old real fast, though.
> It is Firefox that is broken (not conforming to standards).
There is no conformance issue here.
Please move the debate to the newsgroup (where the decision was made, in the open).
I love Firefox and will have to abandon using 2.0 after having it installed less than 48 hours because this bug makes it impossible to do my job without IE, and I loathe IE. I want to see raw XML and am very disappointed there is not an option to turn off browser-imposed styling.
This bug is seeing some pretty active discussion right now here:
(In reply to comment #33)
> I love Firefox and will have to abandon using 2.0 after having it installed
> less than 48 hours because this bug makes it impossible to do my job without
> IE, and I loathe IE. I want to see raw XML and am very disappointed there is
> not an option to turn off browser-imposed styling.
Hi Michelle, you can view-source, just like any web page. Hope that helps.
So I've read the thread in the newsgroup, and while I can see the arguments both ways, one thing that's missing is the ability for the user to turn this off. Sure, I can understand why MoCo wants to ship Firefox with this enabled, but not letting the user turn this off is a bit rude.
From the content-producer point of view, IMHO it would have been better to apply the stylesheet to unstyled feeds only in Firefox 2, with the clear intent to
a) turn it on for every feed in Firefox 3
b) have a clear, non-sniffing, way of turning it off if so desired
c) as above, have a hidden pref to turn it off for all styled feeds
(In reply to comment #36)
> So I've read the thread in the newsgroup,
Please comment in the newsgroup, not here. Thanks.
*** Bug 359791 has been marked as a duplicate of this bug. ***
I do not real see what is this discuss about. There is no doubt for me that this is a bug. The user is now not able use the functionality he use to have (at least not in anyway I can think of beside using IE or Opera). RSS file just as any other XML should be rendered with XSL if it is available. This is all cool and nice that there is an ability to view it in other ways, but (like ignoring CSS in HTML files) this should only be an additional option.
Besides I spend two days making my RSS feed look like my other forum pages, so I'm quite... well not happy about all that.
Anyway just looking for a sequence like (even in those 512B):
"\?xml-stylesheet .* type="text/xsl"" (reg. exp.)
would be a good start
In the "View->Page style" menu there should be an option to use "XSL styles" or "Ignore XSL", but also current options for CSS might fit quite well here. But I understand that you want to make the default different (to ignore XSL).
More or less like in comment #36 I think there should also be an option in the main settings to always use XSL or always ignore XSL on RSS feeds. To be even more similar to use of CSS styling, there should be an option to use user XSL style sheets for RSS feeds, but that could be optional.
And one more thing - please do not blame/move everything to extensions, it's already hard for me to convince people to use FF :(.
Another nice example for a page rendered useless is the video-podcast feed of tagesschau.de, _the_ German news site.
URL is: http://streaming.tagesschau.de/bb/redirect.lsc?rewrite=http://www.tagesschau.de/export/video-podcast-rss/0,,,00.xml&content=content=&media=mp3
Seamonkey 1.x e.g. renders it correctly, with links to the podcasts to download them. Firefox completely screws up the page, so that you can't even download the podcasts anymore.
This is exactly what should be considered a bug and does indeed need to be fixed.
RSS is nothing more than a widepread XML vocabulary for adding metadata to resources. Read: it is an XML vocabulary (yes, there are more than one RSS-vocabulary, but anyways). With the continuing wide spread of XML there is NO guarantee that other XML vocabularies wont use root elements that are identitical to those of RSS (no matter the RSS format) and add xml-stylesheet declarations to those.
If my site provides data encoded using e.g. <feed> or <rss> (YES, it is possible for RSS to be an abbreviation for more things than Rich Site Summary, Really Simple Syndication, etc. and feed might even describe the act or event of FEEDing something in an ontology or whatnot) as the root element, there is NO REASON WHATSOEVER as to why firefox should override a given <?xml-stylesheet ?> declaration. It is just the same as if Firefox discarded stylesheet declarations in XHTML or other XML vocabularies.
It is totally wrong of Firefox to override a web developer's stylesheet declaration. Firefox' behavior reminds me of the 1990s when browser vendors thought they knew what was best without thinking too hard or long ... back then they could have suggested silly workarounds like adding 512 bytes of garbage to your XML, but I didn't expect this from Firefox. God forbid the Mozilla Foundation decide that all HTML documents should start with the same kind of garbage so that web crawlers know what to index and what to not index (:p).
Please just sniff for stylesheet declarations and use your built-in stylesheet IF AND ONLY IF no custom stylesheet is declared. How can that be too hard??!
> You know, this made me realize that using RSS or Atom feeds as a front page
> wasn't that much a good idea.
Well, using RSS as the only format for content is hardly the correct use of RSS anyway. RSS is NOT a substituion for HTML ;)
(pardon my shouting)
FYI, the newsgroup thread ("XML in Firefox is a Major Problem") this bug points us to for further discussion seems to be closed or locked.
I have posted to a thread with the title
"ote to fix this, and mention of XSL text modification capabilities"
(sorry for the poor subject. I mistakenly thought I was posting into that thread rather than creating a new one)
Hopefully this is still open to discussion. It is still a problem that (IMO) needs a better answer. Overriding the website designer's choices without offering any way to see them seems to be unnecessary and unreasonably, and not generally in the spirit of mozilla.
Web feeds are intended to be processed and presented by an aggregator (Firefox for that matter). That's by design. If your feed is useless without a stylesheet, that's a bug on your side. If you need control over the layout of your content, don't serve it as a feed.
(In reply to comment #43)
> If you need control over the layout of your content, don't serve it as a feed.
Everyone needs to understand that not everyone is likely to agree here. We are looking for ways to satisfy everyone's needs here, but we want to preserve user choice of aggregator, and keep compatibility with Safari, Opera, and IE7. Methods might include allowing users to subscribe to hAtom-formatted HTML pages, allowing more presentational control in feeds through CSS, and a preview screen that is more obviously an aggregator UI (even though it will likely remain minimal).
Until we have proposals for Fx3, there won't be any new information to add, so please avoid chiming with your opinions/beliefs/etc (on either side). That's just adding to the noise. We don't make feature choices based on who shouts the loudest.
It's definitely bug (regression) and it should be fixed. XML file with custom stylesheet should be viewed correctly.
I created an extension that may help resolve this bug.
Enhanced Feed Preview (for Fx 2.0.0.x)
If you install this extension, feeds with author stylesheets are shown using the stylesheets. You can subscribe those feeds from a notification bar.
Is it so hard to just add a client-side option to turn this behavior off? I can't believe that this is still here after more than two years.
Jay, I still believe that that won't solve the real problem: developers who want to send the XSLT to non-advanced users. Why can't there just be a bar at the top that asks if you want to subscribe, and have it show the default style sheet if one isn't defined? Then everyone (ok, I know this is impossible) is happy. Right?
I bet Google Chrome would do it if it were added to their development queue...(Just kidding, hope I didn't offend anyone, FireFox is a way better browsing experience than Chrome)
Actually, Chrome takes the "completely hands off" approach. XSL is displayed, and non-styled feeds are left alone and displayed as XML.
Yes, I agree that "display the XSL if its there and default if it's not" is the best option, but at the *very least* a UI option should be available, just like IE.
The Firefox feed preview is crippled at best and useless for anything except subscribing at worst.
Actually, Chrome takes the "this is version 0.2, and we haven't even decided what we're doing with feeds, much less implemented it yet" approach.
Once the browser identifies the document as RSS shouldn't it then honour the stylesheet? The Feed View is a great feature to have. I agree that it should be displayed but I don't understand why my whole stylesheet has to be overridden just to show someone an interface for feed subscriptions.
At the moment we have this:
- load the feed
- throw away the author's stylesheet
- apply a different and arbitrary stylesheet
- display an interface for subscribing to a feed
I like this idea much better:
- load the feed
- apply whatever stylesheets are available
- display an interface for subscribing to a feed
For some reason Opera is supposed to do this semi-correctly. I say semi because once you subscribe to a feed you can't easily look at it directly any more in Opera. And I say semi because the "subscribe to feeds" thing in Opera is untasteful, it offers a dialog similar to javascrpt confirm()
At any rate, the content sniffing, while apparently good, is not something I personally appreciate. I saved my file with the .html extension to invoke the html parser for some tests, and the browser incorrectly rendered the file as xml and rss. But it wasn't xml and rss - it was nasty, invalid html. Bad bad bad!
For fear of being ranty and just a "mee too", I would like to be able to serve my RSS as HTML or plain text if I so desire. I can do it with XHTML, text and images, so I look forward to the day when we can step away from content sniffing for RSS and do that properly too.
I've digressed, the main idea was that showing the feed view and displaying the author stylesheet should not be mutually exclusive. The author stylsheet should be part of content and the feed view thing should be part of chrome.
To draw on an example of a simple interface enhancement that necessitate mean throwing away the page style, take the bookmarks dialogs.
Adding a bookmark makes a little rectangle appear on my screen asking for details about the page - but the browser doesn't disable the page's stylesheet just show that little box, and why should it?
Is an RSS feed somehow fundamentally different in nature from an XHTML web page displaying the same content?
Not all RSS feeds are the same. My feed delivers the actual content from my website to the user. The content itself comes in date-order segments smaller than most feed item descriptions, so this is a perfectly legitimate use of RSS - directly syndicating my site's content.
Displaying options for feed syndication is a behaviour thing in my opinion, and a good one.
The feed preview itself though is not a question of behaviour. It is content. Seriously, XML is a language designed to ship data, nothing more or less. RSS feeds are documents, with content.
According to the w3 there is a method for styling them, however Firefox does not support this.
I think it might be possible to show "Hey, this is a feed!" While still honouring the author's stylesheet, because the style is separate from the presentation.
People saying that the feed should NOT be styled by Firefox, I disagree with. It should provide a _default_ style which is overridden by the author of the particular document's stylesheet.
I downloaded special software to view feeds once, and it was called Firefox.
This is not negative criticism though, I do all my surfing in Firefox, big thanks to everyone working on it!
OH! I meant to say also though, if we can establish that the feed preview is a presentational question which has been partially answered by the w3 consortium with the provision of cascading and XSL stylesheets, then there needs to be a visual refresh for the Feed Preview's Chrome.
What I SHOULD be doing if I am passionate about this is providing some mockups, and really trying to sell the idea instead of arguing about it.
Hinting at the next commenter on the "pro styling our content side", who is no doubt a better artist than what I am....
Some pretty pictures would surely add some weight to our argument.
I have to chime in as I just learned of this unfortunate lack of *proper* support for a w3c standard. I've used XSL in the past but it's been a while... until now. I have renewed interest in styling RSS because I am using RSS differently than I typically have in the past. And using my own stylesheet is important to what I am wanting to achieve. Fine, I have it working with the 500bit rule but c'mon.... this is Mozilla! I'd think that this work-around would be laughable in your camp. For some reason, it is supported and this discussion is a few years old now. WTF?
Chris (the last commenter) is on the right track.
But it's almost August 2009 so let's look at how FF handles alerts/prompts for things like remember password and popup window confirmations etc etc...
The obvious design decision here is to simply provide the same alert when a user lands on an RSS/ATOM url.
- load the feed
- if author supplied stylesheet, use it and prompt first-time user of they want to enable browser supplied stylsheet (all pages/feeds like this, just this page/feed) and "remember preference".
- display an interface for subscribing to a feed using browser supplied stylesheet (no author supplied stylesheet specified in document)
This would be consistent with how common prompts to users are handled already.
Their is NO reason to be over-riding a web document's content based on the fact that it is a certain flavor of XML when you can intelligently provide user with options like most other things in firefox.
Please consider this. If not, i'd like a better and fresh response from Mozilla.
There is another way to avoid the automatic detection of a "feed" a lot less expensive than the 512 bytes of comments. Simply add a prefix to the namespace and place it in the root element. This will break the chain "<feed" that seeks the browser. Anyway you have to establish a generic MIME type "text / xml" or "application / xml". It works in IE7, IE8, FF, Chrome and Safari, only fails with Opera.
That said, I add my vote to respect the "PI". Today the advancement of XML vocabularies means that there are feeds with extensions that provide the basis for the listings of the most dissimilar resources. Why duplicate content when the same list can also get a browser to display a page with context? As for the option to show the feed with the built-in aggregator, it should not display any banners or pop-up window on the page. You must keep the current behavior: show the well-known icon in the address bar that indicates the presence of a feed.
Here I leave another example of a site built on XML vocabularies used to inject content on different XHTML pages. Due to the automatic feeds detection, they must be served in another (proprietary) format. Site: www.aranedabienesraices.com.ar
1+ and CSS too like here http://www.emacswiki.org/emacs/?action=rss;rcidonly=GnusSMIME
I don't think we're going to be fixing this one - the RSS feeder has been mostly demoted in the Firefox UI, and we're unlikely to extend or expand on it beyond what it already is.
> I don't think we're going to be fixing this one
With due respect, this was a bug in 2006. I doubt there's anyone who expected Mozilla to come around.
If you're one of the people who cared about this issue, it's probably been 6 years since you used Firefox anyway.
Good to know that "broken" is the Mozilla gold standard.
Never say never. I finally manged to kick and beat enough people to have bug 455165 fixed, a little more than 4 years after I reported it...(In reply to Adam Scheinberg from comment #57)
> > I don't think we're going to be fixing this one
> With due respect, this was a bug in 2006. I doubt there's anyone who
> expected Mozilla to come around.
Never say never. I finally manged to kick and beat enough people to have bug 455165 fixed, a little more than 4 years after I reported it...
Is there any 3rd party plug-in that replaces the built-in feed reader with a more maintained and less broken one? Far from ideal since it would require users to install an extension, but better than nothing.
(In reply to Jay Rossiter from comment #58)
> Good to know that "broken" is the Mozilla gold standard.
There was no consensus that the feed preview is broken in its current state.
(In reply to Dão Gottwald [:dao] from comment #61)
> (In reply to Jay Rossiter from comment #58)
> > Good to know that "broken" is the Mozilla gold standard.
> There was no consensus that the feed preview is broken in its current state.
There's no consensus needed. Firefox has removed the ability for the developer to style his XML in this one use case and provided no official way to override its behavior. XML stylesheets cannot be used; it is, by most people's definition, "broken". Just because it accomplishes another goal doesn't invalidate that.
I think the lifespan of this bug (and the passion its sparked in people who were once passionate about Firefox itself) proves that Mozilla still thinks it knows better than developers. How's that working out?
I highly recommend (re)familiarizing yourself with the Bugzilla rules of Etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) before commenting further.
WRT "no consensus that it's broken", let's just take a small list of things that don't work, off the top of my head:
1. It uses the "summary" feed text instead of the "full" feed text, even when both are present.
2. It won't display "full" text even if "summary" *isn't* present
3. It can't display images
4. It *overrides the website* and ignores XSLT.
Lack of consensus among Mozilla staff doesn't mean it isn't broken, it just means you don't want to fix it. Completely different things.
Personally, I don't care about this issue anymore. My website has been down for a few years and if I were to make a new one, I probably wouldn't use XSLT stylesheets for it.
For those who might be interested, I use the LiveClick extension (https://addons.mozilla.org/fr/firefox/addon/liveclick/) to manage my RSS/Atom feeds in Firefox (I don't use the feed preview to check for updates). As of now, you must use the 1.0.0b1 version with Firefox 19, which can be installed from the addon's development channel.
Although I understand the usefullness of the "add feed" feature presented through the browser xslt I do not agree with it being forced on the user if there is already a stylesheet present. That's hijacking.
A better sollution would be to use the defined xslt, if present, and add an extra header for the "add feed" feature to it. I cannot believe it cannot be done after seven years.
Have you ever used display:whatever? That's hijacking! :-]. In other words browsers have many default things. Web application change it - that's what web applications do.
One of the challenges and main purposes (IMHO) of a working web browser is to display the received information as close as the creator intended it to be displayed. By adding or removing information or functionality you break that purpose. Besides that, it's not transparent for the end-user that the visual and functional changes where created by the browser and not by the creator of the page. From a creator's point of view one could even argue it's a form of censorship or manipulation if one would take it that far.
I'm not paranoid about Mozilla or an standards evangelist, but I do hope someone will rethink about the current solution from other point's of view.
(In reply to Phil Ringnalda (:philor) from comment #1)
> The emerging workaround for this problem (which isn't new to us, since we're
> using the same heuristic that IE7 betas have been using for months) is to
> put in a comment ranting about the evils of sniffing web content and
> overriding the desires of web developers which is long enough to move "<rss"
> or "<feed" out of the first 512 bytes, since that's all we sniff.
can you confirm that the funny workaround from ~9 years ago is supposed to still work in v36.0.4?
If not so,
- why isn't that change mentioned/referred to here in the ticket (or did I skip that?),
- what do you recommend to get w3c compliant xslt behaviour on xml that happens to have the atom default namespace?
Example where I can't get it wo work: http://purl.mro.name/mozilla/bug338621
Not sure about atom, but seems to work fine fo me:
Maybe you need XSLT above the comment.
(In reply to Maciej Jaros from comment #70)
> Not sure about atom, but seems to work fine fo me:
nice to see.
> Maybe you need XSLT above the comment.
no, tried either way.
BTW, that's the source: https://hg.mozilla.org/mozilla-central/file/cf8864126c58/browser/components/feeds/nsFeedSniffer.cpp#l309 or https://github.com/mozilla/gecko-dev/blob/b245be34395f3caf6048b1d277a5e948213a6256/browser/components/feeds/nsFeedSniffer.cpp#L309
it is the literal '<feed>' *INSIDE* the xml comment that was picked up by the sniffer and mad it think it's an atom feed. OMG.