Opened 11 years ago
Last modified 8 years ago
#6485 closed feature
Solution for HTML5 in IE — at Version 38
Reported by: | jonathantneal | Owned by: | Rick Waldron |
---|---|---|---|
Priority: | high | Milestone: | 1.7 |
Component: | core | Version: | 1.4.4 |
Keywords: | html5, innershiv, innershim, needsreview, 1.7-discuss | Cc: | paul.irish, SlexAxton |
Blocked by: | Blocking: |
Description (last modified by )
I wanted to propose some solutions to be used for some major HTML5 issues in IE6, IE7, and IE8, especially in regards to javascript and jQuery.
Issues / Solutions:
- HTML5 is not supported on a document, html5 elements will not properly contain contents
- document.createElement('X') triggers support for 'X' element (you know this one, it's the "shiv I mean shim" method)
- HTML5 is not supported with innerHTML
- HTML5 added with innerHTML is supported when the element being innerHTML'd is already appended to a shim'd document (or document fragment!)
- <HTML5_elements> become <:HTML5_elements> when element is cloneNode'd
- use an alternate cloneNode function, the default is broken and should not be used in IE anyway (for example: it should not clone events)
Example of solutions, in action, with comments:
EDIT by paulirish.. the scope of this ticket it only to fix #2 and #3. the markup in the document will still require the basic html5shiv/modernizr to adjust.
this fix will correct the assumption that "jquery is broken" because it cannot handle ajax'd in html5 content and the like.
Change History (38)
comment:1 Changed 10 years ago by
Keywords: | needsreview added |
---|---|
Priority: | → undecided |
comment:2 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:3 Changed 10 years ago by
Keywords: | needsreview removed |
---|
comment:4 Changed 10 years ago by
Cc: | paul.irish SlexAxton added |
---|---|
Keywords: | html5 innershiv innershim needsreview added |
Milestone: | 1.4.3 → 1.5 |
Priority: | undecided → high |
Resolution: | invalid |
Status: | closed → reopened |
Version: | 1.4.2 → 1.4.4 |
We've talked about different ways to handle this in the 1.5 feature list. I'm going to open this back up as something we are actively considering.
comment:6 Changed 10 years ago by
Description: | modified (diff) |
---|
The major problem is dealing with new elements either ajax'd in or created on the fly... issue #2 of Jon's above.
More detail from the closed dupe #5327 is here: : http://stackoverflow.com/questions/1191164/jquery-html5-append-appendto-and-ie
Test case: http://jsfiddle.net/DVnmE/
Remy's test case: http://jsbin.com/olizu
comment:7 Changed 10 years ago by
Milestone: | → 1.next |
---|
So right now we're looking for a good patch to this. I'm going to bring it up again for 1.7. If we had had a patch for 1.6, it probably would've landed then.
comment:8 Changed 10 years ago by
Status: | reopened → open |
---|
comment:10 Changed 10 years ago by
Keywords: | 1.7-discuss added |
---|
Nominating ticket for 1.7 discussion.
comment:11 Changed 10 years ago by
Description: | modified (diff) |
---|
+1, I believe we said we'd try this, but I'm beginning to think we should first try out a plugin.
comment:14 Changed 10 years ago by
Description: | modified (diff) |
---|
+1, I'm for this and it would be a boon for many, but the problem isn't size - it's speed. We'd need to see a patch and do a lot of perf analysis..
comment:16 Changed 10 years ago by
+1, Fan of a team-supported solution, but first as a plugin and not in core for 1.7
comment:18 Changed 10 years ago by
Description: | modified (diff) |
---|
+1, Only if this can be done in such a way that doesn't cripple performance.
comment:20 Changed 10 years ago by
Description: | modified (diff) |
---|
I was working with jdbarlett on a new version of innerShiv http://jdbartlett.github.com/innershiv/ that is much faster...
https://gist.github.com/7e1c3c76db44e5a249ff is the general idea.
We feature test to see if the shiv is necessary, and we also regex against the input to see if we should even bother shiv'ing it. If it is, then we innerHTML it into an on-DOM div and grab the new childNodes which we'll use in a docFragment.
Currently it supports two signatures:
innerShiv(htmlstring) // documentFragment innerShiv(htmlstring, false) // array of nodes
But that clearly could be simplified for its purposes within jQuery.
From a perf standpoints the questions I have are:
- does the --- 1) add a node to the dom 2) innnerHTML inside of it 3) pull it off --- trick have a significant hit?
- is the regex against the incoming string worth it?
I'm gonna be quite busy, but I'll try to take a stab at this within jQuery and get some perf numbers, sometime, if no one else beats me to it. Help requested :)
comment:22 Changed 10 years ago by
Description: | modified (diff) |
---|
+1, especially if we're able to limit its impact in the ways paul describes above
comment:24 Changed 10 years ago by
Description: | modified (diff) |
---|
Started looking at the code around this and I'm gonna leave my notes, in case they can help someone else...
Talked with jdbarlett about this at TXJS and we agreed the shiv'ing approach within Shimprove http://www.iecss.com/shimprove/ is probably a better choice here. Well, actually the pastie jon linked in this issue's description has that code in a more readable format.
Essentially, that approach is this:
var frag = document.createDocumentFragment(); frag.createElement('abbr'); frag.createElement('aside'); // etc, ... // fragment can now accept unknown element nodes
It looks like we'll want test coverage for:
-
html()
when using the innerHTML shortcut fast path clone()
append/prepend/before/after/replaceWith
andappendto/prependto/insertbefore/insertafter/replaceAll
andwrap/wrapInner/wrapAll
... all usedomManip
so really only a single code path there should be sufficient.
Implementation notes:
- Appears as though everything is within manipulation.js
buildFragment()
is used by domManip and looks to be the right place to improve things- a docFrag is made before sending it off to
jQuery.clean()
along with the html string. We could shiv it before clean or maybe within clean - We'll probably want a test in $.support to know if a browser collapses unknown elems. The test used in Modernizr would work well.
Open questions:
- regex to test against incoming html? (or some indexOf magic?)
- There is an innerHTML set action inside of clean(). Does that collapse unknown elements, or no, since it's still off-dom?
comment:25 Changed 10 years ago by
WIP here: https://github.com/paulirish/jquery/commits/ticket6485
- unit test coverage and $.support.unknownElems added.
so far, the .innerHTML
use from within clean()
is looking like trouble that'll have to be worked around
comment:26 Changed 10 years ago by
Drupal is working on his drupal8 release. We are planning to include shiv (inner shiv) stuff because we are going to go html5 all the way. BUT apparantly jquery is going to integrate those things for us in their next release.
Correct? When will this happen? 3 months? 6 months? a year? I would like to get this info so we can make a roadmap for drupal8.
Thnx!
comment:27 Changed 10 years ago by
I tracked the bugs down to manipulation.js, within the clean function, specifically where html strings are converted into DOM nodes; the line that reads.
div = context.createElement("div")
This element is used to append the strings, and it's not part of a shimmed document. I successfully experimented by adding the following.
html5elementsArr = 'abbr|article|aside|audio|canvas|datalist|details|figcaption|figure|footer|header|hgroup|mark|meter|nav|output|progress|section|subline|summary|time|video'.split('|'), html5elementsArrLen = html5elementsArr.length, html5elementsArrCar = -1, html5safeFrag = context.createDocumentFragment(); if (html5safeFrag.createElement) while (++html5elementsArrCar < html5elementsArrLen) html5safeFrag.createElement(html5elementsArr[html5elementsArrCar]); html5safeFrag.appendChild(div);
Of course, this html5safe fragment could have been previously generated, but for experimental purposes it worked, completely. I ran the unit tests that Paul Irish shared, and loaded up old IE7 and IE8. They passed: 100%.
comment:28 Changed 10 years ago by
I think we got success here. :)
I can take point to integrate that code in jquery style, commit that and PR it.
The test suite index.html will also need the basic html5 shiv run on it for some of these new tests to pass in IE. I hope that's okay.
comment:29 Changed 10 years ago by
Committed Jon's raw patch to my branch.. https://github.com/paulirish/jquery/commits/ticket6485
snover indicates we'll probably need a test similar to https://github.com/jquery/jquery/commit/0a0cf/#diff-1
for this patch.
comment:30 Changed 10 years ago by
Is there anyway that we can handle creation of elements without maintaining an internal hard-coded list? I seem to recall seeing something somewhere...
comment:31 Changed 10 years ago by
Milestone: | 1.next → 1.7 |
---|
comment:33 Changed 9 years ago by
snover gave some feedback to Jonathan the day we were working on this that was useful so I tracked it back down and it's cleaned up and available here http://oksoclap.com/fNZvdYRdAU
comment:34 Changed 9 years ago by
Owner: | set to Rick Waldron |
---|---|
Status: | open → assigned |
comment:35 Changed 9 years ago by
Worked on this today, but ultimately, I'm hitting walls. Here are screen shots of one of the tests when I pull the branch as-is (resolving a minor conflict is required)
IE8 http://gyazo.com/950889903bb10ad7e947ef221b9b2a16.png
IE7 http://gyazo.com/127aca2933a2f3905bdcc80ba07ae23f.png
IE6 http://gyazo.com/4a16f40faf1fe6c4da40b83949d359c8.png
When I change the test to use:
article.width()
The result changes in IE8
comment:36 follow-up: 37 Changed 9 years ago by
More research stuff...
Running this fiddle: http://jsfiddle.net/rwaldron/t6hqK/show
Produces the following results:
IE vs. FF http://gyazo.com/4f54690fa9126ea78285b71518d97c76.png
IE6, 7, 8 http://gyazo.com/de3be2b41f306b06ec9cc86269f7a3d8.png
comment:37 Changed 9 years ago by
rwaldon, unless specified by the browser or the CSS, elements are display: inline by default, so IE is handling them the way it would normally handle inline elements
Running this fiddle: http://jsfiddle.net/t6hqK/5/show/
Produces the following results in IE6: http://s4.postimage.org/5hrhkupqg/ie6_html5.png
comment:38 Changed 9 years ago by
Description: | modified (diff) |
---|
Take a look at modernizr for this, it's kind of heavy to put into jQuery core because everyone would pay the price for it.