So we aren't using your lovely module and theme on a project of ours, because I heard about it after we'd started development. One issue we've come across is that any HTML5 tags that gets added via AJAX in IE6/7/8 will not get processed by modernizer, so they are unable to be styled it seems.

There are details of this issue here:
http://jdbartlett.github.com/innershiv/

Seems like a possible solution would be to swap out the core ajax methods to use this script, or fix jquery directly somehow.

CommentFileSizeAuthor
#11 1180142-10-innerShiv-prefixed.patch4.15 KBseutje
#10 1180142-10-innerShiv.patch4.14 KBseutje

Comments

steven jones’s picture

steven jones commented

To clarify further, this only occurs if you parse a HTML5 fragment outside of the document's DOM, e.g.:

$myvar = $('<section>Some section</section>');
$('body').append($myvar);
steven jones’s picture

steven jones commented
Status: Active » Needs work

So we (now) have some code that replaces the insert method with a version that supports HTML5 in IE 6/7/8:

I really don't have time for a patch, but here's what we're doing.

(function ($) {
/**
 * @file
 *   Fixes for Drupal's AJAX framework in HTML5.
 *
 *   In IE 6/7/8 document fragments parsed outside of the Documents DOM context
 *   will not have any of the additional HTML5 elements processed properly by
 *   the HTML5 IE shiv. So we need to pass the returned data through the
 *   innerShiv function as detailed here:
 *   http://jdbartlett.github.com/innershiv/
 */

(function (old_insert_command) {
  Drupal.ajax.prototype.commands.insert = function (ajax, response, status) {
    // Allow IE 6/7/8 to process the HTML5 elements in the response, this should
    // be a no-op for other browsers.
    response.data = innerShiv(response.data, false);
    old_insert_command(ajax, response, status);
  }
})(Drupal.ajax.prototype.commands.insert);


})(jQuery);


// http://jdbartlett.github.com/innershiv | WTFPL License
window.innerShiv = (function() {
	var d, r;

	return function(h, u) {
		if (!d) {
			d = document.createElement('div');
			r = document.createDocumentFragment();
			/*@cc_on d.style.display = 'none';@*/
		}

		var e = d.cloneNode(true);
		/*@cc_on document.body.appendChild(e);@*/
		e.innerHTML = h.replace(/^\s\s*/, '').replace(/\s\s*$/, '');
		/*@cc_on document.body.removeChild(e);@*/

		if (u === false) return e.childNodes;

		var f = r.cloneNode(true), i = e.childNodes.length;
		while (i--) f.appendChild(e.firstChild);

		return f;
	}
}());
ericduran’s picture

ericduran commented

Hmm, Make sense,

Maybe we should also include the innershiv js.

I think now that there's a html5 d8 initiative we should pretty much back-port everything to this module.

Also this might be a good d8 issue.

stevetweeddale’s picture

stevetweeddale commented

I might try and make a patch for html5 base to do this for d7. Or should this code live in html5tools? Not totally clear where the between them is on this.

And depending on the outcome of #1077878: Add HTML5shiv to core there may need to be a d8 core issue for it as well.

jide’s picture

jide commented
Issue tags: +html5

Since we use JQuery in Drupal, we could safely remove the second parameter and return childNodes directly.
The WTFPL license is problematic, we should see if the author is likely to change the license if we use this technique.
A jQuery method that behaves like load() is also mentioned : https://gist.github.com/735829.

stevetweeddale’s picture

stevetweeddale commented

You've gotta enjoy the irony if there are indeed licensing issues. Does the WTFPL not mean we can just include it without attribution and under whatever license modules fall under?

"If you do not like the license terms, just relicense [sic] the work under another license." ...taken from the wtfpl license page

ericduran’s picture

ericduran commented

We could use that plugin. We'll just need to remove the license

ericduran’s picture

ericduran commented

Also tools seems more appropriate that base.

jide’s picture

jide commented

Hehe, did not take the time to check the WTFPL license terms :)

seutje’s picture

seutje commented
Status: Needs work » Needs review
StatusFileSize
new 1180142-10-innerShiv.patch4.14 KB

There seems to be a more advanced version of the innerShiv, which also strips script tags, fixes tables, handles XHTML properly and stuff...

the newer version also bails early on when it detects the browser to be able to render HTML5 elements created outside of the active DOM.

Attached patch assumes patch #82 in #1077878: Add HTML5shiv to core went in

seutje’s picture

seutje commented
StatusFileSize
new 1180142-10-innerShiv-prefixed.patch4.15 KB

just found out we are using prefixed patches nowadays, my apologies

inolen’s picture

inolen commented

seutje: If you add the monkey patch into html5.js, you need to ensure that html5.js it loaded after ajax.js:


  $libraries['html5shim'] = array(
    'title' => 'html5shim',
    'website' => 'http://html5shim.googlecode.com/svn/trunk/html5.js',
    'version' => 'r10',
    'js' => array(
      'misc/html5.js' => array('group' => JS_LIBRARY, 'weight' => 3),
    ),
    'dependencies' => array(
      array('system', 'drupal.ajax'),
    ),
  );
ericduran’s picture

ericduran commented

We shouldn't be patching the html5.js file being that this is for d7, we should include our own html5.js in tools instead.

Mind you tools is for 6 and 7. Not so much for 8 ;)

ericduran’s picture

ericduran commented
Status: Needs review » Needs work
seutje’s picture

seutje commented

oh, my bad

bleen’s picture

bleen commented

dont forget if we cinlude our own html5.js we will likely need to make sure the core version isnt also loaded.

ericduran’s picture

ericduran commented

We don't really need to include a html5_tools specific js.

The scripts each have their own names they should stay that way.

We just need to provide the hook_libraries for the scripts.

Also if the html5.js makes it into core it'll be sometime before it gets in 7. Also I doubt there actually be a specific file name html5.js I think thats bad naming and we shouldn't name it that neither ;)

inolen’s picture

inolen commented

So, instead of monkey patching, I patched my local ajax.js to have the same fix by adding:

    response.data = innerShiv(response.data, false);

at the very top of Drupal.ajax.prototype.commands.insert, however, when using innerShiv this broke the AJAX framework when it attempts to insert scripts, because innerShiv strips out

tags. For now I've modified innerShiv to simply not strip them out (source available at https://github.com/jdbartlett/innershiv), but I'm sure it strips them out/doesn't process them for a good reason, so I doubt this is a good solution.
ericduran’s picture

ericduran commented

This is possible without hacking core.

seutje’s picture

seutje commented

@inolen: https://github.com/jdbartlett/innershiv/issues/4#issuecomment-1051825

ericduran’s picture

ericduran commented

Ok, so the shiv is in this module for 7.x now we need to do the innershiv. I'm not totally sure on this one.

Any recommendations?

ericduran’s picture

ericduran commented
Status: Needs work » Fixed

Ok, this is now fixed. I just monkey patch it as @seutje did.

So now the shiv and the innershiv are easily accesible in this module.

Thanks all.

Automatically closed -- issue fixed for 2 weeks with no activity.