This is blocked on ISSUE-56 (which is blocked on the IRI draft being written) so marking as a dupe of bug 8207. I expect Larry and will communicate with me directly when there is specific information he feels should be moved into HTML rather than put in the URL specs.

*** This bug has been marked as a duplicate of bug 8207 ***

(In reply to comment #1)
> This is blocked on ISSUE-56 (which is blocked on the IRI draft being written)

The Change Proposal for ISSUE-56 has been submitted over five weeks ago. The chairs still haven't asked the WG for counter proposals, but that doesn't mean that people who disagree with the Change Proposal couldn't start working on those.

We really need to make progress on this issue.

> so marking as a dupe of bug 8207. I expect Larry and will communicate with me
> directly when there is specific information he feels should be moved into HTML
> rather than put in the URL specs.

That proposal has been sent already.

But *this* bug is very specific and could be treated separately. It is about moving stuff back into HTML5. I don't think that this fact is controversial at all, so why don't we try to make progress on that?

As I noted in Bug 8207, I don't know what "stuff" needs to be "moved back in".

Although [WEBADDRESSES] may contain some material in it that isn't currently in the HTML5 spec, if that material isn't referenced, is it necessary, as far as getting HTML5 to last call?

Please elaborate.

(In reply to comment #3)
> As I noted in Bug 8207, I don't know what "stuff" needs to be "moved back in".
> 
> Although [WEBADDRESSES] may contain some material in it that isn't currently in
> the HTML5 spec, if that material isn't referenced, is it necessary, as far as
> getting HTML5 to last call?
> 
> Please elaborate.

"The document base Web address of a Document  is the absolute Web address obtained by running these substeps:

   1. Let fallback base url be the document's address.
   2.

      If fallback base url is about:blank, and the Document's browsing context has a creator browsing context, then let fallback base url be the document base Web address of the creator Document instead.
   3.

      If there is no base element that is both a child of the head element and has an href attribute, then the document base Web address is fallback base url.
   4.

      Otherwise, let w be the value of the href attribute of the first such element.
   5.

      Resolve w relative to fallback base url (thus, the base href attribute isn't affected by xml:base attributes).
   6.

      The document base Web address is the result of the previous step if it was successful; otherwise it is fallback base url."

(there may be more)

(In reply to comment #4)
> "The document base Web address of a Document  is the absolute Web address
> obtained by running these substeps:
> 
>    1. Let fallback base url be the document's address.
>    2.
> 
>       If fallback base url is about:blank, and the Document's browsing context
> has a creator browsing context, then let fallback base url be the document base
> Web address of the creator Document instead.
>    3.
> 
>       If there is no base element that is both a child of the head element and
> has an href attribute, then the document base Web address is fallback base url.
>    4.
> 
>       Otherwise, let w be the value of the href attribute of the first such
> element.
>    5.
> 
>       Resolve w relative to fallback base url (thus, the base href attribute
> isn't affected by xml:base attributes).
>    6.
> 
>       The document base Web address is the result of the previous step if it
> was successful; otherwise it is fallback base url."
> 
> (there may be more)

That being said, this is addressed by the Change Proposal for ISSUE 56, so *if* we finally make progress with that one, this bug could be closed.

I note that the latest edits, the reference to WEBADDRESSES is gone, and thus this issue can be closed.

closed per comment 6 from reporter