Slow in IE8, possible issue with grouped selectors

[ChrisKam]

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...

[chuckcarpenter]

@ChrisKam, thank you for the very thoughtful and insightful message. I spent some time thinking about the suggestions you made here, which I think would help make this polyfill more universally useful. It's an interesting point that your separate selectors are getting there own lines and I think that'd be a great use case to add to the polyfill. We've not had the need to support < IE9 at my regular job these days, so our enhancements have slowed. That said, we're happy to look at contributions and bring in features that people need.

I love nesting and @extend features that SCSS gives you, but we use more of a BEM methodology and give nodes each a unique class, eliminating a lot of deep nesting scenarios.

I like the small cleanup idea with 0 values having no unit declaration (as it should be) and think that could make it in sooner than later. A

Also, I'm wondering if this pending change, https://github.com/chuckcarpenter/REM-unit-polyfill/pull/39, will do anything to improve performance and it syncs sheet processing a bit better from I can see. Feel free to check out that branch, albeit I expect we can merge it soon.

Again, I really appreciate the insight and sorry it was so long before I responded.

Chuck

[ChrisKam]

Hey Chuck, I appreciate you taking the time to comment! I've been tremendously busy myself lately so no worries on that front. I might even put in a pull request to tackle the things I've mentioned myself once I attain the same level of regex wizadry :)

best wishes Chris

[u353]

Hey ChrisKam thank you for sharing your experiences. What exactly did you encounter when you had rem.js parsing style sheets with base64 encoded icons in it?