ZebulanStanphill commented 6 years ago

Issue Overview

The Columns block, while definitely improved from its first implementation, is still pretty useless due to the fact that the columns are not responsive. The only number of columns you might get away with on a phone screen is 2, and that is only for things like images or buttons, not textual content.

Additionally, the Columns block only allows for same-width columns, which is considerably restricting, but that is covered in #4902, so I'll just say that I think that between the two, responsive columns is more important, as non-equal width columns would not be very useful if they were not responsive.

Since the core of page building is the use of sections, rows, and columns, I think it is essential that the merge proposal version of Gutenberg contains usable Section (see #4900) and Columns blocks.

From a functionality perspective, the inability to have at least responsive columns would render the Columns block almost useless. If it is not responsive, it is almost never going to be used in practice. The Columns block needs at least responsive columns. For ideas on how to implement this in practice, take inspiration from how existing page builder plugins do it and how Bootstrap does it.

From a public relations perspective, Gutenberg would look like a ridiculously under-powered page builder to the average user if the Columns block was not at least decent enough to be used for responsive design. Gutenberg needs to make a good first impression when WordPress 5.0 launches, and I think a better Columns block is necessary for that. I can imagine blog posts appearing all over the internet talking about how incomplete the Gutenberg editor was for not including a decent Columns block in the 5.0 launch. It will be hard to get past all of that, because even when the Columns block is improved, people will still perceive Gutenberg as having been launched as a beta product.

Related Issues and/or PRs

4900

4902

cavalierlife commented 6 years ago

I don't understand why #4902 was closed or why it is considered a customizer thing. I could see it being a customizer thing if the only concern was column widths for global theme layout, but I don't see why column width wouldn't be considered an editor thing as obviously the columns will be used within the post/page editor. In any case, I agree columns should be responsive. That's a must. But I also think column width is equal in importance, with both being VERY important.

ZebulanStanphill commented 6 years ago

@cavalierlife Actually, I think "Customizer focus" was referring to the customization phase of Gutenberg (which I think comes after the merge proposal and WordPress 5.0 release), not the WordPress Customizer, although that may end up being affected by the customization phase as well.

Personally, I would really prefer non-equal width columns to be added before the 5.0 release, and I think that those and responsive columns are related in terms of how they affect UI design and functionality, but if I had to pick just one of the two to be worked on and completed before the merge proposal, it would be responsive columns, because those are basically required for the columns to be useful in the majority of situations.

I could wait a while longer for non-equal width columns (understanding that they are in the works), but I am not so sure about everyone else, and I can imagine the lack of them might leave a bad impression and give them the feeling that Gutenberg is "so weak compared to other page builders" and that "the WordPress team does not understand what a page builder is used for". I get the big picture with where Gutenberg is going and what is planned for the future, but will the general user, designer, or developer understand that or even know about it? To many people right now, Gutenberg just looks like half an attempt at a page builder, but seemingly lacking most features that people expect from a page builder plugin.

Of course, the long term plan for Gutenberg, if successful, will end up creating a common API that all page builders can use as a backend, turning most of them into essentially alternative UIs for a common website builder system that replaces widgets, shortcodes, "modules" (or whatever each page builder calls them), and some metaboxes (the other metaboxes would be replaced by the custom sidebar APIs) with a common element (blocks) and removes the need for manually creating PHP template files in most situations by allowing page template layouts including sidebars, footers, and other non-post-content areas to be built using Gutenberg.

But I only know about that from doing a lot of research on this GitHub and reading lots of articles about Gutenberg. Most people will not spend that much time looking into it, and will just hear about "a page builder in WordPress core" and think that is all there is to it. They will expect features that are standard for page builder plugins to be present in the version of Gutenberg that is shipped in WordPress 5.0.

If non-equal width columns do not make it into 5.0, I think it would help a lot if the post-update welcome screen mentioned that they (along with various other features) were being worked on for a future update. It might give people the impression that Gutenberg was launched too early (and I can not say I would disagree with them), but it would certainly be better than not making it obvious that the features were planned at all.

@karmatosed Could we get a clarification on what you were referring to in #4902?

chrisvanpatten commented 6 years ago

Variable-width columns are going to be a big part of a client project we're working on (to enable customisable homepage layouts), and my hope is that this is an area where our team can contribute back to Gutenberg and get this included in prior to the merge proposal (or shortly thereafter).

rchipka commented 6 years ago

Rather than adding responsive settings to the Columns block, we should consider adding a "Responsive" block around the Columns block.

melchoyce commented 6 years ago

Related, with some existing discussion: #5351

ZebulanStanphill commented 6 years ago

Related: #7414.

designsimply commented 6 years ago

Closed https://github.com/WordPress/gutenberg/issues/7742 as a duplicate and noting the question from that issue for reference because it's relevant to this discussion:

How can I convert multiple column content to 1 column in Mobile view? It looks very weird when I add 4 columns in content & they show side by side even in mobile.

designsimply commented 6 years ago

Closed https://github.com/WordPress/gutenberg/issues/7315 as a duplicate and wanted to include their comment here as well:

It's not currently possible to resize the columns in the columns block. The ability to have columns is imperative for providing more flexible layouts. If you can only add equal width columns though, it makes it extremely limiting.

Ideally, you should be able to specify a percentage width for each column. At a bare minimum though, you should at least be able to select a different layout.

rickcurran commented 6 years ago

Yep, agree with both of those comments above. It shows however that there's quite a lot of combinations possible when it comes to media queries / break points for responsive layouts. There isn't going to be a one-size-fits-all solution but I think there would need to be default Columns block specific behaviour. I'd probably suggest that multiple columns should all wrap to a single column somewhere between 640px - 480px wide. Personally I usually go for < 640px but that can be a bit wide for a single column in some situations. Additionally for a four-column layout these would often break to two-by-two rows on medium size screens so again there are a lot of potential options here.

It would be challenging to build a UI to choose from all of the possible combinations but I think you'd need to pick some of the most common options and leave the more complex options to be possible via custom classes on the parent and / or child columns, or extending the column block itself.

For my own usage of the Columns block I'd be looking to override the standard WP classes on them to use my own preferred column layout classes, most commonly for me would be those used in the Foundation framework, so 'row' classes on the parent and 'columns' classes along with column sizing classes such as 'small-12', 'medium-6', 'large-8' etc on the child columns. This would be doable via custom classes on the parent and child columns, but it would be essential to have a default way to override these for all Columns blocks without having to set these each time, basically just globally overriding the names of the standard WP Columns block classes.

lkraav commented 6 years ago

Based on working for years with shortcode-based column implementations, my current conclusion is that each column must have its own configuration/classes to be available when needed.

Frameworks like https://purecss.io/grids/ (not to mention Bootstrap etc) have provided the general grid architecture and surfaced the related issues for a long time.

Ideally, Gutenberg would be able to toggle between device modes, like Customizer has today, and the block-based content "wireframe" (since Gutenberg will fail to be a polished page builder for a while) should be able to render itself for a quick preliminary human-eye cross-device QA. Final QA would have to still go through frontend Preview function, until real page building / frontend content editing becomes a reality for Gutenberg.

mtias commented 6 years ago

Apart from expanding on the controls, I think a good first step could be to default to stacked columns on mobile, and maybe add a toggle option to the inspector to disable that behaviour.

lkraav commented 6 years ago

Apart from expanding on the controls, I think a good first step could be to default to stacked columns on mobile, and maybe add a toggle option to the inspector to disable that behaviour.

Defining 3 width categories is usually the minimum, or you will get massively white-space heavy wide stacked blocks too often (because columns often already fail to fit on portrait tablets, so the stacking breakpoint needs to generous).

There are also cases where you need to display something in 2 columns even on mobiles.

This is really a framework level challenge, hardcoding some opinionated rules will not get far.

Pretty much anything is good as the first iteration step, though.

ZebulanStanphill commented 6 years ago

Yeah, getting responsive styles with columns done right is a tricky thing to accomplish, but at this point a hardcoded responsiveness (with a toggle to turn it off) would be better than what exists right now. Divi actually has hardcoded breakpoints and no way to customize them (without using custom CSS, of course), and yet a lot of people are pretty happy with it, so I think Gutenberg can get away with hardcoded breakpoints as well for now. Obviously a more flexible solution should be worked on for the future, but I doubt such a thing would make it into WordPress 5.0 at this point.

Just make sure to choose good default breakpoints (check out what page builder plugins do by default for some existing examples). I would recommend at least 3 breakpoints (phone, tablet, and desktop) to start off with.

Also, I recommend checking out how Oxygen uses a CSS flex-based layout system and exposes the settings in a really nice way. I think perhaps in the future a flex-layout block could be something that could work as an alternative to the Columns block.

https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/ https://oxygenbuilder.com/documentation/visual-editing/responsive-controls/

rickcurran commented 6 years ago

@SuperGeniusZeb The most recent 3.2 update changed the columns block to use Flexbox instead of the original css grid method.

For my own usage I'd need a way to specify specific break points and also to be able to set custom classes for the columns block in order for it to be usable in my own projects.

I realise that my needs are probably beyond what is feasible in the short term, but column blocks are such a key feature of what makes Gutenberg attractive it has so far been a a frustrating experience personally trying to work with them.

The core Columns block as it stands isn't capable enough so I've been trying to write my own column-based blocks but with limited success so far, part of the challenge being that I want to use the Foundation framework for the layout classes but it's proving very difficult to use these on the admin side due to clashes with the various extra "editor-block-..." markup that exists there.

I'd expect that adding responsiveness to the existing Columns block with options like different sized columns etc would encounter some of the same issues I've experienced in attempting to write my own block.

ZebulanStanphill commented 6 years ago

@rickcurran I know the Columns block was updated to use Flexbox. I was thinking more along the lines of a block that did not use columns and instead laid out its items depending on its Flexbox settings, reducing the need for columns in the first place, while still allowing them through the use of a generic Container block (perhaps like the one described in the later comments in #4900) to group other blocks.

It is hard to explain; just check out what Oxygen does. It is really neat, and uses a lot less <div>s and feels a lot cleaner than the traditional Section→Columns→Column layout system that nearly everything else uses.

rickcurran commented 6 years ago

@SuperGeniusZeb Ah ok, I see what you mean. That sounds like something that would be suited to CSS Grid style layout methodology. For my part I'd need specific columns as containers for the content in the layouts I'm building so the approach you're looking at doesn't seem like it would work for me.

I'm going to need to persevere with my own column block I think as I don't think the core Columns block is going to work well enough for my needs, for a while at least anyway.

ZebulanStanphill commented 6 years ago

@rickcurran Actually, you can still have individual columns as containers themselves with what Oxygen does. It is simply optional. Check out the video to see how it all works:

https://www.youtube.com/watch?v=NnSfR-YFcQI

I think the Container block described in the later comments of #4900 could have the stack horizontal/vertical and alignment options that the Oxygen Section/Div elements have, and the Columns block could be used in addition to those to provide a full range of layout options. Maybe the Column blocks nested in the Columns block could even end up being replaced by the same Container block used for sections and generic <div>s, though I think that depends on how certain things are implemented in the Columns block.

karmatosed commented 6 years ago

To get something in I have come up with a minimum suggestion here. I'll note we would need to iterate the copy here. For example we need it to be understood. What I suggest as a version one is simply that we have on by default adapting by having one column on top of another at smaller screen sizes. This would be on by default. These mocks are direct from UI we have today, to show it in place.

Later iterations we can look at adding in an option to have various sizes but the above provides a starting point. I have chosen a switch as it seems a simple way of doing this.

ZebulanStanphill commented 6 years ago

@karmatosed Looks good to me. :+1:

karmatosed commented 6 years ago

I have another more 'future' suggestion of making columns adapt purely to device points. I'll note the wording here was super hard and I haven't got it right at all, but it shows a potential interface to kick off ideas.

karmatosed commented 6 years ago

One more option that over using existing pattern in Customizer uses the same as fonts:

rchipka commented 6 years ago

@karmatosed I think the best solution would be to add a Responsive block.

This would allow you to control the number of columns as well as any other setting on any block type, which would solve the problem across the board.

I think a mock-up of a Responsive block would demonstrate the idea better, but I haven't gotten around to that yet.

Either way, we should decide whether to use it before developers start implementing their own custom responsiveness settings for every use case.

Better to solve the problem once and have everything in a single, consistent place.

karmatosed commented 6 years ago

@rchipka whilst I understand your point I still don't think that is the good solution here. Firstly, everything should respond. Having a block to do that is a step backwards a little as an interface. Having control by the block makes a lot of sense. I closed up that issue to focus here.

ZebulanStanphill commented 6 years ago

Responsiveness should be something that exists automatically for all pure styling options, in my opinion. I would like for something similar to what Divi has:

https://supergeniuszeb.com/wp-content/uploads/2018/07/Divi-Visual-Builder-responsive-style-options-demonstration.webm

rchipka commented 6 years ago

@karmatosed If everything should respond by default then the responsive breakpoint should be chosen at the at the root document level and then settings should be changed accordingly.

That would still be the same concept, but essentially with a Responsive block wrapping the entire document.

The only reason I can think that an inline controller would be good, helpful, or easier is for power users that know what they're doing and can mentally visualize the state of a complex computer application.

That being said, I'm a power user and I'd still prefer a "this is my entire view given this single breakpoint setting state" workflow.

Using individual responsive controllers for each setting has quite a few downsides.

For example:

Only block settings that are explicitly coded to be responsive can ever be responsive
Users will enter a complex breakpoint "state hell" (ex. how can I instantly preview mobile settings for more than just one setting)
Users will have to get used to a potentially different interface for controlling responsive settings
Cluttering up each block setting with its own responsive setting
Breakpoint definition, modification, and maintenance mess
Style enqueuing and overriding mess
Introducing inconsistent styling and layout
Reduced visibility into where and why breakpoint changes are happening
No easy way to quickly preview setting changes between breakpoints
No easy way to just edit the settings for a specific breakpoint for multiple blocks
No easy facility for controlling content-based changes at breakpoints
Major version upgrade restructuring/maintenance mess

Not to mention that it doesn't follow the react philosophy of state traveling in one direction and changing based on a single source of truth.

The source of truth for screen size is at the document root level. If you could nest a Responsive block anywhere, that would at least be a more explicit control point than on each block setting.

Even if Gutenberg facilitates a standard responsive setting controller that should be used for all block implementations, there would still be a need to actually hook that controller up to a setting.

Also, if the inline controller doesn't look or behave exactly as the developer needs inside their block, they'll fragment and roll their own, which will bring with it all the problems of non-standardized implementations.

If you put the responsive controls outside of a developer's block, they'll be much less likely to mess around with it, roll their own, and break things.

The concept isn't new either- it's the same breakpoint workflow used by WebFlow and Divi.

It just works and works for every block and every setting. Users know where to find it and how to use it. It makes more sense structurally in a react implementation.

rchipka commented 6 years ago

@SuperGeniusZeb Exactly. If Gutenberg added a Responsive block (or root-level toggle) and took care of CSS property control and stylesheet generation, it would be a WYSIWYG winner and a developer's dream.

ZebulanStanphill commented 6 years ago

I think handling responsiveness from a dedicated block is confusing; it certainly does not line up with my concept of what a block is supposed to be.

I think having a toggle next to styling controls to enable responsiveness for that setting is the right way to go. No need to duplicate an entire block for responsiveness. The toggle allows you to enable responsiveness for a single option.

I would imagine that on the API side, this enable-responsiveness toggle would be either opt-in or opt-out. I am not sure which makes more sense.

The breakpoints you could choose from would be provided by the theme and a core set of defaults; themes could opt-out of the ones provided by core.

For the best user experience, you would ideally want to shrink the displayed content width to match the responsive breakpoint you are currently modifying an option for. (See the above-linked video of how this works in the Divi Visual Builder.)

Also like Divi, there should be a dropdown or some control in the top bar of the editor to shrink the page to a breakpoint and see how everything looks without having to resize your browser window. Here is a demonstration of how Divi does this:

https://supergeniuszeb.com/wp-content/uploads/2018/05/Divi-Visual-Builder-responsive-breakpoint-switcher-demonstration.webm

chrisvanpatten commented 6 years ago

I agree a lot with @SuperGeniusZeb on this. I'd even argue further that breakpoints should be exclusively determined by the theme (core wouldn't provide any defaults, just bake the settings into the default themes retroactively). Even further, I'd argue that themes should have to explicitly opt-in to allowing these settings to display in the editor. As someone working mostly with enterprises and somewhat non-technical editorial teams, allowing that level of control over the layout management experience sounds like a total nightmare. I'd much rather make those decisions — how columns respond, how font sizes shift around, etc. — at a global, unchangeable level, in the theme CSS.

I'd also say, because I've seen it a few times in related discussions, if you're trying explicitly to change content at different breakpoints you are probably doing responsive design wrong. The HTML should be identical at all responsive breakpoints. Allowing any arbitrary attribute to change from breakpoint to breakpoint will inevitably mean different representations of the markup at different levels. (@SuperGeniusZeb noted that it only pure styling options can be supported, as in the Divi example they shared.)

Further, although width is the most common property in a media query, we shouldn't forget that DPI, viewport height, screen type, aspect-ratio, etc. are all acceptable as well. Handling all those possibilities — heck, even the 3 most common — increases the complexity level.

Ultimately I can't speak for everyone involved, obviously, but my sense is that for these types of controls it's probably better for Gutenberg/Core to lean toward "decisions" in the decisions/options spectrum, and let third parties extend the controls for these more complex use cases. (There's nothing stopping anyone from building a "Responsive" block right now, for instance — the APIs are there. Controls could easily be made filterable to support global responsive settings. Et cetera.)

(Those are four semi-related paragraphs. Oops. I thought that would be more cohesive…)

(Also, it's all somewhat moot because these are definitely more "Phase 2" problems 😄)

rchipka commented 6 years ago

@SuperGeniusZeb I think calling it a Responsive "block" is causing some confusion.

It's a "dedicated block" because a block is the best way to modularly inject functionality into a hierarchical block-based system.

How that block appears, where it appears, if it's there by default, its restrictions, etc. are all completely up to however it happens to be implemented.

In an ideal world

In an ideal world, we would have a way to control anything about a block for a specific breakpoint through a standard interface.

There's no way to automatically give every block setting inline responsive controls

Imagine you have this awesome block with all these settings that you want change for a specific breakpoint.

Since we don't have enough knowledge about the values and layout of specific block settings, we have no clean way to automatically add a responsive controller to those settings.

You have to wait around for the developer of that block to decide whether (and to what extent) you can control a given setting responsively.

Even if we could

Even if you could assume enough knowledge about the layout, values, structure, and styling of a block setting to auto-inject a standard responsive controller, it can still be subverted and users still wouldn't have a means of controlling certain things (like block content).

If I have some implementation that, for whatever reason, doesn't follow the expected controller interface, that value cannot be controlled responsively.

Then how could we configure responsive settings on all existing blocks?

Don't try to put the responsive controller next to the setting itself (at least not automatically).

This is an open system in a world of unlimited choices. It will be subverted (intentionally or otherwise) and imposing our will might break the whole system.

Do separate concerns by moving responsive values, settings, state, and interface to a place where we can absolutely control them.

This would require no extra cooperation from a block developer.

More than just "block settings"

For a specific breakpoint I want to:

Show/hide blocks
~~Reorder blocks~~ (let's not do that)
Change some content
Change the value of a custom field
Change the value for a custom controller inside the block content

These are all concerns that would have to be addressed separately if we only focus on block settings as being responsive.

This approach would switch the full render between breakpoints, which means we can literally record a responsive setting for any and every change to a block.

Any change, including the smallest random change to an arcane undocumented beta feature only configurable via a window.dialog() triggered by an esoteric key combo on a certain day of the week where values 1 and 3 are valid but value 2 is invalid depending on some other setting which optionally takes multiple values but isn't required and... well you get the idea... any change to a block.

rchipka commented 6 years ago

@chrisvanpatten While it may be more Phase 2, a decision and standardization should happen as soon as possible.

There's no easy way back from the mess that will emerge once a fundamental (and arguably vital) feature like this becomes fragmented.

chrisvanpatten commented 6 years ago

Show/hide blocks Reorder blocks Change some content Change the value of a custom field Change the value for a custom controller inside the block content

I'd argue that all of these are fundamentally anti-patterns, contrary to what responsive design is, and ignoring what makes it so valuable. Google explicitly expects consistent markup between all viewpoints. Storing and rendering multiple distinct representations of a block would have negative effects on SEO, performance, and complexity.

A "control everything distinctly at different breakpoints" approach is exactly what we were moving away from when dedicated mobile websites were pushed aside in favor of responsive design. Responsive design is better precisely because it's supposed to be easier; let the stylesheet decide how things filter down, so implementers don't have to worry about mapping content to different contexts.

I'm not saying there aren't situations where you might actually need to show a specific block at a breakpoint or not, just that it should be the exception and thus is better handled outside of Gutenberg core so users have to be absolutely certain they need this type of implementations.

ZebulanStanphill commented 6 years ago

@chrisvanpatten

I agree a lot with @SuperGeniusZeb on this. I'd even argue further that breakpoints should be exclusively determined by the theme (core wouldn't provide any defaults, just bake the settings into the default themes retroactively). Even further, I'd argue that themes should have to explicitly opt-in to allowing these settings to display in the editor. As someone working mostly with enterprises and somewhat non-technical editorial teams, allowing that level of control over the layout management experience sounds like a total nightmare. I'd much rather make those decisions — how columns respond, how font sizes shift around, etc. — at a global, unchangeable level, in the theme CSS.

Sounds good to me. :+1:

@rchipka

In an ideal world, we would have a way to control anything about a block for a specific breakpoint through a standard interface.

Controlling the actual content of a block responsively sounds like a bad idea in all but a few special cases. And for those special cases, I think a plugin (maybe one that adds a Responsive block like the one you suggested) would be better suited to handle those. Core should not try to do everything. It should just try to provide the most important things and be extensible enough for plugins to add the things it lacks.

For a specific breakpoint I want to:

Show/hide blocks

Reorder blocks

Change some content

Change the value of a custom field

Change the value for a custom controller inside the block content

These are all concerns that would have to be addressed separately if we only focus on block settings as being responsive.

Showing/hiding a block based on a responsive breakpoint is something Divi has, which it implements separately from the responsive controls feature, and I think it makes sense there. I imagine this could be a setting under the Advanced accordion in the block inspector.

Re-ordering blocks semantically according to responsive breakpoints is a very bad idea, in my opinion.

Re-ordering blocks visually sounds like a special case to me. It is also only easily possible in a CSS Flexbox or Grid container. Because of that, I think this is something that would be better covered just by using custom CSS. Maybe there could even be a plugin that adds a custom CSS box to blocks that can be made responsive (via the inline toggle or whatever else gets implemented). But re-ordering blocks is not something I would want in core.

That is, unless you are just talking about vertical versus horizontal stack direction or left-to-right verse right-to-left direction. In that case, those should be handled by something like the proposed Container block in a flexbox mode or something.

Change the value of a custom field

Change the value for a custom controller inside the block content

Those last two things are definitely something that belongs in a plugin, in my opinion.

ZebulanStanphill commented 6 years ago

- Show/hide blocks - Reorder blocks - Change some content - Change the value of a custom field - Change the value for a custom controller inside the block content
I'd argue that all of these are fundamentally anti-patterns, contrary to what responsive design is. Google explicitly expects consistent markup between all viewpoints. Storing and rendering multiple distinct representations of a block would have negative effects on SEO, performance, and complexity.

Showing/hiding and re-ordering blocks are not bad things if they are just visual, in my opinion. That said, only the former is common enough to warrant being in core.

Re-ordering blocks (assuming that is not just referring to the equivalent of flex-flow in CSS or something like that, which could be covered by settings in a Container block) is definitely something that is not going to be needed by anyone except an advanced user who probably knows how to use custom CSS to accomplish what he wants anyway. And even if not, a plugin could provide the needed functionality. I very seriously doubt this would be something needed in core.

rchipka commented 6 years ago

Anti-patterns

@chrisvanpatten As a systematic thinker and idealist, I completely agree with this philosophy.

That being said, these are all anti-patterns that I (and many others), for one reason or another, have at some point had to implement (hopefully in the best way possible).

Why? Because we're designing visual information interfaces for people, not for computers, and people have strange needs.

Divi, Gutenberg, etc. are all tools for people to design and build visual information interfaces, so these tools should (ideally) accommodate strange needs.

A hammer should work regardless of the nail or the way you swing it. Let's make a hammer.

SEO

At the end of the day, search engines want to drive results to well formatted, valuable information.

If your configuration reduces SEO, that's entirely your choice.

Block content

Controlling the actual content of a block responsively sounds like a bad idea in all but a few special cases.

Client or designer wants to remove extraneous text detail on mobile ("Call for an appointment" => "Call today" or phone icon)

Client or designer wants to resize WYSYWIG image on mobile.

Two random examples. I'm not saying either of these things should be done.

My only point is that if people are doing these things already, and we have the opportunity to easily provide people with this flexibility, why wouldn't we?

Block order

Re-ordering blocks semantically according to responsive breakpoints is a very bad idea, in my opinion. Re-ordering blocks is definitely something that is not going to be needed by anyone except an advanced user who probably knows how to use custom CSS to accomplish what he wants anyway.

This a great point and I completely agree.

Plugins

Those last two things are definitely something that belongs in a plugin

Your custom block setting isn't pluggable, now what? Your custom fields plugin doesn't implement responsive, now what? You install a Responsive block plugin and its styles and media queries conflict with existing responsive settings, now what?

chrisvanpatten commented 6 years ago

My only point is that if people are doing these things already, and we have the opportunity to easily provide people with this flexibility, why wouldn't we?

Because it's still possible to support these use-cases without supporting them in Core. Core support comes with the implicit suggestion that something is an acceptable practice. There may be specific use-cases where that's true, but in the majority of cases it is not true. It's important for Core to encourage best practices wherever possible.

If your configuration reduces SEO, that's entirely your choice.

I'd argue that most casual users of WordPress won't know that a certain choice would reduce their SEO, and I can't point to any users who wouldn't care about that, or be frustrated if WordPress didn't let them know that (and I can't imagine WordPress shipping with a user-facing feature and explicitly discouraging its use, although stranger things have happened).

rchipka commented 6 years ago

@chrisvanpatten This is a good outlook and I think a path to a decent compromise.

Even if the user-facing tools don't allow people to make bad choices out of the box, the underlying system should at least be structured in a way that gives a developer this power, but in a specific standardized way (like a core responsive controller).

Ideally this core responsive controller has a user interface (whether at root level or in the form of a block). This way a developer who wants to extend the default functionality has a clear idea of how/where to do it.

Why is responsive standardization so important?

For the same reason block CSS and stylesheet injection should be handled by Gutenberg directly. If everyone goes their own way with interfaces, classes, specificity, style injection, media queries, responsive breakpoints, etc. things just won't work.

rchipka commented 6 years ago

@chrisvanpatten

A "control everything distinctly at different breakpoints" approach is exactly what we were moving away from when dedicated mobile websites were pushed aside in favor of responsive design. Responsive design is better precisely because it's supposed to be easier; let the stylesheet decide how things filter down, so implementers don't have to worry about mapping content to different contexts.

From my perspective, control would still be given to the stylesheet for most situations.

A responsive setting is only needed in situations where the responsive view for a specific bit of content hasn't been accounted for in the stylesheet (perhaps it's not a common pattern).

These specific situations usually call for specific needs, since, after all, we didn't account for it in our stylesheet.

A user should have to ability to reasonably fulfill these specific needs.

The "responsive block" concept is intended to give the user more control in these situations.

In theory, it should actually improve our CSS since we can keep content-specific media query concerns out of the core CSS file and closer to the associated content.

karmatosed commented 6 years ago

Whilst I understand all the discussion a decision has been made to not have a responsive block as the first step here. I still stand by it isn't the route to go. Let's get the switch in as per mockup and then iterate from there.

@rchipka I would encourage you to explore your idea in a plugin, who knows it may help everyone seeing something like that and it could be useful for others. Right now though we're focusing not on this.

webmandesign commented 6 years ago

Hey guys, A small fix to make columns more responsive would be applying flex-wrap: wrap; styles on columns container. I've described this in #8975 and applied fix in #8979 Hope this helps a bit.

chrisvanpatten commented 6 years ago

flex-wrap definitely feels like the MVP approach here, while a UI with more control is sorted out for the future. Thanks @webmandesign!

kadencewp commented 6 years ago

I appreciated the discussion here, I am very interested in what core ends up with for columns. I used part of the mockup design from @karmatosed when implementing a row layout block https://wordpress.org/plugins/kadence-blocks/ perhaps not a perfect solution yet but something I thought might interest those as a block to test with that includes some responsive options for columns.

maddisondesigns commented 6 years ago

Just adding my 2 cents... In my own theme I simply add a media query and then set each column (.wp-block-columns) to display:block. Benefit being that it keeps all the columns a consistent size rather than having some wrap and some not wrapping.

@media only screen and (max-width: 767px) {
    .wp-block-columns {
        display: block;
    }
    .has-2-columns .wp-block-column,
    .has-3-columns .wp-block-column,
    .has-4-columns .wp-block-column,
    .has-5-columns .wp-block-column,
    .has-6-columns .wp-block-column {
        width: 100%;
    }
}

Vid: https://cl.ly/16b4d0ae58b5

lkraav commented 6 years ago

I'd be looking out for adopting an established UI kit / grid framework. Rolling yet another new one is probably not what the world needs.

Chris2011 commented 6 years ago

As I understand it right, was is correct, that the columns where implemented as css-grid and now with flex-box? It's kind of off-topic but css-grid has the appearance to make it responsive out of the box afaik. Why was it changed? I tried gutenberg in version 2.* and the rendered HTML was using css4-grid for the columns. What was the decission to change it?

andonette commented 6 years ago

i know it's mildly hacky but this helps: edit for widths as you see fit .wp-block-gallery .blocks-gallery-item { @media screen and (max-width: 600px) { width: calc(100% / 1 - 16px); } }

imagelucidity commented 6 years ago

Just adding my 2 cents... In my own theme I simply add a media query and then set each column (.wp-block-columns) to display:block. Benefit being that it keeps all the columns a consistent size rather than having some wrap and some not wrapping.
@media only screen and (max-width: 767px) {
  .wp-block-columns {
      display: block;
  }
  .has-2-columns .wp-block-column,
  .has-3-columns .wp-block-column,
  .has-4-columns .wp-block-column,
  .has-5-columns .wp-block-column,
  .has-6-columns .wp-block-column {
      width: 100%;
  }
}
Vid: https://cl.ly/16b4d0ae58b5

I used this method and it worked well for equal 2 column grid to become mobile responsive. I only specified display block and everything looks ok so far.

@media (max-width: 1140px) { .wp-block-columns { display: block; } }

rafafields commented 6 years ago

Hello there!

I have created a simple displaygrid column system using block classes in pure SCSS. I added few settings options in SCSS variables (just imagine them as block backend settings panel .)

Also, I added a secondary breakpoint where the number of columns become the half (only for even numbers). What do you guys think about this?

I hope it can help anyone :)

//Settings

$column-support: 12;
$breakpoint-lg: 1200px;
$breakpoint-md: 992px;
$vertical-alignment: center;
$gap: 2rem; 

//Column Block

.wp-block-columns{
    display: grid;
    column-gap: $gap;
    row-gap: $gap;
    align-items: $vertical-alignment;
}

// The grid

@for $i from 2 through $column-support{

    .wp-block-columns.has-#{$i}-columns{

        // Check if $i is even
        @if($i % 2 == 0){
          // Create a medium breakpoint grid only for even numbers of columns
          @media (min-width: $breakpoint-md){
            grid-template-columns: repeat( $i / 2, 1fr);
          }

        }
        // Main breakpoint for large screens
        @media (min-width: $breakpoint-lg){
            grid-template-columns: repeat( $i, 1fr);
        }
    }
}

Source: https://codepen.io/Rafafields/pen/QZwpyN

lkraav commented 6 years ago

Following up on https://github.com/WordPress/gutenberg/issues/6048#issuecomment-414708485 I'd recommend peeking at http://demo.kadencethemes.com/kadence-blocks/ for an impressive Gutenberg page building experience implementation all around, including columns cc @kadencethemes

xy0 commented 6 years ago

@rafafields It works for me right out of the box, thanks!

ZebulanStanphill commented 6 years ago

:tada::tada::tada::tada::tada::tada::tada::tada::tada::tada:

WordPress / gutenberg

Support for Responsive Columns #6048

Issue Overview

Related Issues and/or PRs

4900

4902

In an ideal world

There's no way to automatically give every block setting inline responsive controls

Even if we could

Then how could we configure responsive settings on all existing blocks?

More than just "block settings"

Anti-patterns

SEO

Block content

Block order

Plugins

Why is responsive standardization so important?