Closed Bug 255637 Opened 20 years ago Closed 19 years ago

Easier way needed to create Live Bookmarks from <a> links to feeds

Categories

(Firefox :: Bookmarks & History, enhancement)

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: Peter6, Assigned: vladimir+bm)

References

(
URL
)

Details

(Whiteboard: Workaround in comment #45) 

repro/demo:
1. go to http://www.tweakers.net./
2. at the bottomright of the page is a blue [RSS] button, rightclick on it
3. select -- Bookmark this Link -- from the contextmenu
4. The -- Add Bookmark -- dialoue pops up

exp:
After selecting "Bookmark this link" the -- Properties for "New Live Bookmark"
-- dialogue should pop up.

A lot of sites have the RSS feed only available via this kind of link so it
would be nice if we could directly bookmark them i/o having to copy/paste the
url via Bookmarks->Manage Bookmarks->File->New Live Bookmark....

It's not that the current method doesn't work, but it is user unfriendly.

( this bug is vaguely related to bug 251394 )
There is no way to identify the target of a <a> as a RSS feed.  I agree that
there should be an easier way to create live bookmarks though; having to go
through the bookmarks manager isn't ideal.  I'm not sure what that should be
though; adding "Create Live Bookmark for this link" in the right-click context
menu for all links is overkill.  I've been thinking about this off and on and
haven't been able to come up with a good solution.  Cc'ing ben and blake for any
ideas.
Summary: Bookmark this Link on an RSS link should result in New Live Bookmark dialogue pop up → Easier way needed to create Live Bookmarks from <a> links to feeds
*** Bug 251394 has been marked as a duplicate of this bug. ***
just an idea....
forget abut the context menu
If we click on the [RSS] link, Firefox will want to open that page
The mimetype should tell it that this is not a page to open but something to add
to "live bookmarks".
As soon as it has the mimetype it should stop loading and show the "add the live
Bookmarks" dialogue.
After the Live bookmark is set load about:blank and show a message that you can
look at the page(s) by selecting a bookmark from the Live bookmark you just created.

Can't trust mime types; for most RSS content, it'll be application/xml or
text/xml or something, which doesn't indicate RSS.
A suggestion following on from comment 3 and comment 4

If a user clicks on an RSS link, we don't know if its RSS based on the MIME tag.

So, let Firebird load the XML page (as it does currently), and then check to see
if its RSS.  This should avoid the MIME type problem.

If it is RSS, offer to add it as a live bookmark (aka livemark).

This could be by a popup dialog, or use the lightning bolt icon on the status bar.
The automatic filtering of the RSS would be great, but it would mean you'd have
to filter any XML page on presence of RSS.
This would have to be done for (RSS0.9 ?), RSS0.91, RSS0.92, RSS1.0 and RSS2.0.

For a short term, maybe not perfect, solution it would be easiest to add 
"Bookmark This Linked RSS/Atom/Feed..." (or something similar) in the contextmenu.


Open Link in New Window
Open Link in New Tab
----------------------------------
Bookmark This Linked Page
Bookmark This Linked RSS/Atom/Feed
----------------------------------
Save Link As...
Send Link...
Copy Link Location...
----------------------------------
Properties


Comments:
1. the 2 "bookmarks" are now in a separate "group"
2. "Bookmark This Link..." is renamed to "Bookmark This Linked Page"
Thoughts on achieving the solution through site evangelism as opposed to an
enhancement perhaps? I had a recent experience with a site (JetBrains) that had
a link to an RSS on their site. I suggested they add the link tag so the RSS
feed would get picked up. They added it and now it works the intended way with
the nice RSS in the toolbar.
I agree with Steve on suggesting <link> tags, but that's not always possible. A
simple example is the MozillaZine forums, where there are daily posts about new
versions and they offer a link to an RSS feed. Because of the limitations of a
forum, users can't add tags to the header, only a few specific ones to the
contents of their posts.
I suggest offering right-click menus, but only to links that /look like/ RSS
feeds (http://....rdf,.rss,.xml) -- somewhat like we have "Copy e-mail address"
to links that use the mailto: protocol.

I know this isn't a completely reliable method (Gentoo.org serves all their
pages as .xml when they're not even XHTML, just HTML 4; reasons for that are
beyond me), but it doesn't make the wrong assumption when simply bookmarking,
and requires the user to be aware that he's adding a Live Bookmark.
I agree with comment 8. Parsing through the URL and guessing if it's RSS would
probably catch 80-90% (just a guess) of the RSS links. Doing it after the page
is already loaded is more confusion (thou yes, probably mor reliable). Thou
would we want the default behavior for clicking on a link that we think is RSS
to be to add a livemark? My suggestion is that if we can be reasonable sure that
our regex would have none or almost none false positivies, then it might be a
good candidate for default behavior change.
Another option would be to modify the dialog that appears when you click
"Bookmark This Link..." so that you could specify then whether it is a Live
Bookmark. You could probably get away with just a checkbox, though it might be a
good idea to have a link to the help system that explains what Live Bookmarks are.
How about using the info bar. Similar to comment #5, except the info bar is less
obtrusive than a pop-up, and much more explanitive than an icon tucked away in
the status bar.

This would also leave us (or an extension?) opportunity in the future to parse
the RSS (and friends) file for display in the main window, for whatever limited
value that has, while still prominently offering the syndication option.
*** Bug 258987 has been marked as a duplicate of this bug. ***
*** Bug 258996 has been marked as a duplicate of this bug. ***
Seems to me that _when you go to bookmark the page_, we should try to see if we 
think it is an RSS or Atom page (e.g. by trying to interpret it using our 
current RSS/Atom code) and if it is (that is, if there are no fatal errors while 
parsing it) then you put up the Livemark dialog, otherwise you put up the 
Bookmark dialog.
Maybe the Feed Finder is worth a look at:
 <http://diveintomark.org/projects/feed_finder/>
Hardware: PC → All
(In reply to comment #15)
> Maybe the Feed Finder is worth a look at:
>  <http://diveintomark.org/projects/feed_finder/>

In particular the testpages http://diveintomark.org/tests/client/autodiscovery/
are interresting. Firefox does fail in some cases ( like
http://diveintomark.org/tests/client/autodiscovery/html4-014.html where
Uppercase is used i/o Lowercase ).
A simple toLowerCase() would easily fix this offcourse.
(I am aware the above does not refer this bug)


*** Bug 258384 has been marked as a duplicate of this bug. ***
An easy fix could be this:
Change the add-bookmard/add-live-bookmarks dialog boxes such that they are ONE
dialog boxes with two tabs - "Bookmark" and "Live Bookmark". This is the dialog
box which will pop-up when the user clicks "Bookmark this link" from a context
menu. The default will be a regular bookmark, but if the user will click the
"live" tab, the URL will already be filled in where it belongs.

A lightweight alternative:
Add a "live bookmark" checkbox to the "add bookmark" box. The rest is obvious.
*** Bug 260491 has been marked as a duplicate of this bug. ***
There's no single good answer. As Hixie said in comment 14 we can attempt to
parse every single displayed page that someone attempts to bookmark (*every*
page, because RSS is delivered as text/plain and text/html as often as
application/xml), and *offer* to bookmark or Live Bookmark it (I'll thank you
not to force a Live Bookmark when I'm bookmarking at a genuine text/plain
test-case), which covers almost all the wrong-mime-type situations (except
application/octet-stream), we can have handlers for application/rss+xml and
application/atom+xml (though we're likely to lose that one to real aggregators,
since it can be used) assuming we cheat and pass the handler the URL, not a copy
of the file (since RSS doesn't have an element that gives you the URL to
bookmark), we can try to guess what a link leads to by the URL (keeping in mind
that popular blogging programs like WordPress typically have their feeds at
.../feed/) so that we can quite often avoid the ugly step of displaying garbage
to subscribe to it...

Or, we can just say "we support autodiscovery, get to adding those <link>
elements" with extensions like http://philringnalda.com/mozilla/livemarkthis/ to
cover the needs of really heavy Live Bookmark users.
(In reply to comment #20)
> Or, we can just say "we support autodiscovery, get to adding those <link>
> elements" with extensions like http://philringnalda.com/mozilla/livemarkthis/ to
> cover the needs of really heavy Live Bookmark users.

I'm very happy to go this route, especially for 1.0.  That extension is awesome,
btw!  I was hoping someone would do that -- it was decided to not put it in the
UI, but for the people who are interested in heavy live bookmark use, it's
great.  Get it on update.mozilla.org if it isn't there already :)
*** Bug 261007 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> Can't trust mime types; for most RSS content, it'll be application/xml or
> text/xml or something, which doesn't indicate RSS.
True that. On the other hand I haven't seen a lot of web pages linking to not
rss xml files. Having said that, if there is still now way for the browser to
indentify a xml target as a valid RSS feed, then a context menu item like eg.
"Bookmark as RSS feed" should be prefered to "Bookmark *this* RSS feed" IMVHO.
Does this bug also cover the request for a "New Life Bookmark" toolbar button in
the bookmark manager?
(In reply to comment #24)
> Does this bug also cover the request for a "New Life Bookmark" toolbar button in
> the bookmark manager?

I don't expect that to happen - such a button did exist for a couple of days,
but was removed.
(In reply to comment #25)
> (In reply to comment #24)
> > Does this bug also cover the request for a "New Life Bookmark" toolbar button in
> > the bookmark manager?
> 
> I don't expect that to happen - such a button did exist for a couple of days,
> but was removed.

Actually, it might come back -- it was removed only because it was deemed as
not-generally-useful UI.  However, given the relative popularity of live
bookmarks, and that going through the bookmarks manager is the only way to
manually create a live bookmark, it might make sense to put the button back...


For some reason, one relatively simple solution wasn't mentioned yet.
If someone clicks on an rss feed, an xml document tree is shown. There even is a
bar telling that "This XML file does not appear to have any style information
associated with it. The document tree is shown below."

So, how difficult it is to discover if it's an rss feed NOW? All we need is a
bar telling "It's an rss feed, click here to create a live bookmak".

Granted, we'd love this dialog to be shown before XML is loaded, parsed, or even
sooner - but this solution seems as good as you can get.

People simply click on links anyways, even if they are rss feeds. At least I,
when I found RSS feed for the first time, just left-clicked. An idea of
bookmarking it instead never crossed my mind.
Re comment 27:
That's basically bug 258996.
*** Bug 258996 has been marked as a duplicate of this bug. ***
*** Bug 258996 has been marked as a duplicate of this bug. ***
*** Bug 258996 has been marked as a duplicate of this bug. ***
*** Bug 261939 has been marked as a duplicate of this bug. ***
Why don't you just set up a deafult stylesheet for xml documents that set up
styles for the various parts of an rss feed, for example putting the title of
the feed in large type, putting the discription underneeth, putting under that
the various news items, a description of them and the date and a hyperlink to a
news item. Then you wouldn't have to change much code apart from some api issues
in the javascript or something to allow a link for 'add bookmark' (actually
within the page) to work.
One other problem: If, for whatever reason, you somehow create a normal bookmark
to an RSS feed, there is no way to convert it to a live bookmark.

My first instinct was to go into the properties for the bookmark and see if
there was a checkbox, like the "load in sidebar" option, though depending on the
underlying implementation (I haven't looked) a "convert to live bookmark" button
would be better.  At that point you could retrieve the file, see if it parses as
RSS or Atom, and replace the normal bookmark with a live bookmark.  (If it's not
in a supported feed format, say "Sorry, this doesn't look like a feed" and leave
it alone.) Usual caveats about content sniffing wouldn't apply, since it's in
response to a specific action.
hmmm...

Someone said that looking at MIME type isn't trustworthy. OK. but why not look
at it anyways, and then act accordingly if it DOES say that this is a feed?

Same idea could be applied to some other solutions.

I think it's not hard to convince weblogging engines (such as wordpress) to use
an additional header() command in their PHP files, that provide feeds. Same
applies to others, i guess.
What's wrong with the ideas pointed by comment #10, and later comment #18?
*** Bug 255529 has been marked as a duplicate of this bug. ***
*** Bug 266967 has been marked as a duplicate of this bug. ***
*** Bug 268102 has been marked as a duplicate of this bug. ***
I think the best ideas are:
1) use option/checkbox/tab in the "Add Bookmark" dialog;
2) give the possibility to change Standard Bookmark into Live Bookmark and
viceversa;

Another one:
3) Instead of parsing the XML file when the user clicks on it, why not download
and parse it in the background when the user loads the main page?
Probably you need to download only the first bytes of the file, because it
starts like:
<?xml version="1.0" encoding="ISO-8859-1"?><rss version="2.0"

This could be a problem if a page contains a lot of links...
In this case we could put an icon (bottom right) for a manual search like
"Search for RSS".
We could put an option like "Enable automatic search for RSS" with a limit of links.
(In reply to comment #40)
> why not download and parse it in the background when the user loads the main page?

Please no.  This would cause such catastrophic problems with database driven
sites that I would be forced to stop recommending Firefox to people.

However, it would be nice for Firefox to simply handle the application/rss+xml.
 This may not be the only mime type used... but many css files are sent
text/plain, aren't they?  That doesn't make it correct.

-[Unknown]
What's wrong with a checkbox to make bookmarking any arbitrary URL a Live
Bookmark is that the average user doesn't understand that just bookmarking
cnn.com and checking "Make it Live!" doesn't amount to a Live Bookmark. Even as
hard as it currently is to livemark an arbitrary URL, I've already dealt with
bugs and support questions from people who did that. Having every Add Bookmark
dialog encourage people to think that way is not a happy option.

As to the Right and Wrong of application/rss+xml - using that mime type is
actually Wrong: it's both unregistered and unregisterable (there's no way
something which encompasses all of RSS 0.91-2.0, 0.90, and 1.0, could ever be
registered, and for Right use as an unregistered type it would need to be
structured differently).

But ignore that, and persuade someone to write handlers for it, and for
application/atom+xml. The one set of statistics I'm aware of, when someone
sampled 5096 feeds from the pending list at Syndic8.com, 3452 were text/xml,
1064 were text/plain. If all the rest were application/(rss|atom)+xml, that
gives you ~10%, but, that's 10% of all feeds, not 10% of feeds which lack a
<link> autodiscovery tag. I'd expect that using a "wrong" mime type is much more
common among people who've never heard of autodiscovery than among those who
have. Among the sites mentioned here and in dups, and the ones I could think of
offhand that don't support autodiscovery, you would catch exactly 0%.
Assignee: vladimir → vladimir+bm
Mabey instead of looking at the mimetype, you should be instead looking at the
content of the file. if it contains rss-like tags then its an rss feed. do
intelegent decisions.

for example:
<rss version=1.0> this mush be an rss feed
<html> this is not an rss feed

once you know what it is, you automatically create a bookmark or a live bookmark
as appropriate.

the other option is to use a checkbox "make live!" but only have that avaliable
if there is a <link> to the rss feed in the file that is being bookmarked, and
if there is, create the live bookmark if checked (possibaly also create a
standard bookmark to the reffering page?) 
Arg! I accidentally pressed Enter before completing my comment.

Anyway, Phil Ringnalda has a extension on his site that solves this problem. See
previous comment for the link.

Sorry for the spam,

Prog.
Whiteboard: SA → Workaround in comment #45
I do like the "Make it live!" checkbox idea but I agree that it would be to
confusing for the avarage user.

But what about parsing the location of a link ONLY when the user selects "Add
Bookmark" for it. The "Make it live!" (or whatever it should be called) option
could be greyed out until Firefox discovers that the user is actually trying to
link to a RSS/Atom Feed. And it still gives the user enough control to even
create regular Bookmarks to XML/RSS/Atom-Documents.

The "Add Bookmark" Dialog could look just the way it does right now. Links
entered in it could be checked and parsed in the background and if it is a link
to a file that's clearly a "working live bookmark" the "live bookmark flash" and
a message like "This Bookmark can be used as a Live Bookmark, click here to make
it live!" should appear somewhere in the dialog.
Flags: blocking-aviary1.1?
Version: 1.0 Branch → Trunk
*** Bug 285375 has been marked as a duplicate of this bug. ***
*** Bug 293014 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
> The "Add Bookmark" Dialog could look just the way it does right now. Links
> entered in it could be checked and parsed in the background and if it is a link
> to a file that's clearly a "working live bookmark" the "live bookmark flash" and
> a message like "This Bookmark can be used as a Live Bookmark, click here to make
> it live!" should appear somewhere in the dialog.

I think this is definitely the right idea, no need to say "Live Bookmark" in the
context menu, it's certainly good enough to show it in the Add Bookmark dialog.
 However, However, I think instead of a message like this, there should simply
be a checkbox that is called "Live Bookmark".  This checkbox would be greyed out
until the browser discovers the link is an RSS feed, and then would be ungreyed
and <i>checked by default</i>.  I think there are very few cases where the user
will want to bookmark an RSS feed but not make it Live.
The majority of the time this will do what the user expects, but someone who
does want a regular bookmark (perhaps a web developer) will know what the
checkbox means.
No longer blocks: majorbugs
My vote is to implement this exactly like the LiveBookmarkThis extension does. 
An additional item in the context menu when right-clicking on a link.  Fetching
it in the background means the browser would have to be forced to do this for
EVERY single link the user wants to add and is NOT a good approach in my opinion.

Just let the user choose "Bookmark this Link" or "Add Live Bookmark".  It works
beautifully and is the simplest approach.  Anything else is just overhead with
little benefit.
this isn't going to make 1.1, I don't think any of the solutions proposed thus
far really work in such a way as to be acceptable for the general userbase.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Flags: blocking-aviary2.0?
As bug 302121 -Integrate Feedview for beta is fixed, I believe that this bug is
obsolete.

Feedview allows to click on a feed to view it, and in viewing mode you get
option to create Live bookmark in a standard way.
(In reply to comment #53)
> Feedview allows to click on a feed to view it, and in viewing mode you get
> option to create Live bookmark in a standard way.
Unfortunately until now, only a Bookmark (of Feedview) can be created in that
way, and not an Live Bookmark afaik

How about resolving this one INVA in favor of Bug 303105 ?
Agreed. With Feedview being integrated, this is now obsolete.
Confirming, we're saying that allowing the user to have a pretty view of an RSS
feel is seen as removing the need for easy ability to add a live mark from the
link to a feed. That makes sense, but then I think the issue then transistions
into a shortcoming in the feedview that it does not seem to allow ability to add
a live bookmark from the display of the feed. Should this issue be made more
generic to encompass that situation or retargeted since we're still left with
essentially the same issue however we've made it past the point of detection by
the feedview intergration.
Feedview does allow to add a live bookmark to the current feed, check your
statusbar (The UI needs more love, but that's out of the scope of this bug).
Flags: blocking-aviary2.0? → blocking-aviary2.0-
I do see the typical icon for feed detection thou since we have a "control area"
in feedview where the adjust article length control is, perhaps a link to adding
the livemark could be in that section as well to be clearer for newer users or
ones who don't notice / understand the icon in the status bar.
(In reply to comment #59)
> I do see the typical icon for feed detection thou since we have a "control area"
> in feedview where the adjust article length control is, perhaps a link to adding
> the livemark could be in that section as well to be clearer for newer users or
> ones who don't notice / understand the icon in the status bar.

That's the "more love" part of comment 58.
Closing WFM given the comments  (Peter please reopen if you disagree)

If there are "UI needs more love" bugs in the feedview implementation please
file seperate bugs for them.

Ben G and Beltzner have put some thoughts on areas that need imporvement at
http://wiki.mozilla.org/Firefox:1.1_RSS_Pretty_Print which I believe covers most
of the points raised below.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Having backed out of feedview, this bug gets re-opened, really. I don't think
we'll be able to hit 1.5 with any form of a solution, mind you, but we should
either leave it open or resolve it WONTFIX.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to comment #62)
> Having backed out of feedview, this bug gets re-opened, really. I don't think
> we'll be able to hit 1.5 with any form of a solution, mind you, but we should
> either leave it open or resolve it WONTFIX.

Should the - be changed back as well?
*** Bug 306140 has been marked as a duplicate of this bug. ***
(In reply to comment #63)
> Should the - be changed back as well?

Yeah, I'll renominate this for 1.8b4 blocking, but I'm not myself so sure that
it's a *must-have* for 1.5, as a good number of sites are using the <link rel>
tag to indicate XML feeds.
Flags: blocking1.8b4?
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Flags: blocking1.8b4? → blocking1.8b4-
Resolution: --- → WONTFIX
*** Bug 306488 has been marked as a duplicate of this bug. ***
I see no reason to differ between "bookmark types" (is it alive or dead?) at
creation time.

proposed workflow:
1.) User hit create bookmark a link (html, feed, mailto, whatever)
2.) Bookmark ist stored in the choosed folder
3.) if the user click (activate it) on the bookmark the URI is loaded and type
is recognized
3.1.) if the URI point to a HTML file a new tab open and show the file
3.2.) if the URI point to a Feed the Living Bookmark Feature activate and show
the feed messages as folder content
3.3.) if the URI is a mailto the mail program starts
3.4.) if the URI is whatever - whatever can interpret this uri starts and do its
job.. (FTP, IRC, PDF Viewer, News Reader, Download Manager, etc...)
4.) After a Bookmark is hitted once the "type" of the bookmark get cached to
speed up the processs next time. 

This way a user dont need to bother about URI type and can just use it. This way
you dont need to check all links in the page for the type. This way you dont
blow up UI with additional (unnessesary) choices. And this way you are flexible
for new future content types.

greets knt
(In reply to comment #67)
> 3.2.) if the URI point to a Feed the Living Bookmark Feature activate and show
> the feed messages as folder content

While I like the design approach (a bookmark is a bookmark and let the system
sort out the best way to handle it), IIRC the problem here is that detecting a
feed is not an exactly trivial matter. It takes time and pre-processing of any
file with a .rss, .rdf or .xml extension.
(In reply to comment #68)
> While I like the design approach (a bookmark is a bookmark and let the system
> sort out the best way to handle it), IIRC the problem here is that detecting a
> feed is not an exactly trivial matter. It takes time and pre-processing of any
> file with a .rss, .rdf or .xml extension.

Not to mention, that I've already seen feeds with extensions like shtml, asp,
jsp and even jhtml. 
If anything, we have to rely on content type, not extensions.
> While I like the design approach (a bookmark is a bookmark and let the system
> sort out the best way to handle it), IIRC the problem here is that detecting a
> feed is not an exactly trivial matter.

Well, you are right. Its not trivial and it should not relay on extensions and
in worst case it could take some more time to process. But is it a worse
performace hit to take a small peek? Also It only occurs if the user hit a
bookmark first, cause "real content type" can be cached as bookmark attribute.
(its unlikly to change - right?)

Is the mime-type "application/rdf+xml" defined in RFC 3870 optional or not
generaly used? 

The mime-type is the piece of information that is designed to give this kind of
informations! (btw.. why in god shake is it something ugly like
"application/rdf+xml" and not "text/rdf"?)

side note:
look at this url www.digital-environment.net/mourning/Banner/banner.php
It is an image (i guess a jpeg) but because no content-type is given firefox
"fail" to show it but if you warp the url in a html img tag it works nicly again...

So it seem firefox dont look at the content at all but relay completly on
extension and/or mime type - why not in this RDF case to? "sorry - if you break
the standard I can not give you the most effectiv workflow available" - sound
okay for me :o 

basicly 2 steps to recognice content-type:

1) look at the mime-type of the file and decide what should be done with the
file (standard mode).

2) if no content-type is given or the content type may not be specific enough
(i.e. text/xml?) or the public usage of a content type differs from standard -
check the first XXX bytes (i.e. check for the used namespace or common tags) of
the content to be sure about content-type. (optional compatibility mode)

I saw something called "URILoader" around - i am not sure cause i just start to
look around in your pretty project - but the name told me that is exact the
thing what should be used to decide what firefox should do with a given URI :D

greets Knut
p.s. sorry for my bad wording.. en is not relay a strong side of me :( hope you
get the meaning - if not ask so i can clarify :D
> Is the mime-type "application/rdf+xml" defined in RFC 3870 optional or not
> generaly used? 
> 
> The mime-type is the piece of information that is designed to give this kind of 
> informations!
oh just noticed.. news feeds are not exatly RDF, but somewhere related..

RSS1.0 Spec says:
"The current mime-type recommendation for an RSS 1.0 document is
application/xml. However, work is currently being done to register a mime-type
for RDF (and possibly RSS). The RDF (or preferably RSS) mime-type should be used
once it has been registered." 

If this still true mime-type is not realy helpfull in this case :(
> Is the mime-type "application/rdf+xml" defined in RFC 3870 optional or not
> generaly used? 
> 
> The mime-type is the piece of information that is designed to give this kind of 
> informations!
oh just noticed.. news feeds are not exatly RDF, but somewhere related..

RSS1.0 Spec says:
"The current mime-type recommendation for an RSS 1.0 document is
application/xml. However, work is currently being done to register a mime-type
for RDF (and possibly RSS). The RDF (or preferably RSS) mime-type should be used
once it has been registered." 

RSS2.0 seems not to be a RDF application at all.

For Atom Feeds the mime-type "application/atom+xml" is defined.

So mime-type seems not to be realy helpfull in case of news feeds. 

wrong but working: dont trust the mime-type ;)
*** Bug 258824 has been marked as a duplicate of this bug. ***
*** Bug 311066 has been marked as a duplicate of this bug. ***
*** Bug 331727 has been marked as a duplicate of this bug. ***
This has been resolved by the new Feed Preview functionality. See http://wiki.mozilla.org/Feed_Handling for details.
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → bookmarks
You need to log in before you can comment on or make changes to this bug.