Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove IE conditional classes #1290

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

Comments

Projects
None yet
@necolas
Copy link
Member

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.

Copy link

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

@alrra

This comment has been minimized.

Copy link
Member

commented Jan 13, 2013

👍

@influxweb

This comment has been minimized.

Copy link

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

@shaunbent

This comment has been minimized.

Copy link

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

@roblarsen

This comment has been minimized.

Copy link
Member

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.

Copy link

commented Jan 13, 2013

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

@SBoudrias

This comment has been minimized.

Copy link

commented Jan 13, 2013

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

@nvartolomei

This comment has been minimized.

Copy link

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

@derekjohnson

This comment has been minimized.

Copy link

commented Jan 13, 2013

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

@gavtaylor

This comment has been minimized.

Copy link

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

@wouterj

This comment has been minimized.

Copy link

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.

Copy link
Member Author

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.

Copy link

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

@necolas

This comment has been minimized.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link

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

@sturobson

This comment has been minimized.

Copy link

commented Jan 13, 2013

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.

Copy link
Member Author

commented Jan 13, 2013

Writing styles just for IE 8 could be folly!

@sturobson

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Member Author

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.

Copy link

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

@drublic

This comment has been minimized.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link

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

@drublic

This comment has been minimized.

Copy link
Member

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.

Copy link

commented 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]-->
@ChrisWojcik

This comment has been minimized.

Copy link

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

@Inkdpixels

This comment has been minimized.

Copy link

commented Jan 14, 2013

Also +1

@ChrisWojcik That's something Modernizr should handle.

@jswebschmiede

This comment has been minimized.

Copy link

commented Aug 9, 2013

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

@AllThingsSmitty

This comment has been minimized.

Copy link
Contributor

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.

Copy link

commented Aug 9, 2013

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.

Copy link

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

@HichemBenChaaben

This comment has been minimized.

Copy link

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

@sonicbobcat85

This comment has been minimized.

Copy link

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

@komputist

This comment has been minimized.

Copy link

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

@oliverbenns

This comment has been minimized.

Copy link

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

@fernandopasik

This comment has been minimized.

Copy link

commented Sep 28, 2013

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

@oliverbenns

This comment has been minimized.

Copy link

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.

@jpdevries

This comment has been minimized.

Copy link

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

@fernandopasik

This comment has been minimized.

Copy link

commented Sep 28, 2013

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

@battaglr

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2013

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

@andrewbiggart

This comment has been minimized.

Copy link

commented Oct 22, 2013

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

@brunolazzaro

This comment has been minimized.

Copy link

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

@wouterj

This comment has been minimized.

Copy link

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.

Copy link

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.

Copy link

commented Oct 22, 2013

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.

Copy link

commented Oct 22, 2013

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

@patrickkettner

This comment has been minimized.

Copy link
Contributor

commented Oct 22, 2013

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

@andydownunder

This comment has been minimized.

Copy link

commented Oct 22, 2013

Its on the readme

Why can't people RTFM?

@patrickkettner

This comment has been minimized.

Copy link
Contributor

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

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
You can’t perform that action at this time.