Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement front-end styling for blocks #963

Closed
jasmussen opened this issue May 31, 2017 · 13 comments
Closed

Implement front-end styling for blocks #963

jasmussen opened this issue May 31, 2017 · 13 comments
Assignees
Labels
Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts [Priority] High Used to indicate top priority items that need quick attention [Type] Task Issues or PRs that have been broken down into an individual action to take
Milestone

Comments

@jasmussen
Copy link
Contributor

jasmussen commented May 31, 2017

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.

@jasmussen jasmussen added Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts [Type] Question Questions about the design or development of the editor. labels May 31, 2017
@nylen nylen changed the title Consider front-end styling edgecases for the blocks Implement front-end styling for blocks May 31, 2017
@nylen nylen added [Type] Task Issues or PRs that have been broken down into an individual action to take and removed [Type] Question Questions about the design or development of the editor. labels May 31, 2017
@jasmussen jasmussen added this to the Beta milestone Jun 5, 2017
@mtias mtias added the [Priority] High Used to indicate top priority items that need quick attention label Jun 11, 2017
@BE-Webdesign
Copy link
Contributor

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

@BE-Webdesign BE-Webdesign self-assigned this Jun 15, 2017
@mtias
Copy link
Member

mtias commented Jun 15, 2017

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
Copy link
Contributor

BE-Webdesign commented Jun 15, 2017

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
Copy link
Contributor

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
Copy link
Contributor

What if we add a generic assets

I like that.

@mtias
Copy link
Member

mtias commented Jun 15, 2017

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
Copy link
Contributor

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
Copy link
Member

nb commented Jun 15, 2017

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

@mtias mtias modified the milestones: Beta 2, Beta Jun 15, 2017
@westonruter
Copy link
Member

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
Copy link
Contributor

mcsf commented Jun 16, 2017

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
Copy link
Contributor

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

@mathetos
Copy link

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.

BE-Webdesign added a commit that referenced this issue Jun 24, 2017
Related to #963.

This PR splits up some of our CSS build process to have seperate files
generated for blocks and editor specific styles of blocks. Block
specific styles are now loaded both on the front-end and back end.
Styles that should appear on both are currently in a block.scss file.

Styles added:

wp-edit-blocks: blocks/build/edit-block.css
wp-blocks: blocks/build/style.css

Caveats:

It was suggested that the reverse be done, by using an edit.scss to hold
editor specific styles. This seemed pretty daunting a task to me and I
did not fully grasp what benefit that would bring over this approach
either.

** Testing Instructions **
build the files via `npm run build` or `npm run dev`

Verify that the gallery columns work both on the front end as well as
back end.

Verify that the drop cap style still works on the back end.
BE-Webdesign added a commit that referenced this issue Jun 27, 2017
Related to #963.

This PR splits up some of our CSS build process to have seperate files
generated for blocks and editor specific styles of blocks. Block
specific styles are now loaded both on the front-end and back end.
Styles that should appear on both are currently in a block.scss file.

Styles added:

wp-edit-blocks: blocks/build/edit-block.css
wp-blocks: blocks/build/style.css

Caveats:

It was suggested that the reverse be done, by using an edit.scss to hold
editor specific styles. This seemed pretty daunting a task to me and I
did not fully grasp what benefit that would bring over this approach
either.

** Testing Instructions **
build the files via `npm run build` or `npm run dev`

Verify that the gallery columns work both on the front end as well as
back end.

Verify that the drop cap style still works on the back end.
BE-Webdesign added a commit that referenced this issue Jun 28, 2017
Related to #963.

This PR splits up some of our CSS build process to have seperate files
generated for blocks and editor specific styles of blocks. Block
specific styles are now loaded both on the front-end and back end.
Styles that should appear on both are currently in a block.scss file.

Styles added:

wp-edit-blocks: blocks/build/edit-block.css
wp-blocks: blocks/build/style.css

Caveats:

It was suggested that the reverse be done, by using an edit.scss to hold
editor specific styles. This seemed pretty daunting a task to me and I
did not fully grasp what benefit that would bring over this approach
either.

** Testing Instructions **
build the files via `npm run build` or `npm run dev`

Verify that the gallery columns work both on the front end as well as
back end.

Verify that the drop cap style still works on the back end.
youknowriad pushed a commit that referenced this issue Jun 29, 2017
Related to #963.

This PR splits up some of our CSS build process to have seperate files
generated for blocks and editor specific styles of blocks. Block
specific styles are now loaded both on the front-end and back end.
Styles that should appear on both are currently in a block.scss file.

Styles added:

wp-edit-blocks: blocks/build/edit-block.css
wp-blocks: blocks/build/style.css

Caveats:

It was suggested that the reverse be done, by using an edit.scss to hold
editor specific styles. This seemed pretty daunting a task to me and I
did not fully grasp what benefit that would bring over this approach
either.

** Testing Instructions **
build the files via `npm run build` or `npm run dev`

Verify that the gallery columns work both on the front end as well as
back end.

Verify that the drop cap style still works on the back end.
youknowriad pushed a commit that referenced this issue Jun 29, 2017
)

Related to #963.

This PR splits up some of our CSS build process to have seperate files
generated for blocks and editor specific styles of blocks. Block
specific styles are now loaded both on the front-end and back end.
Styles that should appear on both are currently in a block.scss file.

Styles added:

wp-edit-blocks: blocks/build/edit-block.css
wp-blocks: blocks/build/style.css

Adding documentation about the build process, updating variable names,
reducing duplication. Making the drop cap style work on the front end as
well as gallery styles.
@mtias mtias closed this as completed Jun 29, 2017
@mtias
Copy link
Member

mtias commented Jun 29, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Gutenberg Plugin Issues or PRs related to Gutenberg Plugin management related efforts [Priority] High Used to indicate top priority items that need quick attention [Type] Task Issues or PRs that have been broken down into an individual action to take
Projects
None yet
Development

No branches or pull requests

9 participants