Bug 39887 – [chromium] Add isXHTMLDocument() to Chromium's WebKit::WebDocument

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit API

[Aaron Boodman]

Add isXHTMLDocument() to Chromium's WebKit::WebDocument

[Aaron Boodman]

Created attachment 57345 [details]
Patch

[WebKit Review Bot]

Attachment 57345 [details] did not build on chromium:
Build output: http://webkit-commit-queue.appspot.com/results/2644039

[Aaron Boodman]

Whoops. Please hold for better patch.

[Aaron Boodman]

Created attachment 57364 [details]
Patch

[Darin Fisher (:fishd, Google)]

Comment on attachment 57364 [details]
Patch

WebCore/ChangeLog:5
 +          Added isXHTMLDocument() to WebCore::Document.
nit: add bug link

WebKit/chromium/ChangeLog:5
 +          Add isXHTMLDocument() to WebDocument.
nit: add bug link

[Aaron Boodman]

Committed r60377: <http://trac.webkit.org/changeset/60377>

[Eric Seidel (no email)]

Why would you want this?

Don't you want to know if it's XML vs. HTML?  I can't remember if there is a difference between an XHTML document and an SVG document.

Then again, all of this is going to change in HTML5.

[Eric Seidel (no email)]

WebCore currently has 3 types of documents:

HTMLDocument (exposes things like document.body)
Document (generic XML, no .body)
SVGDocument (<svg> root, exposes a couple SVG-specific things).

HTML5 has opinions on all of this.  I think all interfaces are exposed on all document types in HTML5.

[Aaron Boodman]

I want to know whether the document has things like a body node.

When I debugged through it Document::isHTMLDocument() is not currently true for XHTML documents. m_xhtml is true, but m_html is false. So I added this method so that I could catch the XHTML case.

Is there a better fix?

[Eric Seidel (no email)]

Well, the real fix is HTML5. :)  But I'm surprised you don't just check document.body and if that fails, check document.documentElement.firstChild.

It's lame that our XHTML documents don't have a .body (even though no spec until HTML5 said they should), but the .documentElement is a pretty common workaround.

Again, all of this will go away when we move to HTML5's document structure (I don't know when that will be).  We should just design whatever API so that it is future compatible.

[Aaron Boodman]

You are right, that is a better fix. I'm going to rollback this change and submit one just checking document.documentElement's node name is HTML, which is close enough to what I'm after, and more forward compatible.

[Alexey Proskuryakov]

> It's lame that our XHTML documents don't have a .body (even though
> no spec until HTML5 said they should)

They do, and have done for a long time. Implemented in bug 12628.

[Alexey Proskuryakov]

> SVGDocument (<svg> root, exposes a couple SVG-specific things).

It seems that the only difference is how document.title works - as you mentioned, all documents expose all interfaces in HTML5.