In Page Feed Preview: Consistent UI vs. Stylesheets
Ben Goodger
navigates to a feed document. In this case, we show some sample content
from the feed, plus the ability to subscribe.
Some people have noted that with this system if the feed specifies its
own stylesheet, this is ignored in favor of our own one.
There is some debate over whether or not this is a bug.
After some thought, I have decided I don't think it is, because:
- feeds are about communication of raw data, the use of which is to be
left to the user agent
- most sites began offering stylesheets because user agents weren't
savvy enough to do something clever with these documents
- new generation browsers (safari, ie7, firefox 2) are now clever enough
to do something with these documents
- there already exists a mechanism to show content from a website with
specific markup and style, it's called HTML
- showing a simple unified experience for this type of document is IMO
more important than allowing sites to design the feed presentation of
their dreams. feeds are a new concept that could be useful IMO to around
15% (maybe more, who knows) of users, but I would hate to see people
scared away from feeds in Firefox because of all the singing and
dancing. Might people not prefer solutions that provide a simpler
presentation especially if feed hosting services begin to push ads into
their stylesheets?
Users wanting better control over what they see always have choices. The
preview page can be styled with Firefox themes, with the user
stylesheet, and the font settings UI.
I'm looking for more input on this. I know the "a site should determine
how it is presented" argument already, I think the cases above outweigh
that. If anyone can come up with good technical reasons why we should
obey site-provided xslt stylesheets, I would like to hear them...
-Ben
Axel Hecht
The counter-argument I have is, you're assuming that a feed is a feed.
I.e., that what the heuristics determine to be a feed is intended to be
a feed. Even more so, that ie7, safari and fx will call the same things
feeds.
The bug even came up with a "512 byte rule" to fool the sniffer, which
just calls for trouble, IMHO.
I guess I have a counter example, too. We've been thinking to use atom
to gather the mozilla automated tests results. Should we really have to
make up our own XML vocabulary if one of the 3 default stylings doesn't
suite our presentational needs? Actually, let me upgrade this to an
argument.
I'm not sure if the defaults should be pref'able, but I do think that
the "expose the given stylesheet in the View menu" has its merits, at
least. The PI suggestions don't, IMHO. Not sure if making the logic
depend on mimetype would help or hurt.
FYI, the bug is 338621.
Axel
beltzner
> After some thought, I have decided I don't think it is, because:
As mentioned previously in this forum, I think the right thing to do
is provide our stylesheet when no other exists; if a stylesheet
exists, I don't see why we can't inject our subscription mechanism and
then render the content using their stylesheet.
> - feeds are about communication of raw data, the use of which is to be
> left to the user agent
Yes, although I'd define a website as a potential "user agent." After
all, Google News and similar portal sites all work by republishing
various feed content as X/HTML.
> - most sites began offering stylesheets because user agents weren't
> savvy enough to do something clever with these documents
With the exception of Feedburner, I think this is correct, but even
then I don't know how many sites do this (BBC, who else?) What's
interesting to note, however, is that Feedburner provides its users
with the capabilities to use their feeds through their web UI, and
they use XML stylesheets as the way of controlling that experience.
For us to not display those stylesheets is, in effect, robbing the
site of its ability to control the experience.
(as for why they don't regenerate as HTML, I believe it's to avoid
having to republish the content/save on server resources, and because
really, they're using the specs as they were designed)
> - new generation browsers (safari, ie7, firefox 2) are now clever enough
> to do something with these documents
Sure, but "something" isn't always what the web author intended.
Here's where your argument breaks down to me. In the case where
there's unstyled feed content, the solution is obvious - we provide
some level of styling such that users can understand the data they've
asked to see.
However, in cases where the data comes *with* a stylesheet, I don't
see why we'd override that, especially when we know we're doing the
least possible thing with our formatting, and when we cannot know what
the website author intended to do with theirs.
This is the crux of my argument: to not display the XML stylesheet
provided presumes that we understand how these technologies will be
used in the future. I could see clever mashups happening in which
people use stylesheets to repurpose their iPhoto photocast in a way
that can be easily viewed on their website, linked back to their blog
entries, etc, etc. I can see that user being very upset to discover
that we don't honour that possibility simply because of the way two or
three websites were using stylesheets back when all this was new and
exciting.
> - there already exists a mechanism to show content from a website with
> specific markup and style, it's called HTML
As I understand it, in order to republish RSS+stylesheet content as
HTML, you need some server-side processing. Not everyone will want to
either take that hit, nor should they. We don't require people to
republish their HTML+CSS into single files, we take and faithfully
apply their styling information to their HTML.
> - showing a simple unified experience for this type of document is IMO
> more important than allowing sites to design the feed presentation of
> their dreams. feeds are a new concept that could be useful IMO to around
> 15% (maybe more, who knows) of users, but I would hate to see people
> scared away from feeds in Firefox because of all the singing and
> dancing. Might people not prefer solutions that provide a simpler
> presentation especially if feed hosting services begin to push ads into
> their stylesheets?
I don't see how it will negate the user experience. Let's take the
worst case example of BBC:
in Firefox 1.5:
http://people.mozilla.com/~beltzner/drop-box/bbc-xml-in-firefox15.png
in Bon Echo Alpha 3:
http://people.mozilla.com/~beltzner/drop-box/bbc-xml-in-firefox2a3.png
So the user would see some extra goo about what an RSS feed is. Big
deal. We still get the top of the page to inject our newsreading
instructions. I'd also wager that the BBC could be convinced to change
this for us on a UA sniff or somesuch.
In the case of ads -- which is a bit of a strawman argument -- users
will be able to subscribe to their feeds in a variety of other
readers.
> I'm looking for more input on this. I know the "a site should determine
> how it is presented" argument already, I think the cases above outweigh
> that. If anyone can come up with good technical reasons why we should
> obey site-provided xslt stylesheets, I would like to hear them...
I don't know how the argument you have already dismissed isn't
technical. One of the users of Firefox is the website creator, and
shoehorning them into arbitrary restrictions about the web experience
they can create seems wrongminded to me.
cheers,
mike
--
/ mike beltzner / phenomenologist / mozilla corporation /
beltzner
> in Firefox 1.5:
> http://people.mozilla.com/~beltzner/drop-box/bbc-xml-in-firefox15.png
>
> in Bon Echo Alpha 3:
> http://people.mozilla.com/~beltzner/drop-box/bbc-xml-in-firefox2a3.png
These should be:
http://people.mozilla.com/~beltzner/dropbox/bbc-xml-in-firefox15.png
and
http://people.mozilla.com/~beltzner/dropbox/bbc-xml-in-firefox2a3.png
sorry,
Myk Melez
> On 5/30/06, Ben Goodger <bengo...@gmail.com> wrote:
>> - feeds are about communication of raw data, the use of which is to be
>> left to the user agent
>
> Yes, although I'd define a website as a potential "user agent." After
> all, Google News and similar portal sites all work by republishing
> various feed content as X/HTML.
Sure these portal sites are user agents when they republish the content
as X/HTML, but when they republish the content as feeds, they are acting
more like data providers.
>> - most sites began offering stylesheets because user agents weren't
>> savvy enough to do something clever with these documents
>
> With the exception of Feedburner, I think this is correct, but even
> then I don't know how many sites do this (BBC, who else?)
adot's notblog (Asa Dotzler's blog) does this, and Asa is a heavy and
longtime feed user who probably has a good sense about how many other
sites do it, too. cc:ing him.
> What's
> interesting to note, however, is that Feedburner provides its users
> with the capabilities to use their feeds through their web UI, and
> they use XML stylesheets as the way of controlling that experience.
> For us to not display those stylesheets is, in effect, robbing the
> site of its ability to control the experience.
Robbing is a pretty strong sentiment. :-) User agents have never given
sites complete control over their experience on the web. The mere act
of choosing which web technologies to support and which not to implement
(f.e. ActiveX) or even remove (f.e. the <blink> tag) limits sites'
control over their experience.
And so does user-empowering features like selective and complete image
blocking, JavaScript restrictions, font size manipulation, user
stylesheets, pop-up blocking, etc.
Granted, many of these features require users to explicitly choose to
employ them, but only because we thought that to be the most appropriate
default for those features, not because we're categorically opposed to
automatically limiting site control (as far as I know; but I haven't
been privy to prior conversations about these features, so I could be
wrong).
> (as for why they don't regenerate as HTML, I believe it's to avoid
> having to republish the content/save on server resources, and because
> really, they're using the specs as they were designed)
To me, this is the strongest case against overriding site styles. But
it's not just that we'd be essentially penalizing sites for using the
specs appropriately. Increasing the amount of XML+XSLT (as opposed to
plain HTML) on the web would be a boon for the semantic web and mashups.
We should encourage it, and I worry that overriding site styles in the
feed case will have the opposite effect.
> I don't see how it will negate the user experience. Let's take the
> worst case example of BBC:
>
> in Firefox 1.5:
> http://people.mozilla.com/~beltzner/drop-box/bbc-xml-in-firefox15.png
>
> in Bon Echo Alpha 3:
> http://people.mozilla.com/~beltzner/drop-box/bbc-xml-in-firefox2a3.png
>
> So the user would see some extra goo about what an RSS feed is. Big
> deal.
The big deal is when sites start to do much more than add a little extra
goo. Ironically, goo notwithstanding, I think the BBC styling in your
example looks better than Firefox's styling, but I suspect we can make
Firefox's styling look better than most site styles out there, and thus,
even disregarding the benefits of consistency, overriding site styles
would be a usability win for the core use case of reading feed items
(although not, perhaps for other interesting use cases that crop up in
the future).
> In the case of ads -- which is a bit of a strawman argument -- users
> will be able to subscribe to their feeds in a variety of other
> readers.
Indeed. I don't think we can usefully predict how sites will include
ads in feeds at this point or what new steps, if any, we should take
with ads for the benefit of our users.
> One of the users of Firefox is the website creator, and
> shoehorning them into arbitrary restrictions about the web experience
> they can create seems wrongminded to me.
Well, the restriction certainly isn't arbitrary, especially given this
discussion. Site needs matter, but site creators are a small segment of
the total Firefox userbase, and we need to consider what behavior makes
the most sense for the largest number of our users.
A thought experiment that might help is to imagine a user who reads
several news sites regularly by loading their home pages and scanning
for stories of interest. The sites all style their HTML-based home
pages differently, and they also all provide feeds.
If we introduced Firefox's feed reading functionality to this user, and
Firefox suppressed site stylesheets, would the user prefer Firefox's
simple, consistent styling or the more complicated, inconsistent styling
of those sites' home pages? If the former, I'll wager the user won't
want sites to be able to style their feeds as arbitrarily as they style
their home pages.
Another way of looking at it: let's say we make Firefox override site
styles by default but provide a simple way for sites to override this
behavior. So some sites provide no stylesheet, others provide a
stylesheet for older browsers that doesn't override Firefox's, and a
third set provide a stylesheet that does override Firefox's.
Many browser users will experience both Firefox-styled and site-styled
feeds. Presumably some of them will be happy to see some site-styled
feeds, while others will be annoyed by it. Which group is larger?
Which group is more likely to seek out palliatives like extensions,
preferences, and site-specific stylesheet selection UI?
Frankly, I don't know the answers to those questions. I know where I
sit (annoyed by site styles, likely to seek out palliatives), but I'm
certainly an exceptional case. Perhaps most users want pretty site
styles, just as more newspaper readers read the graphics-intensive USA
Today than the more highly-regarded but text-heavy New York Times.
But on the other hand, perhaps the whole point of feeds is to apply the
New York Times style to the USA Today content for those users who want
it like that.
-myk
Robert Sayre
> beltzner wrote:
>
>> What's
>> interesting to note, however, is that Feedburner provides its users
>> with the capabilities to use their feeds through their web UI, and
>> they use XML stylesheets as the way of controlling that experience.
>> For us to not display those stylesheets is, in effect, robbing the
>> site of its ability to control the experience.
>
> Robbing is a pretty strong sentiment. :-) User agents have never given
> sites complete control over their experience on the web.
I'm inclined to agree, but I see beltzner's point as well. For me, the
problem with stylesheets is that they're often intended for browsers
that don't support feeds at all, and contain contradictory or misleading
instructions for our users, who may not even realize they've arrived at
a resource that's something different than an HTML page. For instance,
that BBC feed style directs users to drag yet another RSS icon around.
We don't let sites style our dialog boxes, and this is a gray area in
that respect.
But... maybe site authors really want to show stuff like that. So, we
should give them a way to affirmatively indicate that, distinct from the
presentation methods for older, non-feed handling browsers. Here's my
idea: honor an extra MIME parameter on text/xml that would indicate a
stronger preference for the transform, even if we have other
(consistent) ways of displaying it.
Content-type: text/xml; charset="utf-16"; transform="true";
That transform parameter would be their free pass out of the sniffer :)
-Rob
beltzner
> idea: honor an extra MIME parameter on text/xml that would indicate a
> stronger preference for the transform, even if we have other
> (consistent) ways of displaying it.
>
> Content-type: text/xml; charset="utf-16"; transform="true";
>
> That transform parameter would be their free pass out of the sniffer :)
That sounds like a great idea to me, Robert. I'm sure we could get in
touch with Feedburner and let them know about it, and it sounds like a
simple fix to their templates which would let one of the largest users
of this technology blaze the path.
Dietrich Ayala
Doesn't the inclusion of a style sheet already say the equivalent of transform="true"?
If providers like Feedburner only style their feeds "because user agents weren't savvy enough to do
something clever" then we should encourage them to stop unnecessarily styling their feeds, instead
of adding more complexity to both ends.
However, if we do implement this, we should also disable <blink> unless content authors use <blink
notKidding="true">. And get rid of flash ads too while we're at it :)
Axel Hecht
We're only in this mess because we gave up on mime types for feeds for
the most part. Otherwise we'd just pick the feedview for feed mimetypes
or protocol, and sniff text/xml to fall back in case of pretty print.
Note, "transform" suggests that this would only hold true for XSLT,
which is probably not intended.
Anyway, what I'm bothered about is that we take out a completey field of
creative use of Atom or other feed formats and force site developers to
invent their own XML formats.
As myk said, this is going to reduce the interoperability and put an
unneeded cost on the developers of mashups.
Overall, I'm not sure that that many folks will use the feedview for
their daily browsing habits. It's good to have a decent UI, and it's
definitly important that we don't show the xml pretty print for feeds,
but I do see a good reason to have a source-related branding with the
information you get. If you want multiple sources in the same branding,
you probably go for an aggregation service anyway, if that's tb, a
net-based service or something in the places UI.
So the value of limiting the evolution of use of feed formats to what
three UAs consider to be least common denominator (we don't do RTL now,
for example) seems to hurt more than feedview per default over some
other styling brings. IMHO.
Axel
Robert Sayre
>
> We're only in this mess because we gave up on mime types for feeds for
> the most part.
Yep, but too late now. It's not like we had a choice.
> Note, "transform" suggests that this would only hold true for XSLT,
> which is probably not intended.
Any name is fine.
> So the value of limiting the evolution of use of feed formats to what
> three UAs consider to be least common denominator (we don't do RTL now,
> for example) seems to hurt more than feedview per default over some
> other styling brings. IMHO.
I don't buy it. We don't do RTL and that's a bug in feedview, not a
feature of XSLT.
People like feeds because all of the "branding" goes away. I believe we
should give authors the tools to control presentation of older things
like IE6 and FF1.5, but not force them to use that same approach in FF2
and up. My personal opinion is that feed splash pages will vanish--I
think they're the flash intros of 2006. Your point about repurposing
content stands, and we need something in the headers to tip off the sniffer.
No other feed-aware browser or aggregator pays attention to the
stylesheet PI, so perhaps the argument is moot anyway.
-Rob
Axel Hecht
If we'd go for an additional flag to indicate whether we want to show
feedview or not, how about making the flag indicate that UAs should
overwrite the giving styling rather than not?
I.e., make the flag say "ignoreStyle=yes" instead of the other way around?
Axel
beltzner
> If providers like Feedburner only style their feeds "because user agents
> weren't savvy enough to do something clever" then we should encourage
> them to stop unnecessarily styling their feeds, instead of adding more
> complexity to both ends.
Well, Feedburner styles their feeds as a service to their users. Part
of it is for users with older browsers, but they also do some clever
rendering of things that are podcasts, etc.
Robert Sayre
>
> If we'd go for an additional flag to indicate whether we want to show
> feedview or not, how about making the flag indicate that UAs should
> overwrite the giving styling rather than not?
>
> I.e., make the flag say "ignoreStyle=yes" instead of the other way around?
I don't see the win there. Most of the existing transformations are
things we don't want to show (e.g. http://buzz.blogger.com/atom.xml),
and other browser vendors have already shipped products that ignore
text/xml stylesheets. I think their approach is good. Anything that's an
artifact of default Apache/IIS configuration is not to be trusted in
this situation. *Maybe* IE and Safari would also support a backward
compatible new flag, since it does seem to irritate a vocal, but
probably small, set of web authors.
-Rob
Brian Rakowski
question at hand.
In my mind, we're not providing a full, or even a partial, feed reading
experience with this feature. We're only giving users a way to preview
a feed before subscribing to it. This in mind, I think it's more
important to provide a consistent user experience than to render the
content exactly how the webmaster intended. If we expected users to
commonly read feeds in this UI, I'd have a different opinion.
-Brian
Axel Hecht
> This is tangential to the current debate but relevant (I think) to the
> question at hand.
>
> In my mind, we're not providing a full, or even a partial, feed reading
> experience with this feature. We're only giving users a way to preview
> a feed before subscribing to it. This in mind, I think it's more
> important to provide a consistent user experience than to render the
> content exactly how the webmaster intended. If we expected users to
> commonly read feeds in this UI, I'd have a different opinion.
Doesn't that go the other way around? Because you'll hardly use this UI
on purpose, it should be a fallback in case we don't have anything good
from the site?
Axel, who thinks that this discussion fails to convince anyone of anything.
Axel Hecht
The utterly sad thing is, the PI actually has an alternate="yes" [1],
but at least Gecko doesn't use any of these for XSLT, even if there's
just one. Bug, I guess.
Axel