Permalink
Browse files

Change our conditional comments around the HTML tag to use a single .…

…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.
1 parent 362d0b7 commit e5e057e53815ed55f4ecfaef3057bf2940c7c0b2 @necolas necolas committed May 20, 2011
Showing with 36 additions and 44 deletions.
  1. +3 −3 css/style.css
  2. +1 −3 demo/elements.html
  3. +30 −32 demo/hack2.css
  4. +1 −3 demo/tests.html
  5. +1 −3 index.html
View
@@ -104,7 +104,7 @@ pre {
padding: 15px;
}
-.ie6 legend, .ie7 legend { margin-left: -7px; }
+.oldie legend { *margin-left: -7px; }
/* 1) Make inputs and buttons play nice in IE: www.viget.com/inspire/styling-the-button-element-in-internet-explorer/
2) WebKit browsers add a 2px margin outside the chrome of form elements.
@@ -129,9 +129,9 @@ input:valid, textarea:valid { }
input:invalid, textarea:invalid { border-radius: 1px; -moz-box-shadow: 0px 0px 5px red; -webkit-box-shadow: 0px 0px 5px red; box-shadow: 0px 0px 5px red; }
.no-boxshadow input:invalid, .no-boxshadow textarea:invalid { background-color: #f0dddd; }
-/* Bicubic resizing for non-native sized IMG:
+/* Bicubic resizing in IE7 for non-native sized IMG:
code.flickr.com/blog/2008/11/12/on-ui-quality-the-little-things-client-side-image-resizing/ */
-.ie7 img { -ms-interpolation-mode: bicubic; }
+.oldie img { -ms-interpolation-mode: bicubic; }
/**
View
@@ -1,8 +1,6 @@
<!doctype html>
<!-- paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ -->
-<!--[if lt IE 7]> <html class="no-js ie6" lang="en"> <![endif]-->
-<!--[if IE 7]> <html class="no-js ie7" lang="en"> <![endif]-->
-<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
+<!--[if lt IE 9]> <html class="no-js oldie" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
View
@@ -1,33 +1,33 @@
body { font:13px/1.231 sans-serif; *font-size:small; } /* hack retained to preserve specificity */
- body, select, input, textarea {
- /* #444 looks better than black: twitter.com/H_FJ/statuses/11800719859 */
- color: #444;
- /* set your base font here, to apply evenly
- /* font-family: Georgia, serif; */
- }
-
- /* Headers (h1,h2,etc) have no default font-size or margin,
- you'll want to define those yourself. */
- h1,h2,h3,h4,h5,h6 { font-weight: bold; }
- h1 { font-size: 2em; }
- select, input, textarea, button { font:99% sans-serif; }
-
- /* Accessible focus treatment: people.opera.com/patrickl/experiments/keyboard/test */
- a:hover, a:active { outline: none; }
-
- .current { background: #ccc; }
- header span { padding: 0.2em 0.5em; display: inline-block; }
- dd, h1, body, html { margin: 0;}
-
-
- a, a:active, a:visited { color: #607890; }
- a:hover { color: #036; }
- .wrapper {width:200px; border:1px solid red;}
-
- dl {margin:0 auto; width:900px;}
- dt {background-color:#ccc; margin-bottom:20px; cursor:pointer; cursor:hand; padding:5px; font-weight:bold; }
- dd {margin-bottom:30px;}
-
+body, select, input, textarea {
+ /* #444 looks better than black: twitter.com/H_FJ/statuses/11800719859 */
+ color: #444;
+ /* set your base font here, to apply evenly
+ /* font-family: Georgia, serif; */
+}
+
+/* Headers (h1,h2,etc) have no default font-size or margin,
+you'll want to define those yourself. */
+h1,h2,h3,h4,h5,h6 { font-weight: bold; }
+h1 { font-size: 2em; }
+select, input, textarea, button { font:99% sans-serif; }
+
+/* Accessible focus treatment: people.opera.com/patrickl/experiments/keyboard/test */
+a:hover, a:active { outline: none; }
+
+.current { background: #ccc; }
+header span { padding: 0.2em 0.5em; display: inline-block; }
+dd, h1, body, html { margin: 0;}
+
+
+a, a:active, a:visited { color: #607890; }
+a:hover { color: #036; }
+.wrapper {width:200px; border:1px solid red;}
+
+dl {margin:0 auto; width:900px;}
+dt {background-color:#ccc; margin-bottom:20px; cursor:pointer; cursor:hand; padding:5px; font-weight:bold; }
+dd {margin-bottom:30px;}
+
#clear-demo {width:500px; border:1px solid black;}
#clear-demo-l {width:200px; border:1px solid black; float:left;}
#clear-demo-r {width:200px; border:1px solid black; float:right;}
@@ -36,6 +36,4 @@ body { font:13px/1.231 sans-serif; *font-size:small; } /* hack retained to prese
header {text-align:center;}
.show, .hide {color: #607890; cursor:pointer; cursor:hand;}
-body {
- padding-bottom: 200px;
-}
+body {padding-bottom: 200px;}
View
@@ -1,8 +1,6 @@
<!doctype html>
<!-- paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ -->
-<!--[if lt IE 7]> <html class="no-js ie6" lang="en"> <![endif]-->
-<!--[if IE 7]> <html class="no-js ie7" lang="en"> <![endif]-->
-<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
+<!--[if lt IE 9]> <html class="no-js oldie" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
View
@@ -1,8 +1,6 @@
<!doctype html>
<!-- paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/ -->
@mathiasbynens
mathiasbynens May 20, 2011 Member

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”.

-<!--[if lt IE 7]> <html class="no-js ie6" lang="en"> <![endif]-->
-<!--[if IE 7]> <html class="no-js ie7" lang="en"> <![endif]-->
-<!--[if IE 8]> <html class="no-js ie8" lang="en"> <![endif]-->
+<!--[if lt IE 9]> <html class="no-js oldie" lang="en"> <![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">

52 comments on commit e5e057e

@neave
Contributor
neave commented on e5e057e May 20, 2011

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!

@nimbupani
Member

We do recommend you scope your hacks with .oldie, except just use hacks within that scope! Simpler on both ends.

@paulirish
Member

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!

@hotmeteor

I like it, thanks for the change.

@necolas
Member

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.

@holizz
holizz commented on e5e057e May 20, 2011

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.

@zachleat

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).

@chrisjaure

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.

@swalkinshaw

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.

@nimbupani
Member

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.

@swalkinshaw

@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.

@ttilley

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

@boboroshi

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

@nimbupani
Member

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.

@limeblack

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.

@nimbupani
Member

@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.

@limeblack

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....

  1. Removes conditional comments from around the html and therefore "purifies" :) the html
  2. Allows for clear concise CSS
  3. Doesn't rely on CSS hacks
  4. 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.

@jonathantneal
Member

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.

@mathiasbynens
Member

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?

@jonathantneal
Member

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.

@anselmh
Contributor

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?

@fcalderan

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.)

@limeblack

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;
}
@necolas
Member

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

@philwareham

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.

@mathiasbynens
Member

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.

@limeblack

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.

@shichuan
Member

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.

@bencollier

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.

@pyrsmk
pyrsmk commented on e5e057e May 20, 2011

@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.

@FabianBeiner

I personally like the old way better, just because I will never ever remember all those hacks when I need them.

@pyrsmk
pyrsmk commented on e5e057e May 20, 2011

@FabianBeiner: but as @nimbupani said, there's only two hacks to retain, at least just one to match IE6 and 7 ;)

@Pewpewarrows

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.

@mathiasbynens
Member

@Pewpewarrows:

.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;
}
@Pewpewarrows

@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.

@necolas
Member

@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.

@philwareham

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.

@mathiasbynens
Member

@Pewpewarrows: You could still document the hacks, like so:

nav li {
    /* other declarations go here */
    *color: blue; /* for IE7 and below */
}
@pyrsmk
pyrsmk commented on e5e057e May 20, 2011

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

@necolas
Member

@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.

@RonnyO
RonnyO commented on e5e057e May 21, 2011

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.

@RonnyO
RonnyO commented on e5e057e May 21, 2011

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]-->
@paulirish
Member

FYI: We're expecting to revert and add oldie to all the variants, so we have the both approaches covered.

@mathiasbynens
Member

The discussion continues here: issue #522.

@jessehart

love the new approach! please don't revert.

@leek
leek commented on e5e057e May 23, 2011

+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.

@adeelejaz
Contributor

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.

@limeblack

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);
@ChrisMcKee
Member

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

@kaelig
Contributor
kaelig commented on e5e057e May 24, 2011

+1 rollback too.

Mainly because I've been using sass like this:

.rule {
  color: red;
  .ie6 &,
  .ie7 & {
    color: blue;
  }
}
@paulirish
Member

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 :)

@ChrisMcKee
Member

YEY!

Please sign in to comment.