Side navigation
#13754 closed bug (fixed)
Opened April 09, 2013 07:02AM UTC
Closed April 09, 2013 02:06PM UTC
Last modified February 14, 2014 03:06PM UTC
jQuery doesn't work in a non-HTML document in UAs that have innerHTML on Element and create non-HTML elements via createElement
| Reported by: | bzbarsky@mit.edu | Owned by: | bzbarsky@mit.edu |
|---|---|---|---|
| Priority: | low | Milestone: | 1.10 |
| Component: | support | Version: | 1.9.1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
See https://bugzilla.mozilla.org/show_bug.cgi?id=858850#c8 but the short of it is that in an environment in which the following are true:
1) innerHTML exists on all elements
2) createElement creates non-HTML elements
(for example, an XML document in Firefox 20 or later), jQuery's initialization throws an exception because it tries to set a.style.cssText on an "a" that's not an HTMLElement and hence has no .style.
Attachments (0)
Change History (9)
Changed April 09, 2013 07:33AM UTC by comment:1
Changed April 09, 2013 01:36PM UTC by comment:2
I'm the filer of the FF bug. It arises with the update from FF 19 to 20. So I really wonder why nobody else complains broken scripts when doing client side XSLT to XML transforms?
I'm living a long time with the limited capabilities of jquery used in XML documents. Until now it worked good enough to search DOM nodes and manipulate properties like CSS in a cross browser way. But modules like jquery UI never worked because using the append method with strings of HTML code relying on a working innerHtml on DOM nodes. That's a no go on XML DOMs.
So I will request a fundamental change in XML documents: jquery should use createDocumentNS and parse XHTML/XML strings (to append) on its own (simple stack machine to match open/closing tags and attributes, createTextNode for the rest). You should introduce a RegisterNamespace method to associate prefixes to NS-URIs and split node names on the first ':' to automatically detect the namespace to use in createElementNS. In case of a missing prefix you can fall back to createElement.
That behaviour would be a reasonable design suitable for all browsers and strict standard conforming even in HTML4/5.
Changed April 09, 2013 01:50PM UTC by comment:3
| owner: | → bzbarsky@mit.edu |
|---|---|
| status: | new → pending |
To the original report, can you provide a test case? This sounds like it's outside the scope of jQuery's role as an HTML DOM library.
What postbox is asking for is a huge amount of code (a Javascript-based XML parser, really?) and doesn't belong in the core library. It should be a plugin to effectively serve that tiny portion of people who need it.
Changed April 09, 2013 01:53PM UTC by comment:4
| status: | pending → open |
|---|
Oh, now I see what you're saying. All we're going to do to "fix" that is skip the support.js code for that case. Will that move the ball down the field at all?
Changed April 09, 2013 01:54PM UTC by comment:5
| component: | unfiled → support |
|---|---|
| milestone: | None → 1.10 |
| priority: | undecided → low |
Changed April 09, 2013 02:06PM UTC by comment:6
| resolution: | → fixed |
|---|---|
| status: | open → closed |
Changed April 09, 2013 02:18PM UTC by comment:7
Yes, just continuing to skip support for cases like his is fine by me. The change in c6a694e1c262acb941b7fd86663f186656496bbc looks good, thanks!
Changed April 09, 2013 02:21PM UTC by comment:8
I really wonder why nobody else complains broken scripts when doing client side XSLT to XML transforms?
Because it's incredibly rare. jQuery *really* wants an HTML DOM so it can work right. We support basic selection/traversal/manipulation on XML documents, but for example attaching data and events to XML elements is not possible across all the browsers we support. XML issues have been on our wontfix list for ages.
Looks like #13193 may be related.
For example, this makes jQuery not work in SVG documents in current Gecko....