LightningCSS currently breaks logical border radius properties when translating them where pseudo classes are present.
Given the following setup:
// lightningcss 1.32.0
const lc = require('lightningcss');
const input = `
.btn {
@media (prefers-reduced-motion: reduce) { transition: none; }
border-start-start-radius: 8px;
&:hover { color: red; }
}
`;
const { code } = lc.transform({
filename: 'input.css',
code: Buffer.from(input),
minify: false,
targets: { safari: 14 << 16 }, // any target lacking logical border-radius
});
console.log(code.toString());
The output is this:
@media (prefers-reduced-motion: reduce) {
.btn { transition: none; }
}
.btn:hover { color: red; }
.btn:hover:not(:lang(ae, ar, ...)) {
border-top-left-radius: 8px;
}
.btn:hover:lang(ae, ar, ...) {
border-top-right-radius: 8px;
}
Notice how the border radius was moved into the pseudo classes, but is no longer present on the base class.
This issue looks exactly as expected in UI (and is how I discovered this); when using Rspack, I found that my textboxes were lacking border radius until hovered.
LightningCSS currently breaks logical border radius properties when translating them where pseudo classes are present.
Given the following setup:
The output is this:
Notice how the border radius was moved into the pseudo classes, but is no longer present on the base class.
This issue looks exactly as expected in UI (and is how I discovered this); when using Rspack, I found that my textboxes were lacking border radius until hovered.