[WIP] Layout: Try reducing specificity of layout styles #45927
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
andrewserong
added
[Feature] Layout
andrewserong
changed the title
|
Size Change: -1 B (0%) Total Size: 1.3 MB
ℹ️ View Unchanged
|
|
Update: since we're pursuing a fix for this over in #47399, I'll close out this PR now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
🚧 🚧 🚧 🚧
Note: This is an experiment and will quite likely not be viable. It is an exploration into identifying the problems associated with mixing layout and margin rules. As of right now, this PR does not work!
The attempted idea in this PR is to remove the selector prefix when outputting layout rules for the root selector. That is, layout rules become for example
.is-layout-flow > * + *instead ofbody .is-layout-flow.However, even with this change, it still looks like layout rules (e.g. the root layout rules as in the following screenshot) still take precedence even though we've lowered the specificity of the layout rules.
Why?
Ultimately it'd be good to come up with a solution for #43404 so that folks can use both Layout and Margin rules (e.g. set
blockGapas they'd like globally, and also set margin rules intheme.json) and for those rules to play well together in a way that feels logical. This is necessarily vague in this PR, as I'm not too sure what the ideal state would be. Here in this PR, the goal is simply to experiment with how they work together (or currently don't).How?
body .is-layout-constrainedis now simply.is-layout-constrainedTesting Instructions
TBD, but add a bunch of blocks to a post, page, or template, with a theme that has
blockGapswitched on. Then, in global styles, set one of the blocks to have a custom margin at the block-level in global styles, e.g. maybe try the Buttons block.Ideally, the setting a user sets in global styles there would take precedence over the base layout rules, however as of right now, that is not the case.
Screenshots or screencast
In the below screenshots, note how even with the lowered specificity, the layout
margin-block-startrules still win out. Perhaps the order or rule output might need to be adjusted, too?