-
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
Suggestion: Add a default alignment class to all blocks #10152
Comments
Would it help to look at the cover image block code as an example? I don't know the specifics, but in testing I know that the text in that block has center alignment by default. |
@designsimply So looking over the cover image block, you are correct that that the However that is referencing a Sass variable Also to give a 3rd party example: https://github.com/brettsmason/BreezeBlocks/blob/develop/src/blocks/container/block.js#L115 - that's the div that I would want the same width as any other block that uses a Hopefully this is clear, but if not happy to expand in more detail. |
@brettsmason - could you take a look at the following issue I raised and tell me if it relates to your issue. As a theme designer I have an issue with GB styling the base class and am recommending all styling be qualified. So, in the case of an image block it would be |
@timhibberd I think there is some overlaps for sure. Most themes seem to use code similar to Twenty Nineteen to control the max width: https://github.com/WordPress/twentynineteen/blob/master/sass/blocks/_blocks.scss#L7 They set a max width on every element that's a direct child of This works in the illustration above on the 2nd block, but what about the nested block within the first example? There is no way for a block author to add a simple class and let a theme author control the max width of this easily. Adding a default class to every block would solve this. I don't know what this class would be, but I think its really needed and would be a pretty easy inclusion. |
Agreed. My issue is that if GB block styles the base class it makes it hard to target. A theme can easily target a qualified base class but anything targeted to the unqualified base class will affect all qualified base-class instances as a side-effect. GB and the themes need to work together and if GB leaves the block base class unstyled, the theme can choose to style the block base class or not and the end-user's designer can still use specific targeting or ! to override the theme. Everyone is happy. If nothing else someone needs to explain why the Image Block & Cover Block inconsistently set max-width, width, and left / right margins relative to Media & Text Block and Embed Block. And I'm not sold on the equations other theme designers chose to put in their themes. I'm not challenging their choice...it's just not a solution I want to take. If the block sets
|
I'm open to this idea, but I'm unfamiliar with any historical context to this decision. @jasmussen any thoughts that might help shift this decision one way or the other? |
Thank you for the ping Mark, and thank you bretts for great ticket and notably the illustration in #10152 (comment). This specific issue has come up a number of times and in a number of different variations, suggesting all blocks should have a "wp-block" class or something in that vein. For most situations, we've been able to avoid additional classes and markup, by some clever CSS'ing on a per-use case bases. However this is an interesting proposal, and given that we have just shipped a Cover block with nested children, and hope to soon ship a "Section" block, it's definitely sensible to resurface the conversation around a centered main column existing in conjunction with wide and fullwide alignments. In that vein, although this suggestion is slightly different in the suggested implementation, it could in spirit, be a duplicate of #14234. Can you all take a look at that ticket also, plus comments, and verify if it's similar? Because if yes, then I really liked @youknowriad's suggestion there. On a slightly transversal note, it would be good to narrow this conversation to be specific to the post content, and not any blocks that might or might not in the future be outside the post content area. To clarify, one of the concepts currently being explored is to use the block editor for the full page, including everything. As we try to figure out exactly how that works and what that means, we should be careful not to optimize too highly towards one situation or the other. For example full and wide alignments are concepts that make sense inside the post canvas itself — as illustrated, with wide and full wide images breaking up the layout of a centered column of text. But when it comes to layout, say for example you have a giant Header block — this block just as in regular HTML, should receive its layout from templating CSS, and not have to be applied "full-wide" in order to stretch from edge to edge. |
@jasmussen apologies for the delay! I guess my issue was focused more on the CSS implications of not having a default alignment class on every block. It adds to the specificity and then requires you to have to do some less than ideal selectors to get the desired effect. In the context of the section block, if every block receives this default alignment class, then you could manipulate the inner content width purely by adding the I know its probably more complicated than that, but making this easier in a way that allows for clean CSS is my hope 😄 |
@brettsmason where are we with this one? Is it resolved with the Section block, or are we still missing classes that you feel should be added? |
@mapk I personally think we are still missing a way for custom block authors especially to style inner blocks to match a themes styles. |
The trick is to remember that |
👋 We discussed this in this week's Design triage on slack: In general, I'm definitely torn on this one. I know from experience that it's difficult to target non-aligned blocks. When working on theme styles for InnerBlocks inside the Section/Group block recently, I definitely had to deal with some frustrating But philosophically, I do think that classnames should be additive. If there's no extra state/feature/setting/functionality, no class should be added. Adopting this suggestion would immediately add a huge amount of |
@kjellr Thanks for the update. 🤞 something gets decided on and moved forward... |
@mtias could you help to decide as you should know best why we don't provide default alignment classes anymore. I think we had some in the past. |
@kjellr would it be okay to remove the |
I think further design feedback is needed — I think the design team leans towards no on this for the reason set forth above, but it could use some more discussion. |
For this reason stated by Kjell, I'd rather not add a class here. I'm going to close this one for now. If further conversation is required, please feel free to open it back up. |
The
.alignwide
/.alignfull
functionality is great and provides some much needed flexibility with layouts. However one problem I see and have been experiencing with the system is there is no default alignment class.There are a few reasons/use cases where this would really help:
Both of the above cases could be made a lot easier with a simple class that every block receives and is a required style in a theme. I'm not sure what that class should be, but I think it would be really helpful for more complex layouts. Happy to expand on the above if its not clear enough.
The text was updated successfully, but these errors were encountered: