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...]
Comment | File | Size | Author |
---|---|---|---|
#159 | 1077878-159.patch | 4.9 KB | Jacine |
#154 | 1077878-154.patch | 4.43 KB | ericduran |
#142 | 1077878-142.patch | 4.43 KB | ericduran |
#139 | 1077878-139.patch | 4.43 KB | ericduran |
#138 | 1077878-138.patch | 4.44 KB | ericduran |
Comments
Comment #1
Mark TrappWhat's the solution for no-js?
Comment #2
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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.
Comment #3
Mark TrappIf 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.
Comment #4
Jeff Burnz CreditAttribution: Jeff Burnz commented"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.
Comment #5
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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:
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.
Comment #6
Jeff Burnz CreditAttribution: Jeff Burnz commentedMark, 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.
Comment #7
Mark TrappI 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.
Comment #8
Jeff Burnz CreditAttribution: Jeff Burnz commentedVery 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.
Comment #9
scor CreditAttribution: scor commentedsubscribe
Comment #10
droplet CreditAttribution: droplet commentedThat'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!!
Comment #11
klonos...subscribing.
Comment #12
klonos+ adding tag ;)
Comment #13
Jeff Burnz CreditAttribution: Jeff Burnz commentedAs 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.
Comment #14
dcrocks CreditAttribution: dcrocks commentedAnd 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.
Comment #15
sreynen CreditAttribution: sreynen commentedI'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.
Comment #16
Jeff Burnz CreditAttribution: Jeff Burnz commentedThat 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.
Comment #17
Everett Zufelt CreditAttribution: Everett Zufelt commented@Jeff
Can you give an example of where you see the use of certain html5 sectioning elements being a problem in Core?
Comment #18
Jeff Burnz CreditAttribution: Jeff Burnz commented@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.
Comment #19
Jeff Burnz CreditAttribution: Jeff Burnz commentedtagging with Jacines new Front end tag.
Comment #20
sreynen CreditAttribution: sreynen commentedCan 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?
Comment #21
Jeff Burnz CreditAttribution: Jeff Burnz commented#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.
Comment #22
sreynen CreditAttribution: sreynen commentedI'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.
Comment #23
Jeff Burnz CreditAttribution: Jeff Burnz commented#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.
Comment #24
sreynen CreditAttribution: sreynen commentedThanks 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.
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.
Comment #25
klonos...don't mind me also including the old issue's title so I remember where we started from(?).
Comment #26
Jeff Burnz CreditAttribution: Jeff Burnz commentedThe 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.
Comment #27
sreynen CreditAttribution: sreynen commentedI 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.
Comment #28
Jeff Burnz CreditAttribution: Jeff Burnz commentedI 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.
Comment #29
droplet CreditAttribution: droplet commentedHi, 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 ?
Comment #30
Jeff Burnz CreditAttribution: Jeff Burnz commentedWell 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.
Comment #31
JacineI 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:
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.
Comment #32
Jeff Burnz CreditAttribution: Jeff Burnz commentedA 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).
Comment #33
klonosIt 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...
Comment #34
klonos...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.
Comment #35
Mark TrappIf 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.
Comment #36
Jeff Burnz CreditAttribution: Jeff Burnz commentedIts 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).
Comment #37
JacineMark, 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.
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.
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.
Comment #38
Mark Trapp@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.
Comment #39
adrinux CreditAttribution: adrinux commentedThis 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.
Comment #40
dvessel CreditAttribution: dvessel commentedJust 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.
Comment #41
JacineI 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... ;)
Comment #42
Jeff Burnz CreditAttribution: Jeff Burnz commenteddvessel - 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?Comment #43
dcrocks CreditAttribution: dcrocks commentedAs 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.
Comment #44
dvessel CreditAttribution: dvessel commentedJeff, 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.
Comment #45
dvessel CreditAttribution: dvessel commentedJacine, 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.
Comment #46
Mark Trapp#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.
Comment #47
Mark TrappI 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.
Comment #48
JohnAlbinSupport for IE8 in Drupal 8
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)
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
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
Comment #49
JohnAlbinI 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.
Comment #50
Mark TrappFirstly, 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.
Comment #51
adrinux CreditAttribution: adrinux commentedOne 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 ;)
Comment #52
jide CreditAttribution: jide commentedMaybe 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).
Comment #53
sunThanks @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:
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.
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.
misc/
and the library should be registered and loaded by system.module. An own html5.module does not make sense here.Comment #54
Mark TrappTo 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.
If that's the case, there shouldn't be a shiv in core at all.
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.
Comment #55
Mark TrappAttached are patches that use shim instead of shiv:
Comment #57
dvessel CreditAttribution: dvessel commentedAlthough 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.
Comment #58
Mark TrappRerolled failed no-conditional patch (and attached passed conditional patch from #55 to keep things together).
Comment #59
dcrocks CreditAttribution: dcrocks commentedThis 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.
Comment #60
adrinux CreditAttribution: adrinux commentedA timely post from Paul Irish today: http://paulirish.com/2011/the-history-of-the-html5-shiv/
Comment #61
dvessel CreditAttribution: dvessel commenteddcrocks, 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.
Comment #62
sun@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.
Comment #63
dvessel CreditAttribution: dvessel commentedsun, 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.
Comment #64
jide CreditAttribution: jide commentedCouldn't the ongoing work on plugins subsystems #363787: Plugins: Swappable subsystems for core help here ?
Comment #65
webchickSubscribing. Will chime in here later.
Comment #66
webchickSome random thoughts (I composed this as I was writing the thread, but I see JohnAlbin/sun made similar points):
<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.Comment #67
dcrocks CreditAttribution: dcrocks commented+ to all of the above.
Comment #68
JacineThanks @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
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.
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.
Comment #69
JacineIt's done: http://code.google.com/p/html5shiv/ :)
Comment #70
dvessel CreditAttribution: dvessel commentedThe 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.
Comment #71
klonosI like the route this is taking too.
Comment #72
cosmicdreams CreditAttribution: cosmicdreams commentedSweeeet. 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?
Comment #73
Jacine@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/
document.createElement("tag")
for each of the new elements. This forces IE to render them with the CSS styles like any other tag.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/
<html>
element indicating the status in your browser, e.g. Ageolocation
class is added when support exists, andno-geolocation
when it doesn't.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.
Comment #74
JohnAlbinWell, 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.
Comment #76
seutje CreditAttribution: seutje commented@#5
when I have to support IE with JS turned off, I usually do it the other way around:
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...)
Comment #77
JohnAlbinOops. 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?
Comment #79
aspilicious CreditAttribution: aspilicious commentedHmm this is not html5 related I think ;)
Powered by Dreditor.
Comment #80
sunhah! 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.
Comment #81
Jeff Burnz CreditAttribution: Jeff Burnz commentedAnd that issue is: #865536: drupal_add_js() is missing the 'browsers' option
Comment #82
JohnAlbinBah. 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>
orgit format-patch --stdout 8.x
.Comment #83
RobLoachWe 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.
Comment #84
aspilicious CreditAttribution: aspilicious commentedRob, 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?
Comment #85
aspilicious CreditAttribution: aspilicious commentedAnother 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.
Comment #86
RobLoachCool! So let's hit #865536: drupal_add_js() is missing the 'browsers' option and get conditional browsers in there :-) .
Comment #87
seutje CreditAttribution: seutje commentedalso: afaik, people using windows XP will never be able to install IE9/10 without upgrading to at least vista
Comment #88
aspilicious CreditAttribution: aspilicious commentedIts even worse, they need windows 7.
Comment #89
Jeff Burnz CreditAttribution: Jeff Burnz commentedLooks like IE9 runs on Vista, just did the upgrade one of our craptops.
Comment #90
aspilicious CreditAttribution: aspilicious commentedJeff Burnz thnx for your reply. I was prety sure it didn't run on vista. Luckily I'm proven wrong :)
Comment #91
alexanderpas CreditAttribution: alexanderpas commentedIE9 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.
Comment #92
stevetweeddale CreditAttribution: stevetweeddale commentedJust 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.
Comment #93
Jacine#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.
Comment #94
aspilicious CreditAttribution: aspilicious commentedWe 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)
Comment #95
bstoppel CreditAttribution: bstoppel commentedFor 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.
Comment #96
ericduran CreditAttribution: ericduran commentedsub. (Also I don't think we need a messages, thats why we're adding the html5shiv.)
Comment #97
ericduran CreditAttribution: ericduran commentedI 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
Comment #98
ericduran CreditAttribution: ericduran commentedIgnore my previous comment. I take my .02 back :)
Patch in the other issue.
Comment #99
klonosI 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.
Comment #100
ericduran CreditAttribution: ericduran commented@ 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.
Comment #101
JacineTagging.
Comment #102
iflista CreditAttribution: iflista commented#77: 1077878-77-html5shiv.patch queued for re-testing.
Comment #103
jessebeach CreditAttribution: jessebeach commentedI took the patch in #82 and added conditional browser loading. This assumes that http://drupal.org/node/865536 is resolved.
Comment #104
ericduran CreditAttribution: ericduran commentedThe above patch is correct when using the latest patch over at #865536: drupal_add_js() is missing the 'browsers' option
Comment #105
JacineTagging.
Comment #106
chx CreditAttribution: chx commentedIn 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.
Comment #107
amateescu CreditAttribution: amateescu commentedI 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" :)
Comment #108
Jacineargh... duplicate of the comment below.
Comment #109
JacineWe 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.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:
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:
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.
Comment #110
seutje CreditAttribution: seutje commented@chx: heh, I wish that were true, unfortunately it results in very inconsistent behavior that's rather hard to debug.
given the following markup:
IE6 will render it like this without the shiv, when grabbing the height of #lol, it will return 0...
Comment #111
JacineThis 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.
Comment #112
klonosWell... its description alone says:
...then I guess I see the need too.
Comment #113
idflood CreditAttribution: idflood commentedI 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.
Comment #114
stevetweeddale CreditAttribution: stevetweeddale commented@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.
Comment #115
JacineOk, 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.
Comment #116
klonosI 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 ;)
Comment #117
Jacine@klonos Feel free to create the issue and link it back here.
Comment #118
klonosDone!: #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 ;)
Comment #119
cosmicdreams CreditAttribution: cosmicdreams commentedUpdated #1256132 with an update from the jQuery team. 1.7 will indeed have improved support for HTML5 elements.
Comment #120
klonosI'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.
Comment #120.0
klonos...trying to summarize things.
Comment #121
cosmicdreams CreditAttribution: cosmicdreams commented#1190206: Convert taxonomy-term.html.twig to HTML5 depends on this issue.
Comment #121.0
cosmicdreams CreditAttribution: cosmicdreams commented...just mentioning that innerShiv might no be required if jQuery 1.7 gets in core.
Comment #122
Mark Trapp#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.
Comment #123
ericduran CreditAttribution: ericduran commented@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.
Comment #124
Mark Trapp@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.
Comment #125
klonosFair 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.Comment #126
JacineCleaning up tags.
Comment #127
klonosWe're really close to fixing #865536: drupal_add_js() is missing the 'browsers' option that holds this issue here too ;)
Comment #128
RobLoachQuick 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.
Comment #130
Mark TrappComment #131
ericduran CreditAttribution: ericduran commented@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
Comment #132
ericduran CreditAttribution: ericduran commentedand here's the re-rolled, lease as needs work as the patch doesn't apply yet.
Comment #133
ericduran CreditAttribution: ericduran commentedNot sure what happen there.
Comment #134
ericduran CreditAttribution: ericduran commentedAlso another patch. I can't seem to get this right today ;-)
Here's my own review on parts I still think needs works.
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.
Comment #135
RobLoachThis is meant to be used with version_compare, so it might be better to use a version like "2.1-pre".
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.
"html5shim" is fine, since that is the name of the library, and there will likely be no other library that will have that name.
Comment #136
ericduran CreditAttribution: ericduran commentedMakes sense. A couple of feedback.
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.
Comment #137
ericduran CreditAttribution: ericduran commentedOk, 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.
Comment #138
ericduran CreditAttribution: ericduran commentedNow a useful patch lol with the actual shiv in it. Thanks @aspilicious.
Comment #138.0
ericduran CreditAttribution: ericduran commentedKeeping HTML5 legacy support as a separate module was rejected.
Comment #138.1
ericduran CreditAttribution: ericduran commentedUpdating to reflect no longer being dependent on the other issue.
Comment #139
ericduran CreditAttribution: ericduran commentedI 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.
Comment #140
RobLoachLooking 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.
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.
Comment #141
ruplShim 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/
Not to bikeshed, but shim is the "correct" term. Shiv was merely said first.
Comment #142
ericduran CreditAttribution: ericduran commentedThanks @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.
Comment #143
cosmicdreams CreditAttribution: cosmicdreams commentedI'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?
Comment #144
ericduran CreditAttribution: ericduran commentedThis 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
Comment #145
cosmicdreams CreditAttribution: cosmicdreams commentedAs 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.
Comment #146
ericduran CreditAttribution: ericduran commentedThe 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.
Comment #147
cosmicdreams CreditAttribution: cosmicdreams commentedTesting 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
Comment #148
cosmicdreams CreditAttribution: cosmicdreams commentedadvancing state of issue given the above.
Comment #149
mortendk CreditAttribution: mortendk commented+1 rtbc
Comment #150
JacineThanks @ericduran. I agree this is ready.
Comment #151
catchshim
shiv?
15 days to next Drupal core point release.
Comment #152
Jacine@catch Yeah, it goes by 2 names...
http://code.google.com/p/html5shim/
http://code.google.com/p/html5shiv/
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.
Comment #153
catchYeah I'm fine with either (and shiv seems to be more common), but we should pick one and stick to it.
Comment #154
ericduran CreditAttribution: ericduran commentedJacine 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
Comment #155
ericduran CreditAttribution: ericduran commentedComment #156
JacineLOL! Thanks @ericduran ;)
Comment #157
catchI should have caught this in #865536: drupal_add_js() is missing the 'browsers' option but I didn't..
Why can't I do:
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.
Comment #158
ericduran CreditAttribution: ericduran commented@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.
Comment #159
JacineHere'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()
Comment #160
catchThanks! 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.
Comment #161
catchComment #162
cosmicdreams CreditAttribution: cosmicdreams commentedHow does one properly make a "change notification"?
Comment #163
webchickThere's a form at http://drupal.org/node/add/changenotice that populates the view at http://drupal.org/list-changes :)
Comment #164
cosmicdreams CreditAttribution: cosmicdreams commentedRobust!
I don't feel comfortable summarizing this particular issue but I've bookmarked the form to handle future issues.
Comment #165
ericduran CreditAttribution: ericduran commentedChange notifications created - http://drupal.org/node/1344808
Comment #167
JohnAlbinNote 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
Comment #167.0
JohnAlbinUpdated issue summary.