XML in Firefox is a Major Problem
Adam Scheinberg
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=338621
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.
Please feel free to post your opinions.
Peter Kasting
> 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.
PK
Robert Sayre
>
> 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.
- Rob Sayre
Simon Bünzli
> 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?
Cheers,
Simon
Mark Pilgrim
> 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".
--
Cheers,
-Mark
Adam Scheinberg
> Ironically this feed looks worse than what any of the feed handling
> browsers would have to offer:
Hi Simon,
Well, for one, it's clear where the titles are and where the entries
divide. Some have mentioned this as a style weakness with FF2
(http://eugenia.blogsome.com/2006/10/10/on-firefox-20/#comment-1189).
Secondly, the style is more for proof of concept than anything else.
My blog is read via another source which syndicates it via... RSS.
Either way, this is less about what my style looks like and more about
the fact that I no longer am "allowed" to use it.
A
Simon Bünzli
> 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... ;-)
Cheers,
Simon
Benjamin Smedberg
> 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.
--BDS
Simon Bünzli
> 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.
Cheers,
Simon
Mark Pilgrim
> have been better off with the default styling. In case you just wanted
> to make an academic point, you need not worry though... ;-)
Two non-academic examples:
http://feeds.feedburner.com/BurnThisRSS2
http://feeds.diveintomark.org/
(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/ )
--
Cheers,
-Mark
Peter Kasting
> 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.
PK
Robert Sayre
>
> 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.
- Rob Sayre
Adam Scheinberg
> 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.
Adam
Peter Kasting
>> have been better off with the default styling. In case you just wanted
>> to make an academic point, you need not worry though... ;-)
>
>
> http://feeds.feedburner.com/BurnThisRSS2
> http://feeds.diveintomark.org/
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.
PK
a...@incident.com
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.
Mark Pilgrim
> 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?
--
Cheers,
-Mark
Eric Shepherd
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
Adam Scheinberg
To demonstrate an example of a feed that is more confusing with the
default stylesheet:
http://smallaxesolutions.com/rss.php
Where does one entry end and the next begin? It takes more than a
glance to decipher.
Adam
Mark Pilgrim
>
> 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.
--
Cheers,
-Mark
Simon Bünzli
> To demonstrate an example of a feed that is more confusing with the
> default stylesheet:
>
> http://smallaxesolutions.com/rss.php
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.
Cheers,
Simon
Adam Scheinberg
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.
Adam
a...@incident.com
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.
Robert Sayre
> 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.
- Rob
Mark Pilgrim
> 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.
Please view-source on http://feeds.feedburner.com/BurnThisRSS2 and
tell me where you see styling information in the feed.
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.
--
Cheers,
-Mark
Robert Sayre
>
> And yes, this is a standards discussion.
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."
- Rob Sayre
Mark Pilgrim
> Mark Pilgrim wrote:
> >
> > And yes, this is a standards discussion.
>
> No, it isn't. Show me the standard that dictates this behavior. I can't
http://www.w3.org/TR/xml-stylesheet/
"""
The semantics of the pseudo-attributes are exactly as with <LINK
REL="stylesheet"> in HTML 4.0, with the exception of the alternate
pseudo-attribute. If alternate="yes" is specified, then the processing
instruction has the semantics of <LINK REL="alternate stylesheet">
instead of <LINK REL="stylesheet">.
"""
--
Cheers,
-Mark
Adam Scheinberg
> No, it isn't. Show me the standard
Semantics. It's the invisible "standard" set by FF<2 that people have
built upon. Now, the new behavior forces workflows that used to work
to conform to its new rules with no warning, and furthermore, does what
many believe is not the expected behavior.
Franky, I cannot seem to fathom why there is pushback here. Webmasters
create websites and expect them to be displayed as intended, not see
their tags hacked up and selectively rendered, which is exactly what is
happening. If a feed reader can see and read a valid feed, and a small
div can be inserted to assist the non-technical end user in
subscribing, why -- seriously, someone give me one good reason WHY -
would you intentionally override something that exists for the sole
purpose of styling it?? Am I the only one wondering where the
motivation to enforce a not-very-pretty stylesheet that goes against
all previous RSS handling behavior is coming from?
Robert Sayre
> On 11/2/06, Robert Sayre <say...@gmail.com> wrote:
>> Mark Pilgrim wrote:
>> >
>> > And yes, this is a standards discussion.
>>
>> No, it isn't. Show me the standard that dictates this behavior. I can't
>
> http://www.w3.org/TR/xml-stylesheet/
Yes, I'm very familiar with that document. It doesn't make your case,
and it doesn't make this discussion a moral or standards issue.
So far, I'm not seeing good technical rationales for a change in
behavior. I do see some people who think we should make a different set
of trade-offs, tilting away from the browser user.
-Rob
Mike Shaver
> On 11/2/06, Robert Sayre <say...@gmail.com> wrote:
> > >
> > > And yes, this is a standards discussion.
> >
> > No, it isn't. Show me the standard that dictates this behavior. I can't
>
>
> """
> The semantics of the pseudo-attributes are exactly as with <LINK
> REL="stylesheet"> in HTML 4.0, with the exception of the alternate
> pseudo-attribute. If alternate="yes" is specified, then the processing
> instruction has the semantics of <LINK REL="alternate stylesheet">
> instead of <LINK REL="stylesheet">.
> """
So are Vienna and Google Reader also in violation of this
specification? Are people complaining to them about not honouring the
author's wishes in presentation?
Mike
Mike Shaver
> If a feed reader can see and read a valid feed, and a small
> div can be inserted to assist the non-technical end user in
> subscribing
My understanding, quite possibly incomplete, is that doing that in a
secure way was not feasible in the Fx2 schedule (and required things
like a "sandboxed" CSS parser to go along with the HTML one that we
needed to create already). I don't think that there is objection to
what you describe, though it would again not be quite "the
presentation that the author designed". I suspect that a patch or
extension that demonstrated that behaviour would be quite welcome in
this community, and likely in the application itself.
> Am I the only one wondering where the
> motivation to enforce a not-very-pretty stylesheet that goes against
> all previous RSS handling behavior is coming from?
As has been discussed in this very mailing list, I believe -- you
might well find the thread archived on google groups, if you look for
it -- one significant motivation was that very many uses of
XSLT-on-RSS was to create a page that said "this is not *for* you
browsers, go to the main site instead", which is not what we wanted
the user's experience to be. Distinguishing those cases from the
"righteous use of XSLT for dual presentation" ones is a publishable
result, I submit.
Mike
Mark Pilgrim
> > http://www.w3.org/TR/xml-stylesheet/
>
> Yes, I'm very familiar with that document. It doesn't make your case,
Yes, it does, and I'll go further than your hand-wave and actually
argue my position. The xml-stylesheet standard states quite clearly
that xml-stylesheet processing instructions are semantically
equivalent to <link rel="stylesheet"> elements in HTML documents. The
standard doesn't make exceptions for XML documents that start with the
magic string "<rss". Firefox treats <link rel="stylesheet"> elements
in HTML documents in a certain way, but it sniffs XML documents for a
magic string and then decides to ignore xml-stylesheet instructions
altogether.
--
Cheers,
-Mark
Robert Sayre
> On 11/2/06, Robert Sayre <say...@gmail.com> wrote:
>> > http://www.w3.org/TR/xml-stylesheet/
>>
>> Yes, I'm very familiar with that document. It doesn't make your case,
>
> Yes, it does, and I'll go further than your hand-wave and actually
> argue my position. The xml-stylesheet standard states quite clearly
> that xml-stylesheet processing instructions are semantically
> equivalent to <link rel="stylesheet"> elements in HTML documents.
We're not required to display those. Neither is, say, Lynx. We do it
almost all of the time, because that is the right thing for users. Why
can't we keep the discussion user-centered?
- Rob Sayre
Adam Scheinberg
If either of your scenarios were actually the case, Mike, then I
would've expected someone - anyone - to say "Hey, we hear ya, but it
wasn't ready in time," or even "There are technical limitations which
make this behavior undesirable." Instead, we have people making
decisons for the user and using that as a banner behind which they can
make any assertion with little backup. I have yet to hear a single
user say "I wish this RSS feed suggested some feed readers for me." I
suspect this demand is mostly invented, perceived, and hoped, but not
actually often requested. As it should be - we all want RSS to gain
steam, it's a great technology.
BUT... RSS is for tech savvy folks, and will be for some time. We'll
see FF3 long before anyone non-technical is using (hell, even just
understands) RSS. In the meantime, technical folks have figured out
RSS long before FF2 dispensed with style in favor of handholding.
Somehow, Bloglines, Newsgator, Vienna, Google Reader, etc etc etc got
really popular, and they managed to do it without Firefox handing off
the feeds... so think on that for a bit.
Now, we've had a lot of justification of a stance that is proving to be
less and less popular if you follow up on Bugzilla. It appears as
though the aim here is to program to the least common denominator,
which is exactly the point in the cycle when your tech savvy folks tend
to bail on you for something that gives them more granular control.
The unwillingness to provide any workaround at all, even a non-solution
comprimise, such as a boolean in the prefs anywhere, suggests this is
less about "the user" and more about not backing down now. I hate to
even imply that, truly. But then, I AM a user, and the decisions here
certainly don't represent what I want or expect my browser to do.
Adam
Robert Sayre
>
> The unwillingness to provide any workaround at all,
That's not accurate. Just like other browser, our sniffer is very easy
to defeat, if that's what you want to do. You have a variety of
workarounds at your disposal. We will document them here:
http://developer.mozilla.org/en/docs/Custom_Styles_for_RSS
Additionally, we do consider false-positives in our feed sniffer to be bugs.
- Rob Sayre
Peter Kasting
> If either of your scenarios were actually the case, Mike, then I
> would've expected someone - anyone - to say "Hey, we hear ya, but it
> wasn't ready in time," or even "There are technical limitations which
> make this behavior undesirable."
Actually Mike's point is exactly on target, and was suggested by Robert
earlier as well, *plus* was what I was trying to allude to: doing this
right is hard, but it's worth doing. Our current behavior most
certainly isn't perfect.
> BUT... RSS is for tech savvy folks, and will be for some time.
The entire point of providing a consistent user experience is to make
this statement untrue. We should not use the realm of Geekdom as an
excuse to do something unsuitable for "normal folks", but rather try and
create a solution which solves normal people's problems while still
being acceptable to the geeks. I continue to harp on "what do you
actually want to accomplish" not because I'm trying to justify our
current solution but because I'm trying to step back from the "you
should obey my stylesheet!" low-level solution and figure out what the
high-level issue really is.
I don't think people are "not backing down for pride's sake". I think
there are real UE questions to answer here, on both sides, that perhaps
neither side understands well. At least on the side of the developers,
the Fx2 behavior was not viewed to be a major step backwards because, as
mentioned previously, few sites styled feeds, and most of those did it
only to guide users back to the main page, not actually in an attempt to
get users to interact directly in a web browser. I'm a bit suspicious
that the ranting online consists of a very small non-representative
sample, plus a lot of people ready to jump on a bandwagon because
phrases like "defies standards" and "eliminates choice" are used.
However, just as the stylesheet-advocates need to understand the
developers' perspective, the developers need to understand the
legitimate complaints raised against the current behavior. So, in that
vein: does the idea of a sanitized CSS sink sound appealing? Or is the
XML+XSLT "I do it all myself" approach the only acceptable way?
PK
Mike Shaver
> If either of your scenarios were actually the case, Mike, then I
> would've expected someone - anyone - to say "Hey, we hear ya, but it
> wasn't ready in time," or even "There are technical limitations which
> make this behavior undesirable."
People have said that in the past (did you look in google groups as I
suggested?), though perhaps not in the four hours since your original
post. Are you being a little quick to rush to the judgment that all
things to be said have been said, and in this thread?
(And did I not just say basically that? Or do I not count because I
said it? A puzzle, to be sure!)
> I have yet to hear a single
> user say "I wish this RSS feed suggested some feed readers for me." I
> suspect this demand is mostly invented, perceived, and hoped, but not
> actually often requested.
We did hear that demand from a lot of Fx 1.5 users, in fact, and
product reviews routinely call this change out as a valuable
improvement in Fx 2. Along with "just hand it to a feed reader
already" -- which reader would of course be very unlikely to show the
styling, I imagine.
> BUT... RSS is for tech savvy folks, and will be for some time. We'll
> see FF3 long before anyone non-technical is using (hell, even just
> understands) RSS. In the meantime, technical folks have figured out
> RSS long before FF2 dispensed with style in favor of handholding.
You should read that paragraph again, especially how you juxtapose
"RSS is for tech-savvy folks" with the part about no handholding.
(Aside: people _routinely_ use things before understanding them,
ranging from gravity to bank machines and back to aspirin for good
measure.)
> Somehow, Bloglines, Newsgator, Vienna, Google Reader, etc etc etc got
> really popular, and they managed to do it without Firefox handing off
> the feeds... so think on that for a bit.
None of those are "really popular" on the scale of even a minority
browser like Firefox, let alone the breadth of the web as used today.
> Now, we've had a lot of justification of a stance that is proving to be
> less and less popular if you follow up on Bugzilla. It appears as
> though the aim here is to program to the least common denominator,
> which is exactly the point in the cycle when your tech savvy folks tend
> to bail on you for something that gives them more granular control.
Firefox provides a ridiculous amount of granular control, in the form
of a wide-open extension API, to say nothing of the fact that it's
probably 15 lines of php -- tops! -- to create a web service which can
register itself as a reader and spit the content back as
post-processed text/html.
Popularity on bugzilla is a worse predictor of general impact on the
worldwide market for browsers than probably anything short of a
cryptographically secure RNG. Are users who like a given behaviour
going to look for a bug in bugzilla in which to voice their support
for it? That seems like it would consume a lot of time, even if you
were to only like a very small number of things about the product!
(As another aside, "omg you will kill the project/market base/etc."
tends to not reinforce one's argument very effectively in this part of
the world, unless supported by a truly uncommon amount of data and
analysis.)
> The unwillingness to provide any workaround at all, even a non-solution
> comprimise, such as a boolean in the prefs anywhere, suggests this is
> less about "the user" and more about not backing down now. I hate to
> even imply that, truly. But then, I AM a user, and the decisions here
> certainly don't represent what I want or expect my browser to do.
I believe that it would not be rocket science to write an extension
that provided "leave it the hell alone" as a "feed reader" option,
which you could then select for once and for all as Firefox's RSS
handling, returning you to the glory days of Fx1.5.
When I say "the user", please do not mistake it for saying "every user
equally" or, especially, "every user, no matter how rare their
desire". For that latter group especially, we have extensions.
If an author wishes to override this behaviour, there are a number of
easy (and standards-compliant!) ways to do so, of course, which I
believe work equally well with Safari and IE7. That so few seem to
bother indicates to me that it's not a problem that's really in need
of a solution.
Mike
Adam Scheinberg
> vein: does the idea of a sanitized CSS sink sound appealing? Or is the
> XML+XSLT "I do it all myself" approach the only acceptable way?
A sanitized CSS sink sounds appealing, and seems like a great "first
step." In my personal opinion, it's not an end-all solution, because I
still feel that overriding the both developer and the client is
antithetical to the goal of *any* software. But... I'm prepared to
accept that this isn't an all-or-nothing and that there may be a good
comprimise, even if it's just a placeholder until an even better
solution is identified and agreed upon.
Regardless of CSS sandboxes and technical limits, I maintain the ideal
behavior is to insert a (dynamically named?) div at the top of the
intended style of an RSS feed - push the top margin down 200px or so
and insert the subscribe area. But in the meantime, a useful, dare I
say featureful, "pretti-fied" CSS sink is a nice first step.
A
Jake
RSS feeds are not fit for human consumption. If this is true, then why
does Firefox display the content at all? Shouldn't it display only a
simple message to the effect of, "You clicked on a feed. This is
gobbly-gook-computer-code that is indented to be read by Google, Yahoo
or Bloglines." If the web browser is going to make an assumption about
what RSS is used for, then it should go all the way.
The Firefox programmers are saying that web developers who intend for
their feeds to be read by humans are wrong and that this practice must
stop. While this may be technically correct, there are so many feeds
(feedburner, etc) that DO style it for human consumption, that we
cannot simply ignore it and hope that the whole internet will change to
suit Firefox's ideals. Just like there are zillions of invalid HTML
pages that must still be rendered properly, RSS feeds that are
invalidly styled should still be rendered according to the developers
wishes.
The best of both words solution is the #4 option in the first post.
Obey the web developers style, but place a banner across the top with
the current Firefox subscription options.
Robert Sayre
> But in the meantime, a useful, dare I
> say featureful, "pretti-fied" CSS sink is a nice first step.
https://bugzilla.mozilla.org/show_bug.cgi?id=359316
This will allow feed authors to use CSS in their feeds. Right now, the
sad reality is that they often have to resort to font tags and
equivalent. We need to write the sink such that potentially harmful CSS
is removed, but it should allow presentation control that's vastly
superior to today's aggregators. Such content would also work in other
Mozilla-based feed products, like Thunderbird and Flock.
-Rob
Mark Pilgrim
> >
> > The unwillingness to provide any workaround at all,
>
> to defeat, if that's what you want to do. You have a variety of
> workarounds at your disposal.
Thank you for stating your position so succinctly. Those two
sentences tell me everything I need to know about Mozilla's view of
its place in the world.
I'm bowing out of this discussion, since it's clear to me that nothing
short of a fork will resolve this in any way other than what you've
already decided.
--
Cheers,
-Mark
a...@incident.com
> > And yes, this is a standards discussion.
> No, it isn't.
You're right, Rob... this is only a standards discussion to the extent
that Firefox prides itself on conforming to web standards.
This is, more strictly put, a standards _conformance_ issue... Firefox
used to conform consistently with the W3C recommendations, and now it's
departed from them by arbitrarily excluding RSS and Atom files from its
XSL processing.
A more honest approach. if folks really felt RSS and Atom needed to be
treated differently, would have been to take this back into the
standards process. The "like it or lump it" approach we're seeing here
is simply an end run on the standards process.
Robert Sayre
>
> Thank you for stating your position so succinctly. Those two
> sentences tell me everything I need to know about Mozilla's view of
> its place in the world.
>
That's not appropriate. I don't speak for Mozilla, and not everyone
associated with the Mozilla Foundation sees eye-to-eye on this issue. We
are all doing the best we can, and sometimes we have to make a choice,
even if that makes some people unhappy. It doesn't mean we aren't listening.
> I'm bowing out of this discussion, since it's clear to me that nothing
> short of a fork will resolve this in any way other than what you've
> already decided.
>
No small group of people made this decision initially. The Mozilla
project did, and that included contributions from a number of parties.
Frankly, I find the divisive rhetoric a little tiresome.
I do think it was the right decision, given several choices that all
have downsides. I understand that you disagree. We will work to enable
more presentation control for authors, while preserving the user's
ability to route and handle feeds with the tools of their preference.
Part of working on a large project is accepting decisions you don't
agree with. There are certainly bits I would like to change or delete ;)
- Rob Sayre
Robert Sayre
>
> Thank you for stating your position so succinctly. Those two
> sentences tell me everything I need to know about Mozilla's view of
> its place in the world.
>
That's not appropriate. I don't speak for Mozilla, and not everyone
associated with the Mozilla Foundation sees eye-to-eye on this issue. We
are all doing the best we can, and sometimes we have to make a choice,
even if that makes some people unhappy. It doesn't mean we aren't listening.
> I'm bowing out of this discussion, since it's clear to me that nothing
> short of a fork will resolve this in any way other than what you've
> already decided.
>
No small group of people made this decision initially. The Mozilla
Robert Sayre
>
> Thank you for stating your position so succinctly. Those two
> sentences tell me everything I need to know about Mozilla's view of
> its place in the world.
>
That's not appropriate. I don't speak for Mozilla, and not everyone
associated with the Mozilla Foundation sees eye-to-eye on this issue. We
are all doing the best we can, and sometimes we have to make a choice,
even if that makes some people unhappy. It doesn't mean we aren't listening.
> I'm bowing out of this discussion, since it's clear to me that nothing
> short of a fork will resolve this in any way other than what you've
> already decided.
>
No small group of people made this decision initially. The Mozilla
Mike Shaver
> The Firefox2 implementation of this feature is built on the idea that
> RSS feeds are not fit for human consumption. If this is true, then why
> does Firefox display the content at all? Shouldn't it display only a
> simple message to the effect of, "You clicked on a feed. This is
> gobbly-gook-computer-code that is indented to be read by Google, Yahoo
> or Bloglines." If the web browser is going to make an assumption about
> what RSS is used for, then it should go all the way.
No, it's patently _not_ built on that idea. It's built on the idea
that RSS-format content is not suitable for direct presentation to
unsuspecting users, an idea which bears out virtually universally,
even with feeds that contain references to stylesheets. Indeed, such
stylesheets are predominantly used to say "this content isn't meant to
be read by a human, but by a feed-reader instead"!
So we, like pretty much every feed reader that I can think of, format
the RSS content so that the human has a (much, much,
asymptotically-approaching-100%-much) better chance of being able to
see what sorts of things appear in the feed. And then we ask the user
what they would like to do with it.
> The Firefox programmers are saying that web developers who intend for
> their feeds to be read by humans are wrong and that this practice must
> stop.
No, we're saying that they need to insert a comment or use a namespace
or suchlike. None of this thread is about authors not being able to
suppress the pretty-printing, really.
> While this may be technically correct, there are so many feeds
> (feedburner, etc) that DO style it for human consumption, that we
> cannot simply ignore it and hope that the whole internet will change to
> suit Firefox's ideals.
And IE7's, and Safari's... The point is that the overwhelming
majority of feeds out there _are_ improved by this behaviour, which is
why EOMB shares it.
Feedburner and other nth-percentile cases will quickly adopt the
suppression techniques if indeed they don't want the browser's
feed-manipulation interface to appear. That feedburner _hasn't_ done
so might be a good indication that even they are just fine with us
making it easier to get their feed into the user's reader of choice
(desktop or web).
> Just like there are zillions of invalid HTML
> pages that must still be rendered properly, RSS feeds that are
> invalidly styled should still be rendered according to the developers
> wishes.
I don't think you really understand this thread. The issue isn't that
the styles are "invalid" at all -- they're perfectly legal under the
specifications involved. And developers have a veritable buffet of
options available to them if they should wish to suppress our
presentation in favour of their own, which will also work with IE7 and
Safari.
> The best of both words solution is the #4 option in the first post.
> Obey the web developers style, but place a banner across the top with
> the current Firefox subscription options.
We've talked in this thread already about how that's hard, if indeed
it is what we want to do (in-browser feed handling is moving more
towards feed-reader-like behaviour, rather than away from it, I
think). It will become less hard in the future, possibly, but because
you can't ship email complaints, at some point people have to step up
and provide code. (This is _dev_-apps-firefox, after all!)
Provide an extension or patch that shows the behaviour you're talking
about, and you'll have a much easier time making your case, though
it's obviously no guarantee of success.
Mike
a...@incident.com
> No small group of people made this decision initially. The Mozilla
Can someone please tell me to whom exactly that refers? One of the
difficulties in this thread has been that several folks' ultimate
fallback position seems to be "well, don't blame me, it was The Mozilla
Foundation."
So who are these nameless authorities, exactly, and where can we go, as
users, to petition them for redress of our grievances?
Robert Sayre
>
> So who are these nameless authorities, exactly, and where can we go, as
> users, to petition them for redress of our grievances?
>
You can find the module owners here:
http://www.mozilla.org/owners.html
Sometimes they have tough calls to make, but I don't think any of them
operate without considering all input from the community.
- Rob
Mike Shaver
> Robert Sayre wrote:
> > > And yes, this is a standards discussion.
> > No, it isn't.
>
> You're right, Rob... this is only a standards discussion to the extent
> that Firefox prides itself on conforming to web standards.
It's a standards discussion only to the extent that there is a
standard that governs our behaviour as an RSS processor. If Firefox
1.5 had had this same behaviour -- or, worse, egads, had not displayed
the author's content at _all_ -- would you have come after us for not
following, er, what standard was that again? All I can find about
applying style sheets is that we need to provide a way to turn them
_off_, and we _should_ provide a way to select between alternates. I
don't see anywhere that says that all stylesheets must be processed by
all consumers of XML at all times.
> This is, more strictly put, a standards _conformance_ issue... Firefox
> used to conform consistently with the W3C recommendations, and now it's
> departed from them by arbitrarily excluding RSS and Atom files from its
> XSL processing.
I don't know of a time when we conformed to W3C standards more than we
do today -- can you elaborate, especially on which standards?
Are all consumers of XML content required by some standard to apply
the stylesheet? We certainly have never applied that style sheet when