[Bug 10692] Fix coercion to Infoset for HTML5 to correctly preserve xmlns attributes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10692

Manu Sporny <msporny@digitalbazaar.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED
         Resolution|NEEDSINFO                   |INVALID

--- Comment #13 from Manu Sporny <msporny@digitalbazaar.com> 2010-12-04 22:40:31 UTC ---
(In reply to comment #10)
> I thought this bug was about changing the coersion rules. However, statements
> about javascript/DOM confuse the issue, since the coersion rules are not
> implemented in browsers (and aren't intended to be and can't be for compat), so
> do not affect javascript/DOM in browsers.
> 
> Is this intended to affect non-browsers that implement the coersion rules, or
> is this intended to affect browsers also?

It was intended to affect both, however, it's now clear to me that I
misunderstood how the Coercion to Infoset rules are used in browser
environments. My bad.

This all came about because I was trying to make sure that Henri's concerns
about RDFa in HTML5 were addressed. However, now I think that this is a
non-issue, and will continue to think so until Henri tells me otherwise.

I was under the mistaken impression that the Coercion to Infoset rules somehow
affected how the xmlns: declarations were translated into attribute names and
prefixes available via the DOM. That is, given the following markup:

----------------------------------------------------------
<!DOCTYPE html>
<html>
  <head>
    <title>An HTML5 Document</title>
  </head>
  <body>
    <h1>Example</h1>
    <p id="p1" xmlns:foo="http://example.org/foo#">
       This is an example HTML5 document.
    </p>
    <p id="end">The end.
    </p>

<script type="text/javascript">
var p1 = document.getElementById("p1");
var end = document.getElementById("end");
var attrs = p1.attributes;
for(var i = attrs.length - 1; i >= 0; i--) 
{
   var p = document.createElement("p");
   p.innerHTML = "prefix: " + attrs[i].prefix + ", " + 
      attrs[i].name + " = " + attrs[i].value;
   document.body.insertBefore(p, end);
}
</script>

  </body>
</html>
----------------------------------------------------------

The page above being loaded into an HTML5-capable browser would display this in
the page somewhere:

prefix = null, xmlns:foo = http://example.org/foo#

I was under the impression that an XHTML-capable browser executing similar
code:

----------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>An XHTML1 Document</title>
  </head>
  <body>
    <h1>Example</h1>
    <p id="p1" xmlns:foo="http://example.org/foo#">
       This is an example XHTML1 document.
    </p>
    <p id="end">The end.
    </p>

<script type="text/javascript">
var p1 = document.getElementById("p1");
var end = document.getElementById("end");
var attrs = p1.attributes;
for(var i = attrs.length - 1; i >= 0; i--) 
{
   var p = document.createElement("p");
   p.innerHTML = "prefix: " + attrs[i].prefix + ", " + 
      attrs[i].name + " = " + attrs[i].value;
   document.body.insertBefore(p, end);
}
</script>

  </body>
</html>
----------------------------------------------------------

would have produced this:

prefix = xmlns, foo = http://example.org/foo#

but instead, it produces this:

prefix: xmlns, xmlns:foo = http://example.org/foo#

I could have sworn that I ran this test when Henri first raised it two years
ago and I got different results at that time. Previously, I had stated:

I don't necessarily care how this is done as long as the Javascript that is
executed on the document, intended to find "xmlns:*" mappings, doesn't have to
have two code paths depending on if the document is in HTML5-mode or
XHTML5-mode.

After re-running the tests above, I'm convinced that two code paths for finding
all "xmlns:*" values are not necessary. 

Apologies for the confusion, I'm marking the issue as INVALID, and setting it's
state to CLOSED.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 4 December 2010 22:40:35 UTC