Consider merging strict, preserve and appendVariables option as `strict`

[MoOx]

I think we can simplify the usage of those 3 options as one: strict.

strict set to true will

• add all fallbacks according to the specs
• preserve original author code as future proof code
• append user variables at the end to reflect make sense with previous points. in order to be more close to specs

strict will be default to false in order to reduce output (and because I am sure some will whine :p)

poke watchers + @simonsmith @hgl what do you think about that ?

[hgl]

Hum, this issue starts to give me headache.

Yes, it's taking longer than it should.

it not just no/no/yes/yes.

Mind to elaborate on what's missing?

... 3. seems to just be 2. for declarations.

Not quite understand it. Do you mean #3 and #2 are the same for properties in :root {...}?

Here are some solutions I see (that we can already handle today)

I see where you are coming from with the two options. They actually maps to these combinations of the four conditions:

• i want minimal output (min) no/no/no/no
• i want minimal safe output (with fallback) no/yes/no/no
• i want minimal output + my original code (preserve) yes/no/yes/yes
• i want minimal safe output + my original code (preserve + fallback) yes/yes/yes/yes

The last two scenarios:

• i want minimal output + computed definition (preserve: computed). no/no/yes/yes
• i want minimal safe output + computed definition (preserve: computed + fallback). no/yes/yes/yes

I think we should just define five keywords in one option to map to the five scenario (the last scenario isn't very useful like you said). Because as you can see the two-option way breaks down when we need to add one more scenario. With two options, one option takes three values (true, false, computed) and the other take take two (true, false), you are forced to deal with six possible combinations, even if you are only interested in five.

[MoOx]

I think it's not a good idea to handle several options under flag. What if a some new scenarios came up ?

[MoOx]

you are forced to deal with six possible combinations, even if you are only interested in five.

And what is the problem with that ?

[hgl]

What if a some new scenarios came up ?

If a new scenario comes up, either it is independent of existing scenarios, in which case we simply add a new keyword to the sole option, with existing keywords having the effect of disabling this new scenario. Or, if it affects existing scenarios, we have to introduce a breaking change to modify the behavior of existing keywords. Note that if we use two options approach, we still have to make this breaking change. Adding a new option won't be enough, because it affects existing scenarios even if it's false.

And what is the problem with that ?

Like you previous mentioned, you have to explain to users some particular option combinations are ignored. With one option approach, there is nothing to explain, users simply use one of the keywords we introduced and that's it.

[MoOx]

Do you have lot's of example of this kind of string options that handle multiple scenarios ? Doesn't seems like a good pattern.

[hgl]

Think this option like a screen color profile:

What changing the profile really does is to change the underlying options. The profile merely contains the combination of these options.

What we are doing is to allow the user to change the profile, but not the underlying options.

Hope that makes sense.

[hgl]

Actually autoprefixer also provides this kind of option.

What Firefox < 20 really does is ['Firefox 19', 'Firefox 18', ...].

[MoOx]

You example doesn't reflect our situation. Color profile can be calibrated by hand, and autoprefixer browsers option is to define a range & provide a very wife range of possibility.

[hgl]

Color profile can be calibrated by hand

That's why I said "what we are doing is to allow the user to change the profile, but not the underlying options."

autoprefixer browsers option is to define a range

The point is it allows users to specify a string, which enables a couple of sub-options. This is what I'm suggesting us to do.

To give one more example, think photoshop brushes. When you select a brush preset, what you really did is to apply the sub-option it contains (brush size, roundness, hardness, etc). The keywords we are going to define is like brush presets. To prevent users from generating ugly brushes, we disallow them to change the sub-options individually, only selecting brush presets that we defined is allowed.

[MoOx]

You example with brush is wrong from what I know of photoshop. Brush are defined by some pictures that you can apply some transformations on.

[hgl]

Brush are defined by some pictures that you can apply some transformations on.

That's one of its sub-option called texture.

See the sub-options it provides:

OK, to give some js example, see babel's transformers: https://babeljs.io/docs/usage/transformers/

We can define four options to give users total control over the final output, just like babel exposing all its transformers.

Only that we decided some of the options combinations don't make sense. So we define keywords to controls these four options. Babel, actually already contains such keywords. See the es6, es7 prefixes? Babel could in principle define a single options accepting es6 or es7 to enable corresponding transformers at once.

[hgl]

I think three keywords might be enough:

preserve: false // I want minimal output that works preserve: 'all' // I want spec compliant output preserve: 'definitions' // I want to extract custom properties definitions

I'm unable to come up with a compelling use case for enabling fallback but not keep :root {...} for example. Too many options might confuse users.

[MoOx]

That's what I realize when I started working on this. So I think we should have strict option for fallback and preserve (false, true "computed-definition"). Sorry for insisting on "computed-definitions" but I really think it's more clear than just "computed" or just "definitions". Does this looks good to you ?

[hgl]

Sure, computed-definitions is fine.

[MoOx]

I think I will revert this, since we only talking about edge cases. I will keep fallback by default since I don't want to introduce differences with the specs & leave options as they are for now. Not a big deal imo since nobody came here and ask for news.

For strict, default to false, so no major bump. If you use many fallbacks & want a small output, you will be able to use the strict: false options.

Other options are edge cases anyway.

[hgl]

After all this time, I actually forgot what all these options do. Have to try pretty hard to remember again what they do and how some options don't have effect when some other options are on/off. No to mention people that are not familiar with this plugin.

If you are willing to accept variable extraction in cssnext then I don't think option to preserve computed definitions is an edge case, and I think the current "multiple options to control the output" design is a total mess.

But I guess not many people with fight with options in this plugin, they will simply use cssnext, and this discussion is taking longer than it should. So I'm not willing to fight it out.

I'm eager to send the extract PR to cssnext once all options are stable, my fork seems to lag behind your branch pretty significantly already.

[MoOx]

Since nobody ask for that for a while. We might reconsider this later.