Firefox 2.0 breaks client-side XSL for RSS and Atom feeds
This seems like a small thing, but it bothers me: For RSS and Atom feeds, Firefox ignores client-side XSL transformations in favor of its own new enhanced rendering. The only way to work around this issue is to stuff 512 bytes or more of XML comment text before the initial feed tag. It's been marked as a bug for some months now - but after reading the discussion therein, I don't have much hope of this being fixed. The gist of the discussion appears to boil down to this: "Firefox knows best, consistency is good, and anyone using client-side XSL on feeds is really after what we're doing anyway. Thus, WONTFIX."
This strikes me as a bit condescending, presumptuous, and quite broken. I don't care if it's what IE 7 does - they're broken too. This breaks FeedBurner's XSL presentation, which I like though admittedly don't use for my own stuff. This breaks the feed-styling XSL I've done at jobs past, which rolled in customer-demanded metrics tracking and branding. And I don't care whether or not the Firefox team considers these or other use cases valid - that's up to me to decide.
This "feature" makes a special case breaking client-side XSL for XML documents that happen to have an "<rss" or "<atom" in the first 512 bytes. That sucks. I'd rather the browser left it up to me as a site author whether to follow Firefox's idea of consistency, or whether to happily shoot myself in the foot with my own decisions.
Archived Comments
They should make this a tunable and provide "over riding" the portable behavior with their own value-minded agenda. That is, if there is a demand for it.
This should definitely be something configurable, even if it's one of those deep-dive configuration options. Taking functionality away just because the development team "knows better" is hubris best left for the likes of Microsoft. That, and I use Firefox's XML reader to validate XML for RSS feeds. If that functionality is going away in later builds, that gives me less reason to update.
Len:
And what would the default be?
Why is it a problem when browsers with aggregator functionality disregard XSLT stylesheets, but when dedicated aggregators do it’s not?
My take: if you want to control the presentation, check the
Accpept(and possiblyReferer) header and transform on the server.Why shouldn't it? Because in the former case, it's being viewed in a browser and in the latter, an aggregator. I'm not just being facetious here; the browser functionality shouldn't play second fiddle to the aggregator functionality unless told to do so.
yeah, that's totally ridiculous and really lame that they did that.
This bothers me too. I think Safari has the same problem.
They need to give publishers a way to override this behavior. Maybe an XML processing instruction...
Kevin
Aristotle: Because aggregators tend to me much more purpose-focused and support more of the vocabulary in feeds. The Firefox default view sucks, and its preemption makes it hard for me to fix that for the elements I know I'm using. As for checking headers and transforming on the server... that defeats caching as we have it set up, which I don't feel like reworking because Firefox has decided it knows what's better for me.
It is clearly wrong for brwosers to decide what is best for every website. A processing instruction is probably already in place but is simply being ignored by the browsers in question. The behaviour of the browsers should IMHO be to (1) either handle processing-instructions if they exist, (2) check the content-type (mime) of the document and unless application/rss+xml handle it as xml. I think that's the only approach that matches the specifications and the real world.
That’s fine in theory.
In practice, aggregators tend not to care about the MIME type of feeds, so most feeds today are served as
text/html. (Yes, you read that right. A whole lot of the rest are served astext/plain.) The same is true of images and videos, btw. There is no way to avoid content sniffing.The ideal approach would have been to honour the PI only if the feed is served as
text/xmlorapplication/xml, eg. explicitly as generic XML rather than as a feed. In case of sniffed feeds or feeds served with the proper MIME type, the PI would be ignored (as client apps are free to do; they are under no obligation to honour the PI), but authors would still have a clean and obvious option for getting what they want.Except that RSS 2.0 does not have a MIME type and is therefore served as
text/xmlorapplication/xml.This is what happens when people who have no clue of how the web works come up with things to put on the web: you end up with no good way of implementing their crud.
The only thing I can think of that could have been better than what we have now would be to specify a new PI to explicitly disable the default feed view. (Although I’d want to have maybe add a yellow strip that lets me disable the custom view or something like that; withholding from the reader the ability to be the ultimate arbiter of his own experience is Wrong.)
Yes, this is MOST annoying. I had put off writing a feed waiting until the formats should settle out. I ended up delaying first until Atom 1.0, and then longer yet until I should have some free time...until just a couple of weeks ago. Then, working in Firefox 1.5.0.1 I blissfully labored over an XSLT to go with it. Spent quite a while at that. Only when I have it working pretty much as desired do I bother to check it at work in IE7...and ARGHHH!...all my time and effort wasted.
And oh, by the way, I had also written a howto for Atom 1.0...and XSLT. So I search GOOGLE high and low until I find someone who writes of how to turn the feature off in IE7...and ammend my howto for that instruction. Now I must do so for Firefox 2.0...and Safari...it seems. Alas and alack.
How about Opera? I recall from some years back that Opera was among the first and best of early adopters for XSLT. It looks as if my howto for Atom 1.0 and XSLT is going to be largely composed of workarounds for this mis-feature.
what a pain. fixing this will definitely get my vote. I do some things in XSL stylesheets beyond just showing the straight feed text, so overriding it just blows all that away. Grr.
They should definitely show the user's stylesheet if one is spec'd, and only use their own if there is none defined from the RSS/XML.
fwiw, here's the one feed that's broken by this: http://www.centralpc.org/sermons/sermons.xml
I resisted upgrading to FF 2.0 for quite awhile and just took the plunge. I've very disappointed that Firefox took this route of overriding XLST. I like Gan, I spent quite awhile designing an XLST stylesheet to render Quikonnex.com produced feeds in a user readable format to include providing many quick subscribe links for popular aggregators. At least IE7 allows for their default view to be turned off. Firefox and Safari do not even provide an option.
AND... the options Firefox provides: Live Bookmarks, Google, Yahoo, and Bloglines. Who did they sell out to?
i found that when an absolute URL is used for the tag in FF 2.0.0.12 (maybe elsewhere) the specified XSL stylesheet is ignored. remove the http:// in the tag and the styling comes back. very annoying. removing the tag seems to be the solution.
my last post should say "link tag". hard to understand without that bit of information!