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

Add initial draft of container block #10562

Closed
wants to merge 8 commits into from

Conversation

chrisvanpatten
Copy link
Contributor

@chrisvanpatten chrisvanpatten commented Oct 12, 2018

Please see the newest notes/information here, potential reviewers!

Original description

This is an initial draft of a section block. It definitely needs polish. It's based on @mtias's comment here and supports the following options:

  1. wide and full alignment
  2. background colors
  3. …that's it

edit_page_ tomodomo wordpress_and_1__t___4___zsh__tmux

A few open questions:

  1. Text colors are sort of weird because you have to edit them at the paragraph level, and some blocks don't support text colors. Should this be a section-wide setting too?
  2. Should we also support left/right alignments?
  3. Is <div> the most appropriate element? We could also use <section> and perhaps adjust to <div> when using left/right align if we support that?
  4. new - I think we should add “anchor” support for this. I think that’d be cool

I recognise this has a ways to go so seriously treat this as an early early alpha/WIP/exploration ❤️

A few additional notes:

  1. This will greatly benefit from Adds the block hierarchy navigation menu to the header #10545, almost to the point where I'd consider that a prerequisite for this
  2. I know seeing this PR will get a lot of people excited but there's no guarantee this will get into 5.0 (I'd go so far as to say it's unlikely), so try not to get your hopes up 😅
  3. I haven't applied any styles here yet, although I think whatever styles we end up with can be pretty minimal — any major changes are likely changes that are fundamental to innerblocks in general.
  4. I also didn't pick a new icon; just reused Columns temporarily

@chrisvanpatten chrisvanpatten added [Type] Enhancement A suggestion for improvement. [Feature] Blocks Overall functionality of blocks [Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P labels Oct 12, 2018
PanelColorSettings,
} from '@wordpress/editor';

export const name = 'core/section';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "container" is a better name, since "section" implies the usage of a <section> element, but often you just want to use a simple container just to add a background to something that is not semantically a section. Issues to add color options to other blocks keep being rejected because of the assumption that a generic container block could accomplish the same thing. But if the block is limited to using the <section> element, then that limits its usage, unless you want to encourage bad semantics.

@ZebulanStanphill
Copy link
Member

First of all...

YES! WOO-HOO! IT'S HAPPENING! 🎈 🎉 🎆 👍 ❤️ 😄

Text colors are sort of weird because you have to edit them at the paragraph level, and some blocks don't support text colors. Should this be a section-wide setting too?

Issues to add text color options to the List block and other text-related blocks always seem to end up being closed because of the assumption that the Section/Container block would have text color options, I think. So yes, it should have text color options.

Should we also support left/right alignments?

I would say yes, because if this block is meant to act as a generic container, it would be useful to float things you normally could not.

Is <div> the most appropriate element? We could also use <section> and perhaps adjust to <div> when using left/right align if we support that?

I've said it before, but ideally a section/container block should have the ability to switch between using <div>, <section>, <aside>, or <header> as its HTML element. But if only one is available, it should be <div>, because that is the most flexible. Using <section> limits its functionality unless you want to encourage bad semantics.

@chrisvanpatten
Copy link
Contributor Author

YES! WOO-HOO! IT'S HAPPENING! 🎈 🎉 🎆 👍 ❤️ 😄

IT IS NOT NECESSARILY HAPPENING THIS IS JUST AN EXPLORATION 😂😁😇😅

(I hope it happens, but let's not get too excited just yet! Lots of problems to solve first!)

@ZebulanStanphill
Copy link
Member

Honestly, even if it got in exactly like it is right now, I would be pretty happy. All I ask for WordPress 5.0 is to have a generic container block. Even if it didn't have any background options it would still be useful for applying CSS classes to a group of blocks.

@mtias mtias added this to the 4.1 milestone Oct 13, 2018
@mtias mtias added the Needs Decision Needs a decision to be actionable or relevant label Oct 13, 2018
InspectorControls,
InnerBlocks,
PanelColorSettings,
} from '@wordpress/editor';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a nitpick, but could the imports be put in alphabetical order?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ZebulanStanphill I’m waiting to get some feedback on the UX but if we determine to move forward I have a lot of tweaks I’ll make to the code itself. Thanks :)

@slimmilkduds
Copy link

In my world,
#9278 needs to be fixed asap if this is added, there will be way more cases of people using reusable templates with this nested block if it’s in core which will be frustrating when it breaks.

@chrisvanpatten
Copy link
Contributor Author

chrisvanpatten commented Oct 14, 2018

I renamed the block as container. It would be easy for us to add additional "tag" options in the future, but going with <div> for now allows us to be semantically neutral and still gives users the benefits of grouping blocks.

In my opinion, it would be good to sort out the following before committing this to 5.0:

  • I agree 100% with @slimmilkduds that Reusable Blocks: Convert to Regular Block does not preserve nested blocks #9278 is a blocker, both for this block and for all nested blocks.
  • I think a "Group blocks in container" option would be very useful in the multi-select "More" menu and would help expose this feature a little more. (I explored a bit today and it's definitely possible; I just need to write up the code.)
  • Decision on text color attribute. I think it makes sense, but I can say from experience (building a similar block with text color support) that this is going to expose some block CSS specificity issues that we would need to work out.

A few smaller things:

  • When you insert this block, the Container itself doesn't get focus: the paragraph inside does. This is by design for writing flow reasons but doesn't make a ton of sense in my opinion. I don't think it should necessarily block this, but it definitely should be considered.
  • Is it possible to use the alternate appender even when Paragraph is an available block? I think that appender would make more sense here.
  • Align left/right? I'm ambivalent on these. I think it makes sense but it's also much easier to remove an option than to add an option.

EDIT: To clarify a bit: I think the next step is to get some reviews on whether we even like the experience of this block right now. It shouldn't be hard to solve some of these other concerns, if it's worth continuing the exploration.

If it's not worth continuing, we can table this and revisit as part of the Phase 2 work!

@ZebulanStanphill
Copy link
Member

new - I think we should add “anchor” support for this. I think that’d be cool

I agree.

I agree 100% with @slimmilkduds that #9278 is a blocker, both for this block and for all nested blocks.

Ditto. I've had to deal with this issue before and it is pretty annoying. I would definitely consider it a blocker for WP 5.0.

Decision on text color attribute. I think it makes sense, but I can say from experience (building a similar block with text color support) that this is going to expose some block CSS specificity issues that we would need to work out.

This is probably a good thing to work out before 5.0 since people are going to be making themes that override base Gutenberg styles, and ideally the base styles should be as unspecific as possible so that the theme styles also don't end up overriding per-container styles. If this gets fixed later, then theme-provided editor styles made before the change may still have the issue.

I think a "Group blocks in container" option would be very useful in the multi-select "More" menu and would help expose this feature a little more. (I explored a bit today and it's definitely possible; I just need to write up the code.)

This sounds like a neat idea to me.

When you insert this block, the Container itself doesn't get focus: the paragraph inside does. This is by design for writing flow reasons but doesn't make a ton of sense in my opinion. I don't think it should necessarily block this, but it definitely should be considered.

Is it possible to use the alternate appender even when Paragraph is an available block? I think that appender would make more sense here.

That sounds like it could be a good idea. Note also the ideas for inserter revisions in #10519.

Align left/right? I'm ambivalent on these. I think it makes sense but it's also much easier to remove an option than to add an option.

Personally I think adding them is fine, though I'm fine with them not being added. Perhaps it would be best to wait and see how many people would want those alignments to be available.

Here are some features I think this block should have. Not necessarily for WP 5.0, but definitely at some point later on:

  • Padding options are pretty much a must-have for a container block. I think every single container-like block I've seen in plugins has them. Every page builder has them and tends to show them off in advertisements. Bonus points if you can switch between px and em units and can optionally lock horizontal/vertical padding values together. I highly recommend checking out the Divi Visual Builder UI for padding options (and just options in genera). There are tons of little usability enhancements that make them really nice to use. If Gutenberg can replicate some of that, it can make the customization experience way nicer. Also, while all the Gutenberg plugin blocks I have seen so far use sliders for padding values, I think something else (a visual representation of a box with inputs on each side?) would be better (keeping in mind accessibility, of course).
  • Margin options are probably also a must-have, but not quite as much as padding.
  • If you are going to have background options, you should probably include background images. Yes, I know this overlaps with the proposed Cover block using nesting, but perhaps that means there shouldn't be a Cover block. After all, if you added nesting to the Cover Image block, wouldn't it just end up being a container block anyway? The current background color option would double as an overlay color (much like the current Cover Image block), and background image options should include the ability to choose the source (full, large, thumbnail, etc.), position (top left, center right, etc.) and sizing (cover/contain/etc.). The option to have a parallax background image should probably be thrown in as well, since the Cover Image block has it. The background image options should be hidden until a background image is uploaded.
  • Gradient backgrounds. Divi has this feature, and I use it a lot, such as on my website. As you can see on my site, I am using the feature along with background images to get a neat stylistic effect. Gradient options for direction, start/stop points, and things like that should only be shown when a gradient background is enabled. A button to flip the primary and secondary gradient color would also be handy.
  • While not nearly as common, and of course useless to mobile, video backgrounds are a thing, and pretty much every page builder I know of supports them. This block could support those as well, though I don't see this being anywhere near as useful as the other features I have mentioned.
  • Vertical alignment. This is a tricky one to implement, since the best way to do it involves using CSS Flex, but that prevents floats from being used within the container.

For reference/inspiration, here are all the WordPress plugins I know of that implement a container-esque block:

And here are some links to page builder plugin demos to get some inspiration from how they implement sections and their settings:

They don't have demos, but Elementor (which has a free version) and especially Oxygen are worth checking out as well.

@mcsf
Copy link
Contributor

mcsf commented Oct 15, 2018

@chrisvanpatten: as the PR title reads "WIP", let us know when you'd like more reviews.

@chrisvanpatten
Copy link
Contributor Author

@mcsf I'm interested in conceptual reviews at this point — is the UX good enough/is there enough value to continue? Perhaps a "Needs Design Feedback" tag would be appropriate at this stage? Happy to remove WIP as well if you feel it's appropriate.

@chrisvanpatten
Copy link
Contributor Author

(That is to say I'm not looking for a super thorough review at this point, just a "yes, we like what we see, please keep iterating" at this stage. I'm totally happy to keep iterating, but with so many other things going on I just want to make sure we're on the right track before sinking too much time into this!)

@mcsf
Copy link
Contributor

mcsf commented Oct 15, 2018

I think we should add “anchor” support for this.

I think that's important, let's.

Text colors are sort of weird because you have to edit them at the paragraph level, and some blocks don't support text colors. Should this be a section-wide setting too? / Should we also support left/right alignments?

#7635 would solve this for us, but it's not going to make 5.0, I think. Re alignment, my personal inclination is to not add anything. I'm not sure about how to handle color.

is the UX good enough/is there enough value to continue? Perhaps a "Needs Design Feedback" tag would be appropriate at this stage? Happy to remove WIP as well if you feel it's appropriate.

All good ideas, we can add the label and remove the WIP prefix.

That is to say I'm not looking for a super thorough review at this point, just a "yes, we like what we see, please keep iterating" at this stage.

Yeah, I think this is worth pursuing. How available are you in the next days, if we had 4.1 in mind for this? The mantra is clearly to keep it simple. :)

@chrisvanpatten
Copy link
Contributor Author

@mcsf I feel pretty confident that we can have something ready to ship with 4.1!

@chrisvanpatten chrisvanpatten changed the title WIP: Add initial draft of section block Add initial draft of container block Oct 15, 2018
@chrisvanpatten
Copy link
Contributor Author

Okay, I've updated this block and think we're ready for a formal review.

What's in this PR:

  • This PR adds a simple container block
  • Container provides options for…
    • Wide align
    • Full align
    • Text color
    • Background color
    • Anchor
    • Custom class names

I did add the text color attribute, and was able to work around the cascade issue with a well-placed inherit. This is a hack but the cascade issue should be resolved separately.

Screenshot

edit_page_ tomodomo _wordpress

What's not in this PR

I didn't add a "Group in Container Block" settings menu item, although I still think this would be valuable (just juggling priorities on my end).

I would love to see someone else pick that up, but I think it's also okay to punt that until post 5.0, when container blocks would presumably be more thoroughly addressed.



Okay, with that said… review me! 🚀

@chrisvanpatten chrisvanpatten requested a review from a team October 16, 2018 15:27
@chrisvanpatten
Copy link
Contributor Author

Oh, I think I might need some help generating fixtures for the test suite. My testing skills are not quite up to snuff 🙈

/* translators: Block title modifier */
__( '%1$s (%2$s)' ),
__( 'Container' ),
__( 'beta' )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the UI freeze a block freeze? In which case, I don't think we should want anything "beta"-denoted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch 👍

@@ -0,0 +1,5 @@
.wp-block-container .editor-block-list__block {
// We need to enforce a cascade by telling nested blocks to inherit
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is there a color otherwise being assigned that is breaking the default cascade? It's not clear to me that this should be needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aduth See my comment here: #10067 (comment)

We map body to .editor-block-list__block inside editor-styles.scss which means each block resets the cascade for these properties.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a bit unfortunate 😕 But OK 👍

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed we should refactor the editor styles to apply to the editor container. The downside though is that it can affect the UI bits (toolbars, movers...) so we need to be careful there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I almost wonder if there's a way to do a forced reset for Gutenberg chrome? Something to ponder for the future but for now this works :)

[ textColor.class ]: textColor.class,
} ) }
style={ {
backgroundColor: backgroundColor.color,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the inline styles be necessary? Why isn't it enough to assign the color classes?

(Maybe this is a known limitation, but at a high-level it feels wrong)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aduth if someone picks a custom color, it has to be applied via style. I just copied this over from the paragraph block.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So then what's the purpose of the class name being assigned?

Again, not particularly directed at you or this block, maybe more a general issue we have with colors assignment.

Copy link
Contributor Author

@chrisvanpatten chrisvanpatten Oct 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aduth If you pick one of the colors in the palette, it assigns a class. If you pick a color outside the palette, it applies a style.

This is the rendered HTML for a block using the default red/light gray colors:

<div class="wp-block-container has-background has-text-color has-vivid-red-background-color has-very-light-gray-color">
<p>Container, Paragraph One</p>
<p>Container, Paragraph Two</p>
</div>

Vs this rendered HTML from the same block using two custom colors selected via the color picker popover:

<div class="wp-block-container has-background has-text-color" style="background-color:#2eaacf;color:#ffffff">
<p>Container, Paragraph One</p>
<p>Container, Paragraph Two</p>
</div>

I'm not quite sure how this magic works, but it does 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aduth Oh I see you're referring to the edit representation of the block, not the front-end version, and that's a great question. I'll take a closer look.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pushing up a commit to fix this. I can open a separate PR to do this for the paragraph block as well.

@@ -0,0 +1,5 @@
.wp-block-container {
// 1px top/bottom padding allows us to prevent margin collapsing while
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does margin collapse happen on the front-end, or is this meant to offset the editor styles? If the latter, should we then include this only in an editor-specific stylesheet?

Copy link
Contributor Author

@chrisvanpatten chrisvanpatten Oct 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Front and back-end, but in my testing it was good/necessary for both cases.

@aduth
Copy link
Member

aduth commented Oct 16, 2018

Oh, I think I might need some help generating fixtures for the test suite. My testing skills are not quite up to snuff 🙈

You'll need to add a core__container.html to test/integration/full-content/fixtures/ containing a snippet of expected saved content for the block, then run npm run fixtures:regenerate.

@chrisvanpatten
Copy link
Contributor Author

Okay we are now officially passing! ✅

@ZebulanStanphill
Copy link
Member

Whoops, posted in the wrong issue. 😛

Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise this looks good 👍

@chrisvanpatten chrisvanpatten added the Needs Design Feedback Needs general design feedback. label Oct 17, 2018
@chrisvanpatten
Copy link
Contributor Author

Tagged for needs design feedback but also still needs decision… under the wire, this one ;-)

@karmatosed
Copy link
Member

karmatosed commented Oct 17, 2018

I had a little explore around this and a few bits of feedback.

  • I found the + button being to the right a little weird. What is reason behind not putting it to left?
  • I was unable easily to keyboard out of the container, it got really messy with multiple paragraphs being added. I'd say having easy exit is important.
  • Removing blocks in container is also a weird experience. I have to delete with mouse and that's not something because of ways you can remove outside, that I expected.
  • The 'jumping' of blocks like gallery next to say a list when you click in and see 'upload image' is jarring. I don't think we can do anything about that though.
  • Container in container is incredibly hard to work out what background you are interacting with for color.
  • I can easily loose the '+' depending on backgrounds, it got really weird at one point.

That said, I feel this could be good to push on with accepting it need some polish. The idea I like, it's just feeling a little like needs some iterations.

I would like an a11y review to be super sure though as I have my doubts as this gets complicated with blocks in blocks. I could be worrying about nothing but for me it got intense :) @tofumatt can you give a little look here please?

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Oct 17, 2018
@tofumatt tofumatt added [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility labels Oct 17, 2018
@chrisvanpatten
Copy link
Contributor Author

chrisvanpatten commented Oct 17, 2018

Thanks @karmatosed!

The UI right now is just the standard/default UI for nested blocks — I made almost no changes otherwise.

If those concerns are blockers (and totally fair if so) then we need to sort out a few questions:

  1. Is there currently a way this, or any individual block, can override the standard nesting UI design?
  2. Are one-off exceptions to the standard UI design acceptable? Is that a practice we want to encourage?
  3. Are there any "quick wins" available to us to work through these issues?
  4. Are we really dealing with bigger problems with the nesting UI that this block is just exposing?
  5. Are those problems better dealt with in Phase 2?

I totally understand if we need to punt this block — I obviously tried to set that expectation up front in my original comment! — just need a bit of high level direction so we can decide whether or not to move forward.

@karmatosed
Copy link
Member

@chrisvanpatten thanks for comments and I really appreciate you getting this in. Whilst it does use nested blocks with the coloring options and complexities added this exposes some issues.

Are there any "quick wins" available to us to work through these issues?

I think yes :) We could tackle the color issues and problems finding the + when a background for example.

Are those problems better dealt with in Phase 2?

Right now this is where I am leaning towards. I understand the push here but perhaps thinking about how this works in that phase is the right approach. That said, I am willing to be convinced we just have this block in and iterate for that phase.

@mtias and @jasmussen going to tag you in here as for me I am very much happy either way. As you are leading phase two @alexislloyd and @youknowriad, going to also loop you in for insight as this flows into that.

@jasmussen
Copy link
Contributor

I'm commenting from afar so take my thoughts in that light. I also don't have strong opinions.

In an ideal scenario to me, you can colorize the background, perhaps even the text. Choose whether there's padding or not, and have the benefit of the contrast checker.

On the flip side, I used to think it was enough with a container that did zilch. Simply because it would allow you to group other blocks together and then perhaps make the container reusable. But since you can do this already without a container now, perhaps the bar is raised.

What is the sweet spot? What is enough for a user that inserts this block to get an idea what the point is? I don't know, and perhaps that's not the deciding factor either?

Maybe the fact that we know we want it is sufficient?

I know @kjellr mentioned having this block, I imagine he could field a positive argument for having this.

@sarahmonster
Copy link
Member

I ❤️ this block and would fully endorse it—this is really integral to building some of the super-common layouts that sites are building these days. Combining this block with the columns block would be really 💯 (or just building support for a few columns into this block), since that's likely to be a pretty popular request.

There are definitely some issues with CSS specificity, especially when child blocks use a placeholder:

screenshot 2018-10-18 11 06 56

I imagine this is a bit of a pain to work with if there aren't CSS selectors specific to content vs. UI. (Perhaps we could add some?)

@ZebulanStanphill
Copy link
Member

@jasmussen

In an ideal scenario to me, you can colorize the background, perhaps even the text. Choose whether there's padding or not, and have the benefit of the contrast checker.

My ideal scenario is somewhat more advanced. I picture the ability to choose a background color or gradient, as well as an image or video to appear beneath it. I think custom padding should be allowed, as should custom margins, though presets could be available and perhaps themes could disable showing the custom option. For the sake of being able to use Gutenberg as a fully-semantic site builder, the ability to choose between using a <div> or <section> is essential.

It would also be really nice if there were vertical and horizontal alignment options like what Oxygen has, but since they involve using Flex, that would make you unable to use floats. In the past, I've considered that perhaps the Container block could have a toggle to switch between using the standard display: block or the more powerful (but doesn't work with floats) display: flex, but that sounds kind of funky, so I'm now leaning more towards there being a separate Flexible Layout block or something that provides those options in addition to what the Container block would have.

@sarahmonster

(or just building support for a few columns into this block)

I would prefer to avoid this. I forsee the Container block potentially having a lot of options: background color/image/video/gradient, padding, margin, perhaps even HTML tag selection. Adding columns support would be too much. Additionally, I imagine the Container block could function as an alternative, non-column-based layout block in the future. You can use CSS Flex to arrange things horizontally in a simple way that doesn't require columns, and you could have vertical and horizontal alignment options that make building layouts really nice, and don't use tons of nested <div>s like most column-based systems would.

I recommend checking out how Oxygen does layouts. It is very nice and very impressive. They have a Columns element, but its really secondary to the standard Flex layout options that are provided.

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

Notably, I think the Columns block could also have background and text options, but I don't see it as being that necessary since you can simply nest a Columns in a Container. I see the Container block as a more lightweight and no-columns alternative to the Columns block for layouts.

Essentially, I think Gutenberg should try to avoid becoming too column-based in its layout options. I think the future of page building involves more Flex or even Grid-based layouts than <div>-columns. I don't want to see Gutenberg end up having the same issue as Beaver Builder, Divi, and Elementor where columns end up being used just for having a couple of buttons next to each other, when it would be much cleaner in both HTML and CSS to use a Flex-based system (like Oxygen) to do the same thing.

@chrisvanpatten
Copy link
Contributor Author

Thanks for the thoughts everyone!

I think at this point there are too many open questions and issues to make this viable for 5.0. I think this feels more like a phase two challenge.

Unless there are any strong objections from the leads, I think this PR should be closed. During phase two, once we’ve all had time to breathe, we can start fresh and approach it from the ground up.

Sound good?

@ZebulanStanphill
Copy link
Member

Personally, I think a lot of the issues with implementing the Container block as-is right now stem from UI/UX problems that really should be fixed before WP 5.0 rather than after, but if those issues aren't going to be fixed before WP 5.0, then I guess this block shouldn't come until after WP 5.0 as well. 😞

@youknowriad youknowriad removed this from the 4.1 - UI freeze milestone Oct 19, 2018
@youknowriad
Copy link
Contributor

I removed from 4.1. It doesn't seem like it can be ready for it.

@youknowriad youknowriad reopened this Oct 19, 2018
@youknowriad
Copy link
Contributor

(close and comment and comment buttons are too close :P )

@chrisvanpatten
Copy link
Contributor Author

Hi everyone! I'm going to close this out. Thanks for all the great feedback. A bummer this didn't make the cut, but I'm excited to revisit this in Phase 2 with a little more time for exploration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks [Feature] Nested / Inner Blocks Anything related to the experience of nested/inner blocks inside a larger container, like Group or P [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Needs Accessibility Feedback Need input from accessibility Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.