-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Comments
I can do this. I don't see anyone assigned so hopefully no one is working on it. |
I've been thinking about this for the past week. There are three main goals for this task:
To this end, one approach could be to split the editor specific CSS from Disadvantage: we need to import |
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? |
What if we add a generic Pros:
|
I like that. |
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 |
Okay, I think I understand what you are saying. This seems like a good first step. |
I would also start with something explicit and see where it takes us. |
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. |
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. |
Okay, going to start working on this. Thank you for the ideas 😃 |
I'm a little torn on this being dependent on explicitly declaring 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:
|
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.
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.
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.
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.
) 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.
We have basic styles on the front-end. Let's open specific issues for ongoing iterations. |
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:
See also #289.
The text was updated successfully, but these errors were encountered: