505178 - Default namespace for HTML elements should be http://www.w3.org/1999/xhtml

Status: RESOLVED DUPLICATE of bug 1061578

(Core :: DOM: Core & HTML, defect, P3)

Description

[nanto_vi (TOYAMA Nao)]

Attachment: Testcase for default namespace in HTML

From bug 312019 comment 17
> Since bug 468708 was fixed, the namespace of HTML elements is now
> "http://www.w3.org/1999/xhtml".  But HTMLElement.lookupNamespaceURI(null) still
> returns null.  This behavior differs from WebKit, which correctly returns
> "http://www.w3.org/1999/xhtml", and can break some scripts that assume
> lookupNamespace(null) returns the default namespace, such as AutoPagerize [1].
> 
> [1] http://userscripts.org/scripts/show/8551

See the attachment to reproduce this bug.

Expected results:
  http://www.w3.org/1999/xhtml
  true

Actual results:
  null
  false

Comment 1

[Johnny Stenback (:jst)]

Henri, this is a spec compliance bug, and a bug that affects compatibility with other browsers as well? If so, I think we should fix this for 1.9.2. Seems relatively straight forward to fix this. Or do we think this is likely to break existing websites?

Comment 2

[Boris Zbarsky [:bzbarsky]]

It certainly looks like a spec compliance bug.  For elements, the DOM3 spec basically calls for (see <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/namespaces-algorithms.html#lookupNamespaceURIAlgo>):

 if ( Element's namespace != null and Element's prefix == prefix ) 
 { 
    // Note: prefix could be "null" in this case we are looking for default
    // namespace 
    return (Element's namespace);
 } 
 if ( Element has attributes) {
    // do some stuff (that we don't do quite right either, for attributes with
    // empty value
 }
 // Recurse to ancestors

nsContentUtils::LookupNamespaceURI doesn't do that first part (and doesn't do empty attrs quite per spec either, as I said).

Comment 3

[Peter Van der Beken [:peterv]]

Note that we have a bug on lookupNameSpaceURI not following the spec (bug 312019), but I asked to file a separate bug on |HTMLElement.lookupNamespaceURI(null)|. If we want to fix all the bugs in that algorithm we should probably dupe this again, but for now the HTMLElement bug seemed more important than some of the other stuff.

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I've never liked the lookupNamespaceURI algorithm in the spec as it makes it hard to impossible to control namespace mappings using the DOM.

nanto_vi: Why exactly does AutoPagerize need for lookupNamespaceURI(null) to return the XHTML namespace?

Comment 5

[nanto_vi (TOYAMA Nao)]

(In reply to comment #4)
> nanto_vi: Why exactly does AutoPagerize need for lookupNamespaceURI(null) to
> return the XHTML namespace?

My comment 0 is incorrect.  What breaks AutoPagerize is bug 312019.  In addition, AutoPagerize will be updated to avoid that bug.

AutoPagerize uses lookupNamespaceURI(null) to get the default namespace surely in XHTML/XML documents which contain multiple vocabularies (e.g., [1]).  In such documents, element.lookupNamespaceURI(null) may differ from element.namespaceURI and AutoPagerize wants the former to treat non-prefixed XPath node-tests as if they belong to the default namespace.  That is, AutoPagerize uses lookupNamespaceURI(null) for XHTML/XML documents, not for HTML documents.

[1] http://www.kanzaki.com/docs/sw/meta-in-xh.html (written in Japanese)

However, I still hope this bug fixed in 1.9.2 so that we can write codes for HTML and for XHTML in the same manner, and for Gecko and for WebKit as well.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

But why do you want to get the default namespace? Even if multiple vocabularies are used, wouldn't you still just want the elements with a certain name+namespace?

Comment 7

[nanto_vi (TOYAMA Nao)]

What I thought is using prefix and namespace URI pairs described in a page.
http://www.kanzaki.com/docs/sw/meta-in-xh.html contains the following pairs:
  (null) -> http://www.w3.org/1999/xhtml
  foaf   -> http://xmlns.com/foaf/0.1/
  dct    -> http://purl.org/dc/terms/
  rdf    -> http://www.w3.org/1999/02/22-rdf-syntax-ns#
  rdfs   -> http://www.w3.org/2000/01/rdf-schema#
  dc     -> http://purl.org/dc/elements/1.1/
  cc     -> http://web.resource.org/cc/
It looked better to use these combination rather than to create a large database for all existing namespaces.

But now I think it may be the worse way.  This approach can't be applied to the following markup:
  <p>See the image:
    <svg xmlns="http://www.w3.org/2000/svg">...</svg>
  </p>
and HTML5 HTML syntax (or at least Mozilla's HTML5 parser) allows only this type of markup.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This still doesn't describe *why* you need any of the mappings in the page.

Can you describe in detail what it is that your page needs to do? I.e. are you trying to find all the links in a page? Or all the elements? Or count all the namespaces?

Put another way, say that we fixed this bug. What would your page do differently?

Comment 9

[Henri Sivonen (:hsivonen)]

This is both a spec compliance and a WebKit parity bug. I agree that we should target this to 1.9.2.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm unconvinced. The spec really is rather useless here. It makes it basically impossible to modify which prefixes are in scope where using the DOM.

Comment 11

[Henri Sivonen (:hsivonen)]

Attachment: Fix

(In reply to comment #10)
> I'm unconvinced. The spec really is rather useless here. It makes it basically
> impossible to modify which prefixes are in scope where using the DOM.

I agree the spec is questionable due to the reason you point out. Should we try to get the spec changed here? I tend to fight Namespace-induced badness, but I don't care enough about this case to pursue a spec change.

Another perspective is that using the DOM to change which prefixes are in scope is in itself a bad exercise, because it makes sense mostly for synthetic qnames-in-content stuff, and qnames-in-content is an anti-pattern anyway.

Anyway, here's a patch that makes Gecko behave better per spec. (As far as I can tell, the spec doesn't license the hard-wiring of 'xml' and 'xmlns', but that looks like a spec bug to me, so I didn't make those behave per spec.)

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think we should try to get the spec changed yes. The spec currently only makes sense in scenarios where a parser drops xmlns attributes, but no browsers do that anyway.

Comment 13

[Henri Sivonen (:hsivonen)]

For the purposes of the lookup algorithm, trees created by the HTML5 parser are trees without the xmlns attributes, which is why compying with the spec as written fixes this bug.

Comment 14

[Henri Sivonen (:hsivonen)]

XML-mode demo:
http://hsivonen.iki.fi/test/moz/lookupNamespaceURI.xhtml

Findings:
 * In Gecko, both null and "" mean no prefix.
 * In WebKit, null means no prefix, but "" isn't supported.
 * In Opera, "" means no prefix, but null isn't supported.
 * Opera and WebKit, for the value they do recognize, implement the algorithm per spec to the point of not hard-wiring "xml" and "xmlns"

See also http://krijnhoetmer.nl/irc-logs/whatwg/20090817#l-706 and onwards.

Comment 15

[Henri Sivonen (:hsivonen)]

sicking, what are the next steps here considering comment 13 and comment 14? Should we still go for a spec change (which would essentially involve convincing WebKit devs to change WebKit lookup algorithm to disagree with DOM Level 3)? If so, what should the spec say? In particular, are you suggesting changing the identity elt.isDefaultNamespace(elt.lookupNamespaceURI(null)) == true?

Comment 16

[Johnny Stenback (:jst)]

I think this is the sort of change that should get as much up front testing as possible, let's get this in for beta.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I still think this bug is a WONTFIX. The way the spec is written only makes sense if you want things still to "work" even if the parser dropps xmlns attributes (something I believe the DOM L&S spec allowed). However no relevant parser in this context actually does that. Nor would prefix mapping actually work reliably if it did.

So yes, I think we should bring this up in WebApps and see if we can get webkit to change.

Also, I really don't think there is much risk that this will cause any significant compatibility problems. If we can't get people to agree with what we think is the correct solution I don't see it as a problem to fix this in next release even.

Comment 18

[Johnny Stenback (:jst)]

Ok, not blocking 1.9.2 on this per the above comments.

Comment 19

[Henri Sivonen (:hsivonen)]

Shall we WONTFIX this bug and bug 312019?

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I think so. Though definitely worth raising this with whoever ends up developing the "Web Core" spec.

Comment 21

[Anne (:annevk)]

That DOM specification is being developed now, it would be great if you could give feedback on our algorithms: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html

Comment 22

[Anne (:annevk)]

Maybe we should duplicate this against bug 1061578 too.

Comment 23

[Henri Sivonen (:hsivonen)]

We're still different from Chrome on this point, and I think we should take a fix if someone writes one. (I.e. I disagree with comment 17.)