Hey Chuck,
thank you for writing this great polyfill! I have been using REM for a while but always relied on some scss mixins to include the relevant IE fallback. I'm currently refactoring the CSS for my own website and as I wanted to get rid of all that boilerplate in my scss I was looking for a good js polyfill and stumbled upon your work.
Everything works fine in IE8, but the performance is pretty bad - according to the IE profiler I have about 2.5 seconds (! edit - this is fixed now) of String.match execution time for every page, which produces a very noticeable hiccup as the page changes quite dramatically once all the REMs all properly calculated and the page is re-rendered thus.
I have about 100 mentions of REM in my compiled stylesheet, which isn't all that much I feel like (I am using REM for all dimensions, not just font related stuff). When I check the dynamically inserted CSS portions however I get about three times the number of "px" mentions, which led me to investigate further. This is all speculative but I think the decrease in performance might have something to do with the fact that all my grouped CSS selectors become un-grouped after their rem.js treatment which leads to the increase in selectors, for example:
/* line 173, ../sass/template.scss */
article.intro .button, article.intro .button-small, article.intro footer a, section .pagination a{
font-size: 0.6rem;
}
all get their own line in the CSS compiled by rem.js.
I'm not sure if rem.js is just a bad fit for my particular way of writing CSS or if this is a more general issue you would like to address in future versions. I love the nesting and @extend features that precompilers like Sass provide along with pretty "classless" HTML. But if you belong to the "object-oriented" CSS folks that like to write very granular CSS classes and apply bunches of them to their HTML elements, this issue - in all likelihood - would not nearly be as pronounced.
Oh and by the way: I have also noticed that the generated CSS has quite a few "0px" in it, for example the shorthand of
margin{
0 1rem 0;
}
becomes
margin{
0px 25px 0px;
}
Any 0s can safely be ignored I think, which might also increase performance.
For my particular case, I will try to remove the pre-selection of the affected selectors with REM in them from the script to just replace any "x"rem in a less sophisticated way, maybe that helps.
In any case, thank you again for writing this polyfill, I'd love to hear your thoughts on this issue.
EDIT: Turns out the 2.5s issue was nonsense - I had an error in my build file throwing the base64 encoded icon font into the wrong file, which was getting parsed by rem.js - DOH!
Now I'm down to 180ms on String.match which is not terrific but much better. There is still a hiccup however and my thoughts re: grouped selectors still stand...
Hey Chuck,
thank you for writing this great polyfill! I have been using REM for a while but always relied on some scss mixins to include the relevant IE fallback. I'm currently refactoring the CSS for my own website and as I wanted to get rid of all that boilerplate in my scss I was looking for a good js polyfill and stumbled upon your work.
Everything works fine in IE8, but the performance is pretty bad - according to the IE profiler I have about 2.5 seconds (! edit - this is fixed now) of String.match execution time for every page, which produces a very noticeable hiccup as the page changes quite dramatically once all the REMs all properly calculated and the page is re-rendered thus.
I have about 100 mentions of REM in my compiled stylesheet, which isn't all that much I feel like (I am using REM for all dimensions, not just font related stuff). When I check the dynamically inserted CSS portions however I get about three times the number of "px" mentions, which led me to investigate further. This is all speculative but I think the decrease in performance might have something to do with the fact that all my grouped CSS selectors become un-grouped after their rem.js treatment which leads to the increase in selectors, for example:
/* line 173, ../sass/template.scss */
article.intro .button, article.intro .button-small, article.intro footer a, section .pagination a{
font-size: 0.6rem;
}
all get their own line in the CSS compiled by rem.js.
I'm not sure if rem.js is just a bad fit for my particular way of writing CSS or if this is a more general issue you would like to address in future versions. I love the nesting and @extend features that precompilers like Sass provide along with pretty "classless" HTML. But if you belong to the "object-oriented" CSS folks that like to write very granular CSS classes and apply bunches of them to their HTML elements, this issue - in all likelihood - would not nearly be as pronounced.
Oh and by the way: I have also noticed that the generated CSS has quite a few "0px" in it, for example the shorthand of
margin{
0 1rem 0;
}
becomes
margin{
0px 25px 0px;
}
Any 0s can safely be ignored I think, which might also increase performance.
For my particular case, I will try to remove the pre-selection of the affected selectors with REM in them from the script to just replace any "x"rem in a less sophisticated way, maybe that helps.
In any case, thank you again for writing this polyfill, I'd love to hear your thoughts on this issue.
EDIT: Turns out the 2.5s issue was nonsense - I had an error in my build file throwing the base64 encoded icon font into the wrong file, which was getting parsed by rem.js - DOH!
Now I'm down to 180ms on String.match which is not terrific but much better. There is still a hiccup however and my thoughts re: grouped selectors still stand...