The XL breakpoint - Dun Dun Duuuun


#1

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:


4 default breakpoints in Blocs?
#2

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.

Cheers,
Eldar


#3

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.


#4

@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.


#5

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


#6

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


#7

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


#8

@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:


#9

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.


#10

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.

Casey