New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.7 HTML5 Support for innerHTML, clone & style. Fixes #6485 #490

Closed
wants to merge 4 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@rwaldron
Member

rwaldron commented Sep 7, 2011

This initial pull request should serve as a request for comments, reviews etc.

The approach is based entirely on work by Jonathan Neal, championed by Paul Irish. Please see the ticket for complete details.

This has been tested and is passing in:

FF3.6.20, 6, 7
Chrome 12, 13
Safari 5.0, 5.1
IE 6, 7, 8
Opera 11.01, 11.50
If I could get some backup testing on IE9, that would be greatly appreciated.

http://bugs.jquery.com/ticket/6485

@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Sep 7, 2011

Member

@jdbartlett, would appreciate your code review.

Member

paulirish commented Sep 7, 2011

@jdbartlett, would appreciate your code review.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Sep 7, 2011

Member

@jdalton code review please

Member

rwaldron commented Sep 7, 2011

@jdalton code review please

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Sep 7, 2011

Contributor

FWIW, I just opened up IE9 to test this; all unit tests pass. \o/

Contributor

mathiasbynens commented Sep 7, 2011

FWIW, I just opened up IE9 to test this; all unit tests pass. \o/

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Sep 7, 2011

Member

@mathiasbynens oh awesome! thank you :)

Member

rwaldron commented Sep 7, 2011

@mathiasbynens oh awesome! thank you :)

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Sep 7, 2011

Owner

I'll give a try and report back here. Thanks

Owner

rwaldron commented on src/manipulation.js in 135e409 Sep 7, 2011

I'll give a try and report back here. Thanks

This comment has been minimized.

Show comment
Hide comment
@redoPop

redoPop Sep 7, 2011

Sorry, I moved that comment to the diff just before you replied: https://github.com/jquery/jquery/pull/490/files#r116316

redoPop replied Sep 7, 2011

Sorry, I moved that comment to the diff just before you replied: https://github.com/jquery/jquery/pull/490/files#r116316

Show outdated Hide outdated src/manipulation.js
@aFarkas

This comment has been minimized.

Show comment
Hide comment
@aFarkas

aFarkas Sep 8, 2011

Contributor

It would be really nice, if the shim would not only create a safeFragment, but also a safeDocument. Something like the following:

var safeFragment = (function() {
    var nodeNames = (
        "abbr article aside audio canvas datalist details figcaption figure footer " +
        "header hgroup mark meter nav output progress section summary time video"
    ).split( " " ),
    safeFrag = document.createDocumentFragment(),
    nodeName;

    while ( nodeNames.length ) {
        nodeName = nodeNames.pop();
        document.createElement(nodeName);
        safeFrag.createElement(nodeName);
    }
    return safeFrag;
})();
Contributor

aFarkas commented Sep 8, 2011

It would be really nice, if the shim would not only create a safeFragment, but also a safeDocument. Something like the following:

var safeFragment = (function() {
    var nodeNames = (
        "abbr article aside audio canvas datalist details figcaption figure footer " +
        "header hgroup mark meter nav output progress section summary time video"
    ).split( " " ),
    safeFrag = document.createDocumentFragment(),
    nodeName;

    while ( nodeNames.length ) {
        nodeName = nodeNames.pop();
        document.createElement(nodeName);
        safeFrag.createElement(nodeName);
    }
    return safeFrag;
})();
@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Sep 8, 2011

Member

@aFarkas while I fully understand what the outcome of that addition is, I intentionally omitted this behaviour based on the goals of the ticket - which are not to provide a shim.

Member

rwaldron commented Sep 8, 2011

@aFarkas while I fully understand what the outcome of that addition is, I intentionally omitted this behaviour based on the goals of the ticket - which are not to provide a shim.

@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Sep 8, 2011

Member

If we did that then the recommendation would be:

If you're using HTML5 elements (in the markup) put jQuery in the head, otherwise leave it at the bottom.

I'm not sure we want to force a 35kish file to the head, regardless. But I don't really have perf numbers on this myself.

Member

paulirish commented Sep 8, 2011

If we did that then the recommendation would be:

If you're using HTML5 elements (in the markup) put jQuery in the head, otherwise leave it at the bottom.

I'm not sure we want to force a 35kish file to the head, regardless. But I don't really have perf numbers on this myself.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Sep 8, 2011

Member

@dmethvin and I discussed this at length and agree that adding a "must exist in head" rule to jQuery would be bad.

Member

rwaldron commented Sep 8, 2011

@dmethvin and I discussed this at length and agree that adding a "must exist in head" rule to jQuery would be bad.

@aFarkas

This comment has been minimized.

Show comment
Hide comment
@aFarkas

aFarkas Sep 8, 2011

Contributor

I don't think, that this is the recommendation. It's simply an additional feature, which we get for free. Whether this feature is used directly or the developer has to use Modernizr/iepp additionally is left to the developer. In short: This change, won't break anything, if a developer loads jQuery from the bottom.

And to be here a little bit off topic:
I'm not a real fan of blindly following old performance rules, which where made for IE7. In fact loading 2 15kb js-files is a lot faster in modern browsers (including non-borwsers like IE8), than loading 1 30kb file.

In case of using a script loader, the advantage of loading a script dynamically from head is a lot better than loading it from the bottom. And sometimes loading a bunch of scripts from head is exactly what a developer wants.

Contributor

aFarkas commented Sep 8, 2011

I don't think, that this is the recommendation. It's simply an additional feature, which we get for free. Whether this feature is used directly or the developer has to use Modernizr/iepp additionally is left to the developer. In short: This change, won't break anything, if a developer loads jQuery from the bottom.

And to be here a little bit off topic:
I'm not a real fan of blindly following old performance rules, which where made for IE7. In fact loading 2 15kb js-files is a lot faster in modern browsers (including non-borwsers like IE8), than loading 1 30kb file.

In case of using a script loader, the advantage of loading a script dynamically from head is a lot better than loading it from the bottom. And sometimes loading a bunch of scripts from head is exactly what a developer wants.

@redoPop

This comment has been minimized.

Show comment
Hide comment
@redoPop

redoPop Sep 8, 2011

@aFarkas unfortunately, the shim technique needs to be applied before the browser starts rendering the document content, so a non-blocking loading technique (e.g., a script loader) would kill it. :(

redoPop commented Sep 8, 2011

@aFarkas unfortunately, the shim technique needs to be applied before the browser starts rendering the document content, so a non-blocking loading technique (e.g., a script loader) would kill it. :(

@dmethvin

This comment has been minimized.

Show comment
Hide comment
@dmethvin

dmethvin Sep 8, 2011

Member

This change, won't break anything, if a developer loads jQuery from the bottom.

But it also won't provide HTML5 support in that case. If everyone knew the details of what this is doing and knew how to use it, I think it would be perfectly fine. My worry is that the headline will be "OMG jQuery 1.7 supports HTML5!" and then we'll start getting bugs reported by people who don't load it in the head or who do some other HTML5ish work before jQuery can shim things.

Member

dmethvin commented Sep 8, 2011

This change, won't break anything, if a developer loads jQuery from the bottom.

But it also won't provide HTML5 support in that case. If everyone knew the details of what this is doing and knew how to use it, I think it would be perfectly fine. My worry is that the headline will be "OMG jQuery 1.7 supports HTML5!" and then we'll start getting bugs reported by people who don't load it in the head or who do some other HTML5ish work before jQuery can shim things.

@rwaldron

This comment has been minimized.

Show comment
Hide comment
@rwaldron

rwaldron Sep 8, 2011

Member

@aFarkas please be sure to review: http://bugs.jquery.com/ticket/6485 and note that @paulirish has updated the original ticket's description to clearly define the goals of the ticket:

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.

Note also that my pull request is very clear in this: HTML5 Support for innerHTML, clone & style - care was taken to omit "shim/shiv"

Member

rwaldron commented Sep 8, 2011

@aFarkas please be sure to review: http://bugs.jquery.com/ticket/6485 and note that @paulirish has updated the original ticket's description to clearly define the goals of the ticket:

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.

Note also that my pull request is very clear in this: HTML5 Support for innerHTML, clone & style - care was taken to omit "shim/shiv"

@redoPop

View changes

Show outdated Hide outdated src/manipulation.js
@paulirish

This comment has been minimized.

Show comment
Hide comment
@paulirish

paulirish Sep 8, 2011

Member

it's cool. afarkas is just pointing out jquery can optionally make the html5shiv redundant which would be a nice benefit.

as he's the primary author of the html5shiv, he's in a fair place to propose it. :)

I agree with Dave's assertion that we should be clear on what this fixes. Maybe something like...

jQuery will now successfully inject HTML5 sectioning elements into the page. Use Modernizr or html5shiv in the <head> if you use the HTML5 sectioning elements in the original markup of the page

Member

paulirish commented Sep 8, 2011

it's cool. afarkas is just pointing out jquery can optionally make the html5shiv redundant which would be a nice benefit.

as he's the primary author of the html5shiv, he's in a fair place to propose it. :)

I agree with Dave's assertion that we should be clear on what this fixes. Maybe something like...

jQuery will now successfully inject HTML5 sectioning elements into the page. Use Modernizr or html5shiv in the <head> if you use the HTML5 sectioning elements in the original markup of the page

@@ -626,6 +640,9 @@ jQuery.extend({
depth = wrap[0],
div = context.createElement("div");
// Append wrapper element to unknown element safe doc fragment
safeFragment.appendChild( div );

This comment has been minimized.

@redoPop

redoPop Sep 8, 2011

nice! but now that it's recycling the safeFragment, i noticed the div doesn't actually get removed. i don't think the div itself can be recycled, but around line 680 or so something like safeFragment.removeChild(div); should be added so we don't end up with a heap of used divs loitering around safeFrag.

@redoPop

redoPop Sep 8, 2011

nice! but now that it's recycling the safeFragment, i noticed the div doesn't actually get removed. i don't think the div itself can be recycled, but around line 680 or so something like safeFragment.removeChild(div); should be added so we don't end up with a heap of used divs loitering around safeFrag.

This comment has been minimized.

@redoPop

redoPop Sep 8, 2011

...actually, make that line 650 -- just after div's innerHTML is set: otherwise IE chokes on the depth fixing. :o

@redoPop

redoPop Sep 8, 2011

...actually, make that line 650 -- just after div's innerHTML is set: otherwise IE chokes on the depth fixing. :o

This comment has been minimized.

@rwaldron

rwaldron Sep 8, 2011

Member

Haha, yeah I was just coming back to leave a note that I had to move it higher. Patch en route

@rwaldron

rwaldron Sep 8, 2011

Member

Haha, yeah I was just coming back to leave a note that I had to move it higher. Patch en route

This comment has been minimized.

@rwaldron

rwaldron Sep 8, 2011

Member

Scratch that... I just ran this in IE6 and consistently crashed the browser 3 times in a row

@rwaldron

rwaldron Sep 8, 2011

Member

Scratch that... I just ran this in IE6 and consistently crashed the browser 3 times in a row

@redoPop

This comment has been minimized.

Show comment
Hide comment
@redoPop

redoPop Sep 8, 2011

The current script is definitely causing old-IE to recognize HTML5 elements, and apply styles based on class names, but for some reason the browser's still not picking up on CSS that uses tags as a selector. Haven't been able to work out why this is.

redoPop commented Sep 8, 2011

The current script is definitely causing old-IE to recognize HTML5 elements, and apply styles based on class names, but for some reason the browser's still not picking up on CSS that uses tags as a selector. Haven't been able to work out why this is.

@timmywil

This comment has been minimized.

Show comment
Hide comment
@timmywil

timmywil Sep 19, 2011

Member

Landed in commit 9ecdb24.

Member

timmywil commented Sep 19, 2011

Landed in commit 9ecdb24.

@timmywil timmywil closed this Sep 19, 2011

mescoda pushed a commit to mescoda/jquery that referenced this pull request Nov 4, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment