As developers begin to create custom blocks we're going to see a lot of repeating patterns inside the block settings.

Settings like text color/align, box-shadow, background color/image, border settings, float settings, position settings, transforms, padding, margins, etc. will all be implemented many times over, each with a different UI/UX or in a different location.

Different implementations of the exact same property configuration controller might be buggy or lack certain features/functionality, even though the underlying CSS property has a well-known set of possible values according to the web standards.

Multiple implementations will also result in multiple techniques for injecting the styles, making style overrides an unpredictable headache for a developer.

I think it's important that Gutenberg take some level of ownership over user-defined CSS property control early on so that we don't end up with a buggy, hodgepodge mess in the future.

If a feature is missing from a CSS property controller, developers would patch/update built-in Gutenberg functionality instead of rolling their own, which will benefit everyone once the feature is added.

I think we should come up with a comprehensive user-friendly built-in solution to handle simple CSS configuration options which are generally applicable to all blocks.

But not rendered as inline styles

If the user-defined style settings are injected directly onto the container via the style attribute, it would be difficult for a developer to override these styles and force them to resort to !important.

Instead a class should be added to the block's container and the styles for that post should be injected into the post content inside a <style> tag.

The contents of the <style> tag would be generated by looking at all of the custom style attribute settings for each block, grouping the matching ones, and creating a class based on each unique style attribute value.

The class name would be a hash of the CSS attribute name and value, so if someone sets a block's text color to red, the block might get a class like .color-10b06ba962bec30.

The benefit of the hash is that it allows us to uniquely represent complex CSS attribute values using identifier-safe characters, and it also discourages developers from targeting the class name directly (as it could be subject to change).

An extra class like .gb-block should be added so that we can target the element using a slightly higher specificity.

The resulting <style> tag would contain:

.gb-block.color-10b06ba962bec30 {
  color: red;
}

This way the developer can easily override styles as long as they target the element with a greater specificity (i.e. with a tag name and a class name, or with an ID).

This also means that existing styles with a high specificity can't be overridden by the Gutenberg editor, which is good.

If an existing style has a high specificity and should also be able to be overridden by the Gutenberg editor, the developer should update the CSS selector so that the specificity is lower (i.e. just target the element with a single class name) or put those styles in the footer.

If not a built-in CSS settings UI...

Then the addition of configurable CSS attributes should be standardized as a special prop on each component so that Gutenberg can take care of injecting the styles/classes in an automated, consistent, and maintainable way.

If there were a standardized prop that CSS settings should go into, then these styles would be easily accessible/editable later, should Gutenberg (or a third party) want to override them or implement an advanced CSS settings editor for all blocks.