Clarify the wp-block-styles documentation #23359
Conversation
kjellr
added
[Type] Developer Documentation
|
Size Change: 0 B Total Size: 1.13 MB ℹ️ View Unchanged
|
There was a problem hiding this comment.
Beautiful improvement.
Stumbled briefly on this one:
Without these rules, the block would break entirely on the front end.
Break how? If you read this quickly you might simply assume you see a table with borders, but in fact you'd see all your blocks in a single column as if they were not in any columns block at all. Fundamentally the columns block is probably good to highlight because it is profoundly useless without them. But I wonder if we can dramatize and clarify at the same time:
Without these rules, the block would break entirely on the front end, with a broken layout and no columns to find at all.
Good suggestion! I think I can simplify that a little bit to:
|
|
(Just trying to get these tests to pass... They keep throwing errors. 😕) |
|
Isn't there a docs command line change you need to run? The failure could be legitimate. I'll defer to @mkaz on that |
|
I think that shouldn't be necessary here since I'm just changing some existing text. But I'll take a closer look once these tests finish running. |
|
They've failed a ton lately, and often pass with two or three restarts. |
This PR adds some clarification to the
wp-block-stylesdocumentation.Previously, it stated:
This is misleading, since what most folks would consider "default" styles (from
style.css) are enqueued by default. The opt-in actually applies only to the more opinionated styles intheme.css. This PR makes that distinction more clear: