css-prefix

[jer3m01]

Follow up to #1288.
Used to gather ideas and things to do.

As stated by @ematipico, we could implement css-prefix in a similar way to the linter (linter rules).

Each prefix application (as in per css rule and/or value) would have it's own file with an exported visitor.
So transition, animation, filter and all others would have their own individual file.

Now because certain values also have prefixes (such as flex) we could either have a file for the display property or for the flex value.
css-prefix/prefixes/display.ts vs css-prefix/prefixes/flex.ts, What do you guys think?

Another thing is browser support, as there aren't any existing target browser handling, we could provide a simple exported callback that would return whether the prefix should run or not for the target browser (maybe passed as a string for the time being?).
Or we could wait until an actual target browser implementation is present.

Here are some useful links to information on prefixes:
https://caniuse.com
http://shouldiprefix.com

[jer3m01]

About caching, doesn't seem to need any specific for css-prefix as the base compiler already handles it.

tools/internal/compiler/api/compile.ts

Lines 32 to 35 in 97653ef

	const cached: undefined | CompileResult = compileCache.get(query);
	if (cached) {
	return cached;
	}

[ematipico]

So, on top of my head, I have the following things:

• CSS prefixer would be just one small piece to the whole handler of the CSS
• we should pass to the prefexir the project configuration because we need to have a browser target
• at the moment we have a modern option for bundling and this could be a start
• CSS handler should manage the prefixer, CSS modules (it seems becoming a standard) and an handler to purge the CSS (classes that are not used)
• prefixing should be applied only to CSS that is actually used (later in the future)
• prefixer should depend on the type of browser we want to target
• we should not support IE11: it's been deprecated from MS and it's an hazard

[jer3m01]

Since there will be multiple parts should we make a main folder that groups everything css related in the compile transfomation folder?

What would modern be?

prefixing should be applied only to CSS that is actually used (later in the future)

We could just run the css purger before the prefixer.

[ematipico]

Since there will be multiple parts should we make a main folder that groups everything css related in the compile transfomation folder?

Yes I think it makes totally sense!

What would modern be?

https://github.com/rome/tools/blob/main/internal/compiler/transforms/index.ts#L80

But I think it's old code... by looking at its interface: https://github.com/rome/tools/blob/main/internal/compiler/types.ts#L81-L88

prefixing should be applied only to CSS that is actually used (later in the future)

We could just run the css purger before the prefixer.

I am not sure... purging unused CSS classes should be done only when we bundle - for production - and done only after the prefixer. And it could be very tricky. The prefixer will act on AST level on single file, but purging unused CSS will have to work on the whole three of dependencies/files and trying to identify which class is not used which one is used.

This might be more tricky in case we have global styles all over the place.

[jer3m01]

What would modern be?

https://github.com/rome/tools/blob/main/internal/compiler/transforms/index.ts#L80

But I think it's old code... by looking at its interface: https://github.com/rome/tools/blob/main/internal/compiler/types.ts#L81-L88

I meant what would we consider modern to be? Last 4 versions? Not dead? ...

I am not sure... purging unused CSS classes should be done only when we bundle - for production - and done only after the prefixer. And it could be very tricky. The prefixer will act on AST level on single file, but purging unused CSS will have to work on the whole three of dependencies/files and trying to identify which class is not used which one is used.

This might be more tricky in case we have global styles all over the place.

Yeah it's gonna be hard, would it run during compile or as an additional step? Doesn't to be figured out right now just good to know.

CSS modules (it seems becoming a standard)

That's also going to be tricky, Not quite sure how that would be implemented. If anyone has input on this feel free to respond.

[ematipico]

I meant what would we consider modern to be? Last 4 versions? Not dead? ...

We could start by targeting the last 2 versions of modern browsers? Usually that's how in enterprise environment work.

Yeah it's gonna be hard, would it run during compile or as an additional step? Doesn't to be figured out right now just good to know.

We have three steps at the moment: pre, compile and compileForBundle. I think the purging of the CSS should be done in compileForBundle.

That's also going to be tricky, Not quite sure how that would be implemented. If anyone has input on this feel free to respond.

We can check how PostCSS plugin does it: https://github.com/css-modules/postcss-modules

[jer3m01]

We could start by targeting the last 2 versions of modern browsers? Usually that's how in enterprise environment work.

Sure that seems good.

We can check how PostCSS plugin does it: https://github.com/css-modules/postcss-modules

Great will have a look.

Also modern doesn't seem to exist anymore, can't find any definitions of it.

[jer3m01]

Now because certain values also have prefixes (such as flex) we could either have a file for the display property or for the flex value.
css-prefix/prefixes/display.ts vs css-prefix/prefixes/flex.ts, What do you guys think?

We should go for the name of the property and not the value as some names can be values and porperties.

For value prefixes the corresponding property file should export an array of prefix visitors.

[jer3m01]

As we now finally have everything we need to start this there are some things we have to redesign according to what's been built.

Since browser-features allows us to know whether a feature needs a prefix, we could instead of having files per property just use an array of properties lets keep files in case there are any more advanced transformations and to keep them separate.
The prefixVisitors already handles reading the css block and filing in what needs to be added.

The visitor would accept a Browser[] as a target to avoid coupling it too deep with codec-browsers.

[jer3m01]

Locking this as there doesn't seem to be a close feature for discussions and css-prefix has been implemented.