The XL breakpoint - Dun Dun Duuuun

There has been some talk over the last few days here and in another forum regarding the lack of the XL breakpoint. For those who are not familiar with it, its basically a way to control the look on of your site on very large screens.

What Blocs Currently Does With XL Data

So, Blocs actually already writes data to the XL breakpoint, anything that is set on the LG breakpoint is also applied to the XL breakpoint. So think of it like this, anything you set at the current 1200px breakpoint is inherited by sizes above.

The Reason XL is Not Included

Because XL and LG are both computer targeted sizes, it’s not very common that a designer or client would want to change the layout significantly between desktop and laptop. Especially since some laptops have screen sizes that would show the XL breakpoint and others that will not.

The visual controls for XL are left out but are automatically managed by Blocs, it basically simplifies the workflow. If you had controls for XL, users would start designing in XL first, which would probably then lead to confusion when some see the results on their laptops and others do not.

What we have now means most users get the same results.

What Would Controls For The XL Breakpoint Enable?
You would be able to change the visual style between 1200px+ and 1200px, essentially between a large desktop and a large laptop. This would of course require changing the maximum width of the sites container as well in order to benefit otherwise the styling would literally change but the main content would not occupy any more space on the screen than 1200px.

It’s worth noting, most, if not all apps/platforms that are focused on making web design easier offer less breakpoints than Blocs currently does.

I Want A Wider Site
This can already be done, just change the default max width setting in the main project settings.

Shut Up Norm And Just Give Us The XL Breakpoint
If you are interested in seeing controls for this XL breakpoint, what I need is good examples of sites that take advantage of it and offer something that is better than simply increasing the max container width via project settings.

To clarify, I’m totally open for discussion on this, I just need the data that validates making the workflow more complex. The positives need to outweigh the negatives.

Im always listening :v:


Hello @Norm,

Thank you for making your position crystal clear. I totally agree with your point of view.

I understand that in some cases having XL breakpoint will be beneficial, but in my opinion, it is not something very crucial, and if done properly, can be archived using the existing tools inside Blocs. (Max width of the site, code injection areas, etc).

I think it’s like having a built-in FTP client. It would be nice, but it’s nowhere near being a top priority for me.

Instead, I would love to see Blocs continue to get more solid and bug-free while adding a great little (but important) features like the addition of new tabbed or accordion bric (which make it possible to create great layouts previously almost impossible to do in Blocs 2). Or, more options for existing brics like carousels, tabbed content, etc.

In any case, thank you for sharing your opinion! If XL breakpoint someday will be in Blocs, I will be happy to master it and use in my wide websites, but if it will not be, no problem for me at all.



BTW, to all built-in FTP proponents: be careful what you wish for. This may turn out to be very ugly. For example, in RapidWeaver, FTP publishing engine is the most vulnerable Achilles heel of the application. It always was. For years, it couldn’t be made reliable—while publishing with any 3rd party FTP app is 100% fail-proof.


@FlexitarianFixie Been there, done that and it wasn’t pretty with RW. I’ve tried to warn the others here…

FTP seems to be getting ever more complex as well with different server configurations and I sometimes have to fiddle about with Yummy or Forklift before it works as expected on a new server. If Norm wants to pencil this in for Blocs 17 I wouldn’t cry too much.

@Norm I wonder if you should post a link to this post in the other place, just to explain the reasoning behind the decision?

1 Like

Im not sure its a good move for me, it could be taken the wrong way.


Perhaps somebody else will do it or they’ll find it themselves.

1 Like

@Norm you not only have out the chart developer & design skills, but you have great writing skills also. You’ve made this very clear. I can appreciate your insights. I agree @Eldar having a bug free App is far more important. Go Blocs 4! :wink:


I agree with @Norm and @Eldar, that an XL Breakpoint is not something, which should be on the priority list. The only cases where I can think of, where something linke this would make sense is when using a sidebar menu on the page as icon menu or menu with text and more information on even larger screens.


I like the way it is now. As Norm explained we still have the option without having to deal with another breakpoint.

The new version is stable, I do run into a few small bugs. My biggest wish is to expand on the usability of the current features. The new tabs and accordion are great but it would be really nice with a few more features. Norm has opened up a lot to those who want to insert more code. I have no problem with that, I just want the native Blocs to have as many options possible without adding code.



Hi Everyone

I can understand the point of value vs. simplicity. But as a Designer I need a way to break at XL. In menus with long menu items I’m limited in width and I cannot skew the navigation or break the line. It would be very nice to switch to a hamburger Icon at XL. It there another solution to do this without breakpoint at XL?

Thanks, Florian

What happens if you set it to hamburger at LG? At that point it should always be hamburger on any size screen.

The menu gives useres orientation. Not to show on big screens makes no sense. Today it’s all about usability and there is a reason for the XL breakpoint. Blocs is built upon Bootstrap and we already have the logic for breaking layouts. So why we do not follow this path?

As I can see this thread is not active about 1 year, I would like to take another try to give the XL breakpoint a chance. Anyone else?

Cheers, Florian

I would suggest you send a note to the developer and explain your thoughts. I am sure he will look at it seriously. For me personally it has not created any problems to date, but I am always open to changes if they improve results.

1 Like

in particular I like the places where I can get juice from the entire width of the browser, as I have some measure, I do want an “XL” since I can adjust the design as I would like it to be seen on the wide screen … ex…

How to adjust the layout for a wider screen if I don’t have that option?

You say you can change the browser size …

I have changed the settings to 100% or a specific 1920 pixel, but blocsapp does not show a canvas according to, (unless I am missing something)…

I remember a post in, where the project never fits the defined width, the content never fit, and I never had a good response on the subject …

After changing the design a bit, you can make some things fit, the funny thing is that if I do not change the configuration of the width that comes by default, all the content is adjusted to the width …

so, no, there is no way to configure a larger point, or at least it has not worked for me …

and of course I would like to have a wider point where I can adjust the design for sites that are created to a larger width … or it would be nice if you could enable a wider point only if necessary instead of being activated by defaul, I don’t know if this makes sense to you or if it’s possible … if someone wants a broader point that can only enable it …

While we do not have an XL view in blocs (yet?), you can toogle the view of elements designed for specific breakpoints by using the display utility classes. See:

I used it to display elements containing text with a larger font size when in XL view and hide the elements for LG view.