LeaVerou / prefixfree

Break free from CSS prefix hell!
http://projects.verou.me/prefixfree/
MIT License
3.83k stars 712 forks source link

prefixfree-vars: getting the most 'right' value for the variables #6132

Open joyously opened 6 years ago

joyously commented 6 years ago

You merged my fix for modern syntax(#6127), but while it worked on a small test case, it has a couple issues with the fallback value and some whitespace handling that I recently found. I'm not sure which way is best for an update.

If I make minimal changes, I can improve the fallback and whitespace.

If I split the parsing into two functions and use the index parameter of the register function, I can make those same improvements, but it modifies slightly how the functions are called. It would do all the definitions and then all the usage (for each stylesheet individually). In my mind, this makes more sense, but in testing, it isn't optimal because of the cascade.

If I create a new function in PrefixFree, I can invoke my variable handling the way my testing shows I need to, which is to use two passes for CSS variables. I am referring to doing foreach(fixer) { foreach(stylesheet) } instead of foreach(stylesheet) { foreach(fixer) } The first pass gets all the definitions from all stylesheets, and the second replaces with values that have cascaded. Since this polyfill is limited to global variables, it makes sense to get the values from the last stylesheet in the cascade instead of whatever is defined when the variable is used.

There could be a sort of hybrid approach which uses two passes only for fallback values, but it really can't emulate the cascade the way a browser will work, so I think it's best to assume global variables only.

Since I have a project that I wrote my stylesheets knowing I would use this polyfill, and it does not handle the values correctly(I see the default values instead of the values specified last), I think the way that would work is to use two passes, getting the final values of the variables, and only then replacing them on the second pass. But I can make the small fixes to this library, and make bigger changes to the version I use in my project, although it seems everyone else would need the same thing.

What do you think?

joyously commented 6 years ago

I was going to close this issue, but I occasionally see timing problems. It looks like the code is working fine, except on local tests that load faster than remote ones do. And putting a breakpoint in the script causes it to take longer, so it works fine then. Any suggestions on what a delay would mean to code triggered by an event? Do I need a Promise somewhere?