Problem/Motivation

Older browsers that are still widely used by end users (namely IE6/7/8) do not have support for the new elements in HTML5. Now that we decided to go HTML5 for D8, it would be nice if Drupal played nice with those browsers too.

Proposed resolution

One great way to enable HTML5 element support in IE6/7/8 is to have the http://code.google.com/p/html5shiv/ added to Drupal core. This is a very small script that allows people to use the new HTML5 elements such as section, article, header, footer and so on.

Reasons for html5shiv as a candidate for inclusion:

1. To allow us to use all the new HTML5 elements in D8
2. Support contrib HTML5 themes out of the box without them having to pull the script from google code, which almost all D7 HTML5 themes are currently doing.

Related issues/articles/projects:

HTML5 @ Community & Support
HTML5 in Drupal 8 by Dries Buytaert
Drupal 8 HTML5 Initiative by Jacine Luisi
HTML5 @ g.d.o
DrupalCon Core Conversation: HTML5 + Drupal 8

#963832: Decide how to use HTML5 in Drupal 8
#1077356: HTML5 in core battle plan
#1256132: Add innerShiv to core (after HTML5shiv is in) (might be redundant if jQuery 1.7 or latest gets in core - see more about it bellow)

#474684: Allow themes to declare dependencies on modules (which might allow having this -or any other polyfill- as a separate core module that people can enable/disable as required)

#865536: drupal_add_js() is missing the 'browsers' option tries to tackle conditional loading of js. This will in turn allow this or any other polyfill we choose to be loaded only when required (IOW when browser = IE6/7/8).

modernizr as an alternative polyfill

People mentioned/suggested using Modernizr as an alternative polyfill. There's a contrib project with a D6 and a D7 version available. Its 7.x-3.x branch allows #1278504: Call Modernizr.load() from theme .info files. Jacine provides a comparison between the two polyfills in #73.

HTML5 element support & jQuery

jQuery seems to aim to add HTML5 element support in its upcoming 1.7 version:

1. Events rewrite (unifying bind/live/delegate, fixing bubbling)
2. HTML5 element support

...their roadmap doesn't clarify though whether they actually mean that they will allow older browsers to support HTML5 elements (what html5shiv/modernizr do) or if they simply mean to support HTML5 elements selection *if* the browser already supports their rendering. With regards to that, there's this bug in jQuery's issue queue we should be keeping an eye on.

Update on latest news regarding jQuery 1.7 and its HTML5 support:
The bug mentioned above is currently marked as "fixed" for 1.7. In this article it is mentioned that:

jQuery 1.7 won't come with it's own built-in HTML5 shivs (you'll still have to load in a shiv of choice into the document head), but it will address two important issues previous releases have suffered:

1) In jQuery 1.6.4 and below, HTML5 elements were not supported with innerHTML but this is rectified with the newest release. HTML5 elements now added with any methods using innerHTML under the hood are added to a successfully shim'd document or document fragment as one would expect.

2) HTML5 elements being cloned (when an element is cloneNode'd) will now use an alternative approach to cloning which supports cloning HTML5 elements cross browser.

Remaining tasks

html5shiv is MIT licensed, so we either need an exception to be included or request developers to dual-license it under GPL as well. It is now dual-licensed under GPL v2 after Jacine took care of contacting the developers a bout it (see #68 and #69).

#139 has a patch. This issue is no longer postponed because of the drupal_add_js issue with no support for the browser options (thats been fixed).

User interface changes

None

API changes

None

Original report by Jeff Burnz

[...original text is (mostly unchanged) included in the issue summary - just split and placed in the appropriate sections, so omitted here in order to keep the summary as short as possible...]

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Mark Trapp’s picture

What's the solution for no-js?

Jeff Burnz’s picture

I assume you mean whats the solution for IE when using unsupported elements and JS is off? There are two options here - we could wrap the semantic elements around inner DIV's, but that seems rather verbose and somewhat defeating the purpose of having the shiv in the first place, however relying on DIV/html4 for layout (in core) could have a use case here. The other is that if you really need to support IE6/7/8 with no-js you have the option to build themes that do just that.

Mark Trapp’s picture

If there is no no-js fallback, shouldn't the topic of adding the shiv to core be dependent on a move to requiring JavaScript? That's not the case with Drupal 7. I've created an issue for this: #1077960: Require JavaScript.

But if we're going to entertain the idea that core should only use HTML4-compatible markup for legacy compatibility, why bother including the shiv in core at all? Why not keep the status quo of having themes include it if they want to write HTML5 themes? It would avoid the licensing issue and any issues with no-js compatibility.

Jeff Burnz’s picture

"If there is no no-js fallback, shouldn't the topic of adding the shiv to core be dependent on a move to requiring JavaScript?"

Not sure Mark, its a debate that needs to happen. The reality is there are tens of thousands of sites running HTML5 with the shiv, myself I have over 1500 right now, I don't have any issues posted by IE users with no-js, so I am not experiencing this issue in a real world application of HTML5 in Drupal.

Jeff Burnz’s picture

I think I need to answer this more fully because I think my explanation regarding HTML4 for layout is not clear, let me give a quick code example of what I mean:

<article>
  <div class="presentation">...</div>
</article>

In this example the article element is not used for presentation, in other words no CSS is applied to it such as layout, borders, background etc etc - all those are applied to the div so article is just a semantic wrapper.

So why do this?
1. Its backwards compatible (degrades gracefully) and does not require any JS support.
2. We get the benefits of the new elements such as enriched semantics, accessibility improvements and so on.

Why not do this?
1. Its verbose, and probably fragile at some point.
2. Its not the current best practice, the best practice is to use JS.

I punt for the latter because afaict the number of IE/no-js users is small and decreasing, in other words when I weight up the cost/benefit this falls on the side of using the shiv - the accessibility benefits alone outweigh the small number of adversely affected users.

Jeff Burnz’s picture

Mark, I've been thinking about this for the past week or so and I'm tending to move more towards your way of thinking on this.

It will be two years before D8 is out and things are going to change an lot in that time. For now I would propose that if we change Bartik to HTML5 (which we will) then we add the shiv to Bartik or any other core theme that needs it, however we do not add it to core html.tpl.php, we leave that alone and themers can add it if they want to support browsers that need it.

Mark Trapp’s picture

I think that's probably the best way to go. I finally got a chance to watch Dries's keynote, and I think keeping the shiv out of core output keeps with the idea of making Drupal not just markup agnostic, but output agnostic.

One of the things we need to keep in mind is that while we might have to support legacy browsers in core, themers might want to forgo its use not because they want to use HTML4, but because HTML5 will likely achieve Candidate Recommendation status around the time Drupal 8 launches, paving the way for people who don't have the need to support legacy browsers to write pure HTML5 themes. If I want to write a site that only targets modern/HTML5 browsers, I should be able to without unsetting stuff like the shiv because Drupal assumes I want to support IE6-8.

To that end, I like the idea of relegating certain JS libraries to themes that need them rather than sticking them in misc/ just because a core theme needs it. If Bartik is going to be HTML5 and needs to support IE7 and 8, the shiv makes sense and if I don't want to use a shived theme, I can just not use Bartik.

As corollary to this, Seven (or whatever admin theme Drupal 8 will have) should be shiv independent: people can replace the admin theme, but most people are going to want to use the default unmodified due to the cost of having to create two custom themes, one of which will only be seen by a very small set of users.

Jeff Burnz’s picture

Very good round up of the overall discussion. So I think we have some good points we can nail down there:

1. Don't add shiv to core.
2. Only themes that require the shiv should add it.
3. We need an exception to accept MIT licensed code.

The point you made in the other thread about keeping Drupal output agnostic is what I have been considering, this is a very good point and based on that argument alone I back these points.

scor’s picture

subscribe

droplet’s picture

That's good. we can have a simple way to enable it when use HTML5 new tags in Drupal.

I'm not sure if it have a clear confirmed will be use new HTML5 element in D8 ? and enabled by default ?

no-js isn't a problem, in real world everyone enabled it!!

klonos’s picture

...subscribing.

klonos’s picture

Issue tags: +html5

+ adding tag ;)

Jeff Burnz’s picture

As a proof of concept I make a simple theme that uses polyfil markup instead of the shiv: http://drupal.org/sandbox/jmburnz/1096046

This actually works pretty well, beware this theme is not exactly pretty, its actually quite rough but shows this can be done.

dcrocks’s picture

And there are other choices out there, such as modernizr, which has shiv built into it. If a backward compatibility enabler is added to core, it might not be shiv. IE is not the only issue as opera, webkit, and firefox all vary in their support of html5/css3 and modernizr gives feature based control instead of browser based.

sreynen’s picture

What's the solution for no-js?

I'd like to suggest another answer to this question: there's not really a problem here, just something that could be improved.

The improvement of html5shiv is causing CSS to apply to HTML5 elements in old IE, where it doesn't by default. The elements still render, you just can't style them. The result of this is sites look different in different browsers. They still work, they just don't look as good. We already have CSS rendering variance in XHTML 1, and it's not a problem.

What does change with the introduction of HTML5 elements is sites look more different in some browsers, namely old IE. And html5shiv reverses this somewhat by making sites look more different in fewer browsers, namely old IE with JS. That's an improvement, not a solution. Solutions require no-js alternatives, because without them, we still have the problem. Improvements, on the other hand, do not demand no-js alternatives, because it's okay if sites work a little better in better browsers.

Jeff Burnz’s picture

That might be the case for things that look a little bit different, however many of the new elements are sectioning elements (aka block level) and can be used for layout, so in effect the page does not degrade gracefully, but rather smashes to pieces.

There's only three options here 1) poly fill with DIV and use those as layout hooks or 2) drop support for IE6/7/8 or 3) don't use these elements in core.

I am leaning towards 3. Main reason for me is that I'm not convinced making structural assumptions to the extent that we can with HTML5 is harmonious with the aims of a very generic application.

Everett Zufelt’s picture

@Jeff

Can you give an example of where you see the use of certain html5 sectioning elements being a problem in Core?

Jeff Burnz’s picture

@Everett

For example blocks. A block is a generic container for content used for positioning content somewhere on the screen. The current block wrapper is DIV. In HTML5 they might be section, aside, nav or even article - however we have very few ways of knowing what a blocks content is, where its being displayed or what the structural requirements are (what outline is wanted or needed). It would be somewhat foolish in core to assume that blocks are sections (the most generic sectioning element in HTML5), because clearly they can be so many other things.

We need a better way of dealing with blocks than the current system. For example we could remove block templates from core and use the theme function instead and allow modules to pass the type as a parameter (in which case adding the shiv is required), or we could pass a $tag variable to templates, similar to how Views does this now.

I hope this serves as a simple example that the issues are more complex and why I tend to think a conservative approach is better to begin with, then work though difficult issues like block markup as we go.

Jeff Burnz’s picture

Issue tags: +Front end

tagging with Jacines new Front end tag.

sreynen’s picture

so in effect the page does not degrade gracefully, but rather smashes to pieces.

Can you provide a specific example of this? HTML with no CSS doesn't smash to pieces, even with new HTML5 elements, so this may suggest changes to our approach writing CSS rather than HTML. In the block example, the fallback style for all of those HTML5 elements should be simple <div> styling, so that would render with all blocks stacked atop each other in older IE with no JS intervention. Blocks stacked like that isn't often the style we're going for, but it's still a usable website, not something I'd consider smashed to pieces. I can imagine how that might become smashed to pieces with additional CSS applied (or rather failing to apply), e.g. we put the blocks in overlapping column regions, position them to the outer edges of those regions, and the blocks end up overlapping when that positioning doesn't apply. Is that what we're trying to deal with? Or is there a problem with the default styling by itself?

Jeff Burnz’s picture

#20, see #16, its discussed in the very next paragraph form the one you just quoted. What you are suggesting is a poly filled document, which no one really wants because its verbose (adds additional dom elements we don't actually need), we can be smarter. If you look in my sandbox you will find a theme called Poly which does this (proof of concept), it ads around 15% more dom elements.

sreynen’s picture

I've tried to not to suggest any answer at all because I feel we haven't clearly defined the question yet. That's why I asked for a specific example, which #16 does not give. This issue jumped straight into solutions without clearly identifying the problem; I'm just trying to back it up a bit, not necessarily change direction at all.

Jeff Burnz’s picture

#22 shiv is a very specific solution for a specific set of problems which are well documented, you can google this and find out what the shiv is and why it was invented.

Simple example- if I use a sectioning element for layout then that layout won't apply in browsers that do not recognize that element, namely IE6/7/8.

E.g. I want to float an aside element, maybe this is inside a node and I want this to be a sort of "node sidebar" that holds a field. This will not work in IE6/7/8 without the shiv because those browsers don't understand that element, and wont apply any CSS to it. If I load the html5shiv those browsers will now recognize the aside element and apply styles to it. Of course this is much more than just layout we're talking about, you can't apply ANY styles to those elements in IE6/7/8, so they become mere semantic containers in the document, but without any use as style hooks.

Therefor without the shiv we are precluded from using any of these new elements for layout/style - this is the overall issue we have been discussing and how we might solve this in core. The conclusion we came to initially is to not use those elements in core, and not include the shiv, and leave this up to individual themes - mainly because this forces a reliance on JavaScript in older versions of IE. This is of course still open for discussion, indeed things may well change.

Sorry but I have no idea what you mean when you say "the fallback style for those HTML5 elements should be simple div" - because this sounds very much like polyfil to me.

sreynen’s picture

Title: Add HTML5shiv to core » Determine how to handle styling of HTML5 elements for non-supporting browsers

Thanks for the specific example. I disagree with your characterization of html5shiv as a very specific solution; it applies to all HTML documents, whether it's useful or not. I think it's worth looking at where specifically it might be useful in Drupal, especially if we're looking at alternatives that can be applied more specifically.

Therefor without the shiv we are precluded from using any of these new elements for layout/style

I think that's an overstatement. We could still use those elements for layout/style where such use is non-critical and also where the layout/style we're seeking is the browser default.

In your example, the aside would show in old IE above or below the main node content rather than floating beside it. In some cases, that wouldn't be acceptable. In other cases, though, it would be fine. That might even be the design goal, as "aside" doesn't necessarily indicate a presentation on the side. What I meant by "the fallback style" is what happens when no CSS is applied to those elements in IE: they get rendered just like a div with no CSS attached. We shouldn't assume that's universally a negative, or negative enough to be worth avoiding.

Because the importance of applying CSS to HTML5 elements varies, I think a blanket ban on HTML5 elements in core goes too far. I suggest instead considering potential use more specifically. In some places, the HTML5 elements may not be worth using. In others, they may offer enough benefit to compensate for the cost of polyfil markup. And there will also be some places where default browser rendering of HTML5 elements is exactly what we want, so it's a complete non-issue.

It sounds like the scope of this issue has expanded, so I'm updating the title to reflect that.

klonos’s picture

Title: Determine how to handle styling of HTML5 elements for non-supporting browsers » Determine how to handle styling of HTML5 elements for non-supporting browsers (F.K.A: Add HTML5shiv to core)

...don't mind me also including the old issue's title so I remember where we started from(?).

Jeff Burnz’s picture

Title: Determine how to handle styling of HTML5 elements for non-supporting browsers (F.K.A: Add HTML5shiv to core) » Add HTML5shiv to core

The scope of this issue has NOT changed. This issue is very specifically about adding the shiv to core or not. This issue was opened after much discussion on this in other places. Sorry if you were not party to that but it stands that this is very specific issue and there are many issues that surround this, as you can see in the first 20 odd comments.

If you want to discuss the broader issues at hand then open another thread or take it to g.d.o. Please don't jack this thread for your own purpose. Take it somewhere else.

sreynen’s picture

I certainly didn't intend to threadjack. There's a lot of discussion in this thread that has nothing to do with html5shiv, so I thought I was giving it a more descriptive title. I don't have ulterior motives as you've implied, nor am I ignorant of what html5shiv does, as you implied earlier. I would like to help, but your continued hostility has convinced me that can't happen here. I have no idea where that hostility came from, but I hope you'll eventually recognize it was misplaced.

Jeff Burnz’s picture

I do not think I have deliberately implied anything, sorry if you feel that I have, it was not meant this way. If you felt some hostility, then again I am sorry for that, I was not meaning to be hostile in any way, emphatic yes, hostile, no.

One point I would like to make is that there is a quite bad mistake in your post - HTML5 sectioning elements with no CSS applied, in browsers that do not natively support them, do not render as block level elements. You incorrectly stated that these would fall back to div like state (you actually said they would stack in another post), however they are actually rendered as inline elements. This is a very important point in the discussions you are raising, because it would be design hell to have to account for an element in two different states in different browsers and have no control over the state.

droplet’s picture

Hi, I have to share something Ive seen.

i love move forward and new innovation. but this is a big deal here.
anyone have real experience to implement it into a large site (even not drupal) ?? what real problem you are facing?

I have only see tabao.com (a chinese site, http://www.alexa.com/siteinfo/taobao.com) have to do it before, and removed all html5 structural tags now. (I think no such big site using HTML5 and have such big amount of IE users in the world).

I don't disagree to Add HTML5shiv to core but not the best time to convert all core element to html5 stuff. (only give it as an option to users who need it.)

few question,
- is it easy to use ?
- would it more difficulty to themer ??
- is fallback clever enough to do it auto and without themer to write a single line of specified code ?

Jeff Burnz’s picture

Well there's a gallery site http://html5gallery.com I think you'll find the the various implementations vary widely. apple.com is probably the largest and most famous site I know of that uses html5, and some of googles sites.

Jacine’s picture

I don't think we need to answer the nojs/markup fallback questions in this issue. I think those would be better off discussed in the template file issues themselves. However, there are some other things to consider regarding a shiv:

  • If one opts out of using any new HTML5 tags, he will not need a shiv.
  • If one decides to use Modernizr, he not need the shiv.
  • If one is not rendering HTML, he will not need a shiv.
  • Even with the shiv, dynamically inserted elements still pose a problem: http://jdbartlett.github.com/innershiv/.
  • If Drupal 8 modules and themes need to worry about this individually, it's going to be a mess.

So, I think we need "something" here. I'm not sure what that something is yet, but we cannot really say Drupal supports HTML5 without having something in place to take care of this. We also need to be able to easily toggle it on/off given the considerations above. We could consider something like including a library in core and using a theme setting to toggle it on/off. I'd love to hear if anyone else has ideas or thoughts on these issues.

Jeff Burnz’s picture

A setting (aka a Feature) sounds like it satisfies the requirements quite well:

1. If you include this feature in the info file it loads the lib (features are on by default).
2. You can toggle it off if you don't want it.
3. Don't include the feature in your theme and its completely disabled (opt out, I'm using modernizr etc).

klonos’s picture

It is pretty clear by now that we want HTML5 in D8*. It is also clear that in order to be able to support html5 in various legacy browsers we'll have to rely to an external solution (be it shiv/modernizr/whatever). I am quite confident that Libraries will be in D8 core, so the whole idea of having a library plus a global or per-theme setting like "Support HTML5 in legacy browsers" seems really neat. Further settings (via an easy radio/check-boxes set) could allow selecting one or more of the available/supported solutions.

* #963832: Decide how to use HTML5 in Drupal 8, #1077356: HTML5 in core battle plan, HTML5 @ Community & Support, HTML5 in Drupal 8 by Dries Buytaert, Drupal 8 HTML5 Initiative by Jacine Luisi, HTML5 @ g.d.o, DrupalCon Core Conversation: HTML5 + Drupal 8 etc...

klonos’s picture

...of course -for those concerned about performance etc- this could be implemented in a core module that would only be turned on by those that require it.

Mark Trapp’s picture

If Drupal 8 is to be output-independent, giving special preference to HTML5 by adding legacy support features like the shiv directly into the core libraries seems to go against this. I'm all for the approach in #6-#8, which is to add the shiv only to the outputs that actually need it (i.e. a core HTML5 theme).

We can still say Drupal supports HTML5: we included a core HTML5 theme that demonstrates that support. Heck, we can say Drupal goes beyond this and supports any output under the sun, including HTML4 and HTML5 at the same time. As I said in #7, let's not make extra work for people by making the shiv opt-out via a theme setting (or a hook, or whatever) who are going to want to use HTML5 without legacy support, or for people who just want to use HTML4 or another output, just because a core theme needs the shiv to satisfy a legacy browser requirement.

Jeff Burnz’s picture

Its possible it could be a module and themes/modules can force a dependency on this, we should be able to do this as long as #474684: Allow themes to declare dependencies on modules matures and gets into core.

I don't think we're talking about an "opt out" approach, more of an "opt in". For the "Features" idea that would be as easy as toggling that particular feature OFF in the global theme settings. This might mean we add defaults for Features in the info file, rather than simply toggling them all on by default.

Just thinking out loud but what about issues like #1089912: Provide a html element selector element and #732992: Allow filter_xss_admin() to accept HTML5 tags, both of these effectively allow end users to use HTML5 in their sites, directly, with zero knowledge of what that might cause (wtf, my site just blew up in IE8).

Jacine’s picture

Mark, I'm actually pretty sensitive to the fact that some people will not want to use the new elements. I've been very adamant about being conservative about this from the start, and have taken quite a bit of flack for it from some people. Still, one of my goals in leading this initiative will be to minimize the amount of work needed to opt-out.

However, we will be adding new elements to Drupal 8 as part of this initiative. How and where still needs to be fleshed out, but we need to try to look toward the future here and try to reach a happy medium, with that in mind.

Personally, I don't think toggling a theme setting in a .info file, or something similar, is a lot of work. The alternative, which would be manually including a shiv individually in each theme doesn't sound efficient to me. And like @Jeff Burnz mentioned in #36, it could easily be an "opt in" instead of "opt out" setting.

If Drupal 8 is to be output-independent, giving special preference to HTML5 by adding legacy support features like the shiv directly into the core libraries seems to go against this.

We are not talking about output-independent circumstances here though. We are talking about the HTML case, and we are going to have to deal with some legacy issues as part of this process.

We can still say Drupal supports HTML5: we included a core HTML5 theme that demonstrates that support

I don't understand this statement. None of the core themes currently have HTML5 support. The HTML5 initiative is not only about adding support for HTML5 to themes, it's about moving core to HTML5.

I'm completely open to other ideas for how to accomplish this, but for the reasons I stated in #31, I don't think just disregarding it and leaving it to themes and modules is a solution at all.

Mark Trapp’s picture

@Jacine I know Drupal 7 core doesn't have any HTML5 themes: I'm assuming Drupal 8 is going to include an HTML5 theme, so that should be enough to demonstrate that Drupal 8 supports HTML5.

That is, one of the core initiatives is to make Drupal output independent; that is, to run it even without HTML. WIth that in mind, "adding HTML5 to core" doesn't really make sense except in the context of a specific form of output (e.g. a theme).

For example, if I'm running Drupal with JSON or XML output, the HTML5 stuff really doesn't mean anything for me. The shiv should only really be added when Drupal's outputting HTML5 (like in a theme). Otherwise, the shiv is just one more thing I have to unset in order to use a different output format, and Drupal winds up being HTML5-dependent, with some support for other output formats if you take the time to decouple all the HTML stuff in core (i.e. not much different than Drupal 7 is now).

Taking a step back to just talking about HTML, the shiv (and things like it) optimize for the broken edge cases: it's not an essential component of HTML5. By the time Drupal 8 is released, it's questionable the requirements people are going to have for their websites are going to match Drupal's requirements. It's likely HTML5 will reach Candidate Recommendation and just be the norm for most of the rest of the internet.

So while the default core output might need the shiv to satisfy its own requirements (like in a default theme that absolutely needs to have IE8 support), it's dubious the shiv is the only way people could (or even should) use HTML5 effectively when Drupal 8 launches.

We shouldn't be setting defaults that optimize for the edge cases merely because core needs to. If the shiv is provided as a library (like, say, autocomplete.js) and is opt-in (via Features or the .info file or what-have-you), that seems to make sense. If something needs legacy support, it can add it: whether it's a core theme, or a module, or whatever.

A possible middle-ground, thinking about the stuff in #36, would be an optional module that enables legacy support for the HTML output format. The standard install profile might have it enabled, but a minimal install profile would not.

adrinux’s picture

This really feels like a theme level thing.
Should it be used by core themes? yes
Should it or an equivalent be included in core? Yes - iirc MIT is loose enough to allow inclusion in GPL software like Drupal…

So yes I think it should go wherever autocomplete.js, collapse.js etc end up (really, /misc is getting cluttered. about time we had a javascript folder?). And be included as needed.

dvessel’s picture

Just to throw my two pennies in here, I think it's too early to consider the use of HTML5shiv. I agree with what Mark Trapp is saying here. Couldn't we just wait and see before we even consider IE workarounds? There's so much going on, it's hard to keep up but I'm pretty sure new ideas will keep popping up. Stick to working on the standard, not broken browsers.

Jacine’s picture

I don't see the point of avoiding this. Personally, I'd like to have it decided so we don't have to discuss it on every issue going forward.

I completely disagree that IE8 and below is an edge case, especially since we are just now dropping IE6 support. I think a polyfill, whether we use the HTML5Shiv or something else entirely is going to be a fact of life for most themes that use new HTML5 elements. Lots of Drupal 7 themes use them today, and usage will only grow during Drupal 8 development cycle.

However, if people think this discussion is premature, then I guess we should discuss how the markup is going to be written. For the sake of clarity, I'm not talking about Drupal core themes right now. I'm talking about the core templates found in system, node, comment modules, etc. I'm not down with writing core markup like the example in #5 in these templates (not core theme templates), but then the first question (literally) that is asked is "What's the solution for no-js?"

If we don't care about legacy browsers, then why do we care about no-js? Or do we not care about that right now either? If we don't care about either, and don't want a shiv in core then we are ultimately saying that this burden is going to fall entirely on both modules and themes, which could lead to a mess of both trying to load their own shivs, and certain modules only working with certain themes. I don't think that's very sensible, but if that's what people want... ;)

Jeff Burnz’s picture

dvessel - how do you think we can handle cross browser testing, say if we start using <time> or <mark> for example, we're going to have to write and test CSS for these elements but that's not going to be possible in browsers that don't support these elements. maybe we go the other way around and add the shiv sooner rather than later (because at the moment its the best tool we have) but with an open mind to remove it or shift to a better tool if the circumstances make that possible. Thoughts?

dcrocks’s picture

As pointed out just adding an html5 enabler to core doesn't really make drupal a html5 cms or not. It takes more. And the standard is still in transition(are hgroups going to be kept or dropped?). A 'transition' option could be to make html5 an 'install' option for the many who don't want to do all the work to get to html5, or more likely, expect it to be there. And those who don't choose that option aren't precluded from using html5 themes if they choose(just as is being done in drupal 7 now).
This does require duplication of work as well as code but it could really enable a 'new' drupal earlier than might be expected. I don't think it would add all that much to drupal's weight, especially since there are other pressures to increase drupal's base footprint.

dvessel’s picture

Jeff, I think that's perfectly reasonable. I just don't like the idea that it's "fixed" so early in when everything is in flux.

dvessel’s picture

However, if people think this discussion is premature, then I guess we should discuss how the markup is going to be written. For the sake of clarity, I'm not talking about Drupal core themes right now. I'm talking about the core templates found in system, node, comment modules, etc. I'm not down with writing core markup like the example in #5 in these templates (not core theme templates), but then the first question (literally) that is asked is "What's the solution for no-js?"

Jacine, I agree about #5 and I hope we wait on the solution for no-js and possibly not have to deal with it at all. Maybe it's wishful thinking but over time, so many workarounds were found for IE6. Crossing my fingers for HTML5 support.

Mark Trapp’s picture

#41 The question of no-js and shiv in core go hand-in-hand, don't they? If we're relying on a shiv to be an integral part of how Drupal handles HTML5 because Drupal's supported browsers set, we need to require JavaScript, otherwise the shiv isn't really a solution for legacy browsers who don't have JavaScript enabled (which is still a supported scenario).

The alternative discussed in #6-8, and the one I still support, is to not make the shiv an integral part of how Drupal handles HTML5: you can opt into the support if you need it, and it might be enabled in a standard installation profile (either via a feature, a module, or the default theme). This way, the JS requirement is lessened to "if you want to use Drupal's HTML5 functionality and you need to support legacy browsers".

I don't think it's a stretch to say that Drupal 8 isn't going to be released for at least 18 months: which gets us into 2013, right around the time HTML5 reaches Candidate Recommendation (the same milestone CSS2.1 currently enjoys) and Internet Explorer 8 celebrates its 4th birthday. In that time, Internet Explorer 9 (with HTML5-support that doesn't require the shiv) has been released, IE 10 is almost certainly to be released (given Microsoft started previewing it 29 days after IE9 was released), and I don't think it's unreasonable to surmise Microsoft will continue its rapid pace and launch IE11 in 2012.

Putting aside core's current requirement to support even IE7, the requirement that core supports at least 4 major versions back is an edge case. A no doubt necessary edge case given Drupal's need to appeal to a variety of use cases and environments, but an edge case none-the-less. Most people don't have the resources to test their site with that level of support.

So what I'm suggesting, if it absolutely has to be decided now, is to only include the shiv in core's use-cases. If someone needs to also support them, they can opt into that support. This would mean crafting the core templates, the core theme, the administrative theme, and theme functions with clean HTML5 (no polyfill, no shiv , no wrapper elements), and having a feature/module/what-have-you add back the shiv.

The more I think about it, the more I like the module enabled-by-default-in-the-standard-installation-profile approach, as it keeps HTML5 legacy support global, makes it so the people who don't care about it don't have to worry about it (i.e. the "I don't understand why Drupal is broken in IE 8" scenario), and allows everyone else to use Drupal without having to worry about what other legacy features Drupal has decided to add to core output.

Mark Trapp’s picture

Status: Active » Needs review
FileSize
4.19 KB

I created a proof-of-concept for the solution I've been talking about (shiv as a separate core module enabled by default in the standard installation profile) as a patch (attached) and as a sandbox project.

JohnAlbin’s picture

Status: Needs review » Active

Support for IE8 in Drupal 8

Putting aside core's current requirement to support even IE7, the requirement that core supports at least 4 major versions back is an edge case.

IE8 and below are not an edge case. They are based on actual browser usage stats. And trying to predict whether IE8 will have significant usage 2 years from now is fortune-telling. The current Windows Mobile 7 phones actually have a hybrid IE6/IE7 browser in them! Guess how they handle HTML5 content?

I think it is reasonable to assume they we will need some level of support for non-HTML5-capable browsers. I also think that it would be dead simple to remove any script we add if we later determine that we don't need it (based on browser usage stats.)

Installation profile, only in themes, etc. (the not-always-on javascript)

I finally got a chance to watch Dries's keynote, and I think keeping the shiv out of core output keeps with the idea of making Drupal not just markup agnostic, but output agnostic.

That's a red herring. If I request a page and want it in JSON instead of HTML, than I won't need any attached CSS or JavaScript. What does output agnostic have to do with this script? Nothing. If D8 outputs content in a non-HTML format than it will have to solve the problem of CSS/JS attachments for all scripts and CSS.

With Drupal 7, its now possible to easily remove js scripts if you don't want them. I would like all our themes to be HTML5-based, so why should we have to add a HTML5 polyfill to all the themes individually when we can just have core add it like it does for jQuery?

I would also be totally fine with the suggestions posted in #33 above by klonos.

No-JS fallback for HTML5

I'm glad Jeff made the suggestion he did in #5 above since I had a similar thought experiment last year. What will happen if we implement a wrapper-markup solution like that and D8 comes out in 2013? Designers will take a look at Drupal's markup and laugh (or cry). The HTML5 polyfil solution was released in 2009 and for D8 to be using a markup-bloated solution 4 years later will mean that many will dismiss Drupal as being irrelevant. Drupal 7 was released this year and people (like Jeffrey Zeldman, no less) were asking why it didn't already support HTML5.

Are there any other possible solutions? Is there even anybody working on any other possible solutions? I think the js solution is just too easy.

There's really is no way to make non-HTML5-capable browsers display the new HTML5 elements as block-level elements. EXCEPT if you use a javascript polyfill to add that capability to those old browsers.

Since Drupal 8 will definitely be using HTML5, the "Do we use a JS solution?" question is the equivalent to "Do we add support for incompatible browsers?" And the answer to that is a definite "yes".

Drupal has to require JavaScript then

shouldn't the topic of adding the shiv to core be dependent on a move to requiring JavaScript?

No, it shouldn't. We're not requiring JavaScript for all users of Drupal. We are requiring JavaScript for all users of IE8 and earlier. Not the same thing.

Having no-script alternatives for everything-but-HTML5 in Drupal is fine with me.

HTML5shiv BSD exception

I'm sure lots of people will want to "Closed (Won't fix)" this issue because of its BSD License. If you want to convince everyone that our only choice is this BSD script, you'll need to support that assertion.

Our very own Bevan has an HTML shim that's GPL: https://github.com/bevanr/jquery-html5-placeholder-shim
And there's pages of HTML5 related jQuery plug-ins that I haven't looked at: http://plugins.jquery.com/plugin-tags/html5

JohnAlbin’s picture

Status: Active » Needs work

I accidentally cross posted with Mark. So let me review his patch in #47.

Themes can't require modules. So that solution is postponed until themes can require modules. #474684: Allow themes to declare dependencies on modules Also, I'm not in favor of that solution as stated above.

Mark Trapp’s picture

Firstly, I encourage everyone chiming in about comments #1-5 to continue reading from comments #6 and onward, where the initial contentions were addressed. Issues are being rehashed when they really don't need to be. We can avoid the no-js problem entirely, and I don't think anyone is seriously suggesting wrapper markup (Jeff proposed it in #5, but decided to go another way in #6). I don't think anyone is arguing Drupal 8 shouldn't support HTML5 for any reason (including the no-js problem), and I don't think anyone is arguing the shiv shouldn't be included in some form to support Drupal's requirement to support older browsers.

The remaining issue is how the shiv is enabled in core: whether it's enabled by default for all use cases, or whether it's opt-in for those that actually need it.

Secondly, the shiv isn't BSD-licensed, it's MIT licensed. As pointed out in #8, we'd need to make an exception in core for it (not unprecedented, especially if we can get it dual-licensed). Even if this specific shiv is somehow unacceptable, I don't think that's a particularly large hangup, as several other, more appropriately licensed, alternatives exist. It's not a complex script, and it's likely we could even just write one from scratch fairly easily.

Thirdly, there's no requirement to have themes depend on the module. Under the solution I'm proposing, themes would implement HTML5 cleanly (without their own polyfill and without wrapper markup) and allow the site builder to decide if they need the shiv. The shiv would be applied if the module's enabled, and the module would be enabled with the standard install profile.

adrinux’s picture

Title: Add HTML5shiv to core » Add HTML5shim to core

One thing not yet mentioned is that only IE needs the shiv/shim* other browsers will happily style the new structural elements. So any patch or module, such as in #47 should add the script in conditional comments directed at less than IE9: [if lt IE 9] etc.

@JohnAlbin in #48: Bevan's script is only for the HTML5 placeholder form field attribute, it's not a replacement for the shim yet. I did find one jQuery script to replace the shim https://github.com/jamescarr/jquery-html5-shim/blob/master/src/jquery-ht... but the placeholder support seems less developed than Bevan's and it has no print support. So using Bevan's placeholder shim as a base for a GPL'd HTML5 shim might be the way forward (Shared with the jQuery community, we ought to be better OSS citizens right?). But that will need to be written.

Alternatively using the existing HTML5shim is possible since the MIT license is GPL compatible, it's just a question of keeping the MIT license with the script.

* The real bikeshed issue is what to call it. shim ( http://code.google.com/p/html5shim/ ) vs shiv ( http://code.google.com/p/html5shim/ ). A shim being a friendly "washer or thin strip of material used to align parts, make them fit, or reduce wear" and a shiv being a nasty "knife or razor used as a weapon". I fear years of battling with IE may colour this decision for you, but I for one would like to put aside the scars and mental trauma and use 'HTML5 shim'. I'm changing the issue title accordingly ;)

jide’s picture

Title: Add HTML5shim to core » Add HTML5shiv to core

Maybe it's a little off-topic, but I'm also wondering how core modules will output markup through themes functions, I mean, e.g. will the block module use HTML5 markup in its default theme implementation ? (Just an example).

sun’s picture

Thanks @JohnAlbin for the summary and clarification. Highly appreciated. We need more substantial and in-depth, and less biased/opinionated insights on issues like this.

That said, here's my uninformed feedback:

  1. IE8- and other older browsers will definitely have to be supported. Requiring enabled JavaScript in order to support them sounds like an acceptable thing, considering the release date of D8.
  2. Workarounds like #5 that merely introduce HTML5 markup for the sake of introducing it, but without actually using it, would have been acceptable proposals if the scope and target was D7. For D8, that's not acceptable.
  3. D8 will strongly recommend HTML5, so it's kinda pointless to think conservatively or of an opt-in. It's highly debatable whether a particular theme should be able to opt-out, but if at all, then this needs to happen in the theme layer. In case the solution will still be a JS at the time D8 is released, non-HTML5 themes can remove that JS on their own like any other JS file a theme wants to remove.

    Until (and including) Drupal 5, Drupal core did not enforce XHTML 1.0 Strict. Only afterwards, the new default doctype and implied restrictions took effect. Obviously, that transition was easier, but distributing and deploying Drupal with up-to-date and modern defaults was always beneficial for Drupal and the web at glance. What I'm trying to say is that we should care less about conservative stuff and nostalgia, instead spend the time on implementing a solid, sane, and working default.

  4. There are no "exceptions" to Drupal's license. Someone has to check the Licensing FAQ in detail to figure out whether the currently proposed script can be used. @Crell might be able to help on that question, too. Regardless of that, it wouldn't hurt to contact the author/primary maintainer and ask for dual-licensing under the GPL. Can someone initiate this?

    We should definitely use one of the popular open-source scripts and not a home-grown custom implementation. No pun intended. We simply don't have the manpower and forces of JS/browser gurus that would be required to properly update and maintain such a script.

  5. The file should be added to misc/ and the library should be registered and loaded by system.module. An own html5.module does not make sense here.
Mark Trapp’s picture

To reiterate for people who are not familiar with HTML5, the shiv is not part of HTML5. The shiv is a workaround for allow browsers who don't understand how to style HTML5 elements. It's not a requirement of using HTML5 to use the shiv.

D8 will strongly recommend HTML5, so it's kinda pointless to think conservatively or of an opt-in.

If that's the case, there shouldn't be a shiv in core at all.

Obviously, that transition was easier, but distributing and deploying Drupal with up-to-date and modern defaults was always beneficial for Drupal and the web at glance. What I'm trying to say is that we should care less about conservative stuff and nostalgia, instead spend the time on implementing a solid, sane, and working default.

So the solid, sane, and workable default is to implement HTML5 cleanly and provide an opt-in for those who do care about conservative stuff and nostalgia.

Mark Trapp’s picture

Attached are patches that use shim instead of shiv:

Status: Needs review » Needs work

The last submitted patch, drupal-1077878-55-shim_module_no_conditional.patch, failed testing.

dvessel’s picture

Although it feels wrong to me since I work primarily with themes, I can't find any objections in implementing it as a module. It is a front-end concern which is usually associated with theming but there is a clean separation here. The theme doesn't even have to know of its existence.

If someone can provide a scenario or explain why it shouldn't be a module, please speak.

Mark Trapp’s picture

Rerolled failed no-conditional patch (and attached passed conditional patch from #55 to keep things together).

dcrocks’s picture

This doesn't give me a chance to choose my enabler. What if I want modernizr? What about a configure option to override the default file(ps. modernizr may soon be available through google)? No one here talks about CSS3, but html5 without CSS3 is only putting one foot in the water.

adrinux’s picture

A timely post from Paul Irish today: http://paulirish.com/2011/the-history-of-the-html5-shiv/

dvessel’s picture

dcrocks, your "enabler" is anyone access to the module list page and it can be easily disabled. The question then becomes, do we want this exposed to begin with? Should we leave it up to each theme to enable it through the .info setting?

Thinking about it further, it might be better to set it through .info. There's the possibility that the theme will manually include Modernizr and forget about the module. I'm not sure if they would conflict but there's definitely overlap.

An no one is talking about CSS3 because we are talking about very basic recognition issues in IE. CSS3 is another discussion.

sun’s picture

@dvessel: There's a clear dependency between themes and the shiv. Themes cannot depend on modules. Modules cannot "enable" themes. This is a pure front-end related matter and does not expose any Drupal functionality. Therefore, a module doesn't make any sense and mixes up concepts in the wrong way. If at all, it's a theme setting. In the end, it's a JavaScript file, no more, no less.

But anyway, it's way too early to talk about this implementation detail (which is why I barely mentioned it in #53). AFAICS, we need to research and discuss how to move forward on the summary points that @JohnAlbin outlined in order to come to an informed decision.

dvessel’s picture

sun, the "shiv" whether it's there or not, the theme will not care so it is not a clear dependency as there is no direct interaction between the two. But yes, it does mix up the concepts in the wrong way.

Aren't we passed what JohnAlbin mentioned? What's there to research? The disagreements may not have been resolved but the outcome is the same. Everyone agrees a javascript polyfill is what we want. It's a matter of ironing out the license and implementation details.

jide’s picture

Couldn't the ongoing work on plugins subsystems #363787: Plugins: Swappable subsystems for core help here ?

webchick’s picture

Subscribing. Will chime in here later.

webchick’s picture

Some random thoughts (I composed this as I was writing the thread, but I see JohnAlbin/sun made similar points):

  • If I was a web designer and I saw "HTML 5 support" on the feature list of Drupal 8, then pulled up the source code of the Stark theme in my browser and saw nothing but <div>s everywhere, I would be pretty ticked off and feel like I was lied to. One or more core themes that make use of HTML 5 != "HTML 5 support," IMO. That's setting the bar too low.
  • Drupal 8's default markup should be HTML 5 the same way that Drupal 7's is XHTML. If you don't want that, no problem! You use a contrib "XHTML base" theme as your base theme, which overrides core's default output to get what you want; in other words, the same workaround folks who want to use HTML 5 in D7 need to do.
  • I see people citing the fact that we want Drupal 8 to be able to output-agnostic as a reason not to include the shiv. I wouldn't let that veer the conversation. The decision of whether to output XML/SOAP/RSS/etc. would need to run *before* it gets to the point where the shiv would come into play. By then, Drupal's made the decision to output HTML already.
  • It seems like the shiv is required for HTML 5 compatibility with IE <= 8, unless you feel like adding a bunch of crappy placeholder divs to your markup (and we all know how much designers love crappy placeholder divs). Given that we haven't even dropped support for IE 6 yet, the idea we won't need a shiv or something like it in Drupal 8's default markup is pretty laughable to me.
  • I'm also not sure how pushing off the decision whether to add a shiv to core helps anything. It actually rather seems like adding the shiv is a pre-requisite to doing any of the proposed markup changes in core template files, because otherwise we won't be able to test in IE, and pushing off IE testing to the end of the release cycle is a recipe for pain and tears (as well as pain-soaked tears). Been there, done that, and we're not doing that again.
  • Given all of the above, a module for the shiv doesn't make much sense to me. First, because Drupal 8's default markup is going to need to support IE 7&8 without themers having to copy/paste annoying bits of JavaScript. Period. Full stop. This workaround isn't optional. But secondly, because modules are for turning on site functionality and this is purely a theme-related construct. There's no reason for it to be anything but a theme setting, at best. But one thing it should definitely be is swappable, so that something like Modernizr could be used instead.
  • The GPL issue definitely does need sorting out. It'd be great of Jacine or Jeff could make the connection with the authors of this code and ask them if they'd be open to dual-licensing. That's how jQuery* got into core.
dcrocks’s picture

+ to all of the above.

Jacine’s picture

Status: Needs review » Needs work

Thanks @webchick! I agree with all your points as well.

I reached out to Remy Sharp, and he has agreed to change the license. The only reason it's not GPL is because Google code only allows one license at a time. He agreed to changing it for us in the code/project description. Yay! :D

Drupal 8's default markup should be HTML 5 the same way that Drupal 7's is XHTML. If you don't want that, no problem! You use a contrib "XHTML base" theme as your base theme, which overrides core's default output to get what you want; in other words, the same workaround folks who want to use HTML 5 in D7 need to do.

Yes. I've been thinking about this for a while, and have come to think that the best way to handle this situation is to create a contrib theme called "Legacy" or something that does not use the new elements. People can use this as a base theme for doing straight theme ports, or when their requirements make it not worthwhile to use the new elements. There is really no reason to use XHTML at all, and dealing with all the extra maintenance that something similar in core would require isn't worth it.

There's no reason for it to be anything but a theme setting, at best. But one thing it should definitely be is swappable, so that something like Modernizr could be used instead.

As far as the theme setting goes, it was only a suggestion. If people just want to include the file, and make people override it the normal way, that's fine too.

I hope that after webchick's reply, and since the licensing is not an issue anymore that we can get back to the discussion about implementation.

Jacine’s picture

dvessel’s picture

I'm also not sure how pushing off the decision whether to add a shiv to core helps anything. It actually rather seems like adding the shiv is a pre-requisite to doing any of the proposed markup changes in core template files, because otherwise we won't be able to test in IE, and pushing off IE testing to the end of the release cycle is a recipe for pain and tears (as well as pain-soaked tears). Been there, done that, and we're not doing that again.

The best point you made IMO and it's a safe path to take. Anyone want to bet that by the time D8 is released, IE8 will no longer be supported by MS? ;p I kid.

klonos’s picture

I like the route this is taking too.

cosmicdreams’s picture

Sweeeet. I've been reading up on the properties of the shim/shiv. I definitely looks like a pre-requisite to providing cross-browser HTML 5 support.

However, can someone elaborate / link to a comparison of html5shiv vs. Modenrizr?

Jacine’s picture

@dvessel LOL.

@cosmicdreams Here's a quick overview of both:

HTML5 Shiv

Sole purpose is to enable using new HTML5 elements in IE.
2 kb minified | 1.47 kb gzipped
http://ejohn.org/blog/html5-shiv/
http://remysharp.com/2009/01/07/html5-enabling-script/

  1. IE8 and below do not recognize HTML5 elements, and will not render them with CSS styles by default. The HTML5 Shiv uses document.createElement("tag") for each of the new elements. This forces IE to render them with the CSS styles like any other tag.
  2. Even with the document.createElement() code, any CSS styles applied doesn't stick when printing a document. The HTML5 Shiv includes a script called IE Print Protector which solves this problem too.

Modernizr

Focuses on HTML5 and CSS3 feature detection. Also adds the HTML5 Shiv and yepnope.
12 kb minified | 3.7 kb gzipped
http://www.modernizr.com/

  1. It checks for support for 40+ HTML5/CSS3 features and adds classes to the <html> element indicating the status in your browser, e.g. A geolocation class is added when support exists, and no-geolocation when it doesn't.
  2. It adds a global JS object that you can use to evaluate your code against.
  3. It includes the yepnope library, which is "an asynchronous conditional resource loader that's super-fast, and allows you to load only the scripts that your users need."
  4. It includes the HTML5 Shiv as described above.

Modernizr is awesome. Using it is definitely considered a best practice when feature detection and in-depth fallbacks are required, and many themes will choose to use it over the HTML5 Shiv. However, it does a lot more than we need in core, and comes with a cost. We need to be careful to only add what we absolutely need and IMO, it's the HMTL5 Shiv in this case.

JohnAlbin’s picture

Status: Needs work » Needs review
FileSize
4.12 KB

Well, geez. That was fast! Jacine++ :-D

And I agree with Jacine; Modernizr is awesome but Drupal core doesn't currently need all its extra functionality. We can certainly reconsider later if our requirements grow. (Note: it does have the MIT/BSD license issue that HTMLshim had about 12 hours ago.)

So do we use the shim or the shiv? Let the bikeshed commence!

I say we use the SHIM in our code. Especially, since the grammarian in me used the shiv on the barbarian in me.

Oh, I'm kidding! The file is called "html5.js" and even the source code on http://html5shim.googlecode.com/svn/trunk/html5.js says "shiv" in the code comment. So we don't have any sheds to color.

Here's a patch that adds it as a library.

Status: Needs review » Needs work

The last submitted patch, 1077878-74-html5shiv.patch, failed testing.

seutje’s picture

@#5
when I have to support IE with JS turned off, I usually do it the other way around:

<div class="presentation">
  <article>...</article>
</div>

that way, the outer div can still be floated without having potentially unwanted consequences in IE (e.g. non-inline element within an inline floated container...)

JohnAlbin’s picture

Status: Needs work » Needs review
FileSize
4.58 KB

Oops. typo.

One thing this patch doesn't do is load the JS inside an IE conditional comment. Any drupal_add_js() experts wanna tackle that bit?

Status: Needs review » Needs work

The last submitted patch, 1077878-77-html5shiv.patch, failed testing.

aspilicious’s picture

+++ b/.htaccessundefined
@@ -101,7 +101,7 @@ DirectoryIndex index.php index.html index.htm
   # If your site is running in a VirtualDocumentRoot at http://example.com/,
   # uncomment the following line:
-  # RewriteBase /

Hmm this is not html5 related I think ;)

Powered by Dreditor.

sun’s picture

hah! Indeed, to do this, it looks like we need to add the conditional comment logic from drupal_add_css() to drupal_add_js()... separate issue.

Jeff Burnz’s picture

JohnAlbin’s picture

Status: Needs work » Needs review
FileSize
4.12 KB

Bah. I didn't commit that RewriteBase to my branch, but I forgot to stash it before generating the patch. :-p

Just realized I should be generating my patches using git diff 8.x <feature-branch-name> or git format-patch --stdout 8.x.

RobLoach’s picture

Issue tags: +internet explorer

We should probably keep IE-related stuff out of core until at least Drupal 8 is closer to release. Morten, Jacine, Jen Simmons, webchick, and a few of the Acquia folk connected with the IE development team a while ago and they said that they will be adding as much HTML5 support to upcoming Internet Explorer releases as possible to help with the Drupal 8 release cycle.

There's also the fact that there arn't really many HTML5 tags in Drupal core yet that we would actually require html5.js for too. Drupal 8 will be released at least one year from now. By that time, IE8/9 will be in full force. Is HTML5shiv something that we absolutely need right now?

This also loads the script up for every browser, slowing down every website browser everywhere. Like Jeff Burnz said, we should be looking at #865536: drupal_add_js() is missing the 'browsers' option first.

aspilicious’s picture

Rob, that's totally wrong. IE8 will NEVER contain any html 5 stuff. Before drupal 8 gets released IE10 will be rdy. That one will have improved html 5 support. IE9 which has some basic html5 support will not get the extra goodies IE10 recieves. IE doesn't backport patches

So IE8 will ALWAYS need html5shiv (IE9 doesn't). So why waiting?

aspilicious’s picture

Another note: a year before drupal 7 got released I started testing in ie7, ie8 and it was in terrible shape. We can't afford to do the same for drupal8 or drupal 8 will get postponed.

We need the shiv *before* we can add html 5 stuff into d8 or else nothing will show up in IE8 and below.

RobLoach’s picture

Status: Needs review » Postponed

Cool! So let's hit #865536: drupal_add_js() is missing the 'browsers' option and get conditional browsers in there :-) .

seutje’s picture

also: afaik, people using windows XP will never be able to install IE9/10 without upgrading to at least vista

aspilicious’s picture

Its even worse, they need windows 7.

Jeff Burnz’s picture

Looks like IE9 runs on Vista, just did the upgrade one of our craptops.

aspilicious’s picture

Jeff Burnz thnx for your reply. I was prety sure it didn't run on vista. Luckily I'm proven wrong :)

alexanderpas’s picture

IE9 runs on Vista and up, IE10 only runs on Windows 7 (and up). Windows XP (and Windows Server 2003 too) is limited to IE8.

Windows XP, with a current marketshare of slightly over 50% recieves extended support from Microsoft until 2014.

stevetweeddale’s picture

Just a heads up - the shiv doesn't work with drupal's ajax methods. It gets pretty geeky to explain as the issue lie in how htmlshiv does it's thing, but the take home is that Drupals ajax insert command needs some tweaking - otherwise any html5 elements loaded into the page can't be styled or hold children in < IE9. See #1180142: HTML5 shiv issues with IE6/7/8

Obviously, this is only an issue if we're doing this legacy browser support from core. Themes can fix it themselves as detailed in that issue.

Jacine’s picture

#92: Yeah. I mentioned this in #31 and had a couple of discussions outside of the queue about it. The consensus seemed to be that it should be a separate issue. It's definitely a problem though. I think we'll run into direct problems with this sooner rather than later, so it'd be great to get some feedback on it now. I think the InnerShiv page explains the problem pretty well, so I encourage everyone to take a look.

aspilicious’s picture

We maybe don't need this in core :D

==> http://bugs.jquery.com/roadmap <==

1.7

1) publish()/subscribe()/unsubscribe() : ben's gist
2) generic subclassing
3) hardware acceleration
4) HTML5 element support
5) touch support (core plugin)

bstoppel’s picture

For user of IE6 - IE8* with Javascript disabled, a message should be displayed informing them of the situation. Some like the following (I'm no wordsmith.)

Sorry, this web site supports modern techniques that your browser does not support. Please enable Javascript or download a modern browser.

ericduran’s picture

sub. (Also I don't think we need a messages, thats why we're adding the html5shiv.)

ericduran’s picture

I have to ask, why is this a dependent on the other issue.

The other issue is a nice to have, if you're going to have some giant script thats really only needed for ie6 or something. But that issue probably shouldn't postpone the html5shiv issue since we're only loading the minila html5shiv which isn't really going to slow down on any other browser.

Just my .02

ericduran’s picture

Ignore my previous comment. I take my .02 back :)

Patch in the other issue.

klonos’s picture

I seriously doubt that by stating "4) HTML5 element support" they actually mean that they will allow older browsers to support HTML5 elements (what html5shiv/modernizr do). They most likely mean to support HTML5 elements selection *if* the browser already supports their rendering.

ericduran’s picture

@ aspilicious & @klonos, For now we do need this in core. Maybe we can remove it once jquery does what ever is going to do. But right now this is indeed needed.

Is going to be a lot easier to get this in, rather than wait for jquery 1.7, hope it gets in, then get drupal updated.

Jacine’s picture

Issue tags: +HTML5 Sprint: July 2011 - 1

Tagging.

iflista’s picture

Status: Postponed » Needs review

#77: 1077878-77-html5shiv.patch queued for re-testing.

jessebeach’s picture

I took the patch in #82 and added conditional browser loading. This assumes that http://drupal.org/node/865536 is resolved.

ericduran’s picture

The above patch is correct when using the latest patch over at #865536: drupal_add_js() is missing the 'browsers' option

Jacine’s picture

Issue tags: +HTML5 Sprint: August 2011 - 1

Tagging.

chx’s picture

In the "light bulb moment" comment over at http://drupal.org/node/963832#comment-4034464 "jensimmons tells me that without that JS, we still can address these elements by id and classes -- the JS is only needed to use the element names as CSS selectors."

I was also told that http://www.communitymx.com/content/article.cfm?cid=8C170 this is enough. So -- I would like a (much) better issue summary on a) why do we need the shiv at all b) why do we need this specific shim compared to just calling createElement on the HTML5 tags.

amateescu’s picture

I mentioned this in a #drupal-html5 meeting but it's good to have this info here as well. We should keep an eye on this jQuery ticket: http://bugs.jquery.com/ticket/6485 which aims to bring a html5 shiv into jQuery core.

Paul Irish already commited a patch to his branch, so I guess we need some comments in there to say that "Drupal needs this" :)

Jacine’s picture

Issue tags: -internet explorer, -html5, -Front end, -HTML5 Sprint: July 2011 - 1, -HTML5 Sprint: August 2011 - 1

argh... duplicate of the comment below.

Jacine’s picture

In the "light bulb moment" comment over at http://drupal.org/node/963832#comment-4034464 "jensimmons tells me that without that JS, we still can address these elements by id and classes -- the JS is only needed to use the element names as CSS selectors."

We do need a shiv because we will be styling HTML5 elements directly. The alternative is disgusting markup like <div class="article"><article>...</article></div> which we are not doing.

I was also told that http://www.communitymx.com/content/article.cfm?cid=8C170 this is enough. So -- I would like a (much) better issue summary on a) why do we need the shiv at all b) why do we need this specific shim compared to just calling createElement on the HTML5 tags.

That is definitely an older article by Estelle Weyl, but it is telling you that you need the shiv. In her latest book (and every other book and blog I've read so far), it is recommended to use the official HTML5 Shiv. Since that article is older, it's missing an important part of what the official shiv does, which is 2 things:

  1. IE8 and below do not recognize HTML5 elements, and will not render them with CSS styles by default. The HTML5 Shiv uses document.createElement("tag") for each of the new elements. This tricks IE into rendering them with the CSS styles like any other tag. This is the exact same thing that's going on in the article you referenced.
  2. Even with the document.createElement() code, any CSS styles applied don't stick when printing a document. The HTML5 Shiv also includes a script called IE Print Protector which solves this problem too.

I mentioned this in a #drupal-html5 meeting but it's good to have this info here as well. We should keep an eye on this jQuery ticket: http://bugs.jquery.com/ticket/6485 which aims to bring a html5 shiv into jQuery core.

Paul Irish already commited a patch to his branch, so I guess we need some comments in there to say that "Drupal needs this" :)

It's great that it's going to be in jQuery. The problem is that we have no idea when it's coming out. We need this for one simple reason: We need to be able to cross-browser test and work on this initiative unhindered. I fully expect this to be a temporary solution, and by the time Drupal 8 comes out, this will be fully implemented in jQuery, and sitting in Drupal's misc directory, at which point we can simply remove this.

However, until that happens, we need something in place. I asked Paul Irish about this today. I asked him when he thought it'd be coming out, and whether or not we should wait for it to happen, or use the Shiv temporarily. He said:

tbh i would recommend using innershiv along with the regular html5shiv. the jquery impl is too young

I agree with him that we should implement the InnerShiv as well. I mentioned this back in #31 and #93, but people seem to think that's a separate issue. The InnerShiv is needed when elements are dynamically inserted.

seutje’s picture

Issue tags: +internet explorer, +html5, +Front end, +HTML5 Sprint: July 2011 - 1, +HTML5 Sprint: August 2011 - 1

@chx: heh, I wish that were true, unfortunately it results in very inconsistent behavior that's rather hard to debug.
given the following markup:

<!DOCTYPE html>
<html>
<head>
<meta charset=utf-8 />
<style>
  #lol,
  #heh {
    border: 1px solid #F00;
    display: block;
  }
</style>
</head>
<body>
  <section id="lol">lol</section>
  <div id="heh">heh</div>
</body>
</html>

IE6 will render it like this without the shiv, when grabbing the height of #lol, it will return 0...

Jacine’s picture

Issue tags: -HTML5 Sprint: August 2011 - 1 +HTML5 Sprint: August 2011 - 2

This is still waiting on #865536: drupal_add_js() is missing the 'browsers' option, but does anyone have feedback on Paul Irish's comments I posted in #109? Does anyone else see the need for InnerShiv? Also updating the current sprint tag.

klonos’s picture

...Does anyone else see the need for InnerShiv?

Well... its description alone says:

innerShiv makes HTML5shim work on innerHTML & jQuery

...then I guess I see the need too.

idflood’s picture

I think this issue needs to be addressed as soon as possible. In fact, I totally agree with the solution from Jacine in #109. Let's fix this with html5shiv and InnerShiv first and if it's included in jquery in time it's bonus.

stevetweeddale’s picture

@jacine, we absolutely need InnerShiv until it's in jquery core. Having experienced first hand trying to debug why your theme's all janky in IE with ajax requests... well, put it this way: if D8 was released with 'HTML5 support in IE!' without the ajax issue being addressed, there'll be confused/frustrated bug reports in the core issue queue about it for sure!

As soon as #865536: drupal_add_js() is missing the 'browsers' option is done, I'll start a seperate issue for InnerShiv - it'll give some space to explain what it's for and allow for people to comment on the exact implementation we choose etc.

Jacine’s picture

Status: Needs review » Postponed

Ok, great. Thanks guys. Since the innerShiv will be handled in a separate issue, I am postponing this, because there's nothing we can really do here until we get people to test and review #865536: drupal_add_js() is missing the 'browsers' option.

klonos’s picture

Since the innerShiv will be handled in a separate issue...

I did search and found no related issue. Did anybody actually open a separate issue for this? If so, please point us to it. If not, then please either file one or let me know and I will ... just trying to avoid filing dupe issues - till #19386: Automatically search for duplicate issues/questions before submitting new issue/question is fixed ;)

Jacine’s picture

@klonos Feel free to create the issue and link it back here.

klonos’s picture

Done!: #1256132: Add innerShiv to core (after HTML5shiv is in)

...please feel free to update the issue summary with the appropriate info in the "User interface changes" & "API changes" sections or elsewhere as you see fit ;)

cosmicdreams’s picture

Updated #1256132 with an update from the jQuery team. 1.7 will indeed have improved support for HTML5 elements.

klonos’s picture

I've tried my best to put together a summary of what we have debated here. I mention things such as the suggestion of modernizr as an alternative (so that people not reading the entire issue know that it has been mentioned and discussed previously and that it deserves a separate issue) and I also point to its comparison against html5shiv in #73. I mention related articles and other issues that might be of interest + the latest news on the upcoming jQuery 1.7 and the extent of its HTML5 elements support. Lastly, I mention and link to latest patches available for testing/review and Mark's HTML5 legacy support sandbox for those that need to take a quick look at what's been coded so far. If newer patches come up, please also update the summary links to point to them instead.

PS: I did not include the full initial summary by Jeff Burnz, but I do mention it and give credits to him. Reasons being that a) the summary itself is already long as is and b) everything Jeff mentions in the original summary is also mentioned in the new one (if I missed something please feel free to add/correct as you see fit). No intent to disrespect Jeff - I hope you don't mind.

klonos’s picture

Issue summary: View changes

...trying to summarize things.

cosmicdreams’s picture

cosmicdreams’s picture

Issue summary: View changes

...just mentioning that innerShiv might no be required if jQuery 1.7 gets in core.

Mark Trapp’s picture

#120 The idea that the HTML5 shiv should/could be separated from the theme system—either in a module or by placing the shiv in themes that need it—was more or less rejected by later consensus, so I've removed the reference to my sandbox project: something like it won't make it into core.

ericduran’s picture

@Mark Trapp for D7 this is easily accomplished by either using the html5_tools module which provides the shiv for any theme. Or you can use any of the many themes such as zen that have it build in.

Mark Trapp’s picture

@ericduran Whether it can be done in Drupal 7 wasn't the issue: I tried to argue (unsuccessfully) from #1 to #54 that we shouldn't be forcing anyone who uses the theme system to use the shiv by default, and that it should instead be included in the core themes that need it or as an optional core module (which was the reason for the sandbox project).

My position was rejected and now this issue is about making sure HTML5shiv gets into core, so mentioning the sandbox project in the summary as a way to move forward would be inappropriate.

klonos’s picture

Fair enough Mark, but still the summary is there for people to speed-read instead of having to go through the entire issue. So, how about striking through the non-relative-any-more part of the summary (using del tags) and adding the info about the general consensus you mention in #122 & #124. This helps us avoid the issue being brought up again by people that haven't thoroughly read all the issue's posts, since they will know it's been discussed and rejected.

Jacine’s picture

Issue tags: -Front end, -HTML5 Sprint: July 2011 - 1, -HTML5 Sprint: August 2011 - 2

Cleaning up tags.

klonos’s picture

We're really close to fixing #865536: drupal_add_js() is missing the 'browsers' option that holds this issue here too ;)

RobLoach’s picture

Quick note: jQuery 1.7 RC2 is out and comes with some additional HTML5 support for IE7. #1085590: Update to jQuery UI 1.9 needs a re-roll....

We can still do HTML5shiv, just wanted to ping people on it.

Mark Trapp’s picture

ericduran’s picture

Status: Postponed » Active

@Rob Loach, The html5shiv is still required. For more info see http://bugs.jquery.com/ticket/6485. In Jquery 1.7 the innershiv won't be required but the regular shiv is still needed.

Switching this to active patch coming soon. This can easily get committed right after #865536

ericduran’s picture

FileSize
0 bytes

and here's the re-rolled, lease as needs work as the patch doesn't apply yet.

ericduran’s picture

Status: Active » Needs work
FileSize
4.43 KB

Not sure what happen there.

ericduran’s picture

FileSize
4.44 KB

Also another patch. I can't seem to get this right today ;-)

Here's my own review on parts I still think needs works.

+++ b/core/modules/system/system.moduleundefined
@@ -1181,6 +1181,17 @@ function system_library_info() {
+  // html5shim.
+  $libraries['html5shim'] = array(

This can use a better comment. Also the html5shim should be name spaced like every other library (ex. drupal. or jquery.) but I'm not really sure what to namespace it with.

29 days to next Drupal core point release.

RobLoach’s picture

+++ b/core/modules/system/system.moduleundefined
@@ -1181,6 +1181,17 @@ function system_library_info() {
+    'version' => 'r10',

This is meant to be used with version_compare, so it might be better to use a version like "2.1-pre".

+++ b/core/modules/system/system.moduleundefined
@@ -1181,6 +1181,17 @@ function system_library_info() {
+      'core/misc/html5.js' => array('group' => JS_LIBRARY, 'weight' => -18, 'browsers' => array('IE' => 'lte IE 8', '!IE' => FALSE,),

Could we split this array definition into a number of different lines to clean it up?

Regarding "weight" = -18, we probably want to use something like JS_DEFAULT - 10, or something along those lines. Want to avoid using magic numbers as much as possible.

28 days to next Drupal core point release.

Also the html5shim should be name spaced like every other library (ex. drupal. or jquery.) but I'm not really sure what to namespace it with.

"html5shim" is fine, since that is the name of the library, and there will likely be no other library that will have that name.

ericduran’s picture

Makes sense. A couple of feedback.

+++ b/core/modules/system/system.moduleundefined
@@ -1181,6 +1181,17 @@ function system_library_info() {
+    'version' => 'r10'

I'm not sure what the version actually should be. I just re-rolled the last patch. Any feedback from anyone, I think we should just used 1.0 as I don't see that script ever changing. But does it have a version number somewhere? I couldn't find it.

I'm also against 'weight' => -18, but I didn't really pay attention to the weight, I'm not really sure why we want it to be -18 yet so I would hold of on the JS_DEFAULT - 10.

If everyone is ok with html5shim being that name of the library thats fine with me.

Are there any feedback on the version/weight? Or why those numbers where decided before.

Thanks.

ericduran’s picture

Status: Needs work » Needs review
FileSize
2.2 KB

Ok, here's an actual patch.

I use the weight at -21 this was to place it before all the other JS_LIBRARY. We can argue over the number, but I figure I'll put it before all the JS. -21 is indeed a magic number, but we can fix that in another issue mainly because the other libraries also have random -20, -19 as their weights.

I switch the version of the html5shim to version 1.0 - I'm not sure if this is the actual version number, but I can't really find the real version number out.

ericduran’s picture

FileSize
4.44 KB

Now a useful patch lol with the actual shiv in it. Thanks @aspilicious.

ericduran’s picture

Issue summary: View changes

Keeping HTML5 legacy support as a separate module was rejected.

ericduran’s picture

Issue summary: View changes

Updating to reflect no longer being dependent on the other issue.

ericduran’s picture

FileSize
4.43 KB

I updated the website to be the appropriate link. Also removed an extra comma.

This is a pretty small patch, I think the only thing left to discuss is if this should have such a low weight. I decided it should be before all other JS. But I honestly have no opinion over the weight.

Lets get this one done :)

edit: Updated issue summary to reflect no more blockers.

RobLoach’s picture

Status: Needs review » Needs work

Looking at the jQuery 1.7 announcement, it makes note of HTML5 Shiv. Should we use Shiv instead of Shim? They're pretty much the same, but just want to make sure we're future-proof.

+++ b/core/modules/system/system.moduleundefined
@@ -1240,6 +1240,20 @@ function system_library_info() {
+    'version' => '1.0',

Got an idea for the version... Use the revision number in the SVN.... So, 23 if we use shiv, and 11 if we use shim? I understand that's what you had before, "r10", but I missed it sorry. Just the number will be version_compare compatible.

26 days to next Drupal core point release.

rupl’s picture

Shim and shiv are two names for the same piece of code. Their Google code pages are identical as well:

http://code.google.com/p/html5shim/
http://code.google.com/p/html5shiv/

Common question: what's the difference between the html5shim and the html5shiv?
Answer: nothing, one has an m and one has a v - that's it.

Not to bikeshed, but shim is the "correct" term. Shiv was merely said first.

ericduran’s picture

Status: Needs work » Needs review
FileSize
4.43 KB

Thanks @Rob Loach, I updated the version to be the svn revision number.

I didn't change the shim to shiv, because of @rupl comment above, but I'll change it to what ever we agree on.

cosmicdreams’s picture

I'm going to be working on other stuff tonight so I'll test this patch. What specific tests, above and beyond what I can think of, would you like me to perform?

ericduran’s picture

This is a pretty easy one, the html5.js just needs to be on the page, with the ie conditional around. It doesn't really do anything you'll be able to see. Unless you actually test that the shim works on ie but that seems excessive

cosmicdreams’s picture

As per a previous discussion I had about testing external libraries within the Drupal context, I probably should the actual library since it is assumed that libraries that have their own unit tests are testing their own stuff.

But... I suppose I could test d8 + a HTML 5 theme + this patch and see if I can do some javascript driven tests to try to break it.

ericduran’s picture

The only way to actually test this library is by viewing a site on ie6/7 as this patch is mostly for rendering engine.

You can add an article tag : Test and add a css : article {background: red; } and see if it shows up red on IE.

That should do it.

cosmicdreams’s picture

Testing this now...

After applying the patch, using Chrome, I noticed the html5.js javascript was being loaded on the page users running IE8 and older versions of IE.

I modified the page.tpl.php to include an article tag and add inline styles to make the background of that tag to be red.

As a Chrome user, I noticed that the article appeared with a red background.

As a IE9 user, I noticed the same as Chrome
As a IE8 user, I noticed the same as IE9
As a IE7 user, I noticed the same as IE8

and just for kicks

As a IE6 user, I saw the text I provided in between the starting and closing article tags, but I did not see the red background I expected.

Since we don't support IE6 anymore I don't think we should care. This is likely a deficiency in the HTML5shim anyways.

so.... I recommend RTBC

cosmicdreams’s picture

Status: Needs review » Reviewed & tested by the community

advancing state of issue given the above.

mortendk’s picture

+1 rtbc

Jacine’s picture

Thanks @ericduran. I agree this is ready.

catch’s picture

Status: Reviewed & tested by the community » Needs review
+++ b/core/includes/common.incundefined
@@ -3995,6 +3995,7 @@ function drupal_add_js($data = NULL, $options = NULL) {
+      drupal_add_library('system', 'html5shim', TRUE);

shim

+++ b/core/misc/html5.jsundefined
@@ -0,0 +1,4 @@
+// html5shiv @rem remysharp.com/html5-enabling-script

shiv?

15 days to next Drupal core point release.

Jacine’s picture

Status: Needs review » Needs work

@catch Yeah, it goes by 2 names...

http://code.google.com/p/html5shim/
http://code.google.com/p/html5shiv/

Common question: what's the difference between the html5shim and the html5shiv? Answer: nothing, one has an m and one has a v - that's it.

I didn't notice that though. Given that html5shiv is what is used in both files, and shiv is what most people call it (including the title of this issue) I think we should just call it shiv.

catch’s picture

Yeah I'm fine with either (and shiv seems to be more common), but we should pick one and stick to it.

ericduran’s picture

Status: Needs review » Needs work
FileSize
4.43 KB

Jacine is so cool, she re-rolled the patch for me and ping me on irc to upload it. so I can get the proper credit. lol

ericduran’s picture

Status: Needs work » Needs review
Jacine’s picture

Status: Needs work » Reviewed & tested by the community

LOL! Thanks @ericduran ;)

catch’s picture

I should have caught this in #865536: drupal_add_js() is missing the 'browsers' option but I didn't..

+        'browsers' => array('IE' => 'lte IE 8', '!IE' => FALSE),

Why can't I do:

+        'browsers' => array('IE' => 'lte IE 8',

and have that just assume I don't want it for anything else. This would match how conditional comments actually look as well.

It's off-topic here but since this is the first core code using the feature (and I don't think the tests in the other issue tested the hook_library_info() version) it'd be good to sort this out before we start using it any more.

ericduran’s picture

@catch I think thats actually unrelated to both issues. Being that that is the way drupal_pre_render_conditional_comments works now.

I do agree it is weird, do you think we should add a follow up issue on that?

I'll try to track down why it was done that way.

Jacine’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
4.9 KB

Here's a patch with a changelog entry.

And here's a follow up issue for #157: #1344364: Simplify the syntax of the 'browsers' option in drupal_add_css() and drupal_add_js()

catch’s picture

Category: feature » task
Priority: Normal » Critical
Status: Needs review » Active

Thanks! Since the latest update was only adding the CHANGELOG.txt entry I asked for in irc, committed/pushed to 8.x.

This needs a change notification as well.

catch’s picture

Title: Add HTML5shiv to core » Change notification for: Add HTML5shiv to core
cosmicdreams’s picture

How does one properly make a "change notification"?

webchick’s picture

There's a form at http://drupal.org/node/add/changenotice that populates the view at http://drupal.org/list-changes :)

cosmicdreams’s picture

Robust!

I don't feel comfortable summarizing this particular issue but I've bookmarked the form to handle future issues.

ericduran’s picture

Title: Change notification for: Add HTML5shiv to core » Add HTML5shiv to core
Category: task » feature
Priority: Critical » Normal
Status: Active » Fixed

Change notifications created - http://drupal.org/node/1344808

Status: Fixed » Closed (fixed)

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

JohnAlbin’s picture

Note that an updated HTML5 shim version 3 came out on Dec 22. #1389058: Update html5shiv-printshiv to the latest (minified) version - currently 3.7.2

JohnAlbin’s picture

Issue summary: View changes

Updated issue summary.