[wp-trac] [WordPress Trac] #60877: Twenty Twenty-Four: Many block styles affect all blocks
WordPress Trac
noreply at wordpress.org
Tue Apr 2 11:59:51 UTC 2024
#60877: Twenty Twenty-Four: Many block styles affect all blocks
--------------------------------------------+------------------------------
Reporter: wildworks | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Bundled Theme | Version:
Severity: normal | Resolution:
Keywords: needs-testing-info needs-patch | Focuses: ui, css
--------------------------------------------+------------------------------
Comment (by poena):
I could not find a discussion specifically about the selectors in the
original GitHub repository. But I found that the original design did
include paragraphs with asterisks:
https://github.com/WordPress/twentytwentyfour/issues/45
It was removed because with the **original** implementation, the asterisks
were announced by screen readers. -Not because the style was unwanted for
paragraphs. It was later replaced by a CSS only solution, and the
asterisks are not announced anymore.
The selector for the custom list item style includes {{{ul.}}}
Yes, the {{{name}}} property in {{{register_block_style()}}} should have
been prefixed, that problem is related, but it is too late to change the
class name because it would be a breaking change.
Is the problem that users can create their own custom styles with the same
class name?
Or as reported on GitHub, that {{{When you "Copy Styles" and "Paste
Styles" from one block to another, the custom block style is copied
too.}}}
If a user is capable of creating their own custom styles, they are also
capable of removing class names from the input field. Developers can also
unregister styles they do not want, and replace them.
If a user copies a style and don't like the result, and they don't know
how to remove it using the field, they can use the undo step or delete the
block and add it again.
If a user has intentionally used the CSS class name, and the CSS selector
is updated to work only for a single block, they can't re-add the style
without knowing how to code their own.
So the difficulty gap between these scenarios is rather big.
-----
In theory, WordPress could force the CSS to only apply to the block that
matches the property that is used in register_block_style(). Without
requiring the theme developers to manually include the block class names
or elements.
In reality, since this was not enforced from the start, it would break
backward compatibility.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/60877#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list