Gutenberg: Implement front-end styling for blocks

[jasmussen]

Some blocks will require support from the theme to be displayed properly on the front end, both in terms of theme_support as well as loading relevant styles (gallery columns) that we so chose to not render inline.

---

Extracting from #422:

there’s been some chatter about how themes could define support for blocks or block controls (like image full bleed). maybe something with that and add_theme_support ?

seems we might need to allow a base stylesheet for a block, plus editor and/or front-end specific extras

So, this likely means that more blocks will need to register themselves on the server side, and we'll need to allow the register_block function to accept values for these stylesheets.

Edit: also worth considering: themes themselves will probably want to add styles for individual blocks.

See also #289.

[BE-Webdesign]

I can do this. I don't see anyone assigned so hopefully no one is working on it.

[mtias]

I've been thinking about this for the past week. There are three main goals for this task:

• Provide default structural styles for blocks on the front-end.
• Only write relevant CSS once.
• Easy to extend from a theme perspective.

To this end, one approach could be to split the editor specific CSS from style.scss into edit.scss, then chaining all the style.scss from blocks into a blocks.css through the build process to be enqueued on the front-end.

Disadvantage: we need to import edit.scss in blocks.
Advantage: no introspection needed (i.e. having to determine which styles should be used in the front-end and which are to be excluded, like placeholder, toolbar, or inspector styles).

cc @aduth @youknowriad @nb

[BE-Webdesign]

Okay, so in addition to the API for theme authors to use, we want to register some default styles on the front end, potentially using the build system already in place? Or is the focus of this issue solely on just bringing in default styles to the front end from what we have already created?

[youknowriad]

What if we add a generic assets property to the blocks (backend registration). And whenever we detect this block used in the post content filter, we enqueue these assets?

Pros:

• We load only the styles of the used blocks
• We can also load JS, the idea is that some blocks could also execute JS in the frontend (advanced animations or anything else)

[BE-Webdesign]

What if we add a generic assets

I like that.

[mtias]

We load only the styles of the used blocks

This can get tricky with different theme configurations and plugins like infinite scroll. I think an initial approach should just provide support for all available blocks that require structural CSS for displaying correctly (gallery columns, captions, etc).

There's always the chance of doing inline styles, or a style block rendered through PHP on do_blocks.

[BE-Webdesign]

To this end, one approach could be to split the editor specific CSS from style.scss into edit.scss, then chaining all the style.scss from blocks into a blocks.css through the build process to be enqueued on the front-end.

Okay, I think I understand what you are saying. This seems like a good first step.

[nb]

I would also start with something explicit and see where it takes us.

[westonruter]

I like defining assets when registering the block in PHP as well, and this should include both the script and style handles that need to be enqueued both when editing and when rendering on the frontend.

[mcsf]

I like the idea of being selective about which styles to add and potentially allowing more sophisticated side effects, but I'd err on the side of starting small, echoing some of the thoughts on keeping it explicit and simple.

My advice would be to make sure the API has good semantics, so that later on we can improve the build + enqueuing processes with some confidence that we're inferring the right things from the registration calls — e.g., it should be clear: that the theme author intends to replace the default styles with their own, not complement them; that their styles are aimed at both editor and front-end, or just one of these; etc.

[BE-Webdesign]

Okay, going to start working on this. Thank you for the ideas 😃

[mathetos]

I'm a little torn on this being dependent on explicitly declaring theme_support. If a theme doesn't declare it, then users will see a nice columned gallery in the backend (for example) and just plain images on the front-end -- a bad experience. Regardless of whether that's the theme authors fault or not, the user experiences it as a bug with WordPress.

I think the default should err towards reflecting the edit screen and the theme author have to take EFFORT to disable that. If disabling those styles takes effort from the theme author, then they obviously are paying attention enough to know what they are doing.

So, worst case examples:

• Worst case for the user == bad WordPress experience because of theme authors neglect
• Worse case for the theme author == they don't like the styles, so they either customize them or dequeue them completely. Essentially not a problem.

[mtias]

We have basic styles on the front-end. Let's open specific issues for ongoing iterations.