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
we consumed RSS content to produce Live Bookmark entries, and I don't
recall there having been a standard that required us to. (Or any
complaints that we don't.)
Out of curiosity, do you send these hate mails to the makers of all
other feed readers (Vienna, Bloglines, Netnewswire, etc.) as well? I
don't think most of them honour the author's stylesheets -- which is
probably for the best, given XSS and other concerns.
> 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.
Into what standards process? Please use small words, for I am no W3C
ninja, but I would be very interested to read which standard we're
violating, and whether it would similarly prevent us from using Live
Bookmarks, or a fuller RSS reading implementation (a la Sage or
Vienna, f.e.).
Mike
Adam Scheinberg
Mike Shaver wrote:
> Out of curiosity, do you send these hate mails to the makers of all
> other feed readers
C'mon Mike, is that necessary? Let's not get personal like that.
You've already took a swing at me, and now him, both for what appear to
me to be informative user comments. The argument is a valid one - he,
like me, believes that a browser capable of displaying the style and
ignoring it is a poor implementation of what *we* read as a standard,
and until recently, was in fact, fairly predictable behavior. You
disagree, and do several people here, and we're trying to hash it out
in the best way the community knows how. There's no "hate mail" in
this thread, but there is some strong emotion about the way an
application we all are invested in -- you guys, as developers, clearly
more than I, as a user -- is handling something that we're all using
more frequently, RSS. I'm not trying to be didactic, I'm just sharing
my 2 cents on this.
That said, I think everyone agrees prettying up the CSS is the obvious
first step, because none of the solutions, none of the ones we agree on
and can live with, at least, are implementable immediately, except
perhaps by an extension. I fail to see why an inserted <div> must be
sandboxed, but if that's the case, so be it. Because that, I think,
should be the next step, after cleaning up the CSS.
Adam
Robert Sayre
>
> That said, I think everyone agrees prettying up the CSS is the obvious
> first step, because none of the solutions, none of the ones we agree on
> and can live with, at least, are implementable immediately, except
> perhaps by an extension. I fail to see why an inserted <div> must be
> sandboxed, but if that's the case, so be it. Because that, I think,
> should be the next step, after cleaning up the CSS.
Adam, I don't think you're quite understanding the "CSS sink" term.
First, we are of course open to improving the default feed styling,
which is what I think you're referring to.
Second, we want to allow some CSS in the RSS content. We can't allow
every CSS capability for security reasons, but we can allow most of
them. For example, if you publish this
<div style="text-align: center;">some content</div>
in an RSS item, I don't think you'll have much luck with it displaying
centered. We need to improve that. Keep in mind that most RSS products
don't hand this correctly, if they even make an effort.
- Rob
Adam Scheinberg
> I don't think you're quite understanding the "CSS sink" term.
Maybe not. I'm under the impression it's some sort of smaller CSS
engine that exists separate from the entity that interprets CSS in
Gecko/Firefox proper. Either way, I'm suggesting the goals are/should
be cleaning up the default stylesheet, respecting as much of the CSS as
possible, and eventually respecting the entire stylesheet with an
inserted subscribe DIV at the top. I'm aware that not everyone shares
this vision, and that's okay.
At least, that's my preference with respect to "where we go from here."
Mike Shaver
>
> Mike Shaver wrote:
> > Out of curiosity, do you send these hate mails to the makers of all
> > other feed readers
>
> C'mon Mike, is that necessary? Let's not get personal like that.
> You've already took a swing at me, and now him, both for what appear to
> me to be informative user comments. The argument is a valid one - he,
> like me, believes that a browser capable of displaying the style and
> ignoring it is a poor implementation of what *we* read as a standard,
> and until recently, was in fact, fairly predictable behavior.
The "hate mail" was in reference to phrases like:
"It appears as
though the aim here is to program to the least common denominator"
"A more honest approach"
"Firefox simply ignores developers' wishes altogether."
And then all the unsubstantiated accusations of moving away from our
support for "W3C recommendations", natch.
The "swing" I took at you, was, I presume, the part of a message in
which I pointed out that people _had_ said the things whose imputed
absence made you doubt the truth of what I was telling you. And that
you were replying to one such message! (And the bug you cite also
refers to and summarizes extensive discussion in this very group on
this very topic.) I apologize if you found my incredulity to be
offensive.
I would really like someone to explain to me the difference between
what we do and what Google Reader does. There _are_ several ways for
a feed author to suppress the behaviour in question for not just
Firefox, as Robert has mentioned already in this thread at least once.
Mike
Adam Scheinberg
I think everyone agrees that work needs to be done, and the remaining
questions are really what, by whom, and when.
But nonetheless, let me just include one last response here.
First, I think phrases like:
> "It appears as though the aim here is to program to the least common denominator"
are completely justified. Read some of this thread and you'll see that
the idea is to write for "the user." I *am* a user. This is clearly
not for me, and certainly isn't what I want, as evidenced by the
existence of this very thread. So who are you aiming for again? It
appears it's the people who don't understand the technology yet and
need assistance getting RSS feeds set up with a feed reader. If that's
not the lowest common denominator, I don't know what is.
> "Firefox simply ignores developers' wishes altogether."
Is this not true, on this issue, at least? I want my stylesheet shown.
The only rationale I've heard is that my opinion, as a webmaster, is
not valid, because this isn't really what "the user" wants. Yes, I
know developers have made this call elsewhere. I maintain that a
rational person can differeniate between security related decisons,
such as malicious javascript, spoofed chrome, annoying behavior, such
as popups, and then presentation decisions, such as styling RSS. This
one doesn't fly with me. Yes, Firefox is currently ignoring my wishes
as a developer.
> The "swing" I took at you, was, I presume, the part of a message in
> which I pointed out that people _had_ said the things whose imputed
> absence made you doubt the truth of what I was telling you.
Not in this thread. I said "This isn't the intended behavior as I see
it." No one said "there are technical limitations." They said "we
don't want to do that." Check it out yourself.
Peter Kasting said: 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.
Benjamin Smedberg: 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.
Clearly, this isn't about technical barriers. It's an intentional
decison. It's clearly true that decisions were at least partially made
based on non-technical decisons. Not a complaint, but understand, your
implication that this "technical barrier" info is out there is nearly
moot when your collegues are presenting other info as their primary
stance on the issue.
> I would really like someone to explain to me the difference between
> what we do and what Google Reader does.
I'll do it for you, even though I think you're just dragging through it
here: Google Reader aggregates content from multiple sources. When I
type the URL of an RSS feed, Firefox does not and isn't expected to.
Its job is to fetch content via a supported protocol and render it as
close to standards as possible. An RSS feed is a single XML document.
Should I load it into my browser, I don't expect Firefox to suddenly
pretend it's an aggreation app and decide that THIS XML works one way
and other XML works another way. But that's exactly what it does.
Lastly, your last point:
> There _are_ several ways for
> a feed author to suppress the behaviour in question
You can't be serious. You're suggesting I implement a hack to acheive
the behavior outlined in the W3C specs when someone loads my page
directly. If someone loads my content, fine - that's the very purpose
of XML. But the creation and subsequent implementation of XSLT was
intended to supplement XML exactly like this, and I'm blanked as a dev
...unless I implement a hack to circumvent Firefox's behavior, which
incidentally, cannot be shut off by a client. There is no possible way
for a client to see my XML with its intended style unless I hack my
RSS. This is the situation today. As a client, I can no longer view
styled RSS, period.
I'm burnt out on this. I am not expecting to see this "fixed" in
Firefox anymore, despite my unwavering feeling that it's the wrong
behavior for an open source champion like Firefox to dictate behavior
and deprecate a valid XML construct. It's insulting for anyone to
suggest they know better about "the user" when talking to *a user*.
But I can acknowledge and appreciate that there appear to be private
emailed requests about RSS handling, and this is one bug that is
intentional and here to stay, and I'm obviously just part of a very
vocal minority.
I'd at least like to see Firefox's default stylesheet improved, since
it's obvious that I will eventually have to learn to live with this
behavior.
Adam
Asa Dotzler
<snip>
> People love choice. But even more than they love it, they hate when
> they lose it.
Saying it doesn't make it so. Given a choice between a feature "just
working" for a user and a feature requiring user intervention (choice)
I'd wager that most users prefer the feature just work.
You may love choice. The people visiting this forum may love choice. But
my little sister who just wants easy access to my photostream doesn't.
The school teacher that lives up the road from me who wants to read her
student's classwork blogs doesn't. The Montana farmer getting his first
computer so he can get the weather report delivered to him each hour
doesn't. My grandmother who wants to read my blog posts about the cat
doesn't.
Firefox (along with the other leading browsers, IE and Safari) is trying
to bring a relatively new kind of content to the widest possible
audience. That audience appreciates consistency and dislikes features
that ask them to make unnecessary choices.
- A
Asa Dotzler
> BUT... RSS is for tech savvy folks, and will be for some time.
I think I see better where you're coming from now. You're satisfied with
(or possibly resigned to) the status quo where web feeds are the
exclusive domain of a small handful of geeks. This is where, I think,
the Firefox project goals and your personal feelings are in strong
disagreement.
Firefox, from its first days, has been about empowering as many users as
possible -- not just the "tech savvy folks". I think that Firefox's
mission to bring new and valuable tools to the not tech savvy folks is a
noble one and I hope that we continue down that path.
To take it one step further, I hope that people who want to preserve
those tools for the select few at the expense of the many are routinely
shouted down in the Mozilla community. That view is simply not
compatible with our fundamental mission.
- A
Adam Scheinberg
> those tools for the select few at the expense of the many are routinely
> shouted down in the Mozilla community.
Asa,
Due respect, sir, I sincerely appreciate your work on this project.
That said, you're taking my comment out of context and pretending I
somehow want RSS to be exclusive, and that's both absurd and
condescending. Nobody wants that, nobody wants to alientate any
portion of the crowd, and suggesting that the proponents of a better
solution here are is either naive or dirty, but I'm giving you the
benefit of the doubt and assuming that your got mis-focused on that one
line.
Here's THE REST of what I said, that better makes the point:
> We'll see FF3 long before anyone non-technical is using (hell, even just
> understands) RSS.
The point I was arguing is that a subpar solution today is not better
than a proper solution in time for Firefox 3, because - although you
may advocate for them - there are few or no Montana farmers learning
about RSS from Firefox, and your grandmother ISN'T going to be using
Firefox for feeds (well, except maybe *your* grandmother, because *you*
happen to be her grandson). Realistically, if Firefox 3 is on time
then it's really not that far off, I'd much rather see any of the
discussed solutions implemented properly in FF3 than a half-baked
solution now. With no real warning, we've deprecated an XML construct
in use by some sites, and even "some" sites is significant, because
they now have to adjust their sites to your browser, the opposite of
which is the very goal of standards! With additional time, apparently,
a better solution is within reach. But instead, the admittedly subpar
RSS handling has now shipped.
RSS has NOT pervaded the average standard users' namepsace yet, and as
the admin for several networks, let me assure you that teaching most
users to use tabs in their browser, teaching them about extensions -
honestly, teaching most users about the concept of "bookmarks" is a
challenge. Let's not pretend the universal RSS discoverability and
easy feed reader import is something the that is keeping Firefox from
suddenly taking over 80 percent of the market. It's a great feature if
done right, but even so, one a very small percentage of Firefox users
will likely even notice.
No one is suggesting that making RSS a niche tool for techies is a good
idea. Please re-read this thread if you're somehow under the
impression that that is the goal. There have been several good
arguments for both sides, none of which involved catering to a small
segment *at the expense of* the masses.
Adam
domeni...@gmail.com
set of user and developers. Those of us that sit behind large corporate
firewall that the world can not see. We use browsers for more than just
browsing the web and reading feeds. We use the browser as an
application.
The browser is used as a front end for big applications like Oracle,
WindChill, Peoplesoft and SharePoint. We also have many home grown web
apps running using Tomcat, PHP, ASP, CFM and mySQL. To share chunks of
this data, it is often made available as XML. Since some of it is news
article type info, it is made available as RSS. Even some of our
document repositories are made available as RSS since document metadata
is very similar to article metadata. Why invent a new schema when most
things fit into RSS with a small namespace addition. Much of this RSS
is server side transformed.
Notice, I said much, but not all. We also have to share (replicate)
some of this data onto server available overseas. These server don't
have any server side capablility. Here is where the funs begins for us.
Since much of this content already exists in XML (RSS) and the audience
is predominately using IE6, we syncronize files with the remote server
and let the browser do the transforms to present pretty pages. This
works well in IE 5.5, IE 6, FF 1.5 and Opera. But not in FireFox 2.0.
Now, back to where I started. We use the browser as an applications and
expect it to conform to standards as best as possible. Since most
modern browser are capable of transforming XML, this was a good
solution. FF2 doesn't let it work right and give the user no options
to let it work right.
FF2 is a browser application and is expected to render older HTML
documents along with newer XHTML and XML with XSL. Making the
assumption that RSS is only used for feed is dangerous. Yes, Yahoo news
and Google reader present their own style, but those are designed as
new readers. FF2.0 is a general browser. If news reading is desired in
FF2.0 it should be presented as an option, not forced on you. FireFox
needs to stick to the core of what it is designed for, a small,
lightweight, standards complient browser with extension capabilities.
Sure we can go back and fix our RSS generator code, but we shouldn't
have to. What we have is already compliant to the standards. Please
reconsider stopping the assumption of what an RSS is supposed to look
like and what it even may be used for when a style sheet is supplied.
Thanks for listening,
Dom
DigDug
old Stylesheet switcher an option here? FF could attach isn't own
custom stylesheet to feeds, and then users could select what they
wanted to use through a button in ther interface (URL bar?), or through
the view menu. Is there a way to grant the FF stylesheet and only the
FF stylesheet chrome permissions? There are enough persitant data
storage mechanisms sitting around now that saving the selected
stylesheet would be easier than it was during the 1.0 release.
I dunno... does something like that work? Can you even use XSL in that
way?
Matt Chaput
better than I can, at least in my current state of anger.
This is, simply, Firefox ignoring the presentation standards for XML,
on the basis that "we know better." This would be unsupportable even if
the current feed display wasn't as ugly as it is. This is directly
analogous to ignoring <link rel="stylesheet"> in HTML, and arguing that
you're technically allowed to do that too doesn't make it any less
mean.
I wanted to serve search results from my site's search engine as
OpenSearch Atom feeds that could both be read by tools and humans using
a stylesheet PI. Firefox could display search results, AND allow users
to subscribe to it as a feed using the feed icon, AND add it to the
search box. Except now it won't work correctly, because you decided
that no-one should be allowed to override your ugly feed page for any
reason.
For all the arguments that Mozilla is just a bunch of regular folks
doing the best they can and listening to input, this reeks of extreme
arrogance. Ironically, it's similar to the decision to call FF2 "2.0"
*no matter what*.
Matt Chaput
> The "hate mail" was in reference to phrases like:
>
> "It appears as
> though the aim here is to program to the least common denominator"
>
> "A more honest approach"
>
> "Firefox simply ignores developers' wishes altogether."
That's hate mail? What a sheltered life you must lead.
Those statements seem very polite compared to what I'm feeling, given
the level of
arrogance inherent in the decision on this issue.
Gervase Markham
> This is, simply, Firefox ignoring the presentation standards for XML,
> on the basis that "we know better." This would be unsupportable even if
> the current feed display wasn't as ugly as it is. This is directly
> analogous to ignoring <link rel="stylesheet"> in HTML, and arguing that
> you're technically allowed to do that too doesn't make it any less
> mean.
So surfing the web with Lynx is mean to the site designers?
Gerv
Kevin Hamilton
standards issue. The de facto standard /was/ to put an
<?xml-stylesheet?> PI in all xml documents which you intended to be
consumed by humans via a web-browser. The "NEW" standard is to put an
<?xml-stylesheet?> PI in all xml documents which you intend to be
consumed by humans via a web-browser UNLESS the root node of that xml
document is <rss> or <feed> in which case you should put <!-- xxxxxxxx
[...] xxx --><?xml-stylesheet?>.
The first place I see this being a problem is that this change is still
pretty poorly documented. Searching Google for "xml-stylesheet rss"
and "styled rss" return plenty of links explaining the "OLD" standard
way, and none that I see explaining the new way.
Secondly, I can understand how some content producers would be feeling
uneasy right about now. The "new" way of serving styled xml to
web-browsers /feels/ very much like a hack, and not like something one
can count on working long-term. So the take-away for content producers
seems to be, "<rss> and <feed> typed xml content are meant for
consumption in feed-readers, not web-browsers". This is unfortunate
because in the short-term, it significantly limits the usefulness of
the rss and atom formats. I suspect that feed aggregators are still
years away from having the market penetration that browsers have.
Admittedly, the real-world usage of styled feeds was previously limited
to very xml-saavy content producers. But I think these are the exact
sort of folks that are going to see the comment-hack as a hack. I
don't blame Mozilla for conforming to the new de facto standard, but as
the leading innovator in browser technology, it would have been ( and
would still be ) nice to see Mozilla go one step further and provide an
upgrade path for this sort of xml-saavy content producer who wanted to
take advantage of the ubiquitous web-browsers in the interim while the
uptake (or corporate deployment) of feed-readers increased.
My vote would be for something like proposition #4 in the OP to be
included in Fx3 or sooner.
a...@incident.com
> The de facto standard /was/ ... The "NEW" standard is ...
Seems like the meaning of "de facto standard" has become a bit strained
here. What are the facts that make this new behavior de-facto a
standard? That IE does it? That a few developers think it's a good
idea? Is this actually a de facto standard, or just an attempt
forceably to create one? And who gets to decide?
Given that the developer to whom this bug has been assigned has already
taken a fairly firm and public position that he doesn't see a problem
here, I've joined Adam and others in losing any hope that this
discussion is going be useful in specific terms.
Still, I think it might be worth taking a moment to reflect on how
power is distributed here, as it might tell us something about
potential challenges for open source generally.
The open-source "gift economy" tries to be a meritocracy of software
producers. As long as the users are also the tool-makers, that works
fine... folks who want different functionality are free to "fork" the
codestream and make their own version. But as an open-source project
becomes more complex and/or builds a strong "brand" with, and
distribution channel to, non-technical users, that mechanism loses much
of its practical power.
After all, only a limited number of the stakeholders have the skills
and to contribute to the code. Even skilled coders may think twice
about trying to "read in" on a large body of existing code in order to
contribute. Add to this the accumulation of social links, reputation
and other obligations within the existing project community and a
powerful us/them polarization can develop.
At this point the "community" can start to look more like a cabal and
its followers, with the user constituancy expected to endorse and
promote the decisions of the developer inner circle. Once this
happens, dissent starts to be seen not as valuable input but as an act
of disloyalty and even a personal affront to the developer
establishment. (Obviously this pattern isn't unique to large and
successful open-source projects; the point is that open source doesn't
automatically prevent this sort of social and power stratification.)
The danger, of course, is that the burden grows ever heavier on the
developer core to make every decision absolutely right, because once
they make a choice it becomes a matter of face not to reverse it. At
the same time, because the open source process has limited mechanisms
for assessing customer needs (how many average users or content
producers are ever likely to venture into Bugzilla, particularly in
advance of a release?) there's a growing risk of the core group
becoming insulated, self-referential and out of touch. And although
these problems may be masked by a near-term tipping-point bias toward a
few successful solutions, the ultimate outcome is an historical
commonplace: dissatisfaction grows at the frontiers until an upstart
solution marches in from the provinces and eats the dinosaur's lunch.
Of course, this all may just be the inescapeable Circle of Life for
software products. But still it suggests that if we believe open
source is a fundamentally better way of doing software, we shouldn't
rest on our laurels just yet, because viewed from a distance the
difference is a lot smaller than we might have hoped.
(And folks who see a parable here applicable to other realms of public
life are, of course, free to do so.)
Myk Melez
> a powerful us/them polarization can develop.
...
> the "community" can start to look more like a cabal
...
> dissent starts to be seen not as valuable input but as an act
> of disloyalty and even a personal affront to the developer
> establishment.
...
> The danger, of course, is that the burden grows ever heavier on the
> developer core to make every decision absolutely right, because once
> they make a choice it becomes a matter of face not to reverse it.
...
> there's a growing risk of the core group
> becoming insulated, self-referential and out of touch.
Sure, all these things *can* happen. Are you suggesting they *are*
happening here?
Because, as far as I can tell, they aren't. This isn't a question of
saving face, ignoring users and web developers, or growing out of touch.
To the contrary, the Firefox developers in charge of feed handling have
paid a lot of attention to this issue and the conflicting opinions about
its resolution, both inside and outside the community, as is well
evidenced by this thread and the original conversation about the change.
Reasonable people can disagree.
-myk
(FWIW, I think we should make developer-styled CSS work in Firefox
without an ugly hack like first-512-byte-stuffing, although perhaps not
without some additional indication from the site.)
Robert Sayre
>
> Reasonable people can disagree.
>
Yes. This is why most open source projects lean towards strong module
ownership and benevolent dictators. Otherwise, it's easy for individuals
to focus on a single issue above all else, steering the debate to
governance, power, morals, and interpretations of standards that center
on late 20th century product categories. All well-run projects are
resistant to that sort of noise, and sensitive to cogent technical
suggestions that recognize engineering decisions usually involve several
unpleasant trade-offs.
FWIW, here comes my opinion ;)
>
> (FWIW, I think we should make developer-styled CSS work
Definitely in some form. I am not certain that option needs to include
complete control over the Firefox subscription interface. Web authors
can already use HTML to present a compelling site-specific subscription
interface.
> in Firefox
In all browsers, not just Firefox. Otherwise, we fragment the Web, and
license other browser vendors to do the same. Most of the arguments on
both sides of this thread would be much more forceful between browser
vendors.
> without an ugly hack like first-512-byte-stuffing,
The ugliness of the hack does not affect users, and byte-stuffing is
only one of the interoperable solutions. Never forget that the HyperText
gurus no remembers considered the Web an ugly hack.
> although perhaps not without some additional indication from the
> site.
We definitely need an additional indication that works cross-browser.
- Rob
ubern...@gmail.com
projects are, more and more, involving interesting visual presentations
of XML data, I feel like it's worth chiming in.
Robert Sayre wrote:
> The ugliness of the hack does not affect users, and byte-stuffing is
> only one of the interoperable solutions. Never forget that the HyperText
> gurus no remembers considered the Web an ugly hack.
The ugliness of the hack, to me, is that it's extremely fragile. What
happens if Windows Vista SP1 introduces an IE bug whereby comments
preceding the root element completely break rendering? The old,
took-forever-to-be-fixed IE bug of dropping to quirks mode when
anything, including an XML declaration, preceded the DOCTYPE of an
(X)HTML document should serve as warning that this workaround is not
robust or interoperable enough to stand the test of time.
I've also been somewhat mystified by the resistance to offering a
scheme for using XSL supplied by the document author, given that it's
not hard to implement in a way average users could understand; a simple
notification somewhere of "This page's author has provided different
ways of looking at this page. Click here to try them" would do it,
without the need to resort to big scary technical words. For bonus
points, Firefox would remember whether the user preferred the author's
XSL, and act on that preference for future display of content from the
same location.
But in a larger sense I'm worried about the cost to innovation; one of
the supported feed formats Firefox recognizes (Atom) is not, and so far
as I know never has been, intended solely for consumption by
traditional feed readers. If I decide that I have some data which, for
interoperability purposes, is best serialized as Atom, and then want to
introduce varying views on the data through XSL transforms, Firefox's
current stance will lump its users firmly into the category of people
to whom I have to say "get a better browser".
So given that the current stance of always applying Firefox's built-in
style and refusing to acknowledge author-supplied XSL will have a
stifling effect on innovative presentations, and given that it wouldn't
be hard to achieve a reasonable compromise which ensures a consistent
default presentation to end users while still allowing access to
author-supplied styling, why has there been such stiff resistance here?
I've read through this thread, and the Bugzilla report, multiple times,
and I still don't understand.
cpeter...@googlemail.com
deliver the feed from my site. I decided on FeedBurner because a click
on my "subscribe here" button would give the user an attractively
presented page showing the contents of the feed, a link to a useful
explanation of what this "feeds" stuff is all about, and - most
important - a good selection of one-click options for subscribing to
podcasts. Overwhelmingly, my subscribers use iTunes.
If my users upgrade to FF2, they no longer get this. They get a page
which invites them to subscribe through a small selection of feed
readers, none of which are appropriate for podcasts. Yes, the user can
root around in the applications on their computer and find iTunes, if
its there, and add it to the list. But users are not geeks, and if you
make subscribing to a blog or podcast at all difficult for them, they
go away and find something more rewarding to do. And if users want to
subscribe using a web-based podcatcher like NewsGator, they have - with
FF2 - to return to the stone age and copy and paste the feed URL into
the podcatcher. I doubt they will bother.
OK, there are work-arounds to help users find appropriate ways of
subscribing. In my case I have had to restore the old "subscription"
page in my website, with multiple choices "Click here to subscribe with
...", which I happily abandoned when I first started using FeedBurner.
So from my perspective, this aspect of FF2 is a step backwards.
Something which worked well before no longer works. This is not good.
garth
> Hello everyone. I'm sorry if this is poor etiquette, but I'd like to
> call everyone's attention to a particular BUG in Firefox. The
> developers have asked we move the "debate" here. The debate appears to
> be that many people feel this is a bug, and the Firefox devs feel that
> it's proper browser behavior.
>
> 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.
>
Naturally an application should try to style a document as an author
intended it.
why dont you try asking the developers if you can use just plain CSS2
instead of XSLT?
garth
mobri...@gmail.com
Robert Sayre wrote:
> 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:
"workaround" is just another word for "hack". As long as I have been a
developer I have written pure standards compliant code and it has
displayed (for the most part) how I had intended it by design in
Firefox. THEN I go in and chop it up to get it to do what I want in IE
as well.
This discussion reminds me a LOT of discussions held in the IE blog
where developers request changes to the IE environment and I have to
say, I am starting to like their community and responsiveness to
developers needs much more appealing these days than even Firefox. I
have started recommending that users switch back to IE7 now and,
although the feed issue is a problem in both, IE has done a great job
of moving in a direction toward standards compliance while balancing
backward compatibility. I'm sure many will disagree with me, but the
key word is direction. FF2 on the other hand, appears to be moving away
from developers wants and needs and more toward providing the 'best
user experience'. Skilled developers will find a way to accomplish what
they want with or without being forced to use "hacks". I prefer the
latter but Firefox appears to be in support the former on this topic.
ALLOW THE DEVELOPERS TO PROVIDE THE USERS WITH THE BEST USER
EXPERIENCE! FIREFOX IS A TOOL.
I am sad to say that I am very disappointed in the handling of this
issue and think that the ultimate compromise is a 'bar' at the top of
the page allowing the user to easily re-render the page with or without
Firefox's styles. Remember what used to happen when you would browse
upon an XML file without any style information? There was a bar at the
top that said "This page does not have any default style associated
with it." or something to that affect. So, obviously there is some way
to tell. If there isn't style associated with it show the Firefox
style. If there is, show the developer's style. Have 2 radio buttons
that allow the user to choose between the 2 IN ALL CASES. (Sometimes
people want to see the raw XML).
SERIOUSLY! HOW HARD IS THAT?
(Yes, I am yelling.)
--mobrien118
Nick Vidal
I think both sides (web developers and firefox developers) have valid
arguments. However, we haven't reached a consensus yet in how to solve
this problem. So, I propose the following:
First, let us concentrate on our common goal, which is:
*To provide users a better experience presenting feeds appropriately.*
Now, let us look at our point of divergence:
*Who gets to decide how to present these feeds?*
- Most web developers: they just don't care. Some of them include
stylesheets, others don't.
- Some web developers *who know what they are doing*: we do! Please
respect our stylesheets!
- Firefox developers: most web developers don't care, so let us present
it our way.
- Users: most users don't even know what is a feed, and choices can be
quite confusing.
The solution seems rather obvious: let web developers *who know what
they are doing* DO what they want to!!!
But how? Most web developers don't care, even if they have stylesheets
included.
Something like this would do:
<?xml-stylesheet type="text/xsl" visibility="true" href="rss.xsl"?>
The visibility="true" attribute lets web developers *who know what they
are doing* tell that they *really* know what they are doing. The
default for visibility is "false". This way, web developers *who know
what they are doing* have the choice of *providing users a better
experience presenting feeds appropriately*. As it is right now, web
developers *who know what they are doing* don't have a choice.
So let this attribute be a standard! If anyone has the power to push
this, please do so!
Why is this important? Because the Web is evolving. A feed is not just
a feed, it's a *service*. Let web developers *who know what they are
doing* exploit these services. Let them *provide users a better
experience*! Let them use XSL please!
I'll give one quick example just to show why this is important.
Imagine a REST service where we have:
http://site.com/solutions
When users visit this service in the web browser
http://site.com/solutions
they see the solutions feed, but with the help of XSL, they can see
other services the site provides as well.
this is good! context is good!
When users subscribe to
http://site.com/solutions
they only see the solutions feed. the XSL is ignored.
How can this be achieved if browsers ignore the XSL provided? Users
lose context of the site. For the aggregator to ignore it is
understandable, but the browser shouldn't do that!!! Where is the
browsing? Where is the better experience?
I hope this problem gets settled. Anyways, the "512 bytes of nonsense"
hack was funny! :)
Best regards,
Nick Vidal
Nick Vidal
http://greggman.com/pages/example-with-xslt.xml
But for those that can't see it, there is a screenshot and explanation
here:
http://greggman.com/headlines/2005/2005-01-16-xslt-rss.htm
With user-friendly URLs in RoR and the like, the user might not even be
aware that this is an XML. In fact, this is the best approach.
A site might provide 10 services for example, but only one XSL and one
CSS. This separates the service layer from the presentation layer. It's
an intelligent design. If the user wants to subscribe to a service,
fine. If he/she wants to view it in the browser, it's fine too. Or
should there be 10 RSSs and 10 HTMLs? This is awkward for users and
awkward for developers as well. But this is what is happening right
now! It is the *same* service, but depending from where you access it,
there is a different URL! URL is supposed to be an acronym for Uniform
Resource Locator, right? But it doesn't sound *uniform*, does it?
Why force a presentation layer? Give web developers a choice... Help
them address and present services easier!!!
In my previous post, I said the default value for visibility should be
false. But come to think of it, it should be true. If there is a
stylesheet, respect it. This is to be web standards compliant.
Please reconsider this problem.
Thank you,
Nick Vidal
> When users visit this service in the web browserhttp://site.com/solutions
> they see the solutions feed, but with the help of XSL, they can see
> other services the site provides as well.
> this is good! context is good!
>
> When users subscribe tohttp://site.com/solutions
sull
Anyone interested in rebooting this quest? We are 4 years later with no change to Mozilla's RSS sniffing/handling.
Sull