[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