Internet Explorer support
kettanaito opened this issue · 5 comments
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-gapgrid-areagrid-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.
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
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.
The usage of babel-plugin-styled-components-postcss doesn't solve the issue, since it's the library's build-time transformer. The styles that will be generated by styled-components based on the provided responsive props of Atomic layout happen at the runtime of the usage surface (your app). It will not hook up that Babel plugin, and it shouldn't, as the plugin is a requisite of the library, not your application.
If you introduce that plugin on the usage surface, then it won't be able to process the internal string literals of the library that require processing, because now the plugin application surface (your app) and the styles generation surface (Atomic Layout) are in two different universes.
The more I investigate this issue, the more I'm convinced the result is not worth the noise. At the moment I'm not going to continue investigation of IE support, since it has proven numerous times to be an extremely hacky endeavor. Please consider educating the web.
Technical notes
For those wondering why it's not an easy task to support autoprefixing (polyfilling later) for style template literals in Atomic layout (to enable CSS Grid support in IE, for example), here are a few technical notes.
- Polyfilling must happen on the end developer's side. It's not about supporting a single feature, but about an ability to transform generated CSS (or raw template strings) with whichever transformations required by the end developer.
- Styled components have no support for transforming emitted CSS (on purpose). This makes it impossible to polyfill on the end developer's side directly. As Atomic layout strives to become style-agnostic solution, it gets harded to cope with implementation difference of each CSS-in-JS solution in terms of post-generative transformations.
- Polyfill must reflect developer's changes. Styles generation in Atomic layout is dynamic. This means that the library itself doesn't know which styles you will configure its components to generate. Since the styles are configured by the end developer, there is no way to polyfill them at the library's build time. Build time is the only place where some Babel plugin can be put to take raw style template literals and process them through PostCSS, for example.
@kettanaito -- Love your thought process on this!