Commit
…oldie class. http://mathiasbynens.be/notes/safe-css-hacks We're doing this because that quadruple conditional comment <html> tag definition looks pretty scary and especially when combined with namespace augmenting stuff like Facebook's gross xmlns:fb="http://www.facebook.com/2008/fbml" bullshit. We are trying to simplify the markup we use in H5BP and a combination of conditional classnames with IE-specific hacks would be much simpler than the markup bloat we currently have. We'll target IE6 and IE7 specifically with attribute syntax hacks. http://paulirish.com/2009/browser-specific-css-hacks/ /* CLEAN NO HACKS */ div { color: blue; } /* HACKS FOR IE */ .oldie div { color: blue; /* IE 8 and below */ *color: blue; /* IE 7 and below */ _color: blue; /* IE 6 */ } /* IE6, IE7 - star hack */ .oldie div { *color: blue; } /* IE8 - winning hack */ .oldie div { color: blue\0/; } /* must be last declaration in the selector's ruleset */ Using these attribute hacks by themselves does not change the selector specificity. If you've worked with a large, long-term codebase, you'll know managing your specificity wisely is critical. Also watch Nicole Sullivan's talks.
- Loading branch information
There are no files selected for viewing
52 comments
on commit e5e057e
There was a problem hiding this comment.
Hm I think I'll be sticking to using the .ie6 and .ie7 classes rather than resorting to hacks. The only real benefit is that you don't have to repeat the <html> tag, but with a bit of server-side script it's very easy to generate those first few lines.
I'd much rather have clean CSS and a single (if ugly) HTML head, rather than lots of ugly hacks throughout the CSS. But I guess it's just a personal preference.
Damn you, IE!
There was a problem hiding this comment.
We do recommend you scope your hacks with .oldie, except just use hacks within that scope! Simpler on both ends.
There was a problem hiding this comment.
Also we should mention..
We're very happy to get feedback on this.. If you guys say you cannot live with this.. we will revert. But I think it's a good direction to go in. :)
Comment away!
There was a problem hiding this comment.
I like it, thanks for the change.
There was a problem hiding this comment.
It would also be great if people could have a read of Mathias' article on CSS hacks, maybe try this code out a little in practice, and then share your thoughts and experiences so we can understand any specific problems or benefits.
There was a problem hiding this comment.
I'm with neave. The old way you write the opening html tag once (or rather, four times) and you don't have to think about it again. This new way is less effort up-front (not much less) but then you have to remember the IE hacks every time you test in IE.
No matter, I just won't merge this change into my projects.
There was a problem hiding this comment.
In my stuff, it's always IE6 and IE7 together, and IE8 sometimes needs its own (or it often just works with the base rules).
There was a problem hiding this comment.
I disagree with this change. With conditional classes, it was very clear what styles were applied to which browser. CSS hacks don't have inherent meaning, which decreases maintainability in my opinion. They're probably fine if you're the only one writing the stylesheet, but I don't think they scale to a team environment.
At least keep both versions so we can pick which one we want.
There was a problem hiding this comment.
I don't understand this change. According to Mathias' post, this new solution still has most of the cons of the original.
The CSS hacks are much less readable, obvious, meaningful, etc. They're harder to notice and more complicated to remember and use. The only advantage I see to .oldie is having 1 class to target all old versions of IE. If that's wanted, why not just add an additional "ie" class to all the html tags?
This change might be good if it completely eliminated the conditionals, but it doesn't.
There was a problem hiding this comment.
The "cons" mentioned in @mathiasbynens post are these:
- They’re called CSS hacks for a reason — only use safe CSS hacks.
- There’s no safe CSS hack for IE8 (yet?).
- Contrary to conditional comments, most CSS hacks don’t validate. But then again, CSS3 properties and vendor-prefixed properties don’t validate either
What we need to target are mostly IE6 and IE7. We recommend that you scope IE6 and IE7 hacks within the oldIE selector. Our hope is that anyone who sees the term 'oldie" would recognize these are hacks for IE.
If you think that will not be the case, then do let us know what name would be appropriate. We are also looking into adding this as a comment in the CSS file to make it easier to remember/use the hacks.
There was a problem hiding this comment.
@nimbupani sorry I was referring to his cons for the conditional method:
- Using conditional comments around the opening tag throws IE into compatibility view unless you set the UX-A-Compatible header in a server-side config.
- Simon Pieters reports that using conditional comments before causes IE to ignore the . So again, you’ll need to set the UX-A-Compatible header in a server-side config.
This change is simplifying the markup, but it will probably up making CSS more complex so I personally don't see the benefit.
There was a problem hiding this comment.
CSS hacks make baby jesus cry. :'(
If it's perfectly acceptable to make use of modernizr to target your CSS at functionality known to be available, then I don't see why it wouldn't be just as acceptable to use something like uacss to target your CSS at known bugs and functionality that is unavailable. Given that the conditional comments provide exactly the same functionality for IE without requiring javascript, and a sane method of transitioning from that to uacss if you DO need to target some other browser, it is (for me, personally) more appealing. Insert disclaimer about this being an opinion here.
uacss is part of dojo. I'm currently making use of a version I pulled out to be framework agnostic:
https://gist.github.com/859799/1310b71794bf184b4abe573e4bf2866e50b6fb5f
There was a problem hiding this comment.
This is far less readable in the CSS compared to declarative fixes. We did change this to add a global .ie so you could target all old MSIE
There was a problem hiding this comment.
There are only two hacks that need to be remembered, * and _. They are both scoped to .oldie class in our change which means even if you accidentally remove the hack, it will still only impact old IEs. It is safe to use.
What is not so clear is which hack is for what. This is what we are looking to address within the CSS file itself.
We feel this is a better way to deal with IE issues than to try dealing with them in the markup.
@swalkinshaw for #1 of the "Cons" we are looking at solutions in #378 seems like we have one that would work.
#2 is a problem we know but have chosen not to deal with in the interest of this being a documentation of best practices and not of ways to reinforce legacy rendering.
There was a problem hiding this comment.
Now that many people are pushing html5, javascript is required for new html5 elements in internet explorer. I mean try looking at an HTML5 site in IE with js disabled, well it isn't pretty nor is it remotely usable. Anyways if people have already concluded to using html5 elements in IE(and therefore requiring js for IE) then I honestly I think for those cases we should being adding the IE classes using javascript in mordernzr or the html5 shim.
Basically who cares if a site goes from broken and unusable -> more broken and unusable? I mean it appears javascript in html5boilerplate is already a requirement for IE. The added bonus is that it would remove all conditional comments from the head of the web page and solving it sounds like several problems.
Now for the people here who don't use html5 elements but really html4 with a nicer syntax then conditional comments are currently the best way to go, at least if they want to support IE with out javascript enabled.
There was a problem hiding this comment.
@limeblack it is not a requirement with H5BP. You can use divs with H5BP instead of the section elements. These changes have nothing to do with JS being enabled or disabled they would work either way.
There was a problem hiding this comment.
All I'm suggesting is for the people using html5 elements, I would remove the conditional comments all together. Not to say is should be in the master, but it definitely should be recognized. For example I am currently using divs for backwards compatibility. With all these html purists I figured it should be recognized as an option to make the main html document cleaner.
All I am suggesting, is for sites already requiring js(because of html5 elements), there would be no loss in moving the IE classes to one of the head javascript files.
Assuming your are using html5 elements, then the designer has already required the availability of javascript for IE.
Basically I was trying to show a middle ground that....
- Removes conditional comments from around the html and therefore "purifies" :) the html
- Allows for clear concise CSS
- Doesn't rely on CSS hacks
- Having no conditional comments would also solve this issue: "conditional comments around the opening tag throws IE into compatibility view unless you set the UX-A-Compatible header in a server-side config."
I'm not suggesting it should be in the master, but for sites already requiring js(structured throughly with html5) then adding the classes through a javascript code in mordnizr or shim would provide concise CSS, clean html and in many ways a simpler alternative.
There was a problem hiding this comment.
I am for removing the conditionals. Browser conditional CSS classes are used less and less in website theming. IE needs JS for HTML5 and this is an HTML5 boilerplate. The conditionals should be the exception, not the other way around. My biggest issue with taking them out is that H5BP already had had them, so there's the issue of legacy. Otherwise, I see a very strong argument for their removal entirely.
There was a problem hiding this comment.
In case it wasn’t obvious from my article, I’m all for reducing the number of conditionals used. :) The use of the _ and * hacks is a no-brainer, really. Love the .oldie class by the way – I was thinking of using that when I wrote the article but decided to go with the more neutral .lte-ie-8 instead.
The only thing I would be wary of is the winning hack (\0/):
.oldie div { color: blue\0/; }
For one, it has to be the last declaration in the selector’s ruleset, which is far from ideal. I haven’t done much practical testing, but what happens if you try to use two winning hacks in the same rule set? Is the last one ignored, or what? IMHO, it feels a little bit too hacky to be considered a safe hack.
(Btw, the commit message refers to this hack as the “IE8 Winning Hack” but it actually works in IE9 as well.)
Adding a rule for IE8 and overruling it later for IE7 and IE6 using the * hack could be an alternative. Any other ideas?
There was a problem hiding this comment.
Would anything like this be acceptable? Newer <html> elements conquer older ones, with one caveat mentioned below.
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<title>Document</title>
<!--[if IE 9]><html class="ie9"><![endif]-->
<!--[if IE 8]><html class="ie8"><![endif]-->
<!--[if IE 7]><html class="ie7"><![endif]-->
<!--[if IE 6]><html class="ie6"><![endif]-->
</head>
<body>
</body>
</html>
So, the one issue with this technique is that If you add a classname to the unconditioned <html class="no-js"> then the <!--[if IE]><html class="no-js ie"><![endif]--> is ignored. However, we can turn this frown upside down by using IE's logic against itself with something like <!--[if IE]><body class="ie"><![endif]--><body>.
Since I'm throwing out ideas; here is another.
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<title>Document</title>
<!--[if IE 9]><ie9><![endif]-->
<!--[if IE 8]><ie8><![endif]-->
<!--[if IE 7]><ie7><![endif]-->
<!--[if IE 6]><ie6><![endif]-->
</head>
<body>
</body>
</html>
With this technique, the <ieX> element becomes a child of <body>, which means we can't target html or body, but an advantage is that the ie selector is less powerful than the .ieX selector.
There was a problem hiding this comment.
I think it's time to use .oldie class instead of all the other .ie6/.ie7/.ie8 classes. I mean, normally a site won't need more than the .oldie class and if you really have to use more than that you still can use old method for this few sites. Right?
There was a problem hiding this comment.
agree with chrisjaure, neave and others, as I already wrote in mathias blog. for my developing habits the cons of conditional classes are not so impacting (and I don't use the conditional class for IE6, since it's a browser my company dismissed.)
There was a problem hiding this comment.
This isn't optimized for speed or shortness but for example ie css class support for now and until like forever.
source: http://james.padolsey.com/javascript/detect-ie-in-js-using-conditional-comments/
/*@cc_on
var undef,
v = 4,
div = document.createElement('div'),
all = div.getElementsByTagName('i');
while (
div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
all[0]
);
if(v>5)document.documentElement.className += ' ie ie'+v;
@*/
If we are going to stick with IE hacks, personally I like the clarity of the !bug and the * html ie6 bug.
div{
background:blue !ie67
}
* html div{
background:green;
}
There was a problem hiding this comment.
I can sympathise with the objections to this change. Whether we revert or stick with this, the other option(s) could be thoroughly described in the wiki for those who which to change the default approach.
@mathias Last night I did some testing on the \0/ hack and it worked fine when not the last declaration (as long as not overridden), and when used in multiple declarations.
@jonathantneal Interesting find. I'd tried something similar but didn't realise the presence of a class on the first tag prevented subsequent tags (in CCs) from having any effect. Not quite correct to say that the newer html tag conquers the older, it merely adds the class to it.
This does work. You can still apply the no-js class to modern browsers and not lose the attributes on the html tag.
<!doctype html>
<html lang="en">
<!--[if IE 6]><html class="ie6 no-js"><![endif]-->
<!--[if IE 7]><html class="ie7 no-js"><![endif]-->
<!--[if IE 8]><html class="ie8 no-js"><![endif]-->
<!--[if gt IE 8]><!--><html class="no-js"><!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Document</title>
</head>
<body>
</body>
</html>
However, you still get the Compat View icon. I've included a potential fix - that mixes both the code above and your inclusion of html tags in the head - for the Compat View icon in the issue #378 – see https://github.com/paulirish/html5-boilerplate/issues/378#issuecomment-1208710
There was a problem hiding this comment.
I personally prefer the current .ie6, .ie7, .ie8 method because it is easier for other coders to understand at a glance what the classes are.
But could the above classes be rolled into Modernizr instead (maybe as an extra option when you build your own)? That would remove the need for the extra conditionals in the html tag. Just a thought.
There was a problem hiding this comment.
But could the above classes be rolled into Modernizr instead (maybe as an extra option when you build your own)? That would remove the need for the extra conditionals in the html tag. Just a thought.
It doesn’t seem like a very good idea to depend on JavaScript just for IE-specific CSS.
There was a problem hiding this comment.
For those using HTML4, conditional comments are definitely safer.
For people using HTML5(this is theoretically an HTML5 boilerplate), they are already depending on JavaScript for the styling of their entire site therefore broken -> more broken wouldn't really be a big deal.
There was a problem hiding this comment.
For my personal case, I use .ie6 very often with padding related issues, occasionally use .oldie, use cases of .ie7 .ie8 are very rare. but again, it's just me.
There was a problem hiding this comment.
I think the .oldie class name isn't clear to what it's doing, I much prefer the .lte-ie8 used in Mathias' article. More obvious for people introduced to boilerplate or anyone looking at your site's code.
There was a problem hiding this comment.
@mathiasbynens : I'm agree with @limeblack. We already depend on js with HTML5 layouts. So a tiny js file (lesser than 1k) could just put IE specific version classes directly in the HTML markup and could be a better alternative: no conditional comments, more maintenable stylesheets, no IE rendering bug, no meta charset issues... Therefore, with mobile first development, we need js to activate media queries, then IE hacks. But, what I say is just reliable for HTML5 and mobile first developments ;)
By the way, I like the .oldie concept, it seems to be a good practice for HTML4, XHTML and HTML5.
There was a problem hiding this comment.
I personally like the old way better, just because I will never ever remember all those hacks when I need them.
There was a problem hiding this comment.
@FabianBeiner: but as @nimbupani said, there's only two hacks to retain, at least just one to match IE6 and 7 ;)
There was a problem hiding this comment.
I agree with @holizz on this, I don't like this change at all. With the old (.ie6, .ie7, etc) method, you did a little more work up-front for a lot of relief later on when you're deep in a large CSS file. With this new change not only am I expected to remember the browser hacks every time I'm trying to debug some styling, but so is everyone else contributing or attempting to make sense out of my code years down the line. Take these two snippets:
.ie7 nav li {
color: blue;
}.oldie nav li {
color: blue;
*color: blue;
_color: blue;
}Hell, even a backend dev with absolutely zero knowledge of CSS can glance at the former and know exactly what's going on. I appreciate that you're trying to clean-up the markup on the html side of things, but mucking up the CSS files tenfold to compensate isn't a just tradeoff in my opinion.
There was a problem hiding this comment.
.ie7 nav li { color: blue; }.oldie nav li { color: blue; *color: blue; _color: blue; }
Those two code snippets aren’t equivalent at all. Here’s what the first snippet would look like using the “new” system:
.oldie nav li {
*color: blue;
_color: papayaWhip; /* only if you don’t want the previous rule to apply in IE6 as well! */
}Note that in practice you’ll always want rules for IE7 to target IE6 as well, so you wouldn’t even need the second declaration.
You could even do it without using .oldie, meaning you don’t have to start a new rule set:
nav li {
/* other declarations go here */
*color: blue;
}
There was a problem hiding this comment.
@mathiasbynens I wasn't necessarily stating that the two snippets were absolutely equivalent. I was going for the glancing readability of both in terms of ease-of-maintenance. Nearly anyone reading the first script knows exactly what it's targeting. Reading the second requires up-to-date knowledge of CSS browser hacks, agreement in the entire department about which to use and in what order, and causes unnecessary complexity when trying to debug styling errors.
Of course the argument ends up going back to the age-old debate of whether CSS hacks should be used at all to begin with. To me they're like !important: a quick fix to get something working right now that leads to headaches later down the line. If you know what you're doing and you see absolutely no other recourse, then proceed with caution. Enforcing it as a norm on entire stylesheets is never something I'd ever consider.
There was a problem hiding this comment.
@Pewpewarrows: I think you make a good point about the clarity of CSS code for back-end devs (or teams that may contain front-end devs not familiar with IE6/7 CSS hacks). But I disagree that CSS hacks should only be a last resort. The * and _ hacks are tried and tested.
There was a problem hiding this comment.
Since this commit could potentially polarise boilerplate users, why not throw it open to a public vote? Whichever one wins out, there could still be mention of the other technique within the Boilerplate documentation somewhere. I personally will stick with the old technique whatever but appreciate the option this gives.
There was a problem hiding this comment.
@Pewpewarrows: You could still document the hacks, like so:
nav li {
/* other declarations go here */
*color: blue; /* for IE7 and below */
}
There was a problem hiding this comment.
Just a note, for those who want a js side solution (since it's out of the scope of H5BP and Modernizr): https://github.com/pyrsmk/classie
There was a problem hiding this comment.
@philwareham I think the feedback on this commit has already shown a strong preference for the previous approach. Definitely worth documenting this technique and any other viable ones in the Wiki.
There was a problem hiding this comment.
IMO, This is a major step backward. The cc classnames are elegant, readable by anyone and when set on the body tag have less cons.
I'm going to stick with the old technique on the body tag, but still hope the H5BP will revert to it too.
There was a problem hiding this comment.
oh and if you have lots of attributes on both the html and body tags, you could always use cc'ed classnames on a container, e.g.
<!--[if lt IE 7 ]><div class="ie6"><![endif]--><!--[if IE 7 ]><div class="ie7"><![endif]--><!--[if IE 8 ]><div class="ie8"><![endif]--><!--[if gt IE 8]><!--><div><!--<![endif]-->
There was a problem hiding this comment.
FYI: We're expecting to revert and add oldie to all the variants, so we have the both approaches covered.
There was a problem hiding this comment.
The discussion continues here: issue #522.
There was a problem hiding this comment.
love the new approach! please don't revert.
There was a problem hiding this comment.
+1 for reverting - these hacks are ugly and unacceptable. Specific classnames for each version of IE is much simpler to read and comprehend at a quick glance.
There was a problem hiding this comment.
Hmm... If we are going to use hacks, why do we need oldie at all? I was under the impression hacks were the wrong way to go about doing CSS. Do hacks even validate? I don't see anything wrong with what we had. Yes, people had issues with facebook garbage but I think link to wiki for an alternative solution would had suffice.
There was a problem hiding this comment.
Oldie insures no past or future browsers that have broken parsers could ever possible apply the IE hacks, but I like lte-ie8 better.
I would advise just using php(that's my preference) to convert between the classes and hacks on the fly. Just right a little regex. You could also compress and reorder the attributes for further gzip compatibility.
- You have clean css source
- Have minimal to no conditional comments
- No throwing IE into compatibility mode
<?
$css = include('style.css');
$css = preg_replace(/.ie6/,'* html.lte-ie8', $css);
$css = preg_replace(/.ie7/,'*+html.lte-ie8', $css);
$css = preg_replace(/.ie8/,'html.lte-ie8>/**/body', $css);
echo compress_routine($css);
There was a problem hiding this comment.
Not a fan of the change tbh.
The original class syntax was simpler to explain and easier to maintain than creating a culture of using bad-hacks.
+1 Rollback
There was a problem hiding this comment.
+1 rollback too.
Mainly because I've been using sass like this:
.rule {
color: red;
.ie6 &,
.ie7 & {
color: blue;
}
}
There was a problem hiding this comment.
We plan to revert, everyone. :)
See #522 for more detail, but in general, we're reverting but adding in the .oldie class to the "classic" style.
Thanks for your input and participation y'all. This is a fun community :)
There was a problem hiding this comment.
YEY!
I believe if users check out this URL they expect to see the same code. Perhaps we should add a little bit more info here — something among the lines of “we’re using a minimal variation of this technique combined with safe CSS hacks”.