Yonic Corner on IE: Adapting current design
As a fan for retro technology, I wished for Yonic Corner to be compatible with legacy browsers, while at the same time being able to support somewhat modern features and a modern development environment.
The first version of the Vectarcade design of this blog proved to have some significant hurdles that I had to overcome. In the end, the blog works mostly fine with Internet Explorer 11, but older versions still struggle.
Dear Astro:where(are .you > #going) with this?
The biggest issue with Astro and retrocompatibility was its default behaviour when it comes to scoped CSS.
By default, it uses the :where() pseudo-class to avoid classname collisions. This pseudo-class was added into the specification not long ago, so legacy browsers do not support this.
In order to work around this, I ported most UI components I had with scoped CSS to Svelte, which doesn’t use :where() by default. But when I was almost done doing this, I realized that this behaviour can be configured in Astro to use the
traditional classname approach, that is supported by most legacy browsers.
Guess I will have to refactor the styles again to make it more organized…
Too many var(--iables) to calc(ulate) the result
While it’s natural to assume that CSS variables are not supported by legacy browsers (not even IE11 does), it’s not so straightforward to believe that the calc() function also has its own weirdness with Internet Explorer.
Thankfully, Sass comes to the rescue. I was able to delegate many of the calculations to the Sass preprocessor in order to do them beforehand. There are still some left, but right now I don’t have a proper way to fix them.
As for the CSS variables, it wasn’t as simple as replacing every CSS variable with a Sass one, because some HTML elements would define their own in their inline style. My approach to it was to generate variants with @for and @each loops with selectors that could separate all the variants individually.
The rainbow decoration at the left of every blog post was particularly cheeky to make it working because it had a layout that nastily breaks the document flow and had a mixture of calculations and variables hard to make it working. It is only displayed properly in IE11, as far as I know.
Em… I don’t understand.
Responsive units like vw, em and rem are not supported by legacy browsers. I’m still working on this, but the best way I found to make it backwards compatible is to do this:
.random-element {
/* Applied first */
padding: 5px;
width: 100%;
/* Applied second by browsers that support these units */
padding: 1rem;
width: 100vw;
}.random-element {
/* Applied first */
padding: 5px;
width: 100%;
/* Applied second by browsers that support these units */
padding: 1rem;
width: 100vw;
}.random-element {
/* Applied first */
padding: 5px;
width: 100%;
/* Applied second by browsers that support these units */
padding: 1rem;
width: 100vw;
}If a browser understands the unit of the second rule, it applies it to the element, undoing the effects of the first rule. But if it doesn’t, it will just ignore it and keep the first one.
However, in some situations there may be no other choice than to use the @supports rule.
Broken images, broken images everywhere!
Astro’s new asset optimization model doesn’t have built-in Picture components, but I figured that displaying WebP images was enough for most browsers, even IE 11.
Of course, I was wrong, and not only that, but IE 11 is also incapable of rendering SVG properly, being incapable of understanding how to render it unless I put a viewBox parameter, and it still struggles to render it correctly when it’s not displayed at its original size.
I’ve yet to make a precursor <Picture> component that will be able to handle multiple formats in the requested sizes.
As for SVGs, since versions below IE9 won’t be able to display SVG images at all, I’ve decided to create PNG versions of some of these images, which definitely work on IE.
Broken JavaScript means component drought
The little JavaScript I use to have a couple features in the blog won’t flat out work on IE. The main reason lies on the fact that Astro’s way of handling client-side JavaScript is by bundling into chunks that are imported as modules. This is in no way supported by IE in any version.
The same applies for the main feature of Astro: The Island architecture. The way it hydrates the components uses ES6 syntax, which IE only supported barely anything in IE11. Without hydration, reactive components like Svelte components will be just dry, static HTML widgets.
The only possible workaround I came up with was to sacrifice using UI frameworks and enforce inlining of every single client-side script with <script is:inline> or <script is:raw>,
and stick to ES5.
I may be willing to sacrifice Svelte, but this won’t have support for TypeScript and it won’t be optimized, and there’s no way I’m giving those things up.
We need to go deeper!
Despite my best efforts on making my blog backwards compatible with older browsers and succeeding, I came out pretty disatisfied with the result. I felt like I could do a lot more than this.
Eventually I came out with the decision of creating a legacy version of Yonic Corner, specifically tailored for much older browsers: I’m talking about the first versions of Firefox and Opera as well as IE 5.5; commonplace browsers back in the days of Windows 9x.
I will cover the development of this legacy version in future parts of this series!
