Closed Bug 66054 Opened 24 years ago Closed 21 years ago

Mozilla should support rendering of RSS formats

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.2alpha

People

(Reporter: matthew, Assigned: andreww)

References

(
URL
)

Details

Many sites provide news as an RSS feed, but are not listed as available tabs 
when customising the sidebar. It would be useful if, in conjunction with bug 
50063 (Ability to enter custom URL for sidebar tab), the sidebar could render 
RSS files itself.
Confirming. Excellent idea.
Status: UNCONFIRMED → NEW
Ever confirmed: true
spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay
Would be nice if it was possible to have user style sheets for this.

No need for a preference for choosing the style sheet or any other fancy front
end stuff -- just place 'rs.css' in your profile directory..
Changing summary. RSS files should be available not only from the sidebar, but
also from the rest of the browser, too (just like HTML, MathML and SVG documents).
Summary: [RFE] Sidebar should support RSS formats → [RFE] Mozilla should support RSS formats
With the landing of XLST, the RSS files could easily be transformed into
HTML-like panels with the content creator's own images and colors and etc. Of
course, this could be overridden with a user's own CSS or XSLT file.

HTML sidebar panels just seem so cheap now. Supporting RSS files instantly adds
hundreds of user customized content in an open format, and makes the sidebar
much more useful. This gets my vote.
> With the landing of XLST, the RSS files could
> easily be transformed into
> HTML-like panels with the content creator's
> own images and colors and etc.

RSS files doesn't contain information about colours. But yes, XSLT would be a 
very good solution. I think it's better to transform the RSS into native XUL, 
though.
Target Milestone: --- → Future
I am working on an XP App and sidebar to do this.  It is called RSSzilla and is
over at mozdev.org.  I store a list of RSS feeds in a local RDF file and display
them in an outliner in the app and as a menulist in the sidebar.  Once one of
these feeds is selected I want to transform the rss to an outliner xul using
javascript.  Can anyone help me on this.  I would like to have the outliner in
an overlay say that it can be used in both the app and the sidebar.  Thanks.
iirc, forumzilla (http://forumzilla.mozdev.org) handles RSS 1.0.  their
application is a bit different, but you might be able to get some mileage out of
the code.
Depends on: 104708
As to Huftis' mention of user style sheets... Should have a XSLT sheet in the
communicator content part of chrome, and CSS sheets in each style. And I agree
with XUL over HTML. There, my 1/50 of a dollar.

[OT: Shouldn't RSS be using XML-Link instead of <link></link> tags and such? It
just seems so... wrong...]
I'm willing to take a crack at implementing this  - in terms of having the 
browser detect and load a special rss.css file when it sees a raw rss file.  
Much like how browser loads html.css and view-source loads 
viewsource.css, etc. etc.

matt, do you mind if it take it  on for a bit?
we've been talking about finding a way to support rss files so that we could 
make a local start page (or account central page, for mailnews)) that would 
aggregate rss feeds.

question, is there a special mime type associated with RSS?

is there a way to do what Karl suggested 
(http://bugzilla.mozilla.org/show_bug.cgi?id=66054#c3) and have that style 
sheet apply to any files with that mime type?
Assignee: matt → andreww
Component: Sidebar → Browser-General
The last thing I heard was the application/xml was the only mime-type for RSS;
it was implied that there was work being done to register another, but I'm not
sure what happened to it.

See
http://groups.yahoo.com/group/rss-dev/files/specification.html
http://groups.yahoo.com/group/rss-dev/message/1779
>matt, do you mind if it take it  on for a bit?

If that matt is me, then no, I don't mind.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
there must be some way to sniff for RSS...   perhaps reading  the doctype 
and lazily applying the stylesheet... 
RSS will have either:
  <rss ...> as the root element
or
  <rdf:RDF> as the root element with a namespace that looks like:
      http://my.netscape.com/rdf/.../ 
  or 
      http://purl.org/rss/.../

Hope this helps, Aaron.
How is mozilla going to find the RSS feeds?

I think something like the following would make sense as it would allow people
to get to the RSS feed from the site navigation toolbar:

<link rel="syndication"
  href="rss100headline.rdf" type="application/xml"
  title="RSS 1.0 Headlines" hreflang="en-gb" /> 

This syntax was suggested to the syndication list a while ago but :

http://groups.yahoo.com/group/syndication/message/2542
I would like to state this for the record...

Mozilla should not have complex RSS support.  Specifically because it is a HUGE
complex problem.  

I am the author of two RSS engines (Jetspeed and Reptile) so I feel qualified to
make this statement.

Handling OCS, making sure your content is always up to date, making ann
infrastructure that can support it, etc is all very time consuming.

My recommendation is that there should be some type of support for rendering RSS
and that is all.  This should probably include the sidebar but that is it.

Finding content and making sure it is up-to-date is the users responsibility.

Is RSSZilla a duplication of effort here?
I agree.  And changing the summary to reflect this because "support" is 
simply too vague.

Issues of finding and syndication are outside the scope of this bug.
Summary: [RFE] Mozilla should support RSS formats → [RFE] Mozilla should support rendering of RSS formats
RSSzilla was created when I found this bug.  I thought I would see what I could
do then if successful I would see if it could get included by default in
mozilla.  Unfortunately I have been to busy lately to work on RSSzilla.  If this
bugs is fixed I would get rid of that project.
Target Milestone: mozilla1.0 → mozilla1.1
(continuing rant from comment #9)

I also want the ability to have a single RSS/News tab (like in Nautilus, or at
least I think Nautilus) or multiple tabs, one per RSS file. On top of that, I
want to have both at once (have a seperate Slashdot tab, a seperate Blaksoft.com
tab (when I add RSS to blaksoft.com), and a third tab for all the other feeds).
I don't think it would be too much trouble creating a centralized sidebar tab,
even I should be able to handle that. For having the seperate tabs however,
that'd be more work than I'd be able to handle right now.

Okay, that should finish my rant. :)
Just as an update to comment #16, there's a movement afoot to standardize how to
link to RSS feeds using <link>: 
http://diveintomark.org/archives/2002/05/30.html#rss_autodiscovery
http://diveintomark.org/archives/2002/06/02.html#important_change_to_the_link_tag

What's status here, then?  I like the idea of having RSS rendering supported. 
Letting the user specify various feeds through their own means.  I'd personally
like to see something where people could then aggregate them and republish them
outward into their own new feeds, then.  It should support both RSS 0.9x and
1.0.  Where's the appropriate place to discuss this?  Should interested parties
form a new project if RSSZilla is dead?

Curt
> What's status here, then?  I like the idea of having RSS rendering supported. 
> Letting the user specify various feeds through their own means.  I'd personally
> like to see something where people could then aggregate them and republish them
> outward into their own new feeds, then.  It should support both RSS 0.9x and
> 1.0.  Where's the appropriate place to discuss this?  Should interested parties
> form a new project if RSSZilla is dead?

Building an RSS aggregator is not a trivial process.  It is much larger than
just a bug within Bugzilla, it is a dedicated sub-project.

I hope I speak from experience as I have been working with RSS for > 2 years and
have written about 3 aggregators and producers (Jetspeed, Reptile, SMTP
delivery, Emacs records-mode, etc)

Building an aggregator is going to be really impossible.  I personally think
that an aggregator is a lot more complex than just an RSS reader.

My opinion should be to build an RSS reader similar to pineapple [2] (though
they call it an aggregator).

It should be somewhat easy.  Just a XUL based reader with possibly sidebar
navigation and some type of event based delivery.

My thoughts on aggregators are that they are much more complicated [3] than RSS
readers.  They are going to require large subscriptions and backend databases.

1. http://www.postal-code.com/phpnuke/html/sections.php?op=listarticles&secid=9
2. http://www.sourceforge.net/projects/records
3. http://reptile.openprivacy.org
Target miletone: We missed 1.1alpha, suggest pushing to 1.2alpha or Future?
IIRC, it's your call, andreww.

Aggregation: That might be better off in another bug rather than this one. Let's
first support RSS feeds, then we can worry about aggregating them.

To-do: 1. We should have an XSLT stylesheet that will turn an RSS feed into XUL
for showing in the/a sidebar. 2. Creation of a sidebar tab for feeds a user
watches, or perhaps a new sidebar where each feed has it's own tab. 3. Devising
a system for managing feeds, possibly in prefs (or off the RSS tab? prefs is
cluttered enough as it is).

Anything I missed? Come on, lets get this bug fixed! :D

I guess we need infrastructure which says "always display a document of type
[whatever the MIME type of RSS is] with the stylesheet [wherever we store the
stylesheet]". Is that infrastructure currently available in Mozilla, i.e. can we
register document types and say how to handle them?
RSS mimetype, IIRC, is still text/xml or application/xml or something along
those lines. I don't think there's a seperate mimetype for it. We'll probably
have to sniff namespace or root tag, and then apply the stylesheet. Or at the
least, most feeds have the extension .rss or .rdf which might be useful for
limiting overhead, so we wouldn't have to check every XML document...
URL: http://purl.org/rss/
This is worse than that and namespace sniffing isn't that easy.

In a RSS document, the document element belongs to the RDF namespace and a
document could declare only the RSS namespace at the level after this one (ie on
channel, item and other "top level" elements) and still be a valid RSS document.

In addition, declaring the RSS namespace is not enough to make a RSS document,
even an invalid one (the RSS namespace could be declared in the document element
or anywhere else and not be used in the document).

To make it clear, this is a RSS document:

<rdf:RDF 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

  <rss:channel rdf:about="http://www.xml.com/xml/news.rss"
    xmlns:rss="http://purl.org/rss/1.0/">
 .../...
  </rss:channel>
.../...
</rdf:RDF>

and this isnt't a RSS document:

<rdf:RDF 
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns="http://purl.org/rss/1.0/"
>

  <foo:channel rdf:about="http://www.xml.com/xml/news.rss"
    xmlns:foo="http://my.own.format">
.../...
  </foo:channel>
.../...
</rdf:RDF>

The issue of the type of a XML document is a real nightmare...

Hope this helps anyway!
Perhaps then we should just be trusting and accept anything as a RSS doc if the
user says so. Then if something breaks, the browser can complain that the user
was wrong. I dunno...

Re: "Perhaps then we should just be trusting and accept anything as a RSS doc if
the user says so."

Yes, this sounds like a pragmatic thing to do!
Pushing to 1.2alpha.

If someone were interested in creating a .css file which could style an 
RSS file into something readable that would help out alot. I'm bogged 
down with other bug issues right now but I want to move forward on this.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Considering the differences between the three different versions of RSS (0.9,
0.91, 1.0), we'd need three different stylesheets for that. Considering the
method of the <link></link> tags, we'd need an XSLT stylesheet for conversion.

I'll try to rig up what I can, but for the most part I'm just nagging others to
help out.
* Comments from andreww@netscape.com

> Pushing to 1.2alpha.

> If someone were interested in creating a .css file which could style an 
> RSS file into something readable that would help out alot. I'm bogged 
> down with other bug issues right now but I want to move forward on this.

* Comments From ccharabaruk@meldstar.com

> Considering the differences between the three different versions of RSS (0.9,
> 0.91, 1.0), we'd need three different stylesheets for that. Considering the
> method of the <link></link> tags, we'd need an XSLT stylesheet for conversion.

> I'll try to rig up what I can, but for the most part I'm just nagging others to
> help out.

* Comments from burton@peerfear.org

I think it would be a good idea for Mozilla to *view* RSS documents but I don't
think it should be a full RSS reader.  This would require a dedicated project (
which I am considering taking up as my own [1])

...

Are you sure you want to do this with CSS?  I have 3 XSLT stylesheet which I use
under Reptile [2] that output RSS 1.0 (but can be used to output XHTML).

The really cool thing about this is that you can input any RSS spec (pre 1.0)
and it will output RSS 1.0.  This mechanism does a few tricks (hacks) with XML
namespaces in order to support this.  It would be somewhat trivial to allow this
to include RSS 1.0 and output XHTML.

I would be more than willing to donate these to the Mozilla project.

1. http://www.peerfear.org/rss/permalink/1026365698.shtml
2. http://reptile.openprivacy.org
Well, I think the jury's already decided we want XUL rather than (X)HTML. If we
could retune the sheets to put out XUL instead, that would be great. Then all we
would need is some system to add, remove, and otherwise manage feeds (at least
in the sidebar).

Anyways, what do you consider the difference between viewing and reading RSS?
Those are just synonyms as far as I'm concerned. All I'm asking for is the
ability to do RSS->XUL so I can check out feeds in the sidebar, whether in one
tab for all, or seperate tabs for each (or better yet, a combination of the two).

via Joseph Reagle come two feeds with associated CSS stylesheets:

http://www.w3.org/2000/08/w3c-synd/home.rss
http://goatee.net/,rss

This stylesheet looks pretty good to me: http://www.w3.org/2000/08/w3c-synd/
style.css
Here's some XSLT from Eric vdv:

http://4xt.org/downloads/rss/10-to-xhtml.xsl
I also read somthing about xml pretty printing effort going on... wonder 
how this might relate to that... since what will happen is that when they 
turn on xml pretty printing, rss channels will show up.. until they get styled 
by this bug..
---
Permalink to this entry: http://www.peerfear.org/rss/permalink/1026623588.shtml
---

I spent about an hour today hacking RSS support into Mozilla [1] via protozilla
[2].  

The goal was to render RSS into HTML from an arbitrary URL without any major XUL
or Mozilla modifications while at the same time allowing users to hack the
presentation.

Here is a quick screenshot of this in action:

http://www.peerfear.org/rss/protozilla-rss.jpg

There is one important thing here, notice that the URL to
http://www.wired.com/news_drop/netcenter/netcenter.rdf begins with an 'rss:'
scheme.  This is used to invoke protozilla with the 'rss.sh' script. Internally
this invokes Xalan [3] which passes the RSS to an 'rss.xsl' stylesheet.

This is very close to the 'Ultimate RSS Reader' blog entry [4] that I made the
other day.

* Pros

- Almost no source code to maintain.  We are literally talking about 50 lines of
code here (most of which is contained within the XSL)

- Supports existing RSS without any modifications.

- Most of the other design requirements in my 'Ultimate RSS Reader' blog 
entry [4]

* Cons

- There is a Java VM startup time associated with this.  It should be trivial to
convert to another stylesheet engine (maybe Xalan-C) so that there is no startup
latency.

- Use of the 'rss' scheme is non-standard and would prohibit exchange or URLs
and integration within 

* What is left to do:

- Support mod_content.  This should be very easy since this is XSLT based.  I
just need to incorporate my mod_content template [5] from my website [6].

- Support other RSS formats other than 0.91 (which I implemented by default)

* Getting the code and installation

The code is available here [7] with CVS instructions here [8].  Installation is
simple.  Just install protozilla [2] (restarting Mozilla), copy the 'rss.sh'
file into MOZILLA_HOME/protozilla/protocols.  Then go to any URL for an RSS file
and append 'rss:' in front of it.  This should work fine.

Note that Windows users will need to port this to a .bat file.  I might try to
get this working with a 'rss.js' file but this wasn't working on my machine.

* Future directions

If other people are interested in this I will release to Freshmeat, create a
mailing list, etc.  Please consider this as a GPL product...

1. http://www.mozilla.org
2. http://protozilla.mozdev.org
3. http://xml.apache.org/xalan-j/index.html
4. http://www.peerfear.org/rss/permalink/1026365698.shtml
5. http://www.peerfear.org/rss/rss-1.0.xsl
6. http://www.peerfear.org
7. http://www.peerfear.org/cgi-bin/cvsweb/protozilla-rss/
8. http://www.peerfear.org/website/cvs/

> - There is a Java VM startup time associated with this.  It should be trivial to
> convert to another stylesheet engine (maybe Xalan-C) so that there is no startup
> latency.

Would it be possible for Protozilla to call a Javascript script which invoked
Mozilla's own XSLT engine?
I think so... it looks like I just need to use XPConnect via Javascript and use
the nsIDocumentTransformer interface.

If I am able to use the the Mozilla XSLT engine I will bundle this as an XPI and
release the changes for use on all platforms.
http://lxr.mozilla.org/mozilla/source/calendar/resources/content/calendar.js#696
might provide you a simple example of how to use the XSLTProcessor object.
The calendar uses that to convert ical data in order to format it for printing.
Permalink to this entry: http://www.peerfear.org/rss/permalink/1030570664.shtml

Just a quick update.

I have been working on this a lot.

Right now I have a new code base (right now called Bonita) that:

- adds a mozilla protocol for a view-rss scheme.  This can then allow the user
to do view-rss:http://www.peerfear.org/rss/index.rss and have the bonita handle
the rendering of the channel.

- added -bonita command line option

- added a handler for application/rss+xml media type.

- XUL application that has a tree for representing subscribed XUL similar to
NetNewsLite (or Mozilla with a sidebar running).

The important thing is that most of the plumming has been done to support RSS.  

We are also going to support pluggable RSS handling mechanisms:

- offload to server for external processing (HTML rendering)

- use the Mozilla transformix XSLT engine to process the HTML (this is slow)

- provide a XUL rendering of the RSS similar to Messenger (mark items read,
forward items, etc).

- Provides the ability to use a native XSLT processor to deliver XUL/HTML to
Mozilla once protozilla starts shipping with Mozilla (we could also attempt to
detect this at runtime for Linux and Windows users)

The major issues I have right now are that Mozilla is lacking in a decent
infrastructure to handle XML (strange huh!)

- The DOM uses the GUI event thread to process so XSLT of RSS locks the GUI

- DOM serialization is slow.

- No SAX2 (that is a big one!)

- Transformix XSLT engine is slow.

I also need to play with the RDF database in Mozilla as this might be a really
cool way to handle the RSS.

Anyway.. I am talking to the Blogzilla guys to make sure they don't mind me
using this as the name of the project.  After that I am going to register it
with Mozdev.

I would *really* love to get some more people involved in this project.  We have
a decent source base now.

Also... I would really like to see this become the standard mechanism for
handling RSS within Mozilla.  Hopefully we can have a 1.0 released within a few
months and have it ship standard with a future version of Mozilla.
This is a useful mine of information on the subject:

http://www.oasis-open.org/cover/rss.html

And here is a site with a LOT of rss feeds:

http://www.syndic8.com/
Component: Browser-General → XP Apps: GUI Features
Summary: [RFE] Mozilla should support rendering of RSS formats → Mozilla should support rendering of RSS formats
Blocks: 171453
I've noticed a lot of interest in RSS lately.  I started the RSSzilla project
over at mozdev.org, but I have not produced anything out of it.  I really just
started the project in the hopes that it would attract developers and to help me
learn XUL/Javascript.  I would love to help out in any way that I can on getting
something going, but I don't know how much help I would be. 
Someone needs to update the target milestone.
Also bug 148662 should be marked as a dup of this
Bug 148662 does not duplicate bug 66054. The former suggests an RSS newsfeed for
the mozilla.org website (which it does now have), the latter is for putting
support for viewing newsfeeds in Mozilla.

Firebird has an extension for a RSS reader sidebar, and there is Aggreg8 for
Mozilla itself. I'm tempted to say WONTFIX, but I won't. If andreww is still
around, perhaps he knows what to do.
I guess I didn't notice the product of bug 148662.  Sorry about that.
I would be comfortable with WONTFIX, on the basis that this functionality is
more appropriate for an extension.
I agree. And and said extension exists, at least for Firebird. Marking WONTFIX,
if andreww survived yesterday and disagrees, he's welcome to reopen it.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WONTFIX
Product: Core → Mozilla Application Suite
I don't understand why so many essential features are marked as "Won't fix", just because there is an extension. If Seamonkey is not more feature-rich than Firefox (already advertised as minimalist), then what's left for Seamonkey? I'm sure many people expect Seamonkey to be feature-rich. This is the fundamental difference between the two application:
 - User wants a simple and extensible browser: Firefox
 - User wants a rich Internet suite with a number of features working out of the box: Seamonkey
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.