Remove IE conditional classes #1290

Closed
necolas opened this Issue Jan 13, 2013 · 85 comments

Comments

Projects
None yet
@necolas
Member

necolas commented Jan 13, 2013

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 #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!

@tarciozemel

This comment has been minimized.

Show comment
Hide comment
@tarciozemel

tarciozemel Jan 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@alrra

alrra Jan 13, 2013

Member

👍

Member

alrra commented Jan 13, 2013

👍

@influxweb

This comment has been minimized.

Show comment
Hide comment
@influxweb

influxweb Jan 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@shaunbent

shaunbent Jan 13, 2013

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!

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

This comment has been minimized.

Show comment
Hide comment
@roblarsen

roblarsen Jan 13, 2013

Member

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

Member

roblarsen commented Jan 13, 2013

+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

This comment has been minimized.

Show comment
Hide comment
@ShaneShipston

ShaneShipston Jan 13, 2013

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

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

@SBoudrias

This comment has been minimized.

Show comment
Hide comment
@SBoudrias

SBoudrias Jan 13, 2013

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

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

@nvartolomei

This comment has been minimized.

Show comment
Hide comment
@nvartolomei

nvartolomei Jan 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@derekjohnson

derekjohnson Jan 13, 2013

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

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

@gavtaylor

This comment has been minimized.

Show comment
Hide comment
@gavtaylor

gavtaylor Jan 13, 2013

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

+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

This comment has been minimized.

Show comment
Hide comment
@wouterj

wouterj Jan 13, 2013

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

wouterj commented Jan 13, 2013

-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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Jan 13, 2013

Member

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.

Member

necolas commented Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ryan-blunden

ryan-blunden Jan 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Jan 13, 2013

Member

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

Member

necolas commented Jan 13, 2013

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

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Jan 13, 2013

Member

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

Member

mathiasbynens commented Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@roblarsen

roblarsen Jan 13, 2013

Member

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.

Member

roblarsen commented Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@sturobson

sturobson Jan 13, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@sturobson

sturobson Jan 13, 2013

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

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

@necolas

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Jan 13, 2013

Member

Writing styles just for IE 8 could be folly!

Member

necolas commented Jan 13, 2013

Writing styles just for IE 8 could be folly!

@sturobson

This comment has been minimized.

Show comment
Hide comment
@sturobson

sturobson Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Jan 13, 2013

Member

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

Member

necolas commented Jan 13, 2013

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

@sturobson

This comment has been minimized.

Show comment
Hide comment
@sturobson

sturobson Jan 13, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@drublic

drublic Jan 13, 2013

Member

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.

Member

drublic commented Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@necolas

necolas Jan 13, 2013

Member

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.

Member

necolas commented Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@brianblakely

brianblakely Jan 13, 2013

Member

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.

Member

brianblakely commented Jan 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@bjankord

bjankord Jan 14, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@drublic

drublic Jan 14, 2013

Member

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.

Member

drublic commented Jan 14, 2013

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

This comment has been minimized.

Show comment
Hide comment
@bjankord

bjankord Jan 14, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@ChrisWojcik

ChrisWojcik Jan 14, 2013

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

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

This comment has been minimized.

Show comment
Hide comment
@Inkdpixels

Inkdpixels Jan 14, 2013

Also +1

@ChrisWojcik That's something Modernizr should handle.

Also +1

@ChrisWojcik That's something Modernizr should handle.

@jelmerdemaat

This comment has been minimized.

Show comment
Hide comment
@jelmerdemaat

jelmerdemaat Jan 14, 2013

A +1 and a hooray for feature detection/Modernizr.

A +1 and a hooray for feature detection/Modernizr.

@Marfa

This comment has been minimized.

Show comment
Hide comment
@Marfa

Marfa Jan 15, 2013

If you can safely remove smth it's always good

Marfa commented Jan 15, 2013

If you can safely remove smth it's always good

@ChrisWojcik

This comment has been minimized.

Show comment
Hide comment
@ChrisWojcik

ChrisWojcik Jan 15, 2013

@Inkdpixels am sure I agree

+1 on this

@Inkdpixels am sure I agree

+1 on this

@TheDutchCoder

This comment has been minimized.

Show comment
Hide comment
@TheDutchCoder

TheDutchCoder Jan 15, 2013

-1 For me, because IE8 certainly needs to be targeted as it has a positioning bug with absolute positioned images in a container for example.

I agree with moving away from IE6/7 (we can still use the specific hacks), but IE8 is only 2 versions down and widely used. Authors can remove it if they only want to created websites for "modern" browsers, but a lot of developers still need to develop for "all" browsers.

Hell, I even target IE9 occasionally (I added my own 'lt-ie10' class for it).

-1 For me, because IE8 certainly needs to be targeted as it has a positioning bug with absolute positioned images in a container for example.

I agree with moving away from IE6/7 (we can still use the specific hacks), but IE8 is only 2 versions down and widely used. Authors can remove it if they only want to created websites for "modern" browsers, but a lot of developers still need to develop for "all" browsers.

Hell, I even target IE9 occasionally (I added my own 'lt-ie10' class for it).

@jonathantneal

This comment has been minimized.

Show comment
Hide comment
@jonathantneal

jonathantneal Jan 17, 2013

Member

@TheDutchCoder IE8 support is still there. This is limited to conditional comments. Also mentioned earlier, IE10 does not have conditional comments. Out of curiosity, would you know if your IE8 users have JavaScript enabled?

Member

jonathantneal commented Jan 17, 2013

@TheDutchCoder IE8 support is still there. This is limited to conditional comments. Also mentioned earlier, IE10 does not have conditional comments. Out of curiosity, would you know if your IE8 users have JavaScript enabled?

@TheDutchCoder

This comment has been minimized.

Show comment
Hide comment
@TheDutchCoder

TheDutchCoder Jan 17, 2013

What I meant is that I often need the .lt-ie9 class to target IE8 (and lower) for some positioning fixes in my CSS. I don't see how you can target IE8 in CSS directly.

I'm not quite sure why I would need to know if my IE8 users have JavaScript enabled, most of my mark-up and styling is no-JS friendly or provides at least fallbacks ;-) The boilerplate can be used for non-HTML5 sites as well, keep that in mind :-)

With the conditional classes, I'm able to target IE versions specifically regardless of their version (bar IE10) which, for me, is still essential. It would be a loss to see it gone, especially when authors can so easily delete it themselves.

What I meant is that I often need the .lt-ie9 class to target IE8 (and lower) for some positioning fixes in my CSS. I don't see how you can target IE8 in CSS directly.

I'm not quite sure why I would need to know if my IE8 users have JavaScript enabled, most of my mark-up and styling is no-JS friendly or provides at least fallbacks ;-) The boilerplate can be used for non-HTML5 sites as well, keep that in mind :-)

With the conditional classes, I'm able to target IE versions specifically regardless of their version (bar IE10) which, for me, is still essential. It would be a loss to see it gone, especially when authors can so easily delete it themselves.

@anthonyringoet

This comment has been minimized.

Show comment
Hide comment
@anthonyringoet

anthonyringoet Jan 18, 2013

Same discussion as #1050 imo
If the support for legacy ie6/7 is dropped it makes perfect sense to drop the conditional classes.
Leave them out : )

Same discussion as #1050 imo
If the support for legacy ie6/7 is dropped it makes perfect sense to drop the conditional classes.
Leave them out : )

@TheDutchCoder

This comment has been minimized.

Show comment
Hide comment
@TheDutchCoder

TheDutchCoder Jan 18, 2013

IE8 is still supported and will need the conditional classes as there's no way to single out IE8 in just CSS.
We could drop the .lt-ie7 & .lt-ie8 classes though ;-)

IE8 is still supported and will need the conditional classes as there's no way to single out IE8 in just CSS.
We could drop the .lt-ie7 & .lt-ie8 classes though ;-)

@jonrandahl

This comment has been minimized.

Show comment
Hide comment
@jonrandahl

jonrandahl Jan 18, 2013

Hey all,

Wondering if there wouldn’t be a way, maybe via initializr, that would allow us to “choose” the conditionals we would need on a per project basis?

Just my two pence!

Jon

Hey all,

Wondering if there wouldn’t be a way, maybe via initializr, that would allow us to “choose” the conditionals we would need on a per project basis?

Just my two pence!

Jon

@pierrepavlov

This comment has been minimized.

Show comment
Hide comment
@pierrepavlov

pierrepavlov Jan 20, 2013

Go for it!
I love any development of the files which removes a bulk of code I personally never use. I don't think it's a big issue for the people using them either. If they need to fix some ie7-bug they can easily implement it or some other solution.

Go for it!
I love any development of the files which removes a bulk of code I personally never use. I don't think it's a big issue for the people using them either. If they need to fix some ie7-bug they can easily implement it or some other solution.

@mhmoretti

This comment has been minimized.

Show comment
Hide comment
@mhmoretti

mhmoretti May 29, 2013

I agree, remove the conditionals.

I agree, remove the conditionals.

@AllThingsSmitty

This comment has been minimized.

Show comment
Hide comment
@AllThingsSmitty

AllThingsSmitty Jun 7, 2013

Contributor

Great suggestion. It's time to move ahead with CC's.

Contributor

AllThingsSmitty commented Jun 7, 2013

Great suggestion. It's time to move ahead with CC's.

@battaglr

This comment has been minimized.

Show comment
Hide comment
@battaglr

battaglr Jun 12, 2013

Contributor

Removing conditionals is the first thing I do. A big +1.

Contributor

battaglr commented Jun 12, 2013

Removing conditionals is the first thing I do. A big +1.

@ltartari

This comment has been minimized.

Show comment
Hide comment
@ltartari

ltartari Jul 22, 2013

👍

👍

@Roope

This comment has been minimized.

Show comment
Hide comment
@Roope

Roope Jul 22, 2013

Most of us have done this already. So should BP. +1

Roope commented Jul 22, 2013

Most of us have done this already. So should BP. +1

@tjbarber

This comment has been minimized.

Show comment
Hide comment
@tjbarber

tjbarber Jul 22, 2013

+1

We don't support IE 4/5 anymore, and it's time IE 6/7 died along with them. We shouldn't encourage 6/7 support, so I'm all in favor of removing them.

Besides, someone will come up with something (like ineedconditionals.co or something) that will let people who forget the syntax to copy and paste it in.

+1

We don't support IE 4/5 anymore, and it's time IE 6/7 died along with them. We shouldn't encourage 6/7 support, so I'm all in favor of removing them.

Besides, someone will come up with something (like ineedconditionals.co or something) that will let people who forget the syntax to copy and paste it in.

@luanmuniz

This comment has been minimized.

Show comment
Hide comment
@luanmuniz

luanmuniz Jul 22, 2013

-1
I agree with @wouterj
According to NetMarketShare and Statcounter IE8 has a very large market share, we cant just ignore this and remove all the conditionals.
We can remove the IE6/7, because even if you count the two together, the market share is not considerable, but I think keeping the conditionals for IE8 + is required.

Source:
http://gs.statcounter.com/#browser_version-ww-monthly-201304-201306-bar
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0&qptimeframe=M
http://www.w3schools.com/browsers/browsers_explorer.asp

-1
I agree with @wouterj
According to NetMarketShare and Statcounter IE8 has a very large market share, we cant just ignore this and remove all the conditionals.
We can remove the IE6/7, because even if you count the two together, the market share is not considerable, but I think keeping the conditionals for IE8 + is required.

Source:
http://gs.statcounter.com/#browser_version-ww-monthly-201304-201306-bar
http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0&qptimeframe=M
http://www.w3schools.com/browsers/browsers_explorer.asp

@rthor

This comment has been minimized.

Show comment
Hide comment
@rthor

rthor Aug 1, 2013

+1 For removing them.

Using an anti-pattern isn't a necessity for we could (and probably should) be developing from a low standard to a higher one, i.e. from legacy browsers to cutting edge ones. That is, start any project by creating specific styles and UX for those old browsers that you intend to support and then moving onward—slowly replacing and enhancing until you have reached the cutting edge technology.

It is true that this may require some rethinking and is quite time consuming, especially if you are targeting something as old as IE6 but it will be beneficial as no hacks are required. (Not counting media-queries which are by definition a hack).

This is similar to the mobile-first approach—just more general.


Another way to go would be to use a "shame" file for any hack regarding IE. For more info check out this article: csswizardry.com/2013/04/shame-css. This file could of course be conditioned out if not necessary just like @bjankord pointed out.

rthor commented Aug 1, 2013

+1 For removing them.

Using an anti-pattern isn't a necessity for we could (and probably should) be developing from a low standard to a higher one, i.e. from legacy browsers to cutting edge ones. That is, start any project by creating specific styles and UX for those old browsers that you intend to support and then moving onward—slowly replacing and enhancing until you have reached the cutting edge technology.

It is true that this may require some rethinking and is quite time consuming, especially if you are targeting something as old as IE6 but it will be beneficial as no hacks are required. (Not counting media-queries which are by definition a hack).

This is similar to the mobile-first approach—just more general.


Another way to go would be to use a "shame" file for any hack regarding IE. For more info check out this article: csswizardry.com/2013/04/shame-css. This file could of course be conditioned out if not necessary just like @bjankord pointed out.

@Craigy-

This comment has been minimized.

Show comment
Hide comment
@Craigy-

Craigy- Aug 1, 2013

-1. It's most comfortable way to support IE8.

Craigy- commented Aug 1, 2013

-1. It's most comfortable way to support IE8.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Aug 9, 2013

-1

I do want to target those browsers easily (IE7/8/9). In my company, a lot of our clients still use those crappy piece of software. For our product we have heaps of developers that care about IE7 and 8 more than ever because governmental agencies are still using it. Those agencies are a massive part of our portfolio.

ghost commented Aug 9, 2013

-1

I do want to target those browsers easily (IE7/8/9). In my company, a lot of our clients still use those crappy piece of software. For our product we have heaps of developers that care about IE7 and 8 more than ever because governmental agencies are still using it. Those agencies are a massive part of our portfolio.

@jswebschmiede

This comment has been minimized.

Show comment
Hide comment
@jswebschmiede

jswebschmiede Aug 9, 2013

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

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

@AllThingsSmitty

This comment has been minimized.

Show comment
Hide comment
@AllThingsSmitty

AllThingsSmitty Aug 9, 2013

Contributor

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.

Contributor

AllThingsSmitty commented Aug 9, 2013

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

This comment has been minimized.

Show comment
Hide comment
@thomasthesecond

thomasthesecond Aug 9, 2013

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

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

@TheDutchCoder

This comment has been minimized.

Show comment
Hide comment
@TheDutchCoder

TheDutchCoder Aug 9, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@HichemBenChaaben

HichemBenChaaben Aug 9, 2013

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

-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

This comment has been minimized.

Show comment
Hide comment
@sonicbobcat85

sonicbobcat85 Sep 21, 2013

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

-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

This comment has been minimized.

Show comment
Hide comment
@komputist

komputist Sep 25, 2013

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

@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

This comment has been minimized.

Show comment
Hide comment
@oliverbenns

oliverbenns Sep 28, 2013

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.

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

This comment has been minimized.

Show comment
Hide comment
@fernandopasik

fernandopasik Sep 28, 2013

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

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

@oliverbenns

This comment has been minimized.

Show comment
Hide comment
@oliverbenns

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

This comment has been minimized.

Show comment
Hide comment
@jpdevries

jpdevries Sep 28, 2013

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)

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

This comment has been minimized.

Show comment
Hide comment
@fernandopasik

fernandopasik Sep 28, 2013

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

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

@battaglr

This comment has been minimized.

Show comment
Hide comment
@battaglr

battaglr Oct 22, 2013

Contributor

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

Contributor

battaglr commented Oct 22, 2013

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

@andrewbiggart

This comment has been minimized.

Show comment
Hide comment
@andrewbiggart

andrewbiggart Oct 22, 2013

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

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

@brunolazzaro

This comment has been minimized.

Show comment
Hide comment
@brunolazzaro

brunolazzaro Oct 22, 2013

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

👍 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

This comment has been minimized.

Show comment
Hide comment
@wouterj

wouterj Oct 22, 2013

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 commented Oct 22, 2013

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

This comment has been minimized.

Show comment
Hide comment
@wouterj

wouterj Oct 22, 2013

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.

wouterj commented Oct 22, 2013

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

This comment has been minimized.

Show comment
Hide comment
@andydownunder

andydownunder Oct 22, 2013

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

LOL

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

LOL

@hlfcoding

This comment has been minimized.

Show comment
Hide comment
@hlfcoding

hlfcoding Oct 22, 2013

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

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

@patrickkettner

This comment has been minimized.

Show comment
Hide comment
@patrickkettner

patrickkettner Oct 22, 2013

Contributor

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

Contributor

patrickkettner commented Oct 22, 2013

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

@andydownunder

This comment has been minimized.

Show comment
Hide comment
@andydownunder

andydownunder Oct 22, 2013

Its on the readme

Why can't people RTFM?

Its on the readme

Why can't people RTFM?

@patrickkettner

This comment has been minimized.

Show comment
Hide comment
@patrickkettner

patrickkettner Oct 22, 2013

Contributor

@andypnewman no need to be rude, mate.

Contributor

patrickkettner commented Oct 22, 2013

@andypnewman no need to be rude, mate.

kcmckell added a commit to kcmckell/html5-boilerplate that referenced this issue Feb 25, 2014

Remove IE conditional classes
The reasons behind this decision include the following:

* This project will drop legacy browser support (see #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: #1187).

This change also removes the related documentation.

Close #1290 and #1187.

@AndrewKvalheim AndrewKvalheim referenced this issue in dannyprose/Middleman-HTML5BP-HAML Oct 26, 2014

Closed

Add missing IE conditional comment. #14

rlovtangen added a commit to rlovtangen/grails-profile-repository that referenced this issue Feb 18, 2015

jameskleeh pushed a commit to grails-profiles/web that referenced this issue Jul 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment