How to style alignfull and alignwide

[manake]

The documentation https://wordpress.org/gutenberg/handbook doesn't contain information on how to style alignfull and alignwide.

• jQuery('body').width() returns 1884
• window.innerWidth returns 1901

When I do:

.alignfull {
	margin-left: calc( -100vw / 2 + 100% / 2 );
	margin-right: calc( -100vw / 2 + 100% / 2 );
	max-width: 100vw;
}

then the resulting container is 1901px wide (thus producing horizontal scrollbar). To make it right it would have to be 1884px.

Can you please clarify how themes should style alignfull?

These places (top google results) contain wrong styling information:

• https://themehybrid.com/weblog/align-wide-and-full-classes
• https://themeshaper.com/2018/02/15/styling-themes-for-gutenberg/
• https://richtabor.com/gutenberg-image-alignments/
• https://jasonyingling.me/implementing-gutenberg-image-alignment-options-theme/
• https://www.billerickson.net/getting-your-theme-ready-for-gutenberg/
• https://generatepress.com/forums/topic/styling-for-gutenberg-alignfull-and-alignwide/
• I can't find any blog with correct information?

[webmandesign]

Hi, shameless plug here ;) This might be of interest to you: https://codepen.io/webmandesign/post/gutenberg-full-width-alignment-in-wordpress-themes

[webmandesign]

Also, the issue you describe is actually related to Windows OS only from what I know. The only way around it would be to set overflow: hidden; on your website container (as stated in "Known issues" section in examples accompanying the above article).

[manake]

+1 is for noticing different value of 100vw on Mac vs Windows.

Shouldn't this be filed to Chrome/Firefox/Edge developers as a bug? 100vw should return the same value on all systems, shouldn't it?

[webmandesign]

@manake According to https://cloudfour.com/thinks/breaking-out-with-viewport-units-and-calc/ the bugs were already reported…

[smerriman]

Also, the issue you describe is actually related to Windows OS only from what I know. The only way around it would be to set overflow: hidden; on your website container (as stated in "Known issues" section in examples accompanying the above article).

But that doesn't fix the problem. Yes, it prevents the horizontal scrollbars, but the content still overflows. You won't see the left and right edges of the image.

It seems there is no solution at all to this.

[webmandesign]

@smerriman That's true. However, there is no other way around, unfortunately.

[MichaelRise]

@manake @smerriman @webmandesign I test another 2 solutions.

1. Option 1 - We can add CSS custom properties (variables) to the :root with "body width" value and use it in css. Cause various problems. Some browsers don't support CSS custom properties (variables).
2. Option 2 - We can appending style nodes with javascript.

I must optimize my code but currently it works fine.
I created simple tutorial on github. If you can please check it. https://github.com/MichaelRise/Gutenberg-Fullwidth-Alignment

[manake]

Unfortunately, overflow: hidden; applied to html, body breaks my position: sticky;: https://stackoverflow.com/questions/43909940/why-does-overflowhidden-prevent-positionsticky-from-working

@MichaelRise

1. Option 1 - Is there a way to get body width into a variable without JavaScript? Something like 100vw - (100vw - 100%) maybe? If this works then that would be the solution.

@everyone
In general, shouldn't this be reported to Chrome/Firefox/Edge devs? They could create some new unit like 100rvw ("real viewport width") that would be unified. This lack of a solution and standardization is not good.

[MichaelRise]

@manake Option 3 - We can get scrollbar width and use it as a CSS custom properties (variables). JS code for this solution must be executed only once.
Example:
width: calc( 100vw - var(--scrollbarwidth) );

[chrisvanpatten]

I'm not really sure this is something we should cover explicitly in our documentation, because how you style these can vary from site to site. On my own website I'm using a weird "reverse grid" with wildcard selectors and such, however on another site our full-width option doesn't actually stretch the full width, so it's styled with a simple max-width.

And when you factor in themes with sidebars it gets even more complicated because some pages may treat full alignment differently from others.

Definitely recognise that the world needs more examples, to be clear… I'm just not sure it should be in official documentation.

Thoughts from the CSS and themey folks? Should we prescribe a recommended/official method, or let other sites document the various approaches?

cc @kjellr @jasmussen

[kjellr]

I agree — I'm not sure it's necessary to have a preferred/recommended method in the docs.

It has been helpful to have the sidebar example that's linked from the handbook currently, but I imagine that'll get less useful once more and more themes exist to learn from.

[MichaelRise]

I agree - websites, themes have a unique design and do not always have the same solutions and needs. However, it would be helpful to have examples for programmers that can help them save some time

[smerriman]

I think in this case it would be useful to include something given it's a core feature with no actual valid CSS implementation. I see the twentythirteen theme cuts off the sides of full width images and use a rather nasty hack of 96vw for full width non-images - if this WordPress' official recommendation, it's probably worth mentioning.

I've always used alternative methods - eg actually rewriting the divs to break out when needed. My first thought when seeing Gutenberg's version was 'hey cool, there's now a proper way to do it'. My second was 'wait, it doesn't work at all - why was it included then?'. I'm sure a lot of other people will be thinking the same thing - would love a page to refer to.

[manake]

Best: They should include 100rvw (real viewport width) in the browsers. This is the only real solution here.

Copy and paste code in the documentation is needed because look what I did in the first post: I opened 10 links from Google, wasted time and didn't find any solution.

[nickfmc]

After doing much of the same research as most people did here I decided instead of trying to make the wide classes break outside of my wrapper I would add the following to add a max width to blocks without the classes. I have not tested this thoroughly enough yet but it seams to work on columns, images, block quotes. So I just removed the page templates wrapper and assume it as 100%. Here is a pen with the WP markup as closely emulated as I could https://codepen.io/nickfmc/pen/vvbWQa

.editor-content > [class^="wp-block-"]:not(.alignfull) {
  width: 100%;
  max-width: 1200px;
  margin-left: auto;
margin-right: auto;
}

.editor-content > [class^="wp-block-"]:not(.alignfull).alignwide {
  max-width: 1400px;
}

[nextgenthemes]

@nickfmc This is exactly what I will be going for and I thought of this b4 even reading your comment. I think its way more intuitive then these complicated negative margins combined with calc and you need overflow ...

But I think I just go with

.entry-content > div:not(.alignfull),
.entry-content > p:not(.alignfull) {

or even just

.entry-content > *:not(.alignfull)

to make it independent of Gutenberg and just apply to all elements that are not specified to be wide (with Gutenberg or just by manually adding that class in). Not sure how the * star performance issues are at these days but I think CSS is read by the browser from right to left so I guess its fine.

//edit

Playing arround with this you actually have to at least also target p because Gutenberg (at least in my case) does actually not put a .wp-block- wrapper on ps neither does it put that class on them.

Another cool thing you can do is you can use the image block make it align left/right and then use the advanced section in the GB sidebar to put the alignwide/full class on the block, that will put the class on the wrapper and makes it 'break out' the general limited width while the images still float. I have a JS solution for this but this is just got way better. Now I am thinking about a GB toolbar element that automatically does that for me.

Here is what I got so far: https://codepen.io/nnico/pen/mvJQyB?editors=0100

[onetrev]

Agree @nextgenthemes ... in fact I'd say you have to go with the star selector you suggested because it's not just p tags but also things like headings, ie, h1 that are not wrapped in a .wp-block-. So the wildcard * selector is definitely the way to go.

.entry-content > *:not(.alignfull)

I have yet to really encounter any drawbacks. It works perfectly, and no scrollbars for anyone!

[ghost]

Bravo, thanks guys! This solution is amazing!

[LABCAT]

I think there should definitely be a recommended way to implement these styles and it should be used by all default WordPress themes.

Plugin creators need to implement default styles for their blocks and currently it seems impossible to ensure a block with wide or full alignment will work well on multiple themes.

A combination of @nickfmc and @onetrev seems to be the way to go.

How do we go about getting some action on this? Submit a ticket on core trac suggesting the change to all default themes?

[LABCAT]

You shouldn't need to use JavaScript for styling purposes. I still prefer the solutions suggested by @nickfmc and @onetrev.

[onetrev]

Interesting solution @WraithKenny, thanks for posting! I used to use the solutions posted by @nickfmc and @nextgenthemes but it never felt like the ideal fix. However, I just recently went back to using using vw similar to the setup of Twenty Twenty theme and it's working well and without scrollbars for me (Windows 10 testing only).

.entry-content .fullwidth {
  max-width: 100vw;
  position: relative;
  width: 100%; 
}

[onetrev]

No Mac here. See above, Windows 10 only. No horizontal scrollbar. You can as per Twenty Twenty use overflow-x: hidden to make sure. Just try the new WP default theme -- Twenty Twenty -- to test it out.

[strarsis]

Related: #19331

[nextgenthemes]

@WraithKenny

Quoting from your liked article:

That Mozilla article I linked to at the top? Literally 10 years old. Fact: computers were way slower 10 years ago. I have a feeling this stuff was more important back then. Ten years ago I was about to turn 21 and I don't think I even knew what CSS was, so I'm not going to get all old school on you... but I have a feeling we don't talk about this rendering efficiency stuff very much is because it's not that big of a problem anymore.

This is how I'm feeling about it: the best practices we covered above make sense no matter what. You might as well follow them, because they don't limit your abilities with CSS anyway. But you don't have to be all dogmatic about it. If you happen to be in the position where you need to eek out every last drop of performance out of a site and you have never considered this stuff before, it may be worth revisiting your stylesheets to see where you can do better. If you aren't seeing much rendering slowness in your site, then don't worry about it, just be aware for the future.

I think it's totally ridiculous to be concerned about a few :not() selectors. Computers and phones are getting faster and faster and so are browser engines. I like to see some real world examples of CSS performance that make a difference that is humanly noticeable. I gonna make a the claim that you need to got pretty crazy with A LOT of those "inefficient" selectors to see some real slowdowns.

I have not looked deeply at what TwentyTwenty is doing but that I and others are suggesting are a few basic CSS lines to make this happen. Not sure why that has to be that complicated.

[youknowriad]

Sorry for missing this issue initially. I agree that alignments are hard to support these days. We're rethinking these to simplify things for theme authors in #20650