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 Block: Section #4900

Open
melchoyce opened this Issue Feb 6, 2018 · 100 comments

Comments

Projects
None yet
@melchoyce

melchoyce commented Feb 6, 2018

Now that we have official support for nesting as of #3745, let's consider adding a Section block that can act as a generic block container.

section-block

This block would have the following settings:

  • Columns.
  • Background image, color, and color dimness (so you can overlay transparent colors over your image), along with a fixed background toggle.
  • Text color.
  • Wide or Full-Width block alignment.

@melchoyce melchoyce added the Blocks label Feb 6, 2018

@karmatosed

This comment has been minimized.

Show comment
Hide comment
@karmatosed

karmatosed Feb 6, 2018

Member

I really like this idea! I also like fact it has a background setting to it.

Member

karmatosed commented Feb 6, 2018

I really like this idea! I also like fact it has a background setting to it.

@karmatosed karmatosed added this to the 2.3 milestone Feb 6, 2018

@motleydev

This comment has been minimized.

Show comment
Hide comment
@motleydev

motleydev Feb 7, 2018

Contributor

Nice! What if the block allowed the three following 'advanced' settings:

  • Define a class-name to be serialized onto the children .child_class, .child_class_1
  • Add an optional first child class .child_class, .child_class_1, .child_class_first
  • Add an optional last child class .child_class, .child_class_n, .child_class_last

:nth-child selectors may be able to compensate for the last two, but I think adding a class to all children could be useful in certain contexts.

Contributor

motleydev commented Feb 7, 2018

Nice! What if the block allowed the three following 'advanced' settings:

  • Define a class-name to be serialized onto the children .child_class, .child_class_1
  • Add an optional first child class .child_class, .child_class_1, .child_class_first
  • Add an optional last child class .child_class, .child_class_n, .child_class_last

:nth-child selectors may be able to compensate for the last two, but I think adding a class to all children could be useful in certain contexts.

@tomusborne

This comment has been minimized.

Show comment
Hide comment
@tomusborne

tomusborne Feb 8, 2018

Love this idea. If background and text colors can be altered, it might make sense to add link colors as well.

tomusborne commented Feb 8, 2018

Love this idea. If background and text colors can be altered, it might make sense to add link colors as well.

@munirkamal

This comment has been minimized.

Show comment
Hide comment
@munirkamal

munirkamal Feb 16, 2018

Contributor

Excellent Idea. This will literally add much value to Gutenberg Editor.

Contributor

munirkamal commented Feb 16, 2018

Excellent Idea. This will literally add much value to Gutenberg Editor.

@hedgefield

This comment has been minimized.

Show comment
Hide comment
@hedgefield

hedgefield Feb 21, 2018

Much better than just the Columns block, which has a lot of issues. Cool!

hedgefield commented Feb 21, 2018

Much better than just the Columns block, which has a lot of issues. Cool!

@jvisick

This comment has been minimized.

Show comment
Hide comment
@jvisick

jvisick Feb 21, 2018

Contributor

This is the first thing I set out to create when I saw that nesting was available. My version is similar except I envisioned that you would add the columns block into it.

screen shot 2018-02-21 at 11 06 55 am

Do you have code for this available?

Contributor

jvisick commented Feb 21, 2018

This is the first thing I set out to create when I saw that nesting was available. My version is similar except I envisioned that you would add the columns block into it.

screen shot 2018-02-21 at 11 06 55 am

Do you have code for this available?

@youknowriad

This comment has been minimized.

Show comment
Hide comment
@youknowriad

youknowriad Feb 22, 2018

Contributor

If this block has "columns", we should just update the "columns" block. But it's still possible to use a columns block inside a section block and keep the section block columnless.

Contributor

youknowriad commented Feb 22, 2018

If this block has "columns", we should just update the "columns" block. But it's still possible to use a columns block inside a section block and keep the section block columnless.

@hedgefield

This comment has been minimized.

Show comment
Hide comment
@hedgefield

hedgefield Feb 22, 2018

As long as you can't put column blocks inside column blocks 😉

hedgefield commented Feb 22, 2018

As long as you can't put column blocks inside column blocks 😉

@jvisick

This comment has been minimized.

Show comment
Hide comment
@jvisick

jvisick Feb 23, 2018

Contributor

A lot of site pages are broken up into sections that has mixed content with multiple rows of columns and often columns nested inside larger ones. This is a quick example:

screen shot 2018-02-23 at 12 47 53 pm

A section block that just acts like a bare wrapper I think would be the most flexible. (as would being able to nest column blocks!)

We've kicked off a new site project this week. Normally it would be built with with Advanced Custom Fields flexible content layouts but I'm going to see how far we can get using Gutenberg alone.

Contributor

jvisick commented Feb 23, 2018

A lot of site pages are broken up into sections that has mixed content with multiple rows of columns and often columns nested inside larger ones. This is a quick example:

screen shot 2018-02-23 at 12 47 53 pm

A section block that just acts like a bare wrapper I think would be the most flexible. (as would being able to nest column blocks!)

We've kicked off a new site project this week. Normally it would be built with with Advanced Custom Fields flexible content layouts but I'm going to see how far we can get using Gutenberg alone.

@melchoyce

This comment has been minimized.

Show comment
Hide comment
@melchoyce

melchoyce Feb 23, 2018

Yeah, I think multi-column sections like @jvisick's above example aren't uncommon. A container with background/text options that nests blocks would be the most flexible approach. Since we now have a functioning column block, we could even consider taking out the column option from this.

melchoyce commented Feb 23, 2018

Yeah, I think multi-column sections like @jvisick's above example aren't uncommon. A container with background/text options that nests blocks would be the most flexible approach. Since we now have a functioning column block, we could even consider taking out the column option from this.

@aduth aduth modified the milestones: 2.3, 2.4 Mar 1, 2018

@fabianpimminger

This comment has been minimized.

Show comment
Hide comment
@fabianpimminger

fabianpimminger Mar 5, 2018

Contributor

It would be great if there is an inner-container (div) in this block which then contains all the child blocks. This container could then be styled with max-width and margin-left/right: auto to center the child blocks and have a full-width background.

Contributor

fabianpimminger commented Mar 5, 2018

It would be great if there is an inner-container (div) in this block which then contains all the child blocks. This container could then be styled with max-width and margin-left/right: auto to center the child blocks and have a full-width background.

@jvisick

This comment has been minimized.

Show comment
Hide comment
@jvisick

jvisick Mar 6, 2018

Contributor

Having a fullwidth section with the content contained to a narrower layout is a common design pattern. I'm wondering if it would be best controlled by the nested blocks rather than baked into the parent section block?

Contributor

jvisick commented Mar 6, 2018

Having a fullwidth section with the content contained to a narrower layout is a common design pattern. I'm wondering if it would be best controlled by the nested blocks rather than baked into the parent section block?

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Apr 5, 2018

Contributor

I think a section block would be very useful for... well, sections on a page, and I agree that columns should be a separate block (like the one that exists now) that can be nested in a section block. I think this is something that, along with the Columns block, should be included in the version of Gutenberg that is merged into WordPress 5.0. If you look at existing page builder plugins, sections are used a lot, as are columns (obviously), so including them in the initial core release is essential in my opinion.

(I also think it is important that the columns block gets features like variable-width columns and responsive columns, both for the sake of the core experience as well as making it easier for existing page builders to re-base themselves off of Gutenberg, but that is a separate issue.)

Contributor

ZebulanStanphill commented Apr 5, 2018

I think a section block would be very useful for... well, sections on a page, and I agree that columns should be a separate block (like the one that exists now) that can be nested in a section block. I think this is something that, along with the Columns block, should be included in the version of Gutenberg that is merged into WordPress 5.0. If you look at existing page builder plugins, sections are used a lot, as are columns (obviously), so including them in the initial core release is essential in my opinion.

(I also think it is important that the columns block gets features like variable-width columns and responsive columns, both for the sake of the core experience as well as making it easier for existing page builders to re-base themselves off of Gutenberg, but that is a separate issue.)

@JiveDig

This comment has been minimized.

Show comment
Hide comment
@JiveDig

JiveDig Oct 12, 2018

I think the main issue is that currently Gutenberg is very limited to standard post/page content. Without a Section/Container block we have no way to allow users to build front pages with full width sections (with background solid/gradient color or full width background image) with all sorts of content inside (hopefully via nested blocks).

A section/container block would be perfect here. Even a basic one that could be extended with more controls by themes/plugins. I'd love to get some more alignment settings in there as well. We're already doing something with CMB to have a pseudo-page builder right on pages, but really hope Gutenberg can make this all more flexible for everyone.

JiveDig commented Oct 12, 2018

I think the main issue is that currently Gutenberg is very limited to standard post/page content. Without a Section/Container block we have no way to allow users to build front pages with full width sections (with background solid/gradient color or full width background image) with all sorts of content inside (hopefully via nested blocks).

A section/container block would be perfect here. Even a basic one that could be extended with more controls by themes/plugins. I'd love to get some more alignment settings in there as well. We're already doing something with CMB to have a pseudo-page builder right on pages, but really hope Gutenberg can make this all more flexible for everyone.

@rchipka

This comment has been minimized.

Show comment
Hide comment
@rchipka

rchipka Oct 12, 2018

@JiveDig I don't think anyone, including the Gutenberg team, is opposed to some sort of block container mechanism.

The main hesitation from the Gutenberg team (in this case and many others) is to keep the core interface down to a Squarespace level of complexity from a UI/UX standpoint.

In order to get this implemented in core, it seems the primary issue is finding a way that this can be represented without putting an extra burden on the end users.

Although, in my opinion, it doesn't seem like a big deal, a "Container Block" does place a small burden on the end user by requiring knowledge of its purpose and its usage.

That's why I proposed the concept of "grouping" as a more approachable analogy to "containers" for end users.

The end user wouldn't think in terms of wrapping blocks in containers and would instead think in terms of grouping blocks together, which seems more intuitive.

This way, the end user doesn't need to know anything ahead of time in order to group together blocks and apply settings to that group.

Of course, these "groups" would function exactly like a Container block internally, it's just a more integrated and intuitive front end interface.

rchipka commented Oct 12, 2018

@JiveDig I don't think anyone, including the Gutenberg team, is opposed to some sort of block container mechanism.

The main hesitation from the Gutenberg team (in this case and many others) is to keep the core interface down to a Squarespace level of complexity from a UI/UX standpoint.

In order to get this implemented in core, it seems the primary issue is finding a way that this can be represented without putting an extra burden on the end users.

Although, in my opinion, it doesn't seem like a big deal, a "Container Block" does place a small burden on the end user by requiring knowledge of its purpose and its usage.

That's why I proposed the concept of "grouping" as a more approachable analogy to "containers" for end users.

The end user wouldn't think in terms of wrapping blocks in containers and would instead think in terms of grouping blocks together, which seems more intuitive.

This way, the end user doesn't need to know anything ahead of time in order to group together blocks and apply settings to that group.

Of course, these "groups" would function exactly like a Container block internally, it's just a more integrated and intuitive front end interface.

@chrisvanpatten

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Oct 12, 2018

Contributor

@rchipka A very easy way to approach that would be the ability to select one or more blocks and click a "Move selected block(s) into Container block" option in the "more" menu. This way blocks don't need an additional settings panel.

Contributor

chrisvanpatten commented Oct 12, 2018

@rchipka A very easy way to approach that would be the ability to select one or more blocks and click a "Move selected block(s) into Container block" option in the "more" menu. This way blocks don't need an additional settings panel.

@wmodes

This comment has been minimized.

Show comment
Hide comment
@wmodes

wmodes Oct 12, 2018

wmodes commented Oct 12, 2018

@wmodes

This comment has been minimized.

Show comment
Hide comment
@wmodes

wmodes Oct 12, 2018

wmodes commented Oct 12, 2018

@wmodes

This comment has been minimized.

Show comment
Hide comment
@wmodes

wmodes Oct 12, 2018

wmodes commented Oct 12, 2018

@rchipka

This comment has been minimized.

Show comment
Hide comment
@rchipka

rchipka Oct 12, 2018

@chrisvanpatten I agree, however this solution does not adequately address @mtias's original concern of exposing the concept of a Container or Section to the end user.

The issue, as raised by @mtias, is not about the logistics of putting blocks into a container, but rather intuitively presenting that interface to the end user (without exposing additional block types).

rchipka commented Oct 12, 2018

@chrisvanpatten I agree, however this solution does not adequately address @mtias's original concern of exposing the concept of a Container or Section to the end user.

The issue, as raised by @mtias, is not about the logistics of putting blocks into a container, but rather intuitively presenting that interface to the end user (without exposing additional block types).

@JiveDig

This comment has been minimized.

Show comment
Hide comment
@JiveDig

JiveDig Oct 12, 2018

The "how we get blocks into a container" discussion is necessary. However, i don't necessarily see it being overly complex to a user. Many users won't use it, or at least won't use it outside of their home page. Many of our clients and theme customers express their websites wants/needs in visual terms fitting for a Section block. They say things like, "I want a big full width {bar/area/section/block/panel/span} with a pretty image" followed by, "and {insert content requests here} in that section". They visually understand the section itself (the container) is separate from the content inside it.

Granted, how to do it via the UI needs to get worked out, but hopefully my above point makes sense.

JiveDig commented Oct 12, 2018

The "how we get blocks into a container" discussion is necessary. However, i don't necessarily see it being overly complex to a user. Many users won't use it, or at least won't use it outside of their home page. Many of our clients and theme customers express their websites wants/needs in visual terms fitting for a Section block. They say things like, "I want a big full width {bar/area/section/block/panel/span} with a pretty image" followed by, "and {insert content requests here} in that section". They visually understand the section itself (the container) is separate from the content inside it.

Granted, how to do it via the UI needs to get worked out, but hopefully my above point makes sense.

@rchipka

This comment has been minimized.

Show comment
Hide comment
@rchipka

rchipka Oct 12, 2018

@chrisvanpatten My previous statement is based solely on the semantics of the block types.

The only reason I'm arguing semantics here is on behalf of @mtias, as there was an issue raised with the complexity exposing these semantics in the first place.

I like your suggestion, but if I'm following my analogy, perhaps I'd change the semantics "Group selected block(s)".

rchipka commented Oct 12, 2018

@chrisvanpatten My previous statement is based solely on the semantics of the block types.

The only reason I'm arguing semantics here is on behalf of @mtias, as there was an issue raised with the complexity exposing these semantics in the first place.

I like your suggestion, but if I'm following my analogy, perhaps I'd change the semantics "Group selected block(s)".

@chrisvanpatten

This comment has been minimized.

Show comment
Hide comment
@chrisvanpatten

chrisvanpatten Oct 12, 2018

Contributor

@rchipka that’s not how I interpreted his comment - I took it to mean that the proposed block would need to be simple, but would still need to be itself a block (if it is to be an InnerBlocks area, that has to be enclosed in a block). Perhaps there’s a way to hide it from the inserter and only have container blocks created by selecting multiple blocks and providing a “place in container” option but based on my understanding of the system that would still mean a dedicated block.

That said I am more than happy to be wrong :)

Contributor

chrisvanpatten commented Oct 12, 2018

@rchipka that’s not how I interpreted his comment - I took it to mean that the proposed block would need to be simple, but would still need to be itself a block (if it is to be an InnerBlocks area, that has to be enclosed in a block). Perhaps there’s a way to hide it from the inserter and only have container blocks created by selecting multiple blocks and providing a “place in container” option but based on my understanding of the system that would still mean a dedicated block.

That said I am more than happy to be wrong :)

@rchipka

This comment has been minimized.

Show comment
Hide comment
@rchipka

rchipka Oct 12, 2018

@JiveDig I very much agree....

However, the Gutenberg team seems to be highly sensitive to exposing these things to the end user in Gutenberg core.

This is my only basis for raising these arguments and presenting these ideas.

Again, if it were me, we'd just have the damn container block.

rchipka commented Oct 12, 2018

@JiveDig I very much agree....

However, the Gutenberg team seems to be highly sensitive to exposing these things to the end user in Gutenberg core.

This is my only basis for raising these arguments and presenting these ideas.

Again, if it were me, we'd just have the damn container block.

@rwrobe

This comment has been minimized.

Show comment
Hide comment
@rwrobe

rwrobe Oct 12, 2018

I don't think a container block really even makes sense, as it would clutter the UI. I would rather see something like the "Section Break" marker you see inline on Microsoft Word. Adding a section break would offer some style options in the inspector like a classname for the section, background color, text color, drop shadow, whatever it is that stylistically defines your section. It could be inserted like any block and moved around like any block.

rwrobe commented Oct 12, 2018

I don't think a container block really even makes sense, as it would clutter the UI. I would rather see something like the "Section Break" marker you see inline on Microsoft Word. Adding a section break would offer some style options in the inspector like a classname for the section, background color, text color, drop shadow, whatever it is that stylistically defines your section. It could be inserted like any block and moved around like any block.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Oct 12, 2018

Contributor

@rwrobe That idea doesn't work for nested containers.

Contributor

ZebulanStanphill commented Oct 12, 2018

@rwrobe That idea doesn't work for nested containers.

@mikedance

This comment has been minimized.

Show comment
Hide comment
@mikedance

mikedance Oct 12, 2018

I'm currently building a site with Gutenberg and have made heavy use of a modified version of marcusig's section block. This is what I've learned based on the experience:

  • "Section" is the best name for the block. Its meaning is clear to developers and end users, and it avoids complicating the markup/options by logically using the <section> block.

  • The only context menu options needed are alignnormal/wide/full (and in fact I only use alignfull). The alignment does not affect the inner blocks, which stay within normal alignment unless they have their own alignment options. The primary use case has been creating an alignfull background color that contains a normal-aligned text block -- a very common design pattern that's not currently possible.

  • The only sidebar block settings needed are Background Color and Background Image (with associated fixed/opacity options). Any additional customization can be handled with the custom CSS class. (Including the Background Image option also has the side effect of turning this into a much more useful version of the Cover Block.) (But: if @mtias is right that avoiding that conversation by only including the Background Color option would get this out the door faster, then I'm all for it.)

  • Usability has been simple. Easier than Columns, which have been around for a while now. The only potential issue is that when the section is first added, focus is switched to a paragraph inside the section, so it can be hard to tell that the section was just added until you mouseover it. One possible solution for that is to default to a light gray background color.

mikedance commented Oct 12, 2018

I'm currently building a site with Gutenberg and have made heavy use of a modified version of marcusig's section block. This is what I've learned based on the experience:

  • "Section" is the best name for the block. Its meaning is clear to developers and end users, and it avoids complicating the markup/options by logically using the <section> block.

  • The only context menu options needed are alignnormal/wide/full (and in fact I only use alignfull). The alignment does not affect the inner blocks, which stay within normal alignment unless they have their own alignment options. The primary use case has been creating an alignfull background color that contains a normal-aligned text block -- a very common design pattern that's not currently possible.

  • The only sidebar block settings needed are Background Color and Background Image (with associated fixed/opacity options). Any additional customization can be handled with the custom CSS class. (Including the Background Image option also has the side effect of turning this into a much more useful version of the Cover Block.) (But: if @mtias is right that avoiding that conversation by only including the Background Color option would get this out the door faster, then I'm all for it.)

  • Usability has been simple. Easier than Columns, which have been around for a while now. The only potential issue is that when the section is first added, focus is switched to a paragraph inside the section, so it can be hard to tell that the section was just added until you mouseover it. One possible solution for that is to default to a light gray background color.

@rwrobe

This comment has been minimized.

Show comment
Hide comment
@rwrobe

rwrobe Oct 12, 2018

@ZebulanStanphill Are you talking about columns? I could see "section" blocks doing the job for vertically separated content-- there could even be a toggle for inheriting styles from the previous section, which sort of allows you to "nest" style variations inside of a section.

Horizontal composition, like in columns, seems necessarily more difficult due to the way Gutenberg builds the page from top to bottom in full-width blocks.

rwrobe commented Oct 12, 2018

@ZebulanStanphill Are you talking about columns? I could see "section" blocks doing the job for vertically separated content-- there could even be a toggle for inheriting styles from the previous section, which sort of allows you to "nest" style variations inside of a section.

Horizontal composition, like in columns, seems necessarily more difficult due to the way Gutenberg builds the page from top to bottom in full-width blocks.

@JiveDig

This comment has been minimized.

Show comment
Hide comment
@JiveDig

JiveDig Oct 12, 2018

@mikedance I think that is exactly what is needed. A background image option would be important though IMO. Maybe this block could replace the Cover Block then, though the naming may not be conducive for people that only want a background image with basic text over it. Though there is some overlap in functionality, but it would take away a large percentage of use-cases for the Section block without adding bg image support.

JiveDig commented Oct 12, 2018

@mikedance I think that is exactly what is needed. A background image option would be important though IMO. Maybe this block could replace the Cover Block then, though the naming may not be conducive for people that only want a background image with basic text over it. Though there is some overlap in functionality, but it would take away a large percentage of use-cases for the Section block without adding bg image support.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Oct 12, 2018

Contributor

@rwrobe It should be noted that you can have horizontally-laid-out blocks. The Column (note the lack of "s") blocks are just that. The Columns block lays them out horizontally. The UI could probably be improved in some areas, but blocks are not limited to being full-width or vertically-laid-out.

@mikedance

"Section" is the best name for the block. Its meaning is clear to developers and end users, and it avoids complicating the markup/options by logically using the

block.

Because the <section> element has semantics attached to it, it would be best if you could choose to use a <div> rather than a <section>, since in many cases you want to wrap several blocks, but they are not semantically part of a section. In fact, it would be even better if you could also choose to use elements like <aside> or <header>, the latter being particularly useful for adding semantics to headings-with-backgrounds in page building.

On another note, I think having background image options available for a Container block would be quite useful. Of course, the overlap with the Cover block concept becomes quite apparent. If you make the Cover block more flexible, it basically turns into a Container block anyway, so perhaps the Cover block concept does not need to exist? A Container block could do pretty much everything it does. The Cover concept could just be a Reusable Block template.

Contributor

ZebulanStanphill commented Oct 12, 2018

@rwrobe It should be noted that you can have horizontally-laid-out blocks. The Column (note the lack of "s") blocks are just that. The Columns block lays them out horizontally. The UI could probably be improved in some areas, but blocks are not limited to being full-width or vertically-laid-out.

@mikedance

"Section" is the best name for the block. Its meaning is clear to developers and end users, and it avoids complicating the markup/options by logically using the

block.

Because the <section> element has semantics attached to it, it would be best if you could choose to use a <div> rather than a <section>, since in many cases you want to wrap several blocks, but they are not semantically part of a section. In fact, it would be even better if you could also choose to use elements like <aside> or <header>, the latter being particularly useful for adding semantics to headings-with-backgrounds in page building.

On another note, I think having background image options available for a Container block would be quite useful. Of course, the overlap with the Cover block concept becomes quite apparent. If you make the Cover block more flexible, it basically turns into a Container block anyway, so perhaps the Cover block concept does not need to exist? A Container block could do pretty much everything it does. The Cover concept could just be a Reusable Block template.

@wmodes

This comment has been minimized.

Show comment
Hide comment
@wmodes

wmodes Oct 12, 2018

@ZebulanStanphill I concur. That an advanced configuration that allows you to select whether it is a section, header, aside, or div (default) would be useful. Yes, most users might not use that option, but it is an option that supports good web dev.

wmodes commented Oct 12, 2018

@ZebulanStanphill I concur. That an advanced configuration that allows you to select whether it is a section, header, aside, or div (default) would be useful. Yes, most users might not use that option, but it is an option that supports good web dev.

@strarsis

This comment has been minimized.

Show comment
Hide comment
@strarsis

strarsis Oct 15, 2018

How can a theme integrate? Can a theme add "variations" to a block, in this case
the section block and the user can directly pick one from a ilst and see the resulting styles applied?
Also it may be very helpful to add a filter or hook to section block for letting
a theme add wrapper and other elements that are sometimes required for styling.

strarsis commented Oct 15, 2018

How can a theme integrate? Can a theme add "variations" to a block, in this case
the section block and the user can directly pick one from a ilst and see the resulting styles applied?
Also it may be very helpful to add a filter or hook to section block for letting
a theme add wrapper and other elements that are sometimes required for styling.

@mikedance

This comment has been minimized.

Show comment
Hide comment
@mikedance

mikedance Oct 15, 2018

@ZebulanStanphill @wmodes I doubt including an option to select the containing element would ever get past the core devs. It's an overcomplication. From a certain point of view the <section> element is as semantic as it can possibly be because the user is already defining it as a "Section" by virtue of creating the block. It's up to them to use it responsibly, just like headings. But if it would avoid the semantics argument, I don't have issue with using <div>.

mikedance commented Oct 15, 2018

@ZebulanStanphill @wmodes I doubt including an option to select the containing element would ever get past the core devs. It's an overcomplication. From a certain point of view the <section> element is as semantic as it can possibly be because the user is already defining it as a "Section" by virtue of creating the block. It's up to them to use it responsibly, just like headings. But if it would avoid the semantics argument, I don't have issue with using <div>.

@rchipka

This comment has been minimized.

Show comment
Hide comment
@rchipka

rchipka Oct 15, 2018

@mikedance Agreed, we should probably just use <div>. If semantic layout is a concern then it would be best handled as an extension to the container block.

rchipka commented Oct 15, 2018

@mikedance Agreed, we should probably just use <div>. If semantic layout is a concern then it would be best handled as an extension to the container block.

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Oct 15, 2018

Contributor

@strarsis Themes can use the existing block styles API to add styles to blocks. (The core Button and Quote block include multiple style variants by default.) Unfortunately, I can't find any documentation on this functionality. (There are multiple issues tracking the current lack of docs: https://github.com/WordPress/gutenberg/milestone/500 )

@mikedance

From a certain point of view the

element is as semantic as it can possibly be because the user is already defining it as a "Section" by virtue of creating the block.

I think I get what you are saying, but I disagree. In many cases, a Container block would be used simply to add a background color to a couple or even just one block that does not have its own background (or other styling) options. A List block wrapped in a Container to give it a background color and highlight it does not mean the List is in its own section.

But yeah, <div> is the most neutral choice since it has no semantic meaning. If there will never be an option in core to change the HTML element, then <div> is the best choice.

The main reason I want the ability to choose the HTML tag is because it allows you to more easily create semantic pages and posts without having to resort to the Custom HTML block or plugins that add custom blocks. If you want to use a <section> tag in Gutenberg right now, you end up having to put everything in that section in a Custom HTML block, losing the visual editing capabilities for things like Paragraphs, Lists, etc. that you would have otherwise. Perhaps the tag switcher could be shown under the Advanced group in the inspector?

Contributor

ZebulanStanphill commented Oct 15, 2018

@strarsis Themes can use the existing block styles API to add styles to blocks. (The core Button and Quote block include multiple style variants by default.) Unfortunately, I can't find any documentation on this functionality. (There are multiple issues tracking the current lack of docs: https://github.com/WordPress/gutenberg/milestone/500 )

@mikedance

From a certain point of view the

element is as semantic as it can possibly be because the user is already defining it as a "Section" by virtue of creating the block.

I think I get what you are saying, but I disagree. In many cases, a Container block would be used simply to add a background color to a couple or even just one block that does not have its own background (or other styling) options. A List block wrapped in a Container to give it a background color and highlight it does not mean the List is in its own section.

But yeah, <div> is the most neutral choice since it has no semantic meaning. If there will never be an option in core to change the HTML element, then <div> is the best choice.

The main reason I want the ability to choose the HTML tag is because it allows you to more easily create semantic pages and posts without having to resort to the Custom HTML block or plugins that add custom blocks. If you want to use a <section> tag in Gutenberg right now, you end up having to put everything in that section in a Custom HTML block, losing the visual editing capabilities for things like Paragraphs, Lists, etc. that you would have otherwise. Perhaps the tag switcher could be shown under the Advanced group in the inspector?

@ajitbohra

This comment has been minimized.

Show comment
Hide comment
@ajitbohra
Member

ajitbohra commented Oct 15, 2018

@strarsis @ZebulanStanphill

You can find docs for adding Block Styles in handbook under extensibility https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#block-style-variations

@ZebulanStanphill

This comment has been minimized.

Show comment
Hide comment
@ZebulanStanphill

ZebulanStanphill Oct 15, 2018

Contributor

@ajitbohra Thanks! I checked that page several times but I kept missing that section somehow. 😆

Contributor

ZebulanStanphill commented Oct 15, 2018

@ajitbohra Thanks! I checked that page several times but I kept missing that section somehow. 😆

@strarsis

This comment has been minimized.

Show comment
Hide comment
@strarsis

strarsis Oct 18, 2018

@ajitbohra: Thanks! Is there a demo for Gutenberg block style variations btw.?

strarsis commented Oct 18, 2018

@ajitbohra: Thanks! Is there a demo for Gutenberg block style variations btw.?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment