Subject: Re: <base> within HTML content

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 01 Jan 2007 17:59:25 +0100

On Fri, 22 Dec 2006 18:38:33 +0100, Geoffrey Sneddon  
<[email-masked]> wrote:

> If we come across something like: "<description type="html"><![CDATA 
> [<base url="http://example.com/"><a href="test.html">Test Link</a>]] 
>  ></description>",

Yikes!

> I assume the link should point to <http://example.com/test.html>, due
> to the <base> element? I assume, likewise, that <base> would take
> precedence over xml:base, as it is directly within the content.

Like James Holderness wrote, the <base> element has no place in an HTML  
fragment, so its meaning is (although most browsers wrongfully supports  
its presence anywhere in an HTML document) unspecified. The correct base  
URI to use here is the closest xml:base in the ancestor vector or the  
document's base URI.

What's the use case for not using xml:base here?

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Geoffrey Sneddon <[email-masked]>
Date: Mon, 1 Jan 2007 17:47:43 +0000

On 1 Jan 2007, at 16:59, Asbjørn Ulsberg wrote:

> Like James Holderness wrote,

Eek! I should keep up with emails better!

> the <base> element has no place in an HTML fragment, so its meaning  
> is (although most browsers wrongfully supports its presence  
> anywhere in an HTML document) unspecified.

Web Applications 1.0 (keeping with the real world) defines that it  
should be moved to HEAD within the DOM tree.

Why, may I ask, MUST (under the RFC 2119 definition) HTML content be  
a fragment ("HTML markup within SHOULD be such that it could validly  
appear directly within an HTML <DIV> element, after unescaping." -  
note the word SHOULD, not MUST, implying that you can have a full  
HTML document within)?

> The correct base URI to use here is the closest xml:base in the  
> ancestor vector or the document's base URI.
>

I don't know - this is just an example of a feed I came across a few  
weeks back.

- Geoffrey Sneddon

---

From: "Thomas Broyer" <[email-masked]>
Date: Mon, 1 Jan 2007 19:19:25 +0100

> should be moved to HEAD within the DOM tree.

I suppose HTML within Atom is rather processed as "innerHTML", so
there is no "head pointer", and the <base> element is just appended as
a child of the current node (along with a "parse error" !)

> note the word SHOULD, not MUST, implying that you can have a full

Yes, you could, in the sense that the Atom document wouldn't be
"invalid", but you shouldn't expect it to be processed as a "full HTML
document".

The "SHOULD" implies that Atom processors are OK if they process HTML
"content" as "innerHTML" on a <div> element.

-- 
Thomas Broyer

---

From: "A. Pagaltzis" <[email-masked]>
Date: Mon, 1 Jan 2007 19:39:51 +0100

* Geoffrey Sneddon <[email-masked]> [2007-01-01 19:00]:
> >the <base> element has no place in an HTML fragment, so its
> >meaning is (although most browsers wrongfully supports its
> >presence anywhere in an HTML document) unspecified.
> 

Thereby, of course, breaking the links in any other entries
rendered in the same page by a web-based aggregator, f.ex.

> note the word SHOULD, not MUST, implying that you can have a full  

Because many aggregators (most, very likely) do not render items
in isolation, but rather in some sort of collection, either
across feeds as a “river of news” or even just several within a
single feed. (Weblog engines do that when showing the front page
of the weblog or archive for particular intervals.) They will
usually strip any header-level information from your entry, so
putting such elements in the content will usually fail to achieve
what you wanted – hence the SHOULD.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 1 Jan 2007 14:22:48 -0500

On 1/1/07, Geoffrey Sneddon <[email-masked]> wrote:> Why, may I
ask, MUST (under the RFC 2119 definition) HTML
> content be a fragment ("HTML markup within SHOULD be such
> that it could validly appear directly within an HTML <DIV>
> element, after unescaping." - note the word SHOULD, not
> MUST, implying that you can have a full HTML document within)?

What would you do if you wanted to display a feed of 10 entries in
"newspaper" style (i.e. all entries in a single HTML page) yet each of the
entries had a different BASE defined? It wouldn't do you much good to move
all the base elements to the HEAD of the DOM tree -- you'd just end up with
a mess. If you want a local base, then use xml:base. That's what it is for.

The same problem exists for other page-global stuff. For instance, XHTML
modularization is useless if you're creating Atom entries since that stuff
relies on elements in HEAD but, an Atom entry ain't got no head....

Remember as well that not all of the entries in a feed document need be
created by the same person. For instance, with aggregated or synthetic
feeds, you end up with entries written by many different authors who have no
chance of negotiating how they will divide the global resources that might
be used to display their entries. Because some entries may be signed, you
can't simply say something like "just rewrite the entries" -- that would
break the signatures.

It is good that Atom entries should be fragments. That increases to a great
degree the variety of environments in which Atom entries are useful. If you
feel constrained by this, I would suggest that you push on those who define
HTML and get them to provide mechanisms for allowing fragment-local
expression of things that at this time can only be expressed as page-global.
(Yes, I realize this will take some time.)

bob wyman

---

From: Geoffrey Sneddon <[email-masked]>
Date: Mon, 1 Jan 2007 20:22:33 +0000

On 1 Jan 2007, at 19:22, Bob Wyman wrote:

> If you want a local base, then use xml:base. That's what it is for.

When the spec says you SHOULD treat html content as if it were in a  
<DIV>, it adds a certain amount of unclarity as how such Atom feeds  
should be parsed. I'm asking merely to see if there's any consensus  
as to how it should be done. I have no control over the vast majority  
of feeds out there - telling me to use xml:base will make no  
difference, as I have no control over the feed in which I found a  
<base>.

- Geoffrey Sneddon

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 01 Jan 2007 21:46:54 +0100

On Mon, 01 Jan 2007 21:22:33 +0100, Geoffrey Sneddon  
<[email-masked]> wrote:
> should be parsed. I'm asking merely to see if there's any consensus as  
> to how it should be done. I have no control over the vast majority of  
> feeds out there - telling me to use xml:base will make no difference, as  
> I have no control over the feed in which I found a <base>.

Hmm, the same is true for a large number of other cases. Atom in general  
is ambigious at best in terms of error handling.

I suppose you could raise this on the WHATWG list. Asking what happens if  
you set innerHTML of a <div> where the setted value has both a <base> and  
an <a> for instance.

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: "James Holderness" <[email-masked]>
Date: Mon, 1 Jan 2007 23:29:48 -0000

Geoffrey Sneddon wrote:
> should be parsed. I'm asking merely to see if there's any consensus  as to 
> how it should be done. I have no control over the vast majority  of feeds 
> out there - telling me to use xml:base will make no  difference, as I have 
> no control over the feed in which I found a  <base>.

Do you still have a copy of the feed you encountered that was using a base 
element? I'd be curious to see whether its links and images would fail to 
work if you didn't take that base into account? Because if that's the case, 
I'd recommend supporting it (i.e. the base element takes precedence over 
xml:base or however else the current base uri is determined).

In other words, do whatever it takes to get that particular feed to work. 
This obviously isn't a common scenario, and it's arguably not a valid feed, 
so whatever you do you can't be faulted. Unless you find more data 
suggesting this is a bad idea, it seems to me it would make sense to at 
least get your one known example to work.

MHO.

Regards
James

---

From: James M Snell <[email-masked]>
Date: Mon, 01 Jan 2007 16:00:09 -0800

-1. If there's anything we can learn from the mess that is RSS, at a
certain point feed consumers should be allowed to say simply that a
buggy feed is a buggy feed and that it falls on the responsibility of
the feed publisher to get things right.

- James

James Holderness wrote:
> [snip]
> Do you still have a copy of the feed you encountered that was using a
> base element? I'd be curious to see whether its links and images would
> fail to work if you didn't take that base into account? Because if
> that's the case, I'd recommend supporting it (i.e. the base element
> takes precedence over xml:base or however else the current base uri is
> determined).
> 
> In other words, do whatever it takes to get that particular feed to
> work. This obviously isn't a common scenario, and it's arguably not a
> valid feed, so whatever you do you can't be faulted. Unless you find
> more data suggesting this is a bad idea, it seems to me it would make
> sense to at least get your one known example to work.
> 
> MHO.
> 
> Regards
> James
> 
>

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 2 Jan 2007 02:21:09 +0200

On Jan 1, 2007, at 22:46, Anne van Kesteren wrote:

> I suppose you could raise this on the WHATWG list. Asking what  
> happens if you set innerHTML of a <div> where the setted value has  
> both a <base> and an <a> for instance.

Interesting. I hadn't thought that Atom was supposed to use innerHTML  
parsing. I'd have said that you prepend "<!DOCTYPE html><title></ 
title><div>" to what travels in the feed and append "</div>" to it,  
parse the resulting string and grab the first div in the document order.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: "James Holderness" <[email-masked]>
Date: Tue, 2 Jan 2007 01:12:14 -0000

> the feed publisher to get things right.

Well that's not really what I've learnt. I've learnt that there are a lot of 
broken feeds out there (Atom as well as RSS) and that users are less than 
impressed when you tell them it's not your fault and they should complain to 
someone else.

In the words of Mihai Parparita (Google Reader): "as anyone who has 
attempted to implement a feed parser knows, there are many subtle deviations 
from the spec that you have to handle if you want to have any hope of 
satisfying the needs of your users".  [1]

I'm not saying that aggregators MUST support this particular buggy feed. I 
just got the impression that Geoffrey WANTED to support it. I think that's 
his choice to make.

Regards
James

[1] http://googlereader.blogspot.com/2005/12/xml-errors-in-feeds.html

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 02 Jan 2007 11:07:06 +0100

On Tue, 02 Jan 2007 01:21:09 +0100, Henri Sivonen <[email-masked]> wrote:
>> I suppose you could raise this on the WHATWG list. Asking what happens  
>> if you set innerHTML of a <div> where the setted value has both a  
>> <base> and an <a> for instance.
>

That could work as well. In that case <base> would most certainly apply.  
But nothing like that is defined...

---

From: "A. Pagaltzis" <[email-masked]>
Date: Tue, 2 Jan 2007 11:40:53 +0100

* Henri Sivonen <[email-masked]> [2007-01-02 01:35]:
> I hadn't thought that Atom was supposed to use innerHTML
> parsing. I'd have said that you prepend
> "<!DOCTYPE html><title></title><div>" to what travels in the
> feed and append "</div>" to it,  parse the resulting string and
> grab the first div in the document order.

That will lead to silent data loss if the content is malformed
such that it contains an extraneous `</div>`.

Regards,

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 02 Jan 2007 12:11:36 +0100

On Tue, 02 Jan 2007 02:12:14 +0100, James Holderness  
<[email-masked]> wrote:
> Well that's not really what I've learnt. I've learnt that there are a  
> lot of broken feeds out there (Atom as well as RSS) and that users are  
> less than impressed when you tell them it's not your fault and they  
> should complain to someone else.

So if a feed is non-well-formed you should just parse it as well using  
some tag soup parser for XML? I don't necessarily disagree with that, but  
I'd like error handling to be defined in great detail. Everyone just doing  
what is best for their users will lead you to where HTML is now (at best).

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 02 Jan 2007 12:07:58 +0100

> such that it contains an extraneous `</div>`.

Yeah, it's probably better to take the first and only <body> element.

---

From: Henri Sivonen <[email-masked]>
Date: Tue, 2 Jan 2007 14:14:02 +0200

> such that it contains an extraneous `</div>`.

Good point.

Prepending <!DOCTYPE html><title></title> and grabbing the contents  
of body would work better.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: "James Holderness" <[email-masked]>
Date: Tue, 2 Jan 2007 12:33:16 -0000

Anne van Kesteren wrote:
> some tag soup parser for XML?

Well that's what I do. The Google Reader blog post I quoted estimated that 
about seven percent of feeds contained XML errors of some kind. That's a lot 
of feeds for me to ignore. I'm sure other aggregator authors will choose 
otherwise. It just depends on their needs and the needs of their users.

> what is best for their users will lead you to where HTML is now (at best).

To be honest, I don't care. I'm not trying to make policy here. I was just 
offering my advice to one particular person in response to one particular 
query.

Regards
James