Skip to content

Loading…

Remove IE conditional classes #1290

Closed
necolas opened this Issue · 85 comments
@necolas
H5BP member

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

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
H5BP member

:+1:

@influxweb

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

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

@ShaneShipston

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

@SBoudrias

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

@nvartolomei

Hands up for this. :+1:

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

@derekjohnson

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

@gavtaylor

+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

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

@ryan-blunden

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
H5BP member

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

@mathiasbynens
H5BP 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.)

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

@sturobson

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

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

@necolas
H5BP member

Writing styles just for IE 8 could be folly!

@sturobson

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

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

@sturobson

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

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

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

@bjankord

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

@bjankord

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

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

Also +1

@ChrisWojcik That's something Modernizr should handle.

@jelmerdemaat

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

@Marfa

If you can safely remove smth it's always good

@ChrisWojcik

@Inkdpixels am sure I agree

+1 on this

@TheDutchCoder

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

@TheDutchCoder

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

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

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

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.

@WouterJ

@pierrepavlov but people that don't use that solution can also easily remove it from there source code. People shouldn't just use the complete boilerplate if they start a new project. They should remove every part they don't use and understand what every line means.

@bjankord

@WouterJ That's why I like the single conditional comment for an IE8 and lower stylesheet solution I talked about here: #1290 (comment) It's the most delete key friendly, just need to remove 1 line if you don't need it. It also fixes another open issue.

@WouterJ

@bjankord yeah, I think that is the best approach. It is easy to remove for people who hate old IE's and it is somewhat easy to use for people that love old IE ;-)

@JoshuaJones

@WouterJ That's why I like the single conditional comment for an IE8 and lower stylesheet solution I talked about here: #1290 It's the most delete key friendly, just need to remove 1 line if you don't need it. It also fixes another open issue.

+1

IE8 is gonna be with us for awhile.

@reecekol

According to this http://www.w3schools.com/browsers/browsers_explorer.asp. I think it would be safe to drop it at least for IE6 and maybe 7

@ryanswedal

I was fooled on that one originally too. You have to read the fine print... those stats on w3schools are only from their sites logs. FYI.

@maogac

toca ver como se comporta...!!!

@scottnix scottnix referenced this issue in middlesister/thematic-html5
Closed

Add h5bp html classes #2

@gpakosz gpakosz added a commit that referenced this issue
@gpakosz gpakosz make clearfix use IE conditional classes
Albeit IE conditional classes are meant to disappear (#1290),
be consistent and make use of them while they're still here
instead of IE6/IE7 CSS hacks.
9d011ad
@victoriafrench

rather than use the browser injection (conditional comments) a better solution is to include Defunctr. Not because I created this project but because it resolves many issues. First it uses Modernizr and like Modernizr it adds the browser classes based on feature detection (so it works even in IE emulation mode and even if the user fakes the host header). Second it will tell you that you are .ie-gt-9 when 10+ is encountered, something that can't be done in the current method being used. It also adds no- classes, which means you can style for .no-ie. It will also allow the IE=Edge to be read correctly because there is only one html element. This list goes on. It's also really easy for a user to remove, they just exclude the script. Please consider this option. http://github.com/victoriafrench/defunctr

@gpakosz

Defunctr assumes Javascript though. Bookmarked it.

@GloverDonovan

I completely agree that the IE conditionals should be removed. Most developers don't support IE6/7 today, and IE8 is slowly dying. Many XP users will upgrade to Win 7/8.

@alfredxing

I agree as well. I think we should start by removing the IE7 conditional tag, especially since there's already a browser update conditional in place.

Also: I'm relatively new to Boilerplate, so feel free to correct me and provide feedback/tips.

@mhmoretti

I agree, remove the conditionals.

@AllThingsSmitty

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

@battaglr

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

@Roope

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

@tjbarber

+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

-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

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

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

@ghost

-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

:-1: the reality is the users actually use IE7 or IE8.

@AllThingsSmitty

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

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

@TheDutchCoder

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

-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

-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

@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

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

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

@oliverbenns

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

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

@alrra alrra added a commit that closed this issue
@alrra alrra 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.
13f17a7
@alrra alrra closed this in 13f17a7
@battaglr

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

@andrewbiggart

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

@brunolazzaro

:+1: 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

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

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

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

LOL

@hlfcoding

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

@patrickkettner

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

@andydownunder

Its on the readme

Why can't people RTFM?

@patrickkettner

@andypnewman no need to be rude, mate.

@WraithKenny WraithKenny added a commit to WraithKenny/html5-boilerplate that referenced this issue
@alrra alrra 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.
216767d
@kcmckell kcmckell added a commit to kcmckell/html5-boilerplate that referenced this issue
@alrra alrra 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.
6c08acd
@AndrewKvalheim AndrewKvalheim referenced this issue in dannyprose/Middleman-HTML5BP-HAML
Closed

Add missing IE conditional comment. #14

@rlovtangen rlovtangen added a commit to rlovtangen/grails-profile-repository that referenced this issue
@rlovtangen rlovtangen GRAILS-11998 Align with latest changes to HTML5 Boilerplate. Remove c… 23e4d62
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.