Transpilation is highly inconsistent about changing vendor prefixing

[twilight-flower]

When I process some CSS with a browser target, it doesn't reliably change around vendor prefixes for compatibility with that target. Behold some code:

use lightningcss::targets::Browsers;
use lightningcss::stylesheet::{StyleSheet, ParserOptions, MinifyOptions, PrinterOptions};

fn main() {
    let test_stylesheet = r#".foo {
    -webkit-transition: background 200ms;
}"#;
    let target_firefox_version = 108 << 16 | 2; // 108.0.2

    let mut stylesheet = StyleSheet::parse(test_stylesheet, ParserOptions::default()).unwrap();
    stylesheet.minify(MinifyOptions {
        targets: Some(Browsers {
            firefox: Some(target_firefox_version),
            ..Browsers::default()
        }),
        ..MinifyOptions::default()
    }).unwrap();
    let res = stylesheet.to_css(PrinterOptions::default()).unwrap();

    println!("{}", res.code);
}

Naively, we would expect this code to output something like this:

.foo {
  transition: background .2s;
}

However, instead, it outputs this:

.foo {
  -webkit-transition: background .2s;
}

...in other words, despite being targeted at modern Firefox (which doesn't require the -webkit- prefix on its transition properties), the output property is still being kept as webkit-transition rather than transpiled to transition.

If I change the input CSS to this:

.foo {
    -webkit-transition: background 200ms;
    transition: background 200ms;
}

...then the output changes, as expected, to this:

.foo {
  transition: background .2s;
}

...but, while this works if the unprefixed form of transition is present, it doesn't work if only a different prefixed form is present. Given this input:

.foo {
    -webkit-transition: background 200ms;
    -moz-transition: background 200ms;
}

...we get this output:

.foo {
  -webkit-transition: background .2s;
  -moz-transition: background .2s;
}

...rather than a proper change over to transition.

But it's not even consistently the case that the proper output is obtained given the presence of the unprefixed form! If we switch from transition over to writing-mode, we'll find that this input:

.foo {
    -webkit-writing-mode: vertical-rl;
    writing-mode: vertical-rl;
}

...leads to this output:

.foo {
  -webkit-writing-mode: vertical-rl;
  writing-mode: vertical-rl;
}

So I'm not sure what's going on here, but I'm pretty confident it's not intended behavior.

(Tangentially: -webkit-writing-mode, input by itself, is also not transpiled to writing-mode. Which is a problem! Because, unlike with -webkit-transform—which Firefox 108.0.2 knows to handle the same way as unprefixed transform—Firefox doesn't recognize the -webkit-writing-mode property. A paragraph with a -webkit-writing-mode of vertical-rl, displayed in Firefox, won't be displayed as if it had a writing-mode of vertical-rl, but rather as if it had no writing-mode set at all. So this issue is potentially leading to actual incompatibilities with the target browsers, not just to uglier-but-still-compatible code.)

[devongovett]

In the first case:

.foo {
  -webkit-transition: background .2s;
}

the input only targets WebKit (and compatible) browsers, so changing it to remove the prefix would change the behavior of the CSS in other browsers (where -webkit-transition wouldn't have been applied). So unless there is also an unprefixed property which would apply in any supported browser, we don't change the input prefixes. That's why this works as you expect:

.foo {
    -webkit-transition: background 200ms;
    transition: background 200ms;
}

Since transition is specified, we can remove -webkit-transition since it won't be applied in any of our target browsers (it is overridden by transition).

As for writing-mode, I don't think we have particular handling for that property yet, so it just gets passed through as is. If we were to implement support for it, then it would behave as above.

-webkit-writing-mode, input by itself, is also not transpiled to writing-mode

I don't think we should be converting things from one prefix to another as the author of the CSS might have specifically meant to target only that one browser and not any others. The right way to get prefixes when needed is to author using the unprefixed propertes.

[twilight-flower]

I don't think we should be converting things from one prefix to another as the author of the CSS might have specifically meant to target only that one browser and not any others. The right way to get prefixes when needed is to author using the unprefixed propertes.

This works fine contingent on the author of the CSS being the same person as the user of LightningCSS, but is very limiting if that assumption breaks down. One of the central things I've been trying to use LightningCSS for, in my own browser-extension-project-in-progress, is very specifically "take CSS targeting one browser and re-aim it at a different one"; I'm not working with CSS I've written myself, but rather CSS written by other people, so 'author using the unprefixed properties' isn't an option.

(I could, in theory, do all prefix-rewriting manually by directly parsing the StyleSheet's selectors and modifying them where applicable, but then I'd be doing it manually, rather than being able to take advantage of LightningCSS's large library of pre-assembled knowledge regarding which prefixes are or aren't needed for which versions of which browsers.)

[devongovett]

the author of the CSS being the same person as the user of LightningCSS

I don't think that's really fair. It is a pretty common expectation that a tool would not change the behavior of the input by default. Autoprefixer, by far the most popular tool in this space, works the same way.

That being said, it sounds like you are writing a tool in Rust. Lightning CSS does have a visitor API which can be used to build custom transforms. So one thing you could do is visit all of the properties and remove the vendor prefixes first, and then let Lightning CSS add back the prefixes where they are still needed. This would make the input behave as if there were no prefixes written, so that -webkit prefixed properties would apply across all browsers.

Basically something like this (untested):

struct RemovePrefixesVisitor;
impl<'i> Visitor<'i> for RemovePrefixesVisitor {
  const TYPES: VisitTypes = visit_types!(PROPERTIES);

  fn visit_property(&mut self, property: &mut Property) {
    match property {
      Property::Transform(v, _prefix) => *property = Property::Transform(v, VendorPrefix::None),
      _ => {}
    }
  }
}

We could add a property.set_prefix method to make this easier so you don't need to write a giant match yourself.

[twilight-flower]

The visitor API seems to have been removed, as of 1.0.0-alpha.39? But, assuming that was unintentional and it'll be back, something like this does seem like it'll solve my current issue, yeah. Thanks!

[devongovett]

It's there, but now behind a feature flag ("visitor"). I need to fix docs.rs again so it shows it.

[devongovett]

Implemented Property::set_prefix in the above commit. So you can do property.set_prefix(VendorPrefix::None) rather than the match in the above example and we'll handle setting the prefix across all properties. Will do a release to crates.io soon.