Remove IE conditional classes #1290

necolas · 2013-01-13T18:45:22Z

We should consider their complete removal from the HTML5 Boilerplate template. A good time to do it would be as part of #1050 when IE 6/7 support is dropped for version 5.0.

Reasons:

You can easily develop without them (personally, I've never used them).
For IE 8+, their use is much more limited.
IE 10+ will not support conditional comments.
We don't explicitly target any other browser versions in the same way.
It would fix whatever is going on in the very long-standing issues about the X-UA-Compatible meta tag. See Conditional comments wrapping <html> prevent IE from honouring <meta http-equiv=X-UA-Compatible> #1187.

Hopefully, even "conditional IE class" users will view them as disposable in an IE 8+ development setting. If you need IE 6/7 support, the last 4.* release will still cater to your needs. However, feedback is welcome!

The text was updated successfully, but these errors were encountered:

tarciozemel · 2013-01-13T18:57:38Z

Move the web forward is always a good thing. Since people with old browser needs can still use 4.*, it's a good decision, in my view.

alrra · 2013-01-13T18:57:56Z

👍

influxweb · 2013-01-13T19:06:42Z

I think it's a great idea. I have been using CSS Browser Selector (http://ridjohansen.github.com/css_browser_selector/index_en.html) lately to be able to target specific browser instance if needed.

shaunbent · 2013-01-13T19:16:46Z

I've never been a fan of browser sniffing, even if it is for IE. I feel using Modernizr for feature detection is a much nicer solution. So thumbs up on this one for me!

roblarsen · 2013-01-13T19:19:06Z

+1

Although as I write this I just added these in on a project. Of course the internal environment there is IE7 (insert dancing banana which illustrates how happy I am about that.)

I'd like to go back through my projects to see where I've actually had to use them. I know I have, agency pace basically requires it for late-stage bugs, but I wonder what percentage it is.

ShaneShipston · 2013-01-13T19:52:47Z

I'm all for removing them. I've only used them once since I started using boilerplate.

SBoudrias · 2013-01-13T19:54:50Z

+1 feel like it's the right time to do this.

nvartolomei · 2013-01-13T19:58:54Z

Hands up for this. 👍

Modernizer all the way actually, it's bad practice to sniff particular browser
we should develop keeping in mind supported features.

derekjohnson · 2013-01-13T20:16:25Z

+1 for removal. I don't think I've ever used them.

gavtaylor · 2013-01-13T20:35:07Z

+1 for removal

I've never found a reason to use them and it's easy enough for people to add back in if they really need too .

wouterj · 2013-01-13T20:42:48Z

-1

One of the 'oh' moments when I looked at the HTML5 boilerplate V1 code and viewed paul's presentation about it. It is part of the boilerplate and it is a really really usefull part of the boilerplate.

You can easily develop without them (personally, I've never used them).

If you don't use it, you can easily delete them or just ignore them.

IE 10+ will not support conditional comments.

They are created to create special styles for old browsers, something IE10 isn't.

We don't explicitly target any other browser versions in the same way.

Because the other browsers are not that smart to implement such a great feature...

necolas · 2013-01-13T20:55:07Z

it is a really really usefull part of the boilerplate

It's much less useful when you don't need to support IE 6/7. And even then, it's preferable to use the _property and *property hacks (as normalize.css does) as you can easily group the IE 6/7 styles in the rule, rather than making a separate rule with higher specificity.

ryan-blunden · 2013-01-13T21:37:53Z

I think they should stay as a way of providing a best practice example for how to tame older versions of IE without using CSS hacks. If you don't need them, delete them. Many developers and websites still do.

necolas · 2013-01-13T21:44:08Z

Problem is, I don't think they are a "best practice". Using hacks for IE 6/7 has fewer problems.

mathiasbynens · 2013-01-13T22:02:40Z

Relevant: http://mathiasbynens.be/notes/safe-css-hacks (It feels like we’re having the same discussion again, the difference being that nowadays the browser landscape looks different.)

roblarsen · 2013-01-13T22:25:45Z

BTW, I want to add a double gold star to one of the points @necolas brought up:

It would fix whatever is going on in the very long-standing issues about the X-UA-Compatible meta tag. See #1187.

Even in the environments I've worked in (financial services) where older versions of IE are still common, the biggest problems I've had over the past year or so have been with compat mode issues, not with the basic CSS stuff this pattern targets. While I'm working in grown-up environments where we can configure web servers to our heart's content, people in hosted environments and/or without any server config skills will be better served by having the <meta> solution work.

sturobson · 2013-01-13T22:26:54Z

I've been recently dropping the IE6 & 7 conditional classes bit from my boilerplate mashup and using this something similar to this - http://codepen.io/sturobson/pen/oJEwg with a pre-processor which is marked up similar to this -

.an-example {

  // put the IE9 and 'other' browser CSS declarations here  

  .lt-ie9 & { 

   // put the IE8 and below CSS declarations here
         /* IE8 and below */ 

   // if you need IE7 as well then prefix the CSS with a *
         /* IE7 and below */  

   // if you need IE6 as well then prefix the CSS with a _
         /* IE6 */ 

    }
}

As you can see I'm utilising the IE6 & IE7 hacks to only have one conditional class snippet in my head.

I have no problem with this. I use a bastardised version of the HTML5 boilerplate that 'suits me'.

The problems I do see are if this boilerplate drops support without stating 'options' like my snippet above for example. People would just forgo testing on these browsers regardless of any usage statistics etc. It shouldn't happen. But it will.

So to sum it all up. Drop it, but point developers to a resource that'll show them 'how else' to do it.

sturobson · 2013-01-13T22:44:20Z

Also re-reading @mathiasbynens post. If there is no 'safe' hack for IE8 then dropping that conditional class coud be folly.

necolas · 2013-01-13T22:52:10Z

Writing styles just for IE 8 could be folly!

sturobson · 2013-01-13T22:55:49Z

@necolas quite possibly, all I ask is to help explain to current/future developers using the boilerplate 'verbatim' how to 'put it back in' or fix it differently if required. I don't know how, but I'd be more than prepared to help with this :)

necolas · 2013-01-13T23:01:11Z

If we take it out it's because we don't think it should be there. I think it's an anti-pattern.

sturobson · 2013-01-13T23:07:55Z

my only real issue is, if we (royally) stick to just CSS hacks for IE 6 & 7 by dropping conditional classes then need something that is IE8 specific this - color: green\9; would also effect IE9, right? If I'm wrong, nae bother.

Just shooting the breeze :)

drublic · 2013-01-13T23:31:34Z

If we take this out – and I am pretty sure this will happen – we can easily add some documentation about how to target older browsers in the FAQs or so. The CC-section in the doc's "The HTML" section could be moved somewhere else I think.

CSS hacks are anti-patterns as well as CCs are. It's just a matter of what anti-pattern you want to work with. At least that's my opinion.

Anyways I am +1 on removing the CCs as suggested.

necolas · 2013-01-13T23:44:29Z

FWIW, the CSS in HTML5 Boilerplate relies on IE 6/7 hacks. IE 6/7 has non-standard rendering and other weird bugs that make them different enough to require specific targeting. But when IE 6/7 support is dropped, I think it would be good to do away with the conditional IE classes altogether because IE 8 does not suffer from the afflictions of those legacy-legacy browsers. The vast majority of property-values it doesn't support can be handled with fallbacks.

I've argued that we should move away from the "ok change things, but document the old solution and other alternatives"-pattern that can pop up as solutions to issues. It tends to paralyze the project, adds unnecessary maintenance overhead, may send mixed messages, and panders to conservatism. The documentation is primarily for the code that makes up the project. We don't take decisions to change code lightly -- dropping IE 6/7 support has been on the slow-burn for months -- so when we do make changes, we should just plough forward and leave the documentation for old things in the old tagged releases!

I may be wrong. We'll see.

brianblakely · 2013-01-13T23:49:12Z

I suggest removing the conditionals for IE6 and 7 only.

IE8 is not a significant upgrade from IE7 by any metric, and so workarounds in CSS are nearly just as desirable. Dropping entirely for a future IE9+ version would probably be the appropriate one for this.

The only way I can see a typical dev getting away with not using them at all for IE8 is by leaning pretty heavily on fallbacks; probably more than is acceptable to the majority of organizations.

bjankord · 2013-01-14T04:20:14Z

If the conditional comments are dropped from the boilerplate, I see no harm in leaving a note for those who still want to use them/know about them. Sure, devs could just bookmark Paul's post about them, rather then leaving a note in the docs, but I don't see leaving a note about them in the docs as a potential issue that could paralyze the project.

On a side note, the comments have kind of become a quick standard thing I notice when viewing other projects source code and can instantly guess that a site was built with H5BP, much like the pink selection highlight color background used to be an indicator. While this is kinda nice, I won't miss seeing them when I view source if they are dropped.

drublic · 2013-01-14T10:19:33Z

Removing (or not adding) documentation that isn't needed shouldn't be a problem (as for example in #1279). I just think there are situations where docs might be useful – and backwards compatibility as in this case is one of those.
The project should still have an educational aspect and documenting methods that extend the current boilerplate should be part of this. When we drop IE 6 and 7 we will need to document how to get around this (use HTML5BP 4.x). At least that is my opinion and there will be a lot of people arguing the same way. HTML5 Boilerplate should be a good default template for experts and beginners.

@brianblakely I think keeping a subset of the CCs isn't what we should discuss. It is a question of how you approach writing CSS.

bjankord · 2013-01-14T15:06:51Z

I really like @mathiasbynens combining conditional classnames with safe CSS hacks approach

I can see two approaches with this technique. One where the opening HTML tag is wrapped with just one conditional comment.

<!--[if lt IE 9]><html class="lt-ie9"><![endif]-->
<!--[if gt IE 8]><!--><html><!--<![endif]-->

Though this approach promotes the CSS for IE8 and lower being in the same file as the styles for other modern browsers increases the file size for modern browsers.

Another approach based on the same idea of one conditional comment for IE would be to separate the styles for IE8 and lower into their own style sheet using a conditional comment instead of wrapping the opening HTML tag with the conditional comments.

Removing the conditional comments from around the opening HTML tag would also fix Issue 1187

This approach is also delete key friendly. Don't need/want to optimize oldIE from a baseline experience? Delete the conditional comment and move on.

<!DOCTYPE html> 
<html class="no-js">
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
        <title></title>
        <meta name="description" content="">
        <meta name="viewport" content="width=device-width">

        <!-- Place favicon.ico and apple-touch-icon.png in the root directory -->

        <link rel="stylesheet" href="css/normalize.css">
        <link rel="stylesheet" href="css/main.css">
        <!--[if lt IE 9]><link rel="stylesheet" href="css/ie.css"><![endif]-->

ChrisWojcik · 2013-01-14T18:57:54Z

One thing I can think of where you might still need to treat IE8 separately even after you drop IE6/7 is media queries.

Inkdpixels · 2013-01-14T19:20:33Z

Also +1

@ChrisWojcik That's something Modernizr should handle.

jswebschmiede · 2013-08-09T14:14:13Z

👎 the reality is the users actually use IE7 or IE8.

AllThingsSmitty · 2013-08-09T14:32:25Z

I don't think H5BP should be required to maintain conditional comments just because IE7-8 users are still out there. I'm expecting that number to be very low. Developers should be taking that upon themselves if they have to support oldIE browsers.

thomasthesecond · 2013-08-09T14:35:41Z

I totally agree. If you still need to support IE 7 or 8, add the conditionals. It's not that difficult.

TheDutchCoder · 2013-08-09T14:43:02Z

H5BP is supposed to be "delete key friendly".

Just leave them in, people who don't use them delete them with one key-stroke, others can just leave them in and use them if required. It's more work adding them than deleting them.

There's a bunch of stuff that you might or might not use in your application (e.g. the two separate css files, instead of a single one), deleting stuff is much, much easier than adding it in yourself, especially since it's more error prone.

HichemBenChaaben · 2013-08-09T14:53:28Z

-1 I think it's not the best idea, If a considerable number of users are on still on IE8 and below then you still need the conditions otherwise remove them yourself.

sonicbobcat85 · 2013-09-21T07:11:57Z

-1

Simply removing conditional comments essentially removes legacy support, which encourages developers to drop support for IE8 altogether, a widely used browser (Windows XP is far from dead at this time). Modernizr has its place, but it's not a perfect solution due to its dependence on JS.

Leaving CCs in and retaining the "X-UA-Compatible" bug is far from ideal either. Part of our job as developers is to protect users from themselves and not let a confusing feature like Compatibility Mode break our sites.

It looks to me like @bjankord's suggestion to remove conditional comments from the tag and use them for IE-specific stylesheets solves everyone's problems. It's delete-key friendly and doesn't leave any gaps in support. What's the disadvantage?

komputist · 2013-09-25T16:51:01Z

@sturobson and @mathiasbynens, regarding safe CSS hack for IE8, then the following does not affect the CSS specificity and only targets IE8:

@media \0IE8 { div {color:lime}}

You can even do this:

@media \0 { div {color:lime}}

Or this:

@media \0screen { div {color:lime}}

But you cannot do this:

@media \0all { div {color:lime}}

The clue seems to be that the first character after the backslash must not be one of the characters that are used in hexadecidmal numbers – characters 0-9 and letters a-f.

(My only contribution to this hack is to realize that the media keywords are (almost) irrelevant. Here are some page that have mentioned the at-media screen hack before me: http://dimox.net/personal-css-hacks-for-ie6-ie7-ie8/ and http://www.conijnwebdesign.nl/tutorials/how-to-target-IE-in-CSS.php )

oliverbenns · 2013-09-28T10:38:04Z

I think we should remove IE 6 + 7. IE8 also has .lte8 so browsers before can still be supported, just not so specifically.

With that said I am keen to push the web forward and the question lies as to WHEN do we drop them then.

Yes we can target those with IE7+8 with Javascript. But what if they have it disabled? Which of all internet users is fairly likely let's be honest.

fernandopasik · 2013-09-28T10:52:47Z

With modernizr tests for each feature, why would you use nowadays the ie class in the html tag?

oliverbenns · 2013-09-28T10:57:45Z

@fernandopasik Because one might not want to load all of Modernizr for only 1 or 2 detections. These conditionals provide a non-javascript way which I still think may be required.

jpdevries · 2013-09-28T15:36:36Z

I used to use the HTML hacks, but now I use modernizr tests and assume .no-js is the crappiest browser ever. I do feel that the hacks should stay in the build as people can choose to remove them in their own projects

—
Sent from Mailbox for iPhone

On Sat, Sep 28, 2013 at 3:58 AM, oliverbenns notifications@github.com
wrote:

@fernandopasik Because one might not want to load all of Modernizr for only 1 or 2 detections. These conditionals provide a non-javascript way which I still think may be required.

Reply to this email directly or view it on GitHub:
#1290 (comment)

fernandopasik · 2013-09-28T21:37:44Z

@oliverbenns good point!
I think for IE8 at least is definitely required, too many people still use it.

battaglr · 2013-10-22T14:32:16Z

Goodbye conditional classes... you won't be missed. Great work guys!

andrewbiggart · 2013-10-22T14:49:11Z

I.E isn't even a browser. It doesn't deserve conditional classes! Adios!!!

saibayadon · 2013-10-22T15:37:21Z

👍 For removing them. Anyone that need theese can just add them back (i've used them in the past and probably will use them for some projects in the short-term future)

wouterj · 2013-10-22T16:42:37Z

bleh. Really, go and do some research before screaming like a pig without any knowledge of the topic...

IE11, what's wrong with it? IE10, what's wrong with it? Who invented the awesome .innerHTML? Which browsers decided to create W3C, to do everything just different from IE? Who had CSS3 filters way before chrome? Who does care to only put stable things in their browser, instead of beta vendors? Who created a way to make browser specific styles?

I work in this business for 6 years and I've never had any problem with IE, except from the cases in which I was stupid to use beta things

wouterj · 2013-10-22T16:43:43Z

And btw, the reason of removing this is not because H5BP hates IE, it's only because there are currently better ways to do this. But I'll still love this.

andydownunder · 2013-10-22T16:50:09Z

bleh. Really, go and do some research before screaming like a pig without any knowledge of the topic...

LOL

hlfcoding · 2013-10-22T17:06:49Z

👎 At least keep a version for those of us who still need to write for those browsers.

patrickkettner · 2013-10-22T17:09:02Z

@hlfcoding they did. Its on the readme - its V4

andydownunder · 2013-10-22T17:12:17Z

Its on the readme

Why can't people RTFM?

patrickkettner · 2013-10-22T17:13:05Z

@andypnewman no need to be rude, mate.

…ml5-boilerplate#1290 and h5bp/html5-boilerplate#1187)

The reasons behind this decision include the following: * This project will drop legacy browser support (see h5bp#1050), therefore, the use for conditional classes for IE 8+, becomes much more limited. * IE 10+ does not support conditional comments: http://msdn.microsoft.com/en-us/library/ms537512%28v=VS.85%29.aspx. * Users do and can develop easily without using the conditional classes, this technique being very limited in scope as no other browser versions are explicitly target in the same way. * It fixes the issue that prevents IE from honouring `<meta http-equiv="X-UA-Compatible" content="IE=edge">` (see: h5bp#1187). This change also removes the related documentation. Close h5bp#1290 and h5bp#1187.

…onditional comments and IE6/7 hacks. Ref h5bp/html5-boilerplate#1050, h5bp/html5-boilerplate#1187 and h5bp/html5-boilerplate#1290

alrra mentioned this issue Oct 11, 2013

Suggest target specific IE back and add IE10 to the conditional #1451

Closed

alrra closed this as completed in 13f17a7 Oct 21, 2013

louh pushed a commit to codeforamerica/fast_pass that referenced this issue Nov 10, 2013

Remove conditional IE html tags (see HTML5 Boilerplate issues h5bp/ht…

f33f1c3

…ml5-boilerplate#1290 and h5bp/html5-boilerplate#1187)

AndrewKvalheim mentioned this issue Oct 26, 2014

Add missing IE conditional comment. dannyprose/Middleman-HTML5BP-HAML#14

Closed

Remove IE conditional classes #1290

Remove IE conditional classes #1290

Comments

necolas commented Jan 13, 2013

tarciozemel commented Jan 13, 2013

alrra commented Jan 13, 2013

influxweb commented Jan 13, 2013

shaunbent commented Jan 13, 2013

roblarsen commented Jan 13, 2013

ShaneShipston commented Jan 13, 2013

SBoudrias commented Jan 13, 2013

nvartolomei commented Jan 13, 2013

derekjohnson commented Jan 13, 2013

gavtaylor commented Jan 13, 2013

wouterj commented Jan 13, 2013

necolas commented Jan 13, 2013

ryan-blunden commented Jan 13, 2013

necolas commented Jan 13, 2013

mathiasbynens commented Jan 13, 2013

roblarsen commented Jan 13, 2013

sturobson commented Jan 13, 2013

sturobson commented Jan 13, 2013

necolas commented Jan 13, 2013

sturobson commented Jan 13, 2013

necolas commented Jan 13, 2013

sturobson commented Jan 13, 2013

drublic commented Jan 13, 2013

necolas commented Jan 13, 2013

brianblakely commented Jan 13, 2013

bjankord commented Jan 14, 2013

drublic commented Jan 14, 2013

bjankord commented Jan 14, 2013

ChrisWojcik commented Jan 14, 2013

Inkdpixels commented Jan 14, 2013

jswebschmiede commented Aug 9, 2013

AllThingsSmitty commented Aug 9, 2013

thomasthesecond commented Aug 9, 2013

TheDutchCoder commented Aug 9, 2013

HichemBenChaaben commented Aug 9, 2013

sonicbobcat85 commented Sep 21, 2013

komputist commented Sep 25, 2013

oliverbenns commented Sep 28, 2013

fernandopasik commented Sep 28, 2013

oliverbenns commented Sep 28, 2013

jpdevries commented Sep 28, 2013

@fernandopasik Because one might not want to load all of Modernizr for only 1 or 2 detections. These conditionals provide a non-javascript way which I still think may be required.

fernandopasik commented Sep 28, 2013

battaglr commented Oct 22, 2013

andrewbiggart commented Oct 22, 2013

saibayadon commented Oct 22, 2013

wouterj commented Oct 22, 2013

wouterj commented Oct 22, 2013

andydownunder commented Oct 22, 2013

hlfcoding commented Oct 22, 2013

patrickkettner commented Oct 22, 2013

andydownunder commented Oct 22, 2013

patrickkettner commented Oct 22, 2013