Internet Explorer support

In this issue I would like to elaborate on the support of Internet Explorer.

First, let me address the developers that require Internet Explorer support: I respect your decisions, and understand that one of the top priorities is satisfying the client’s needs. By no means I want to show disrespect or hold a grudge against you, or any kind of technology you support. I simply want to cover how Internet Explorer support affects atomic-layout. Thank you.

Insufficient partial CSS Grid spec support

Atomic layout uses CSS Grid, which is only partially supported in IE11, without any kind of support in prior versions of the browser. Upon testing, that partial support is simply not enough to provide good developer and user experience, as some vital CSS Grid properties are not implemented:

• grid-gap
• grid-area
• grid-template-areas

There are some ways to polyfill those properties, which I will mention in this post below, as well as why it won’t ship as a part of the atomic-layout package.

In general, I see no point of such archaic support if it results into broken implementation. I’m also against shipping workarounds for the sake of legacy browsers.

Internet Explorer is dead

Internet Explorer as project is not supported by Microsoft for years. It still gets bugfixes, but it will not ship new features, and what interests us the most, new implementations of CSS spec. I believe that when Windows 7 gets out of the lifespan, Internet Explorer will by officially dead.

Since you cannot use CSS Grid with IE, do not expect to use Atomic Layout with IE. I believe in a brighter future of web, where we don’t support legacy browsers for years, but rather educate our customers to evolve alongside the web.

Holding things down

Supporting legacy technology comes with a cost: you cannot develop things how you envision it, but need to constantly compromise to endure that support. For example, I do wish to adopt Proxy (#86) to grant much better developer experience when working with the library and support runtime template changes. With IE support I simply cannot do that.

Conclusion

I’m sorry for those who count on using Atomic Layout in IE10-11, but I’ve decided to remove IE support entirely by introducing Proxies. You will not be able to use this library in the mentioned browser, so please consider an alternative, or drop the support of IE in your product, if you can.

Thank you.

[kettanaito]

As the next step, I will try to integrate babel-plugin-styled-components-postcss into the Babel config of the library. This way the AST transformations will be applied to the CSS emitted by the library. The tricky part would be to inherit the usage-point PostCSS config.

[kettanaito]

Technical insights

Limited support of CSS Grid in IE

Despite IE team actually creating the first draft of CSS Grid, the latest spec is not fully supported in the latest Internet Explorer browser, being IE11.

The unsupported CSS properties include:

• grid-gap (and its derived properties: grid-gap-row, grid-gap-column)
• grid-area (connects a child element to the given grid area of the parent)

Those properties crucial when building layouts with CSS Grid, and are primarily relied on internally in Atomic Layout.

Polyfilling

There are, however, ways to use the spec to a certain extent via Autoprefixer, and its CSS Grid support. It would create prefixed replacement properties, and use other supported properties (such as grid-column: 1 to substitute grid-area, for example. Sounds like a good start.

To recap: if we enable Autoprefixer (implies PostCSS) transformations to the CSS output of styled-components, we may have Internet Explorer support. However, it turns out there is no way to transform CSS from styled-components due to how the library works internally, and its ideology.

To be fair, there are plugins that may allow to transform the output (although its affect on the runtime styles and bundle size is to be verified), for example babel-plugin-styled-components-postcss. The issue with that is that there is no meaningful example of how to use it. Examples mentioned in the README contradict the API from Autoprefixer, which in return contradict the API mentioned in the linked articles.

Conclusion

Internet Explorer support doesn’t move anywhere at this point.

Although autoprefixing the CSS allows CSS Grid support in IE10-11, it cannot be used with styled-components. I believe this relates to any runtime CSS-in-JS solution in general.

Possibilities

Consider a different CSS-in-JS solution

Styling solution for Atomic layout is meant to be pluggable. This is not implemented yet, but the concepts of Atomic layout, and its usage of CSS Grid, are not reliant on any specific solution. It can be Angular, or Vue, using their respective styling packages. Prefixing and IE support would fall on the shoulders of the end developers, which I find the most appropriate solution. The library must not assume browser support and ship potentially unused transformations.

Using runtime-free CSS-in-JS

One of such packages is astroturf.

This would allow to have a familiar CSS-in-JS setup, and gather the CSS statically, applying necessary transformations of any sort.

Cons:

• Limits Atomic layout to a specific styling solution, preventing from future modularity;
• Puts CSS more control over CSS processing to the end developer (not necessarily a good thing), as they are now responsible for setting up CSS transformation pipeline (i.e. loaders chain).

Expected behavior

It would be great to expose the generated CSS to the end developer, and let them transform it in whichever way is necessary to fulfill their requirements.

Materials

• https://github.com/styled-components/styled-components/issues/482
• babel-plugin-styled-components-postcss
• The guide about Grids in IE and Autoprefixer