Opened 9 years ago

Closed 5 years ago

Last modified 5 years ago

#11808 closed enhancement (patchwelcome)

[patch] Fix dojo._toDom() to support HTML5 tags IE6-8

Reported by: Thomas Bachem Owned by: Eugene Lazutkin
Priority: high Milestone: 1.10
Component: HTML Version: 1.5
Keywords: Cc: James Burke, phiggins, bill, Adam Peller
Blocked By: Blocking:

Description

Internet Explorer has problems with dynamically created HTML5 tags, see http://jdbartlett.github.com/innershiv/.

I've implemented a workaround as inspired by innerShiv to dojo._toDom(), see attached patch file. Works for us in production use.

Attachments (6)

DojoToDom.patch (420 bytes) - added by Thomas Bachem 9 years ago.
html5shivTest.html (766 bytes) - added by dylan 9 years ago.
html5 innershiv test
DojoToDom-featuredetection.patch (537 bytes) - added by Thomas Bachem 9 years ago.
html5shivTest-dojoplace.html (728 bytes) - added by Thomas Bachem 9 years ago.
html5shiv.patch (1.0 KB) - added by dante 9 years ago.
first pass at featuretesting and shimming if ever needed. really only helps with DOM when using dojo-only apis.
DojoToDom-New.patch (1.1 KB) - added by Thomas Bachem 6 years ago.

Download all attachments as: .zip

Change History (66)

Changed 9 years ago by Thomas Bachem

Attachment: DojoToDom.patch added

comment:1 Changed 9 years ago by Eugene Lazutkin

Milestone: tbdfuture
Owner: changed from sjmiles to Eugene Lazutkin
Status: newassigned
Type: defectenhancement

comment:2 Changed 9 years ago by Thomas Bachem

I really see this rather as a defect than an enhancement - this basically breaks using any HTML5 tags in a Dojo-powered website.

comment:3 Changed 9 years ago by Eugene Lazutkin

Obviously your point of view is your own business, but we never claimed that dojo._toDom() (technically an internal undocumented function) supports new HTML5 tags, SVG, VML, XML or any other tags used in web browsers outside of the common HTML4 realm. Especially supporting them in browsers that do not support them, like Internet Explorer. So I see it as a questionable enhancement. ;-)

comment:4 Changed 9 years ago by Thomas Bachem

Although being an internal function, dojo._toDom() affects basic functions like dojo.place(), which is where we had this big issue.

Are you saying HTML5 support is not of urgency for the Dojo Toolkit? I mean we're not talking about all the buzz stuff around the "HTML5" universe but really just about the plain new markup elements with no extra functionality. So Dojo doesn't officially support markup containing "<header>", "<article>", "<details>" etc. elements? If not, this should really be an important goal for 1.6 in my eyes.

You managed working around zillions of much uglier bugs and shortcomings of Internet Explorer already - this is a breeze for you :)!

comment:5 in reply to:  4 Changed 9 years ago by Eugene Lazutkin

Replying to thomasbachem:

Are you saying HTML5 support is not of urgency for the Dojo Toolkit?

Read what I wrote, and read what you wrote above. Now think how it affects the classification of the ticket: defect vs. enhancement - it doesn't, does it?

I am sorry to say, but IMHO the whole rant above is nothing but a fine piece of demagoguery and posturing, which has *absolutely nothing* relevant to the problem at hand on all possible levels.

comment:6 Changed 9 years ago by Thomas Bachem

elazutkin, I'm on your side - we want to contribute to Dojo, not "posture". This is why every single of my tickets includes a patch. So far, using any HTML5 markup breaks Dojo in IE, which really is critical for any modern website from a practical point of view.

We do already have a sophisticated patch management in place for our custom Dojo build (unavoidably), so I'm really not having this discussion for our sake but for the other Dojo users.

Having this said, I accept that it's your decision to define these priorities.

comment:7 Changed 9 years ago by Thomas Bachem

And yes, you're right, it's probably an enhancement if Dojo never claimed to support anything other than HTML4. I'm just hoping this doesn't affect priority. Keep up the good work.

comment:8 Changed 9 years ago by Eugene Lazutkin

Replying to thomasbachem:

elazutkin, I'm on your side - we want to contribute to Dojo, not "posture".

Then please accept and do not interfere with our technical decisions, which do not affect the treatment of your ticket, but help us to organize our work. No need to resort to drama like "by questioning my judgment in the area of ticket classifications Dojo kills puppies, saws off unicorn's horns, defecates on rainbows, and sides with Hitler". No need for that, really.

comment:9 in reply to:  7 Changed 9 years ago by Eugene Lazutkin

Cc: James Burke added

Replying to thomasbachem:

And yes, you're right, it's probably an enhancement if Dojo never claimed to support anything other than HTML4. I'm just hoping this doesn't affect priority. Keep up the good work.

Thank you. I didn't see this comment when I answered to your previous comment.

My notes on the patch (extended version, short version was published elsewhere):

  1. Dojo decided to go the feature detection way. Your patch uses dojo.isIE. The feature detection branch tries hard to eliminate browser sniffing. I prefer to avoid adding more of that.
  2. There is no test case to demonstrate the problem and the fix.
  3. There is no qualification what versions of IE are affected. For example, is IE9 affected too? That's why the feature detection is preferred.
  4. I am not sure if it is a universally needed functionality. But if I add it to the base all users will pay a price. It is small, but nevertheless, we have to be vigilant.
  5. dojo._toDom() works fine in all browsers that support HTML5 tags. You can use it to create all tags you mentioned above in those browsers.

comment:10 Changed 9 years ago by Eugene Lazutkin

Cc: phiggins bill Adam Peller added

comment:11 Changed 9 years ago by bill

Probably we should do this for 1.6 since it seems like we are shooting for HTML5 compliance for 1.6, see the other HTML5 tickets.

I'm confused though, I tried the test below on IE6 (from the firebug lite console in dijit/tests/test_Dialog.html), and it seemed to work fine:

var s = document.createElement('div'); s.innerHTML = "<section>Hi!</section><p>here's a paragraph</p>"; document.body.appendChild(s);

I see "Hi" and "here's a paragraph" show up below the console. This works too:

dojo.place("<div><section>Hi!</section><p>here's a paragraph</p></div>", dojo.body())

IE developer toolbar shows the markup as all goofy (with a tag called </SECTION> rather than <SECTION>), but the same thing happens when appending the div to the document first, ex:

var div = dojo.create("div", {}, dojo.body());  div.innerHTML = "<section>Hi!</section><p>here's a paragraph</p>";

comment:12 Changed 9 years ago by Eugene Lazutkin

Heh. You, Bill, are clairvoyant or something. :-) From my email discussing this ticket --- debugger session in IE7 (IE8 is the same):

> zzz = dojo.create("div", null, dojo.body());
< div id="" />
> zzz.innerHTML = "<section>12345</section>"
<section>12345</section>
> zzz.innerHTML
12345</SECTION>
> zzz.children.length
1
> zzz.children[0].tagName
/SECTION
> zzz.outerHTML
<DIV>12345</SECTION></DIV>

The way to make it kinda work:

> qqq = document.createElement("section")
< section id="" />
> qqq.outerHTML
<?XML:NAMESPACE PREFIX = PUBLIC NS = "URN:COMPONENT" /><section></section>

Still it looks like a weird XML node rather HTML node.

comment:13 Changed 9 years ago by dylan

It's this goofy tag insertion that prevents a node from being properly styled. This is a well known bug in IE 6-8.

Let's please not attack someone who's passionate enough to contribute a patch, we're just encouraging them to go elsewhere.

Now, that said, the provided patch doesn't work with my attempted testcases in IE6 or IE8...

comment:14 Changed 9 years ago by Thomas Bachem

Thanks for digging into this guys! To make my simple patch work, you need to additionally add the basic html5shiv via

<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5-els.js"></script><![endif]-->

So integrating some sort of a Dojo-html5shiv is probably a dependency for this.

comment:15 Changed 9 years ago by Thomas Bachem

On the other hand we could just add a basic workaround to dojo._toDom() and leave it up to the user to include a html5shiv on their own if they really want to style HTML5 tags - which they would need anyway. I think adding HTML5 elements dynamically is Dojo's business, but having IE to accept HTML5 styles in general is not. Seems like a good compromise?

Changed 9 years ago by dylan

Attachment: html5shivTest.html added

html5 innershiv test

comment:16 Changed 9 years ago by dylan

Oh, ok, I've updated the test.

With regards to requiring a user to include a third-party script, that's not generally our approach because it's annoying and adds another step to optimize performance.

I could ask @rem if he's willing to contribute it under the Dojo CLA. It's such a small script that it's easy to create on our own if necessary.

Finally, for your patch, is there a feature we can detect here rather than an IE version?

comment:17 Changed 9 years ago by dante

I added a test to has.js: http://github.com/phiggins42/has.js/commit/bac51ad424bc4820b55c863725e539279728a35c

The firstChild.nodeType is being reported as a textnode before shivving. This doesn't test style application, but would love to see if those couple tests/etc prove adequate for a "standalone" html5-shiv and fix (eg: do style properties end up being processed)

comment:18 Changed 9 years ago by Thomas Bachem

Actually, there really is a "feature-dection" way: http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-explaining-quot-jscript-version-quot-and-styling-new-html5-elements.aspx.

I've attached another patch do utilize this, although I'm not sure whether this causes too much overhead for unaffected browsers. The patch will need some improvement to work with the "tagWrap" part too.

I've also added a corrected test case that uses dojo.place(), because the original testcase is using dojo.create() which doesn't use dojo._toDom() with a HTML string supplied and works fine with just html5shiv loaded.

Changed 9 years ago by Thomas Bachem

Changed 9 years ago by Thomas Bachem

comment:19 Changed 9 years ago by dante

fun. So that blog article basically vindicates my test, too. I am checking for the textnode that appears as a side effect of buggy browser. everyone else reports childNodes.length as 1, whereas it's two textNodes in buggy. I can adjust the has() test for this. If you can make that test a one-time cost (like has()) I'd be okay with it in core immediately. perhaps even explicit, like:

dojo.htmlShiv = function(){ if(featureTestForHtmlOnce()){ dotheshiv(); }); 

at that point, nothing in dojo.place() should need to be touched, as the elements will "just work"

comment:20 Changed 9 years ago by bill

It's a pretty short bug detection test, although I don't see any advantage over dojo.isIE < 9.

Looks like there are two possible shivs, one in http://blogs.msdn.com/b/ie/archive/2010/06/10/same-markup-explaining-quot-jscript-version-quot-and-styling-new-html5-elements.aspx and the other in http://html5shiv.googlecode.com?

comment:21 in reply to:  18 Changed 9 years ago by Eugene Lazutkin

Replying to thomasbachem:

I've attached another patch do utilize this, although I'm not sure whether this causes too much overhead for unaffected browsers. The patch will need some improvement to work with the "tagWrap" part too.

Is it possible to detect the feature in the patch once, instead of doing it on every dojo._toDom()? Or is it the provision to add html5shiv script dynamically?

comment:22 Changed 9 years ago by dante

Bill - as appealing as your isIE < 9 solution may seem it's the wrong decision moving forward. The test takes literally < 1ms to run, is a tiny byte overhead and is futureishproof.

uhop - Yes, it is entirely possible to detect the patch once, but I'd personally prefer to not even take the 1ms hit until it's actually used. The real question is do we use the shiv after detecting the bug (in base) or make a module that says explicitly "include this module if you want/care about html5 elements + IE"

I would argue there is no need for a CLA on the shiv, as the issue is documented and explained clearly in the msdn blog.

Changed 9 years ago by dante

Attachment: html5shiv.patch added

first pass at featuretesting and shimming if ever needed. really only helps with DOM when using dojo-only apis.

comment:23 in reply to:  22 Changed 9 years ago by Eugene Lazutkin

Replying to dante:

I would argue there is no need for a CLA on the shiv, as the issue is documented and explained clearly in the msdn blog.

I came to the same conclusion using different reasoning. :-) Besides I use something like that in vml.js for a long time now.

With your recent patch --- do we still need a 3rd-party script to be loaded?

For the future: we need to collect pieces like that for the IE-only legacy overlay, so we can rid the base from most of the legacy stuff.

comment:24 Changed 9 years ago by John Hann

If we decide to go with a shim (aka shiv) that fixes all possible HTML5 tags at once, I posted a few variations I had been playing with up on jsperf.com: http://jsperf.com/shivs-sic/6

@elazutkin All I can say is W T F? Way to embrace and engage the dojo community. thomasbachem is obviously just trying to help out.

Also, since we're embracing HTML5 in other ways (data-*, for instance), we should absolutely embrace the new semantic tags. Even if you don't consider this to be a bug, the rest of the world will see it as such.

comment:25 Changed 9 years ago by John Hann

Ha. dante beat me to it with a shim/shiv. I was gonna suggest we make the list of elements configurable, but it seems to run fast enough. So nm.

comment:26 in reply to:  24 Changed 9 years ago by Eugene Lazutkin

Replying to unscriptable:

@elazutkin All I can say is W T F? Way to embrace and engage the dojo community. thomasbachem is obviously just trying to help out.

Sorry about that. Somehow I just don't like when "type changed from defect to enhancement" is suddenly read as "Are you saying HTML5 support is not of urgency for the Dojo Toolkit?". I guess I am weird this way. You can reduce my salary for that. ;-)

Guys, if you don't like what I said and want to talk about it let's move "the talk about me" to a mailing list and keep the trac to purely technical stuff. Yes I am guilty at polluting this ticket with two emotional comment, but it is never too late to stop and be more constructive.

comment:27 in reply to:  22 ; Changed 9 years ago by bill

Replying to dante:

Bill - as appealing as your isIE < 9 solution may seem it's the wrong decision moving forward. The test takes literally < 1ms to run, is a tiny byte overhead and is futureishproof.

"futureproof" meaning what exactly? If IE10 reintroduces the bugs from IE6?

comment:28 in reply to:  27 ; Changed 9 years ago by dante

Replying to bill:

"futureproof" meaning what exactly? If IE10 reintroduces the bugs from IE6?

exactly. Or they do something like mozilla did with FF 3.1, where it shipped with a UA saying 2.x.something ... better to test what is actually going on rather than deferring to dojo.isIE < 9 as an actual foundation for more stuff. Or perhaps other browsers that may or may not yet exist display similar or identical behavior. Insta-fix.

@unscriptable vs uhop - I think it was just a communication error. Eugene loves contrib as much as the rest of us. I wouldn't think any more of it, as "it" isn't an issue. Sorry if thomas feel's snubbed or anything, clearly wasn't the intent. Let's move on. agree on keeping trac limited to technical discussions.

comment:29 Changed 9 years ago by Eugene Lazutkin

Milestone: future1.6

Obviously I didn't mean to snub anybody, and yes, I love when contributors filing bugs *and* attach patches. All I wanted to say was that there is no need to read too much into bureaucratic classification of tickets, and obviously miscommunicated. Sorry about that.

On the up side :-) we got a major involvement of contributors and committers alike resulting in well-discussed topics (HTML5, FD, general policy towards IE) and an excellent patch. Kudos to everybody participated!

comment:30 in reply to:  28 ; Changed 9 years ago by bill

Replying to dante:

Replying to bill:

"futureproof" meaning what exactly? If IE10 reintroduces the bugs from IE6?

exactly. Or they do something like mozilla did with FF 3.1, where it shipped with a UA saying 2.x.something ... better to test what is actually going on rather than deferring to dojo.isIE < 9 as an actual foundation for more stuff. Or perhaps other browsers that may or may not yet exist display similar or identical behavior. Insta-fix.

OK. It sounds farfetched that a new browser version (or new browser) would reintroduce an old IE bug/limitation, and that the same workaround code would still work. I wouldn't spend any lines of code safeguarding for that, especially in consideration of mobile.

The typical problem (about browser bugs) is when new version fixes a bug but our code is still expecting it to be there. That's when feature detection buys us something. Although it's not a cure-all, we still need to do some work to support new browsers, since they sometimes have new bugs (ex: #11279).

Note that if you wanted to take your idea to it's extreme we could reintroduce all the special code paths we removed for FF2 and safari3 (#4614, #10816, #11634, etc.)

About the FF 3.1 UA sniffing problem, I haven't heard of that one before, presumably it's fixed now since dojo (which still has version detection branches) runs correctly on FF3.1/3.5.

comment:31 in reply to:  30 Changed 9 years ago by dante

Replying to bill:

Replying to dante:

Replying to bill:

"futureproof" meaning what exactly? If IE10 reintroduces the bugs from IE6?

exactly. Or they do something like mozilla did with FF 3.1, where it shipped with a UA saying 2.x.something ... better to test what is actually going on rather than deferring to dojo.isIE < 9 as an actual foundation for more stuff. Or perhaps other browsers that may or may not yet exist display similar or identical behavior. Insta-fix.

OK. It sounds farfetched that a new browser version (or new browser) would reintroduce an old IE bug/limitation, and that the same workaround code would still work. I wouldn't spend any lines of code safeguarding for that, especially in consideration of mobile.

it is a bit far fetched, but entirely possible. The one "real" mobile build we have, as seen by my patch, is for webkitMobile -- which is there but admittedly inadequate.

The typical problem (about browser bugs) is when new version fixes a bug but our code is still expecting it to be there. That's when feature detection buys us something. Although it's not a cure-all, we still need to do some work to support new browsers, since they sometimes have new bugs (ex: #11279).

exactly.

Note that if you wanted to take your idea to it's extreme we could reintroduce all the special code paths we removed for FF2 and safari3 (#4614, #10816, #11634, etc.)

that's unnecessary as we've consciously decided not to support _those_ browsers based on market share and the upgrade frequency of the users. When we discover new browser bugs and determine adequate tests for them we can drop support based on specific bugs that exist. By logging the has.js results for instance we can do "super advanced browser sniffing" by seeing in which browsers these bugs exist. When the time comes to drop IE6 support, we'll have a big chart of bugs listed and branches in code that we can simply remove. This also applies to "platform specific builds" where you can consciously drop IEx support without fear of inadvertantly reintroducing a bug that may appear in another browser.

About the FF 3.1 UA sniffing problem, I haven't heard of that one before, presumably it's fixed now since dojo (which still has version detection branches) runs correctly on FF3.1/3.5.

fwiw, It was fixed before the version went final, but the point is we all upgraded to ff 3.x beta/alpha to test for the next version and got lots of errors, which turned out to be a misreported UA string from FF. When the next update came out it was all 'fixed' again, but not without the lost cycles of us rummaging around trying to determine where we'd gone wrong. The value of FT/FD is in that once you've tested it and put the branching in place you theoretically never have to think about it again.

On an aside, Pete LePage? (of IE team) did a talk at jsconf.eu this year pleading we "just give IE9 the same code you give the rest of the browsers", specifically regarding addEventListener/attachEvent. Rather than rely on isIE < 9, we should simply give anyone who passes a basic test for addEvent/attachEvent the appropriate code regardless of version. If we had been doing this, when ie9 came out the workload would be closer to 0 than having to double-check a lot of dojo.isIE < 8's and bumping the version one.

comment:32 Changed 9 years ago by Eugene Lazutkin

It would be really nice to have a battery of FD tests (as part of has.js?) as one file, which we can run on all target browsers, and be able to select only those tests that differ on any of supported browsers. This way we can clean up irrelevant tests from our codebase either statically or during the build. Otherwise we are going to grow the codebase forever.

comment:33 Changed 8 years ago by bill

Milestone: 1.61.7

comment:34 Changed 8 years ago by Chris Mitchell

Is this ticket now covered by the has() feature in 1.7?

comment:35 Changed 8 years ago by Eugene Lazutkin

To all stakeholders of this ticket: are we OK with increasing the Base size with this patch? Or should we rework it as a Core add-on? Does the current work on the AMD loader require to redo the patch in favor of "has" techniques?

Thoughts or comments?

comment:36 in reply to:  35 Changed 7 years ago by Eugene Lazutkin

Replying to elazutkin:

To all stakeholders of this ticket: are we OK with increasing the Base size with this patch? Or should we rework it as a Core add-on? Does the current work on the AMD loader require to redo the patch in favor of "has" techniques?

Thoughts or comments?

Ping. Are we all in favor to commit the patch? My only concern is it increases the base by 1k (several hundred bytes when minified). Pete? Bill? James?

comment:37 Changed 7 years ago by bill

Summary: [patch] Fix dojo._toDom() to support HTML5 tags in Internet Explorer[patch] Fix dojo._toDom() to support HTML5 tags IE6-8

I guess we are talking about html5shiv.patch?

First of all, I checked and unfortunately this bug still happens in IE8. It's fixed in IE9, unless your page is in quirks mode. (I tried running dojo.body().appendChild(dojo._toDom(<section>hi</section>")) from the console.)

You'd want to redo the patch using has.add() and has(), and not using the >>excludeStart("webkitMobile", kwArgs.webkitMobile); pragmas that I removed a few months ago. Then at least the extra code could be filtered out for browser specific builds... but it would still be there in general.

It's a toss-up. I guess I would add the code.

comment:38 Changed 7 years ago by bill

See also #15079, which shows another person wanting this feature.

comment:39 Changed 7 years ago by Colin Snover

Milestone: 1.82.0

1.8 is frozen. Move all enhancements to next release. If you need an exemption from the freeze for this ticket, contact me immediately.

comment:40 Changed 6 years ago by dylan

Ok, we need to decide on this one for 1.9.

2.0 isn't going to support IE6-8.

It's a small patch, it's unlikely to fix all edge cases, but if it fixes some of the common cases, perhaps it's useful.

I'll be honest, the new HTML5 tags in IE6-8 doesn't seem 100% useful to me, but if this patch solves the common use case and doesn't break other things, I'm ok with seeing it in core for 1.9.

comment:41 Changed 6 years ago by dylan

Milestone: 2.01.9

comment:42 Changed 6 years ago by Eugene Lazutkin

Some of HTML5 elements make no sense on IE, like audio, canvas, video, and some others, yet I'll commit it using Pete's patch as a foundation.

comment:43 Changed 6 years ago by Eugene Lazutkin

Resolution: fixed
Status: assignedclosed

In [30983]:

dom-construct: added HTML5 patch for IE6-8 browsers, !strict, fixes #11808.

comment:44 Changed 6 years ago by dylan

I'm glad to see this one land. Just curious, any reason to use sniffing over feature detection here?

comment:45 Changed 6 years ago by Eugene Lazutkin

Easier to remove when we drop IE <= 8.

comment:46 Changed 6 years ago by bill

Resolution: fixed
Status: closedreopened

This patch doesn't work. I get an exception, for example, when running dijit/tests/_base/popup.html on IE8. The new code is accessing a non-existant variable called "d". Historically d is dojo, and it looks like it's supposed to be dojo for the line:

var div = d.create('div', { innerHTML:"<nav>a</nav>"}); 

which should presumably be changed to just:

var div = create('div', { innerHTML:"<nav>a</nav>"}); 

But then the weird thing is the reference to "d" a few lines down, which I guess should be document??

d.createElement(n);

comment:47 Changed 6 years ago by Eugene Lazutkin

Resolution: fixed
Status: reopenedclosed

In [31015]:

Fixed the ancient patch, !strict, fixes #11808.

comment:48 Changed 6 years ago by Thomas Bachem

Guys, your patch does NOT fix the issue I was talking about. You implemented merely a general HTML5 shiv, but I was refering to INNER shiv as that's an IE < 9 bug regarding the use of innerHTML.

dojo.toDom() does still return a DocumentFragment? instead of a DOMElement if I do e.g. dojo.toDom('<section>...</section>');. jQuery has a good documentation on all three kinds of bugs around HTML5 in IE < 9: http://bugs.jquery.com/ticket/6485.

Luckily, we can patch the patch with minor adjustments. I did it mostly like jQuery (https://github.com/jquery/jquery/commit/9ecdb2472be7661477564e46bce51432d4a5a84e), you'll find it attached.

comment:49 Changed 6 years ago by Thomas Bachem

Oh and the two-line string thing didn't work properly, so only tags from the second line were recognized. We need to add braces. I updated my patch accordingly.

Changed 6 years ago by Thomas Bachem

Attachment: DojoToDom-New.patch added

comment:50 in reply to:  49 Changed 6 years ago by Eugene Lazutkin

Resolution: fixed
Status: closedreopened

Replying to thomasbachem:

Oh and the two-line string thing didn't work properly, so only tags from the second line were recognized. We need to add braces. I updated my patch accordingly.

Are you 100% sure that your last patch works?

if(has("ie") <= 8){
  doc = doc.createDocumentFragment();
  html5domfix(doc);
  doc.appendChild(masterNode[masterId]);
}

In the patch (above) you redefine a document as a document fragment, call html5domfix(), which creates a bunch of elements with this document fragment, but never attaches them anywhere, then move masterNode from its document into the document fragment, which is still unattached, and not going to be attached anywhere. Later the same document fragment and its masterNode is used to produce new nodes. Is this a correct behavior?

comment:51 Changed 6 years ago by Thomas Bachem

Yes, strangely that works. I stumbled upon this bug again today, so I could test it properly. html5shivTest-dojoplace.html should still work as a test.

Last edited 6 years ago by Thomas Bachem (previous) (diff)

comment:52 Changed 6 years ago by Eugene Lazutkin

In [31372]:

Fixed the obvious typo, thx thomasbachem, the whole affair is still not done yet, will be fixed in a point release later, !strict, refs #11808.

comment:53 Changed 6 years ago by bill

Milestone: 1.91.9.1

comment:54 Changed 6 years ago by Thomas Bachem

Ok, I recommend reading the stuff in the jQuery ticket, especially http://pastie.org/935834.

comment:55 Changed 6 years ago by Colin Snover

Milestone: 1.9.11.9.2

1.9.1 is released; moving all outstanding tickets to next milestone.

comment:56 Changed 6 years ago by Colin Snover

Milestone: 1.9.21.10

Please resubmit any functioning patch as a pull request on GitHub? if you’d still like this enhancement.

comment:57 Changed 5 years ago by Eugene Lazutkin

Do we really need it? I worry about price/performance --- quite a few extra bytes for a questionable return + it doesn't come free CPU-wise during a critical initialization phase.

Personally I don't need this functionality in my projects. Is there any interest in 2011 to support obsolete browsers?

comment:58 Changed 5 years ago by bill

Is there any interest in 2011 to support obsolete browsers?

Not much interest... since there's no automated test case and the patch hasn't been moved to git, I'd say to just close this.

I worry about price/performance

The latest patch isn't changing the code size much, but the weird thing is that it re-fixes the document on every call to toDom(). I don't understand why the patch is needed. What's wrong with the doc.__dojo_html5_tested flag that's there today?

comment:59 Changed 5 years ago by dylan

Resolution: patchwelcome
Status: reopenedclosed

This is a very long-lived ticket that has never quite made its way into production out of concern for the possible performance impact, and limited gain because IE8 is near its end of life.

We do understand that some people still need to support IE8 and want to use HTML5 semantic markup. As such, we will consider this patch again if you want to make a pull request where this functionality is opt-in, via some has() flag, ex:

if(has(“ie8-html5-some-better-name-hopefully”)

then we could consider it. But again, the PR would need to be submitted on github and more importantly contain an automated test case so we could test that it doesn't introduce any regressions, and so we can measure the performance.

I appreciate that this would be the third time this would be updated, but if you do the following, I will look at it as soon as the above has been handled. Thanks for your years of patience on this one.

comment:60 Changed 5 years ago by bill

#18192 is a duplicate of this ticket.

Note: See TracTickets for help on using tickets.