-
Notifications
You must be signed in to change notification settings - Fork 68
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
Sort shorthand vs. longhand declarations — breaking change behind config #1700
Conversation
🦋 Changeset detectedLatest commit: 4ed15eb The changes in this PR will be included in the next version bump. This PR includes changesets to release 19 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for compiled-css-in-js ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
a3a841d
to
bc029db
Compare
]} | ||
</Style> | ||
); | ||
|
||
// WARNING: This is wrong, the `focus` border properties are different than without focus, borders would be indeterministic. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is required, all "bucket sorting" needs to be drastically rewritten to be nested.
Right now it's flat:
.abc { border: none }
.abc:link { border: none }
.abc:visited { border: none }
/* … */
.abc:active { border: none }
@media (/* … */) { .abc { border: none } }
But this doesn't support @media (…)
being sorted internally or .abc:focus { … }
being sorted against each other.
This would need deeper nested bucketing:
.abc { border: none }
.abc{ border-top: none }
.abc:link { border: none }
.abc:link { border-top: none }
@media (/* … */) {
.abc { border: none }
.abc { border-top: none }
.abc:active { border: none }
.abc:active { border-top: none }
}
And I'm not exactly sure if that's even feasible for @media
queries either…
89df158
to
c9cae48
Compare
'border-block-end-style', | ||
'border-block-end-width', | ||
], | ||
'border-color': [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example: Should this sort above border-top
as well, not just the children? I think this one is still required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dddlr I'm not decided enough on what "perfect" looks like for these, so I think it's fine to have some bugs for very rarely used properties…let's circle back to this and call it a gap unless it's obvious.
…in a way, these are "siblings", but to me it feels like there's an explicit order? MDN doesn't really provide anything and I think there's no explicit browser setting—it's a first-defined-basis:
- https://developer.mozilla.org/en-US/docs/Web/CSS/border-width
- https://developer.mozilla.org/en-US/docs/Web/CSS/border-top
But if this makes sense, in theory I think for all of border-color
, border-style
, border-width
, this should be:
'border-color': [ | |
'border-color': [ | |
'border-top', | |
'border-block', | |
'border-inline', | |
'border-left', | |
'border-right', | |
'border-bottom', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah the order of properties in shorthandFor
no longer matters - i should probably just reset that to alphabetical order to be honest ...
shorthandBuckets
is now used in packages/css/src/plugins/sort-shorthand-declarations.ts
(previously was just in packages/react/src/runtime/sheet.ts
) to enforce that border-{color,style,width}
comes before border-{top,right,bottom,left}
let me know if this aligns with what you have in mind
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it, the test LGTM, that's what this aShorthandBucket - bShorthandBucket
does 👌
More todos
|
…rting as well. Concerns: - Runtime sorting does not work properly as we'd also need per-bucket nested sorting where `@media, :focus, border` needs to be sorted. - `shorthandFor` needs 40 more shorthand properties defined…
…uents. This no longer sorts `border-top` vs. `border-block-start` as they are siblings, not a sibling of a constituent…
… by moving shorthandFor to @compiled/react/runtime
…properties are sorted deterministically
c948dbd
to
9ca3547
Compare
docs deploy preview https://deploy-preview-1700--compiled-css-in-js.netlify.app/docs/shorthand based on my best understanding of how it works, feel free to make any corrections |
packages/utils/src/source-maps.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this appeared to be unused everywhere and was causing me grief when building
@@ -11,6 +11,8 @@ const classNameCompressionMap = require('./class-name-compression-map.json'); | |||
|
|||
const extractCSS = process.env.EXTRACT_TO_CSS === 'true'; | |||
|
|||
console.log('Stylesheet extraction enabled?', extractCSS); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this console.log intentional?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh yeah, i added it as a debugging measure but then decided to keep it as it seemed to be useful
happy to remove it if it's not valuable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dddlr This is my own PR so I can't request changes, but could use a sanity check in a few places and minor suggestions, nothing too blocking.
'border-block-end-style', | ||
'border-block-end-width', | ||
], | ||
'border-color': [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dddlr I'm not decided enough on what "perfect" looks like for these, so I think it's fine to have some bugs for very rarely used properties…let's circle back to this and call it a gap unless it's obvious.
…in a way, these are "siblings", but to me it feels like there's an explicit order? MDN doesn't really provide anything and I think there's no explicit browser setting—it's a first-defined-basis:
- https://developer.mozilla.org/en-US/docs/Web/CSS/border-width
- https://developer.mozilla.org/en-US/docs/Web/CSS/border-top
But if this makes sense, in theory I think for all of border-color
, border-style
, border-width
, this should be:
'border-color': [ | |
'border-color': [ | |
'border-top', | |
'border-block', | |
'border-inline', | |
'border-left', | |
'border-right', | |
'border-bottom', |
transition: 1, | ||
'view-timeline': 1, | ||
} as const satisfies Record<ShorthandProperties, Depths>; | ||
// ^^ this type lets us enforce that the copy of shorthandBuckets |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To question aloud, why do we even have this in this file?
…what if we imported this into the other file, doesn't that just work? I'd expect shorthandFor
to be tree shaken, am I wrong?
It's fine, it feels maintainable, just looking at it again, I'm not sure why it's in both places…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah i made two copies of shorthandBuckets
because in @compiled/react/runtime
, importing @compiled/utils
bloats the bundle size and causes npx size-limit
to fail yeah
re: tree shaking, can we assume that tree-shaking always runs in realistic Compiled usage? if so, i can see if i can update the size-limit
config to account for tree-shaking maybe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no clue 😸
website/packages/docs/src/pages/pkg-babel-plugin-strip-runtime.mdx
Outdated
Show resolved
Hide resolved
Can we add linting for this area? This change makes the behaviour deterministic but it's still confusing to developers. Given the example in the description:
The inverse could happen:
which would have deterministic behaviour opposite to what the developer intended. Generally, we should make the linting sort the code with autofixers (and warn when not possible) so that the source represents the production code. |
yeah sure @zesmith2 is working on sorting shorthand and longhand properties within the same |
What is this change?
Adds sorting of shorthand vs. longhand to ensure longhand deterministically will override shorthand.
Why are we making this change?
This is because quite commonly this code may be applied in either direction meaning sometimes
font-weight: bold
is applied and sometimes it's not, depending on the order that the stylesheet was generated in.Example in a Storybook:
How are we making this change?
Where we already sort atomic styles, we now sort shorthand vs. longhand in that same area.
PR checklist
sortAtomicStyleSheet
iterates over all declarations or just one by one…outline
andfont
, there are many more!website/
with this new config