Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

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

Open
joyously opened this issue Nov 26, 2017 · 1 comment
Open

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

joyously opened this issue Nov 26, 2017 · 1 comment

Comments

@joyously
Copy link
Contributor

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?

LeaVerou pushed a commit that referenced this issue Dec 12, 2017
* trigger a custom event 'StyleFixProcessed'

Add a custom event 'StyleFixProcessed' to indicate when the styles are fixed.
This is needed for situations that entail further processing, such as described in #6132

* Fix variable fallback parsing

Split variable handling into two parts so fallback handling could be recursive.
Fixed fallback whitespace and nested variable handling.
Parsing now handles more cases with parentheses.
Addresses #6132 by using new custom event to get the last value of variables after they are all processed (which meant a little bit of duplicated code for the second pass).
@joyously
Copy link
Contributor Author

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant