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.

append/prepend/before/after/replaceWith and appendto/prependto/insertbefore/insertafter/replaceAll and wrap/wrapInner/wrapAll ... all use domManip 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

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.

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%.

If I may, I think this issue should be extended to really support unknown elements for IE7/8. The problem is that the current implementation has a list of unknown elements.

This causes in my view (at least) two problems:

If tomorrow html5 decide to add a new element, old versions of the applications that use the current jQuery version will suddenly stop working until they upgrade their jQuery, and for any new element this list must be upgraded.

This approach also doesn't allow custom elements to be created that are not (and will never be) part of HTML5. We are actually using this in an application, where we create custom rendered metadata nodes on the fly (we receive them via AJAX). Elements are things like <loop>, <metatarget>, etc.

I am currently working on a fork where I try to allow creation of completely unknown elements, because currently (in the 1.7 beta):

jQuery('<customelement>some content</customelement>');

has a different outcome in IE8 than in IE9 (or any other decent browser).

I hope you find these requirements acceptable for reopening this, or even better in my opinion reopening the duplicate issue 10427. (since HTML5 support is implemented, and only custom elements are not working).

Perhaps it'd be more appropriate to open a new bug for this (please yell if so), but it looks like this has been marked "fixed" prematurely; I tried innerShiv's test page with jQ1.7b2 and Test 2 (which checks for innerShiv support built into jQuery) fails in IE8 :o :( :_(

Yeah, innerShiv's test page includes Rem's HTML5shim (otherwise none of the tests would pass at all) -- it's actually the test set I used when developing the original innerShiv. jQuery 1.7's HTML5 support is substantially the same technique as innerShiv, which is why it's so odd that this isn't working. Either I've done something really stupid in the test page, or something's going on between the HTML being cleaned and appended that's causing the breakage.

When using a class name as a selector instead of a tag name, the page is styled successfully.

innerShiv uses _exactly_ the same technique as the jQuery 1.7 fix, but I've never before encountered this problem with being able to style based of class selectors but not tags, which is why I suspect something's happening between the innerShiv fix and the append.