Replies: 3 comments
-
|
Thanks for opening this discussion. I like the idea of maintaining a set of utility classes and applying them as necessary rather than generating bespoke, unique classnames. The unique classnames do serve a purpose as far as I can tell where blocks have unique and specific layout properties. Here's a random dump from a test site: Generated CSS.wp-container-core-group-is-layout-1 {
gap: 4px;
flex-direction: column;
align-items: flex-start;
}
.wp-container-core-group-is-layout-2 {
gap: 24px;
}
.wp-container-core-navigation-is-layout-1 {
justify-content: flex-end;
}
.wp-container-core-group-is-layout-3 {
justify-content: space-between;
}
.wp-container-content-9 {
flex-grow: 1;
}
.wp-container-core-group-is-layout-5 > :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
max-width: 729px;
margin-left: auto !important;
margin-right: auto !important;
}
.wp-container-core-group-is-layout-5 > .alignwide {
max-width: 1200px;
}
.wp-container-core-group-is-layout-5 .alignfull {
max-width: none;
}
.wp-container-core-group-is-layout-5 > .alignfull {
margin-right: calc(var(--wp--preset--spacing--40) * -1);
margin-left: calc(var(--wp--preset--spacing--40) * -1);
}
.wp-container-core-group-is-layout-5 > * {
margin-block-start: 0;
margin-block-end: 0;
}
.wp-container-core-group-is-layout-5 > * + * {
margin-block-start: 71px;
margin-block-end: 0;
}I suppose the challenge will be extract common rules and apply classes to blocks - the bepoke layout declarations would still have to live somewhere 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I can see how those unique classes are necessary if a user has entered a custom value into a field, but even those could be better. If you have one 729px wide content area on a page you're likely to have another one, so instead of piling another meaningless class, it could generate something like |
Beta Was this translation helpful? Give feedback.
-
This reminds me of an exploration @andrewserong did a while back: The pros and cons discussion in that (now closed) PR is related I think, especially the point about creating too many classnames and not creating a backwards compatibility spider web should devs ever use them as hooks for other styles. See #38974 (comment) To counter the latter point, perhaps an obfuscated classname using a hash of unique rules. See #38974 (comment) |
Beta Was this translation helpful? Give feedback.
-
In #41993, @ramonjd points out that layout classes like
is-verticalandis-nowrapare only generated for backwards compatibility:gutenberg/lib/block-supports/layout.php
Lines 739 to 744 in 8dc36f6
If this class will be kept indefinitely for backwards compatibility, why not use it? It seems nonsensical to keep a class around forever while ignoring it in favor of outputting the same CSS over and over again under different classes.
Instead of repeating
flex-direction: column;inside every.wp-container-whatever, the style engine could generate a style for.is-layout-flex.is-vertical1 the first time it encounters a a block with that layout, and then every subsequent block that needs the class would be good to go. In aggregate, this would make pages require much less generated CSS.Here is what the style engine generated for a simple test page with a bunch of different group/row/stack blocks on it:
flex-wrap: nowrap;repeated 10 timesflex-direction: column;repeated 8 timesIf the style engine instead created block-agnostic utility classes, this can be refactored down to simply:
That's 70% less CSS for just a simple test page. Why are these convoluted repetitive classes being generated when there is no custom value entered by the user that would require them?
Related issue: #54033
Footnotes
I guess it might need to be
.is-layout-flex:where(.is-vertical)to keep specificity the same between the two layouts. ↩Beta Was this translation helpful? Give feedback.
All reactions