[wp-trac] [WordPress Trac] #46498: Block style attribute issue, when using Custom properties/CSS variables

[WordPress Trac]

#46498: Block style attribute issue, when using Custom properties/CSS variables
-------------------------------------------------+-------------------------
 Reporter:  olafklejnstrupjensen                 |      Owner:  (none)
     Type:  defect (bug)                         |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  General                              |    Version:
 Severity:  normal                               |   Keywords:
  Focuses:  ui, docs, administration, coding-    |
  standards                                      |
-------------------------------------------------+-------------------------
 == First a little background on the issue
 We use Custom properties, also referred to as CSS variables, when creating
 themes for our clients. This helps us define various color schemes
 quickly, for each new client and makes our development of new project much
 quicker.

 In WP, we then add theme support for the **editor-color-palette** setting
 and add our CSS variables inside the array.

 **Example**
 {{{#!php
 <?php
 add_theme_support(
         'editor-color-palette',
         [
                 [
                         'name'  => 'color 1',
                         'color' => 'var(--color-1)',
                 ],
                 [
                         'name'  => 'color 2',
                         'color' => 'var(--color-2)',
                 ],
         ]
 );
 }}}

 This adds our color scheme to the various block elements, that use the
 **PanelColorSettings**, so that our clients can quickly access the colors
 in their color schemes.

 == The issue
 This works great with admins and super admins, that have the **unfiltered
 html** capability, as they are allowed to add any inline style. However,
 if the user does not have that capability, then the css part is stripped,
 as part of the **safe_style_css** function.
 ([https://core.trac.wordpress.org/browser/tags/5.1.1/src/wp-
 includes/kses.php#L2214])

 For our setup, this is not very practical, as all of that functionality is
 hardcoded and we can not override it, except by giving all contributing
 user roles, the **unfiltered html** capability.

 But a more unexpected issue is that if an admin with the **unfiltered
 html** capability authors a post and chooses a background color for a core
 paragraph block, the block gets the right style attributes, even with the
 CSS variable. Later on, a user without that capability adds a correction
 to that page. When the user save their changes, the style attribute
 containing the CSS variable, **var(--color-1)**, gets that part stripped.
 However the block attribute is not removed and as it remains in the block
 attribute, the block displays correctly in the block editor. The next time
 an administrator with the unfiltered html capability edits the post, the
 core paragraph block creates a new paragraph and wraps the existing
 paragraph inside the new one, thus breaking the block in the block editor.

 == Fixes
 There are a multiple ways of fixing this.

 1. We stop using CSS variables in our **editor-color-palette** array.
 However these CSS variable are part of modern web development and very
 practical.
 2. The block editor also strips attributes that are deemed unsafe in
 accordance with the users role and capabilites
 3. The **safecss_filter_attr** function gets another hardcoded exception
 for CSS variables, **var()**, that mimics the way the **url()** exception
 works.
 4. A hook is introduced in the **safecss_filter_attr** function allowing
 developers a chance to override the allowed style attribute values.

 I would like to hear if others are affected by this issue and the opinions
 regarding the above practice and if there are suggestions for best
 practices for these cases.

 I know that this issue is mainly related to the use of Gutenberg, however
 the **safe_style_css** that strips the CSS values is part of the core of
 WordPress, so I think this is more an issue for WordPress.

 I am also in doubt if this qualifies as a bug, as the behaviour could be
 seen as expected behaviour, so some might see it as a feature request or
 enhancement, however the above example breaks the block editor and could
 then be seen as a bug.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46498>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform