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

blocks arent wrapped on front end #4883

Closed
saltnpixels opened this issue Feb 6, 2018 · 8 comments
Closed

blocks arent wrapped on front end #4883

saltnpixels opened this issue Feb 6, 2018 · 8 comments

Comments

@saltnpixels
Copy link

saltnpixels commented Feb 6, 2018

Issue Overview

I was playing around making a new theme with Gutenberg.
I made a paragraph block with an image block floated to the right.
In the editor it works and looks right because it contains BOTH the paragraph and image in a block.
screenshot 2018-02-05 18 40 55

Front End

On the front end, using the_content(), it outputs a simple paragraph and an image. They are not combined in any way and there isn't a wrapper div containing both of them.
This can potentially lead to bad results.


I was also trying to use the full width image block at the same time.
This means making sure the article tag itself is 100%, so an image inside can go 100%.
But text should never be 100% or it can be too long. See below.
screenshot 2018-02-05 19 00 39
As you can see the text is really long and we need to contain it.

Setting a Max-Width

If I set the whole article with a max-width for my content, well then, the images work nicely, somewhat, but now I cant have full-width images without silly hacks. I'd rather not use those.

If instead, I set ALL p tags to a max-width, that allows for full width images, butnow those floated images are completely not in the right place! See below
screenshot 2018-02-05 18 55 37


At the end of the day: the paragraphs need to be combined with the floating images in a div that i can work with. I thought Gutenberg created blocks. I figured each block would be contained for further styling.

Steps to Reproduce (for bugs)

  1. Install Wordpress
  2. Install Gutenberg
  3. Make a paragraph block
  4. Make an image block and float right

Chrome

Expected Behavior

Magically just work

Current Behavior

Magic is not working. Possible tampering by muggles.

Possible Solution

Contain paragraphs and floated images in one div with a class. Even single paragraphs should be contained or at least be given a class.

Because a plain paragraph with no class handle cannot be styled easily, and if styled, can potentially ruin some other fancy block with paragraphs within.

@saltnpixels
Copy link
Author

technically you can play around like this for full width items:
.full-width { width: 100vw; position: relative; left: 50%; right: 50%; margin-left: -50vw; margin-right: -50vw; }

and that could be for full width images inside a narrower item like the article... But still I thought blocks would allow for separate items that can be style throughout my article.

@jasmussen
Copy link
Contributor

Thanks for the ticket.

In the editor it works and looks right because it contains BOTH the paragraph and image in a block.

This is not actually the case. The markup is the same in front and backend, however we have some UI issues with floats, that makes it visually appear to be the case. I'm working on improving that UI aspect right now, and just recently a change to how floats are handled has been merged in, and will be in 2.3.

The key challenge, as I read this ticket, is the desire to have a normal main column with a fixed width, yet accommodate both wide and fullwide images. This can be done using the vw unit, but this has its own challenges with scrollbars being included, and it doesn't work too well when you also have a sidebar.

I put together this codepen, suggesting a method for creating floats that magically work, alongside wide and fullwide items: https://codepen.io/joen/pen/oEYVXB

This is now the same approach Gutenberg uses for wide images.

Closing this ticket for now, but feel free to reopen if you feel that codepen approach doesn't address your questions.

@saltnpixels
Copy link
Author

saltnpixels commented Feb 23, 2018

@jasmussen
hmmm as you can see here it would seem the figure element gets the class of alignleft, not the image within.
https://www.dropbox.com/s/bzp07dt3rcyveke/Screenshot%202018-02-23%2010.53.51.png?dl=0

Ahhh I see you now use .alignleft img as your selector.
Will this ruin other things that are alignleft? It's different from how the classic editor works, where that class is directly on the image. Is there a way to let css know whether we are using the classic editor or the new one?

The figure element is also being given an inline width of 50% by WordPress, which ruins the layout further.

@saltnpixels
Copy link
Author

saltnpixels commented Feb 26, 2018

@jasmussen
Unless I use !important in my code, the figure element has an output of max-width: 50% which ruins the layout.

I tested some layouts
https://codepen.io/saltnpixels/pen/jZeexN

@sc0ttkclark
Copy link

Not seeing the option to reopen the issue, but I'm interested in the outcome of this issue as well.

@saltnpixels
Copy link
Author

saltnpixels commented Feb 26, 2018

Also using the layout suggested, the issue is exasperated if there is a caption included. Because the figure is no longer floated but only the image within. The caption is no longer under the image.

I propose containing the whole figure>img element in a div.wp-block so we can float the whole element as one unit, image and caption together.

@jasmussen
Copy link
Contributor

Closing this ticket for now, but feel free to reopen if you feel that codepen approach doesn't address your questions.

I should've clarified that I meant it's totally okay to open new tickets for issues. I wasn't trying to quell any issues or presume no issues existed, sorry if it came across as such.

In this case I'm still not sure whether the initial issue is fixed or not. Can you take a look at this PR and discussion, to see whether it tackles the same issue? #5209 (comment)

Also using the layout suggested, the issue is exasperated if there is a caption included. Because the figure is no longer floated but only the image within. The caption is no longer under the image.

I updated the original codepen, by the way, to include captions: https://codepen.io/joen/pen/oEYVXB

Note that this is just one way to utilize wide images. You can also use this method.

I propose containing the whole figure>img element in a div.wp-block so we can float the whole element as one unit, image and caption together.

The markup is this:

<figure class="wp-block-image alignleft" style="width:355px">
    <img src="http://gutenberg/wp-content/uploads/2017/10/pic6.jpg" alt="" class="wp-image-313" width="355" height="237" />
    <figcaption style="width:355px">Lovely mountain<br/></figcaption>
</figure>

The entire element already has a classname such as you suggest. So you could potentially write:

.wp-block-image.alignleft {
...
}

@saltnpixels
Copy link
Author

saltnpixels commented Feb 27, 2018

Note that this is just one way to utilize wide images. You can also use this method.

That method doesn't account for if there is a sidebar right?
I think the method you use seems safer for the future.
One could technically write separate code for when there is a sidebar, but it's more work than needed. And what if you have yet another layout?
It should work no matter what they layout is.

Also your example doesn't take into account the inline max-width applied to the figure element.

I Would rather it be:

<div class="wp-block-image alignleft">
   <figure>
      <img src="http://gutenberg/wp-content/uploads/2017/10/pic6.jpg" alt="" class="wp-image-313" width="355" height="237" />
      <figcaption>Lovely mountain</figcaption>
  </figure>
</div>

This makes it much easier to style the whole figure as one unit. It also gives more control to theme developers who might decide to position the figure, say, off to the side of the content, or do some animation to it. Without a surrounding div, you need to style the img tag and caption tag separately as they are not together.
By being able to float the actual figure element, the whole thing moves together.
i also don't think an inline max-width is necessary. That's for theme developers to decide how big the image should be when floated.

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

3 participants