In Gtk-Webkit browser, we are facing issues with respect to accessing DOM elements directly, without using getElementById() from inside javascripts. We have many XHTML pages written already, without using getElementById() and all the pages are perfectly working fine in Opera. As “Chrome” is built using webkit, I tried testing the pages on ‘Chrome’. To my surprise, the same files worked fine in ‘Chrome’. Then, I tried with Safari, (latest nightly updated), the behavior is same as Gtk-Webkit. It throws, “Can’t find variable: DOM element name”
Created attachment 25099 [details] test XHTML page This is a XHTML test page! And it also display the result of test
Created attachment 25100 [details] test page (HTML) This is a HTML test page! And it also display the result of test It succeeds in webkit. But, I am interrested in XHTML pages.
If you just rename my test page from .xhtml to .html ... All works fine.
I wonder if this is a quirks behavior.
This is not a quirks issue, but is due to this bit of code in JSDOMWindowBase::getOwnPropertySlot // Allow shortcuts like 'Image1' instead of document.images.Image1 Document* document = impl()->frame()->document(); if (document && document->isHTMLDocument()) { AtomicStringImpl* atomicPropertyName = AtomicString::find(propertyName); if (atomicPropertyName && (static_cast<HTMLDocument*>(document)->hasNamedItem(atomicPropertyName) || document->hasElementWithId(atomicPropertyName))) { slot.setCustom(this, namedItemGetter); return true; } } Presumably, the isHTMLDocument is return false for document in question. The reason this works in Chromium is because they have their own bindings to JS. In order to provide a cohesive product from this project, we really should try and stay bug for bug compatible. Though I am not sure this is actually a bug quite yet.
For what it's worth, Firefox fails the XHTML version of the test, but it also fails the HTML version. Opera passes. IE is not testable because it does not support XHTML at all, but I am pretty sure it would pass the HTML version. For HTML, I think our choice to emulate the IE compat quirk is sound. For XHTML I could see an argument either way. PRO: HTML and XHTML should behave the same to the degree possible. CON: We shouldn't import this HTML quirk into XHTML (it makes programming tricky since you have unexpeced things in your global namespace), and since Firefox is the leading XHTML-based browser we should try to emulate them for XHTML content. Either way we should have this match between V8 and JSC based versions of WebKit.
Might be good to bring up on the whatwg list to see if the HTML5 spec will have an opinion on this behavior for either HTML or XHTML.
HTML5 currently says that this should work in XHTML. On the other side, Firefox only lets this work in quirks mode HTML, which generally seems like a safer and saner approach to me.
The JSC and V8 behavior appear to match. The XHTML version matches Firefox. Dumping junk in the global namespace is sad face, so I think we should keep our current behavior until we see broken sites.
Adam, would you be willing to file a bug against HTML5 then? I couldn't convince Ian on IRC.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10631
hi, Another issue I was facing is direct DOM access via "document" object. See, <body><img src='s.jpg' id='img1'/></body> If I access document.img1, webkit throws error, but other browsers like FireFox & Opera works without any problem for HTML & XHTML documents. Any suggestions..? Please refer the attachments for more info. Regards, Vicky.
Created attachment 118185 [details] HTML document
Created attachment 118186 [details] XHTML document
Created attachment 118187 [details] Img