Plan for IE support

[dsingleton]

Our current approach to IE support uses different CSS files for each version of IE, targeted by conditional comments (aka, the archibald method).

A goal alpha is to reduce the number of CSS files, to try and simplify integrating the package into consuming apps (eg, directly consuming sass, without compiled CSS). Part of this includes trying to have a single representation/codified version of a component/layout, not spread across multiple files. We've also had some evidence that this method of IE support is confusing to contributors and consuming teams.

As part of the alpha we should look at how we support IE, and what we can simplify. At this stage in the alpha we're ignoring IE support (there are no IE specific stylesheets) while focusing on other parts of the alpha, but we'll need to decide a plan before the beta.

Possible approaches include;

• Forecast what level of IE support we will need for a beta product, can we reduce the need to support legacy browsers (based on analytics, within www.gov.uk and on services, ideally) and/or re-evaluate where browsers fall in our support levels (eg, moving more old IE to functional)
• Profile what conditional IE support the alpha SCSS is currently using, investigate if these could be done in another way. We should also do the same for some example services
• Talk to services about their IE support needs
• If we changed approach, how would that affect teams using the existing approach?

[selfthinker]

Wouldn't it be best to simply rewrite the mixins (currently in FET's _conditionals.scss)? Assuming everyone is using those and not the variables directly, and also assuming we will have classes on either the html or the body tag instead...

@mixin ie-lte($version) {
  @if $is-ie {
    @if $ie-version <= $version {
      @content;
    }
  }
}

could become

@mixin ie-lte($version) {
  html.ie-lte-$version & {
    @content;
  }
}

(Untested, but you get the gist.)