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

Rendered HTML for Button block makes styling incredibly difficult #4145

Closed
maddisondesigns opened this issue Dec 22, 2017 · 11 comments
Closed

Comments

@maddisondesigns
Copy link

maddisondesigns commented Dec 22, 2017

Issue Overview

Currently, a left aligned button produces the following html

<div class="wp-block-button alignleft"><a>Left Aligned Button</a></div>

I can't see any anyway to style this that would be acceptable on any website.

This is how it displays using the Gutenberg theme...

gutenberg-buttons

Having a (left) floated button outside of any other content, makes no sense. It would actually make more sense to be able to insert a button within a Paragraph block, rather than as a separate block.

You can't set the margins to auto so that it aligns nicely with the rest of your paragraph content. Unless you're viewing your content on a tablet or mobile, you very rarely want your paragraph content going full-width as that just makes the line length extremely long and completely unreadable.

I know it's been mentioned in other tickets before (no idea where, sorry), but with the likelihood that a significant number of sites are going to be requiring to fall-back to using the classic editor, it makes it even more important that you should be adding a extra body class when the content is being rendered by Gutenberg. Maybe in a few years this could be removed, but in the short term, theme developers are going to have to modify all their themes so that not only do they render correctly with Gutenberg, but also when using the classic editor.

With the html that is currently rendered, styling Gutenberg is going to be a complete nightmare!

Gutenberg 1.9.1
Firefox Quantum 57.0.1 (64-bit)
WordPress 4.9.1

@youknowriad
Copy link
Contributor

duplicate of #2907?

@maddisondesigns
Copy link
Author

Hmmm maybe a little bit of overlap, but overall I think they're different. A lot of what #2907 refers to is in regards to what html is styled. Whereas, I have an issue with the overall markup that generated.

Sami talks about changing the styles so that they're on the a tag, which I agree with, but I don't think his example goes far enough to improving the markup.

The example mentioned is...

<div class="wp-block-button aligncenter"><a href="#" style="background-color:#cf2e2e">Modified button</a></div>

I would argue that it would actually be better to do something like...

<div class="wp-block"><a class="wp-block-button aligncenter" href="#">Modified button</a></div>

Even with that though, it just makes another issue. While it allows you to style the outer container so that it matches your paragraph, for example, the issue then becomes that the following paragraph block doesn't wrap around the button as they're not in the same container. While having buttons as a separate container make sense for some usage (eg. a centered button), in other cases such as float left or right, it makes no sense and no matter which way you write the markup, you're going to have issues.

As I said above, it would actually make more sense to be able to insert a button inside a paragraph container so that your text could wrap nicely if needed. If you didn't force every single paragraph to be a separate block, and instead, allowed people to add multiple paragraphs to a block and let the end user decide when they wanted to insert a new block, it would be even more useful.

@youknowriad
Copy link
Contributor

<div class="wp-block"><a class="wp-block-button aligncenter" href="#">Modified button</a></div> Each block has a separate classname on its container. The wp-block-button will always be on the outer container.

That said, nested blocks are being worked on. What you're suggesting matches the use case of a container block (which is different than a paragraph block) that can hold multiple paragraphs/buttons etc... And this is something we'll have with nested blocks.

@maddisondesigns
Copy link
Author

My quick example probably could've been written better. It's understandable that the outer container for each block would have a unique class. I was just basing it on the current styles that are produced (i.e. all the button styles are currently on wp-block-button).

Having a container block that can hold multiple blocks would be great, but unless that's going to be available when WP5.0 is released, then we're still going to have some serious issues trying to style the current markup whilst also supporting both Gutenberg and Non-Gutenberg content.

@karmatosed
Copy link
Member

I think we can close this as comes under nested blocks with #2907 and #3445 in.

@maddisondesigns
Copy link
Author

@karmatosed So, until we get nested blocks, which btw, no-one will say when they're coming, we just have to put up with this terrible markup? Can you please reopen this. This needs to be addressed before nested blocks and before WP5.0 is released.

@karmatosed
Copy link
Member

Nested blocks are coming in the next release @maddisondesigns. Let's keep this closed until we see what happens there.

@maddisondesigns
Copy link
Author

@karmatosed By "next release" do you mean the next release of the plugin, in the next week or two, or the next version after the initial release in WP5.0?

@ntwb
Copy link
Member

ntwb commented Jan 5, 2018

"... looking at the next release next week. I’d like for it to include nested blocks."
(Via @mtias in Slack yesterday

Fingers crossed nested blocks will be in a release next week @maddisondesigns

@maddisondesigns
Copy link
Author

@karmatosed Any update on when these nested blocks coming?

@karmatosed
Copy link
Member

@maddisondesigns in the next few releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants