Proposal of removing inline styles

[samikeijonen]

Some blocks like Paragraph and Button use inline styles. For various reasons we should avoid them and invent better system for styling blocks.

• Hard to maintain: Let's say we have hundreds buttons with my brand color. But then we re-design colors including button colors. It would be nasty job to change all previous button colors.
• Future-proof markup: Using !import is not an answer. It's also bad practise for modular, future-proof, and semantic separation of markup and presentation.
• Performance: Inline styles have small performance issue.
• Child themes: Child themes should be able to easily use different color combinations that parent theme.
• SEO: It's not good for SEO (don't ask me details, I don't know them:)
• In short, using inline styles has been considered as a bad practise for a long time.

Joe Dolson summarize it well:

Inline styles inhibit the ability of users to use their own custom stylesheets and create a barrier to tools that customize the view.

Proposal 1

I don't have a silver bullet but what if we start exploring how we could automate custom classes for blocks, something like bg-color-1, color-1, bg-color-2, color-2.

Example of current markup for paragraph:

<p style="background-color:#eee;font-size:28px;text-align:left" class="has-background has-drop-cap">
This is styled paragraph.
</p>

Example of markup for paragraph when we select first Background Color and Text color from Block settings:

<p class="has-background has-drop-cap bg-color-1 color-1">
This is styled paragraph.
</p>

Theme could map those styles to correct color what's declared in add_theme_support( 'gutenberg' ) and child themes could easily overwrite them.

Proposal 2

If nothing else theme should be able to disable inline styles. It could be done for example using 'inline-styles' => false, argument:

add_theme_support( 'gutenberg', array(
'wide-images' => true,
'inline-styles' => false,
'colors' => array(
	'#0073aa',
	'#229fd8',
	'#eee',
	'#444',
),
) );

[lumberman]

Inline styles are very ugly and don't belong to modern web.

[mike-schut]

I like both your suggestions. I have seen plugins like divi page builder use your first idea above where they use php to inject css in the head for the whole page.

One Idea I have been floating around in my head for a while now is what if we use something like file_put_contents() (http://php.net/manual/en/function.file-put-contents.php) so on save we pull what is currently on the page and add the new css to the stylesheet. My guess we could write or use a composer plugin to compress the css and javascript to get it minified/compressed.

Each element would need to have a class based off post type and id. So basically:

#page-81-button-1{}
#page-81-button-2{}

#page-90-button-1{}

We would then need to make each button have an id that if a button was removed it would remove the style from the stylesheet based on an id being removed from the page.

This could get very technical but I would be interested in working with a few people to see if we could come up with a good way to do this. Let me know your guys thoughts.

[ellatrix]

Note that the current WordPress editor will also put there inline (e.g. change the text colour). Not saying it should be like this though. I'm also in favour of creating a colour palette that the theme can change, e.g. a good variety of colours and the theme could adjust the shades so it fits for that theme.

[mike-schut]

I like that idea @iseulde having the theme create a palette to choose from would also allow theme developers to create more consistency across their pages.

But you do then loose the capabilities for someone that is wanting to "Create their own page" using colors not specified in the theme.

[ellatrix]

But you do then loose the capabilities for someone that is wanting to "Create their own page" using colors not specified in the theme.

Yes, that's a limitation that comes with the design, but hopefully there could be a good variety of default colours that the theme can adjust based on their design. Downside is that these colours will slightly change when you switch themes, upside is that it should always fit well. If the theme does not define the colours, it would fall back to default colours.

[lumberman]

If you inline css in the head it's bad for SEO. Google want to see your actual content part as close the the top of the page code as possible. If you move CSS into the end of the page before you end up with unstyled content flash.

[camya]

In my opinion it's should be possible to disable the block settings complete (or limit them) by configuration like defined by a theme- or plugin-author.

The block settings could be replaced by "Block Themes", which are defined in the theme (the parent theme, or plugin). These "Block Themes" can for example direct match a CSS-Class.

An user/editor can select a "Block Theme" from a dropdown, and the underlying CSS class is applied to the block. This CSS class could be easily overwritten in the child theme for example and could be used for both, fronted and Gutenberg editor preview.

I wrote about this idea here: #2783

First idea only. For sure there is a better way to implement it.

[mike-schut]

I agree with you guys, allowing the theme developer to create these "theme colors" would be a good approach. Additionally, would remove the inline css. And allow for the user to have a more consistant design across the site, which many wordpress users need rather than the ability to control everything. More options doesn't always mean a better user experience.

[geoconklin]

As a long time WordPress user I'd rather see a delay in Gutenberg's release if it means a better product. Using inline styles because its easier & faster to implement them is not a good reason for using them. Mass use of inline styles reminds me of MS Word HTML.

I think every predefined element that Gutenberg can produce (like multi-column blocks, blockquotes, paragraphs, etc) should have base external CSS assigned, or at least inherit styles from external CSS. Adding customizations to those predefined elements, like color and margins, may be a good reason to use inline CSS. It doesn't sound like the best option, but its reasonable.

[samikeijonen]

@geoconklin We probably "have to" use inline styles as a default styling system for some blocks. But there should be way to disable inline styles and use other ways (custom classes for example) to style blocks. I try to write more detailed answer this week.

[lumberman]

We don't "have to"... Unique classes for every block is a clean solution to all the problems.

[geoconklin]

Oops, I hope above I did not reply to "Button block markup in the front-end #2907," I was trying to reply to "Proposal of removing inline styles #2862". Inline styles are god to avoid unless necessary as I believe @lumberman (and others probably) was pointing out.

@samikeijonen I can't imagine why we'd have to use inline styles as default styling for any blocks or common Gutenberg elements which I'd think would be deigned beforehand and not on-the-fly. I do understand why custom settings to a predefined element would need to be inline. For example, if there is a multi-column class called wp-2-col the margins, padding etc would be standard and included in the main stylesheet (eg wp-content/themes//styles.css). The main stylesheet would have all .wp-2-col and all of its attributes predefined. But if the user wanted to change the color of the text inside that block I can see why inline styles would be required.

If that's not the case I'm missing something.

[samikeijonen]

Okay here is me thinking out loud comment. We need to consider at least these scenarios:

• Switching public themes.
• Switching custom themes for clients.
• Switching to theme that has different number of colors set in add_theme_support( 'gutenberg' ).

Why inline-styles could be default behaviour

Public theme example

When user changes public theme the person understand and expect that theme colors changes, for example link colors. I'm pretty sure user expect color changes even if the user changes the link color from the Customizer setting.

But if the same user picks the color - let's say button background color - in the editor, would to user expect the same button background color be there after a theme change?

If the answer is yes, perhaps defaulting to inline-styles are OK.

Custom theme example

In custom theme for client I can't think even one reason why we would use inline-styles (back-ground image is an exception). I outlined the reasons in my first comment.

Custom themes are easier to handle in many ways. We can always educate to client that when you now add a button background color, and we re-brand your site after 5 years, all button colors will automatically match the new button colors.

Switching to theme that has different number of colors options

With inline-styles

With inline-styles different number of color options would not matter. Old button colors would stay the same and all new button colors would have new colors.

Without inline-styles, with custom classes

If inline-styles would be default behaviour we should be able to disable them. It could be done using inline-styles' => false argument like I proposed before:

add_theme_support( 'gutenberg', array(
'wide-images' => true,
'inline-styles' => false,
'colors' => array(
	'#0073aa',
	'#229fd8',
	'#eee',
	'#444',
),
) );

Note that even with inline-styles (inline-styles' => true), there should always be custom classes also. That would help

• overwriting inline-styles.
• keep sanity when switching themes from/to with/without inline-styles support.

Users would still see and use colors tool to pick button background and text color. But there would be no inline-styles. Instead there would be custom classes. Let's say user picks the first background-color and second text color for button. Markup could be like this:

<div class="wp-block-button wp-block-button-bg-color-1">
<a href="https://github.com/WordPress/gutenberg" class="wp-block-button-text-color-2"><span>Help build Gutenberg</span></a>
</div>

Let's say user picks the second background-color and fifth text color for button. Markup could be like this:

<div class="wp-block-button wp-block-button-bg-color-2">
<a href="https://github.com/WordPress/gutenberg" class="wp-block-button-text-color-5"><span>Help build Gutenberg</span></a>
</div>

Note that I'd like to propose a little bit different markup for buttons in #2907.

Naming the classes doesn't even have to be block specific if we can't choose specific colors for specific blocks. Then class name could be generally the same for all blocks.

Something like wp-block-bg-color-2 and wp-block-text-color-2.

So what happens if themes has different number of colors options

Theme one has 6 color options

add_theme_support( 'gutenberg', array(
'wide-images' => true,
'inline-styles' => false,
'colors' => array(
	'#0073aa',
	'#229fd8',
	'#eee',
	'#444',
	'#fff',
	'#000',
),
) );

Theme two has 4 color options

add_theme_support( 'gutenberg', array(
'wide-images' => true,
'inline-styles' => false,
'colors' => array(
	'#cc73aa',
	'#229fd8',
	'#ccc',
	'#888',
	'#1f1f1f',
),
) );

What happens if user switch from Theme one to Theme two?

• First 4 colors would map to new colors.
• Last two colors would not map anywhere. They would need to fallback to default bg and text color defined in Gutenberg or in the theme.
• Once again this can be problematic for public themes only. In custom themes developers would know how many color options and which order they are in the old theme, and how to handle possible fallbacks.
• In public themes we could even end up having almost the same background and text color on theme switch.

Conlusion

For public themes I see a lot of problems if going without inline-styles, perhaps they are needed:)

Or we need to think this differently like proposed in #2783. Or totally something else.

For custom themes we need the way of disabling inline-styles, like proposed in this issue. I'm not sure are the custom classes the best way but I can't think any other way at this point.

[davidakennedy]

To me, there are two problems here:

• What does the user expect when switching a theme after they've applied customizations to colors and text via Gutenberg? It would be good to ask some. 😄
• How can a professional web worker provide a consistent design experience on a site that has been heavily customized.

The first is more important to me. On one hand, I can see a case for the fact that the theme has changed, so that means everything changes. But if a user has applied a custom color or arrangement of elements, they've designed it, and it should probably stay that way. Again, better to ask some real people that Gutenberg will help empower to create what they want. I like the idea of the palettes being used to put smart color choices in front of the user. Help them make good decisions. Maybe any color picked from the palette changes on theme switch and any custom colors do not? Hard to make that distinction in Gutenberg. It also potentially creates an area where things are different on theme switch, which we don't need more of. 😉

Maybe a plugin exists to disable inline styles or remove them entirely from posts and pages in cases where people need a fresh start?

[samikeijonen]

What does the user expect when switching a theme after they've applied customizations to colors and text via Gutenberg? It would be good to ask some.

Definitely worth to ask. Although users might not know what Gutenberg is before they actually start using it.

My opinion is still very clear on this. Gutenberg API needs to have possibility to disable inline styles from everywhere. This is crucial for custom themes for clients.

For public themes we probably need some kind of compromise which could have inline styles.

[jorgefilipecosta]

Hi, it looks like a productive discussion is happening here. I have been thinking about this subject and I will describe my thoughts on a possible approach to remove inline styles from colors. There is a big overlap with what was proposed by @samikeijonen.

Themes would set their colors by using:

 add_theme_support( 'gutenberg', array(
          'colors' => array(
                  array(
                   'background_class' => 'gutenbergBackgroundColorX',
                   'text_class' => 'gutenbergTextColorX',
                   'color' => '#0073aa',
                   'description' => 'dark red',
                  ),
                  array(
                   'background_class' => 'gutenbergBackgroundDefaultColorX',
                   'text_class' => 'gutenbergTextDefaultColorX',
                   'color' => '#0073aa',
                   'description' => 'dark red',
                   'hide_from_palette' => true,
                  ),
           ),
       ) );

Where background_class is a class that the theme defines that sets the background color to the specified color and text_class sets the text color. "color" is passed to the editor so it is able to render the correct colors without requiring the inclusion of the theme CSS files. 'description' is a description of the color that screen readers could use. 'hide_from_pallete' allows themes to set custom colors that are not shown in the palette but are rendered correctly by the editor. This allows themes to overwrite the Gutenberg default colors or even classes that other themes used (useful in a design migration). So if the user edits a post that uses old classes the new colors will appear correctly.

When choosing a color the editor just adds the correct class without any inline styles.
Gutenberg default color palette would follow the same logic as the colors the themes provide, themes would easily be able to overwrite the Gutenberg default colors and change them to other ones if they want to.

If the user chooses to use a custom color using the color picker an inline style is needed but a custom color class is added so theme developers can also target this cases and even overwrite old inline styles that existed with CSS.

I would love to know thoughts of other persons on this approach.
cc: @samikeijonen, @iseulde, @mtias, @jasmussen

[samikeijonen]

@jorgefilipecosta I really like the idea of setting custom classes. That would give possibility to use what ever naming conventions (BEM or similar) on block components.

Perhaps there needs to be default classes anyways by the Core. And custom classes would be added without removing default classes.

When I have some time I think more what this would mean on public themes, and which issues it might bring.

[mtias]

@jorgefilipecosta I think this conflates a couple things that should be separated. Themes can already supply a custom color palette, the question is how these are applied and what the UX expectations are (as @davidakennedy mentions) on actions like theme switches. The current state is that as soon as color options are saved into a block, the theme loses control.

Which is also part of the balance here, giving users control over the look of their site while also allowing themes to set up the constrains they see fit.

I like the idea of equating the presence of a custom color palette by the theme to the notion that these colors are meant to work with the theme and not be carried over into inline styles.

That said, I also think we should avoid inline styles for custom colors too. This could be generating a style block that is rendered server side dynamically, using the saved color attribute (also filterable by themes / plugins) as a <style> block, targeting a generated class on the block (ideally using the className extension). This is the first task that I think should be done.

Finally, the idea of allowing themes to specify their colors through classes is interesting, and it could be an option on the colors array, though I'd probably simplify as:

add_theme_support( 'gutenberg', array(
    'colors' => array(
        array( '#ff0000', 'color-class-name' ),
        array( '#00ff00', 'other-color-class-name' ),
    ),
);

Tasks

• Themes modifying the default color palette — already possible.
• Not rendering inline styles in favor of a <style> block generated at block render time.
• Allow themes to treat colors as classes and not as hex values.
• Allow themes to disable custom colors.

[jorgefilipecosta]

Thank you @mtias for breaking this down into tasks. I think we have now a clear set of steps to follow 👍

Themes can already supply a custom color palette, the question is how these are applied and what the UX expectations are (as @davidakennedy mentions) on actions like theme switches. The current state is that as soon as color options are saved into a block, the theme loses control.

Yes, I'm aware that they can change the default color palette, I was talking about replacing colors choose previously using the default palette. E.g: for the color X from default palette, using a given class, now use this color in the editor. For the publishing, the theme would be responsible for overwriting our class for that color.

Finally, the idea of allowing themes to specify their colors through classes is interesting, and it could be an option on the colors array, though I'd probably simplify as:
add_theme_support( 'gutenberg', array(
'colors' => array(
array( '#ff0000', 'color-class-name' ),
array( '#00ff00', 'other-color-class-name' ),
),
);

I would love to simplify things a bit but I think we will have at least two classes one for text/main color and other for background color. The CSS rules are different. The other possibility is using the simple structure but providing distinct color palettes e.g

add_theme_support( 'gutenberg', array(
    'main_colors' => array( ...
add_theme_support( 'gutenberg', array(
    'background_colors' => array( ...

Anyway, these are implementation details that we can talk about later. Thank you for providing steps and sharing your inputs.

[mtias]

Glad it makes, @jorgefilipecosta. Regarding the theme defined class, the purpose should really only be to avoid including a specific color in the rendering process — since the theme can handle it with the class — but it doesn't have to supply one for bg and text, I think. It is basically naming a color with a class, nothing more.

Consider this flow:

add_theme_support( 'gutenberg', array(
    'colors' => array(
        array( '#ff0000', 'ruby' ),
    ),
);

Now in the editor we know to represent this with #ff0000 in the color picker, but when applying it, based on which color control is being used (text or background) gutenberg would pass this to className, like is-{ $color }-text-color, or is-{ $color }-background-color, which the theme would know how to handle as is-ruby-text-color.

[afercia]

For a number of years, WordPress hasn't allowed users to play with colors, and for good reasons. The web is not MS Word. Colors should be in total control of the theme, and I'd recommend to allow custom colors only if the theme declares support for them.
This way, the final decision would always be up to users, they would always have the chance to pick up a theme that supports, or not, custom colors.

[jasmussen]

One question is about portability if we remove inline styles; what would happen to a colorized post if you changed to a theme that has no, or a different, color palette defined?

[afercia]

I'd argue "colorized posts" should not exist in a first place 🙂 trying to find a trade-off here, in my opinion allowing this kind of customization should be entirely up to theme authors. If it's a feature that needs theme-support, portability is not an issue. Some theme will allow colors, some won't.

What is actually happening with this feature, is that we're going against a basic principle re: separation of content and presentation. Not a spectacular idea in the first place. Also, there's the risk of theme-locking.

[jasmussen]

@jasmussen can still make it work through theme switches even if it's not inline — the custom colors are stored as attributes and can be generated without the theme.

Cool that was my primary concern 👍

[jorgefilipecosta]

I think what is being discussed is more or less equivalent to what is planned:

• Themes already can change the color palette, and they will be able to pass a class created by them. So no inline style attributes exist in this case.
• Themes are able to disable custom colors, from new posts and existing ones.
• For colors without a class (custom colors), a mechanism (used if the theme allows) is going to exist that creates classes for them.

Regarding theme changes, if the color is set using a class, from the old theme, if the new one provides a class with the same name the color that class sets is going to be used. If not, the default color will appear. For custom colors, if the new theme also allows custom colors the same color will appear as before, if not the default color will be shown.

This is the idea I have but It may change depending on other people inputs or I may have misunderstood some point.

[davidakennedy]

I'd argue "colorized posts" should not exist in a first place

I definitely can understand that point. Shifting control from primarily the themer to the person building the site is a big shift. It really changes what a theme means to WordPress. I wrote about that here.

I do agree that enabling colors in Gutenberg is scary. Themers lose some control. Those who work on Gutenberg will need to work harder to ensure that theme switching is better and creating something not accessible is a bit harder. We'll have to help people make good decisions, but I think it's vital we start to give some of the control around appearance to site owners. So many people who I've helped with WordPress just want to make a tweak or two to a site's appearance so it's perfect for them – it feels like their own. That starts with relinquishing some control in the theme world.

[Netzberufler]

I was just about to open an issue about the font size setting, but it is basically the same problem as colors. Not sure if it warrants a new ticket.

In my opinion users should be able to choose font sizes from a predefined array of options like Small, Medium or Large Text. These are then added as CSS classes rather than inline styles. Theme developers should be able to declare which font sizes are supported with add_theme_support.

While there are some valid points about inline styling for colors, I do not see any good reason to keep inline font sizes. Especially not in px

[Soean]

@Netzberufler This idea is related to #3090 (comment)

[Netzberufler]

@Soean Thanks, somehow missed that issue :/

[mor10]

Question: Has anyone defined the use case for the styling options in question outside of "it would be neat for people to be able to add background colors, font colors, and font sizes to a paragraph block"?

The reason I ask: if the use case is the author wants to highlight a certain part of the content, then the answer is to change that content from a paragraph to something else - a blockquote or another semantic element. If on the other hand the use case is purely visual (which in my experience is extremely rare), the inline styles approach is appropriate because this would be an extremely rare occurrence. But that begs another question: If this feature is only for rare occurrences, why is it given such prominent position and display?

Though we have zero telemetry on this so all discussion around it is an educated guess at best, I'd venture to propose the text color button in TinyMCE is hardly ever used. One reason for this is likely that it is not prominently displayed so people rarely consider it an option. Thus the inline styling of text color under TinyMCE is unproblematic as it is extremely rarely used. The color and size features in Gutenberg on the other hand are prominently displayed inviting authors to use them liberally just because they are there. In other words, while they may not have an actual need for these features, some users will likely use them simply because they are neat. That's a real problem because it blurs the boundary between content and presentation.

Color and sizing without semantic purpose is just visual fluff and should have no impact on markup.

Here are my suggestions:

1. Suppress the display of the sizing and color features under a drop-down or similar to make them less attractive as bling.
2. Define what intent the user has when applying these features and identify what semantic markup is needed to communicate this intent when the applied visuals are not available (screen readers etc).
3. Provide a separate feature for the theme-centric color/highlight options suggested by previous commenters.

One possible path forward on point 2 is to use the <b> element. More than likely, someone applying custom colors and sizing to a paragraph want to bring attention to that element without emphasizing it. That's exactly what the <b> element - literally named the "Bring Attention To element" - is for. Style classes could be applied to this element allowing for transfer of semantic intent while at the same time isolating the style properties or classes from the paragraph element.

[ShawnRisk]

I think that inline styling even though this isis avaliable, I dislike thisthe. Yet, sometimes you can't find all the styles in the themes.

I still feel that all styles should either be in stylesheet or in a theme option page. I like the theme option page as that allows all users to see changes clearly.

[andreiglingeanu]

One thing we (internally, with out themes) love to do is this:

• Assign a unique class to each block
• Parse the blocks on the wp_enqueue_scripts and extract attributes
• Based on attributes and the unique class, we generate some CSS that is specific to that particular block
• After we have this CSS, we can take a couple of approaches:
  1. Compute the CSS & write in <head> at every request to the frontend
  2. tricky: On every post save, generate a special CSS file for each post that will contain the generated styles for each block.

We can even go about combining those two approaches: inline in <head> for preview requests, regular <link rel="stylesheet" /> for normal requests (the advantage is long-term caching).

I do feel that there are other directions one could take about that but that's definitely a nice starting point.

Up until now, this works okay for us and that way we can keep the markup very clean. It takes a double amount of computation power without proper care though.

[octalmage]

I want to surface an argument for keeping inline styles. I've been using Gutenberg to build posts, then pull them into a JavaScript frontend using the REST API and without inline styles the post style won't transfer correctly. This actually is already happening for a few blocks, like the cover image block.

[lucprincen]

Another possibility (instead of inlining styling, or dumping everything in the head) is to create a php file which will compile the css on-the-fly (obviously cached, or refreshed on post-save) with the right headers set. The file can then be enqueue'd (and de-enqueued) like a regular css file.

This way, theme developers could still use regular CSS (without having to resort to !important hacks) if they just enqueue their styles later. It would also mean that plugin developers could use this if we'd build it as an API, which would (hopefully) lead to less seperate css files being loaded all together.

Just an idea.

[andreiglingeanu]

@lucprincen the problem with this method is the fact that you don't really have the access to the post content in that PHP file, in order to be able to send only a subset of the CSS -- only needed parts. Of course you could parse the REFERER URL but I imagine that being very fragile and error prone.

[lucprincen]

@andreiglingeanu yeah, you're probably right. And doing it site-wide would defeat the purpose of it being a php file...

I get that using inline styles is easier @octalmage (especially from a REST point-of-view) but isn't the entire idea of the REST api to separate data from logic / styling?

[octalmage]

@lucprincen I guess somewhat, I'd just love to be able to use Gutenberg to write posts on my site since it's a great editor and it produces good looking posts. I don't really care to manually reproduce the Gutenberg styles or copy the CSS on my site.

Another solution would be to just document the correct way to include Gutenberg's styles. If the styles got extracted and published as a separate NPM package, I'd be happy to install and include them on my site. Id rather not include the CSS file from my WordPress site directly since my WordPress site is behind basic authentication, or manually copy the CSS file over to my frontend since it could get out of sync. So publishing a package seems like a great alternative.

[LearnWebCode]

I agree with removing inline styles completely, but I can see why others would disagree. That's why I love your proposal 2 @samikeijonen, it lets inline styles be enabled by default but gives theme developers and webDevs that manage WP sites for clients a simple way to disable them.

On a side note, perhaps we can take matters into our own hands on a site by site basis; has anyone wrote a bit of boilerplate that will remove the styling settings from the core/paragraph block type? I've been searching for an example of how to do that in the documentation, but haven't found it yet and I don't want to completely unregister the core/paragraph block type for obvious reasons :)

[samikeijonen]

has anyone wrote a bit of boilerplate that will remove the styling settings from the core/paragraph block type

Not that I'm aware of but I'd imagine that there would be way to removing them.

[omarreiss]

From a technical perspective, I agree with an approach like the one @lucprincen is proposing. Though I would like to manage this in the editor with a solution like Styled components (or similar), which offers an approach that is much more native to actual CSS.

Within a styled component, we support all of CSS plus nesting. Since we generate an actual stylesheet and not inline styles, whatever works in CSS works in styled-components!

Instead of inline styles, we could export the generated stylesheet to a post meta and only save the generated classes in the post content. Blocks should probably have a base HTML class and a generated class that is specific to the custom styling.

Doing it like this will keep Themes in charge of styling while at the same time allowing for some basic customization that doesn't get in the way from a CSS point of view.

[raptor235]

Beaver Builder does a nice job with this, they generate unique js / css files per component / component dataset.

The great thing you also get out of that is that you can have conditional rules based on css / js values.. so if a block for example has a style type dropdown then based on that dropdown there could be conditional rules executed to generate a unique file for that component.

Check out their frontend.css.php => https://github.com/brainstormforce/timeline-for-beaver-builder/blob/master/timeline-for-beaver-builder-module/includes/frontend.css.php

It's a super flexible system that's much more powerful then having just one dimensional layer of css or js per component... if you think of conditions the system becomes a lot more versatile and powerful.

[mtias]

Thanks for all the thoughts and references. Going to close in favor of #5360 which is a bit of a bigger overview of the various elements involved. Let's keep this one as a reference.