Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autoprefixing not working #28

Open
lukidoescode opened this issue Dec 22, 2024 · 3 comments
Open

Autoprefixing not working #28

lukidoescode opened this issue Dec 22, 2024 · 3 comments

Comments

@lukidoescode
Copy link
Contributor

I have a little bit of an issue with the automatic vendor prefixing. I've dug in the source code quite extensively and originally planned to just submit a PR instead of a ticket. But this side quest turned into a main quest and I need to refocus my efforts. In my own project I've resorted to manually add vendor prefixes for now.

How to Reproduce

Just change examples/leptos-example/src/hello_leptos.scss like this:

@import "color";

.hello-leptos {
    h1 {
        color: $headline-color;
        user-select: none; // add this line
    }

    .hello-world {
        color: blue;
    }
}

I know it's nonsensical to make a heading not user selectable. I chose this example to make it very simple to follow and reproduce.

Next, run the example like this: cd examples/leptos-example && trunk serve and visit the resulting page in your browser. The currently wrong behavior can be observed and experienced in Safari.

Expected Result

(not minified and annotated for illustrative purposes, actual result would be minified and possibly feature more extensive vendor prefixing)

.leptos-example_hello-leptos_DfeORJ h1{
    color: #ff69b4;
    user-select: none;
    -webkit-user-select: none; /* <-- THIS ONE and maybe some more */
}

.leptos-example_hello-leptos_DfeORJ .leptos-example_hello-world_y71x44 {
    color: #00f;
}

Actual Result

(not minified, actual result would be minified)

.leptos-example_hello-leptos_DfeORJ h1{
    color: #ff69b4;
    user-select: none;
}

.leptos-example_hello-leptos_DfeORJ .leptos-example_hello-world_y71x44 {
    color: #00f;
}

Why This is an Issue

The Leptos example is already configured and supposed to be compatible with Safari.

What I've tried so far:

  • Extensive drug logging in
    • impl<'a> From<Settings> for lightningcss::printer::PrinterOptions<'a>
    • turf_internals::transformer::transform_stylesheet()
  • Implementing browsersquery support for turf into my debug branch and supplying a query that is supposed to guarantee certain vendor prefixing: browserslist_query = [">0.3%", "last 2 versions", "not dead"]. My debug printing from above told me that this was working.
  • Updating lightningcss to version =1.0.0-alpha.61 in case it was a bug in that specific version
  • Digging into the lightningcss source code to find out if there are any kind of additional undocumented config options or possibly bugs. So far without any success.
@lukidoescode
Copy link
Contributor Author

If anyone is willing to join forces, I'll happily collaborate and provide what I already have. I'm also open to do a live collab session to come up with a PR together.

@myFavShrimp
Copy link
Owner

Thank you for your extensive writeup and testing!

I have taken a quick look at it. The lightningcss website says the following regarding browser compatibility

By default Lightning CSS does not perform any transpilation of CSS syntax for older browsers. This means that if you write your code using modern syntax or without vendor prefixes, that’s what Lightning CSS will output. You can declare your app’s supported browsers using the targets option.

https://lightningcss.dev/transpilation.html

It seems that lightningcss will only add vendor prefixes for safari if it is specified as a target browser.

I believe exposing lightningcss' browserslist support to make this easier should be the way moving forward.

@myFavShrimp
Copy link
Owner

I might have not fully understood the problem when I made my first comment. I did a few tests on a mac and I think I understand the issue better now. This seems to be much more complicated than I initially thought. Would you mind sharing your work to help me get a better understanding of what you have tried? I am especially interested in your debug branch with the browserslist_query support which seemed to work.

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

No branches or pull requests

2 participants