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 best practice guidance for the group block element selector #31502

Closed
desrosj opened this issue May 5, 2021 · 3 comments · Fixed by #33976
Closed

Add best practice guidance for the group block element selector #31502

desrosj opened this issue May 5, 2021 · 3 comments · Fixed by #33976
Assignees
Labels
[Block] Group Affects the Group Block (and row, stack and grid variants) [Block] Query Loop Affects the Query Loop Block [Block] Template Part Affects the Template Parts Block [Package] Block library /packages/block-library [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.

Comments

@desrosj
Copy link
Contributor

desrosj commented May 5, 2021

What problem does this address?

#28576 introduce an element selector to the group block to allow a user to change the container element within a user created template.

106254186-19217d00-6221-11eb-892d-a35f4d2e2757

While this is great for flexibility, there is no guidance around purpose or proper use of each element and could lead users to construct pages with bad structure and accessibility.

For example, each document must not have more than one <main> element. Another example is that the <header> element could also be easily confused with the page's actual "header" area, but it's not meant to designate a new section on the page (it will not be reflected as a new section in the outline). Instead it should represent a header for the surrounding section.

What is your proposed solution?

At the minimum, I think a description of the selected element (potentially with suggested best practices) should be added to the selector. This would provide the user with some clarity and guidance as to how the element can be properly utilized.

At the most, I think we could explore adding some contextual hints to the user. Something that came to mind for me was when a user is warned that the selected colors for a block could potentially be hard for people to read. For the <main> element, a warning like this could be displayed if more than 1 <main> tag is detected in the page.

Screen Shot 2021-05-05 at 09 19 43

@desrosj desrosj added [Type] Enhancement A suggestion for improvement. [Package] Block library /packages/block-library [Block] Group Affects the Group Block (and row, stack and grid variants) labels May 5, 2021
@carolinan carolinan added [Block] Template Part Affects the Template Parts Block [Block] Query Loop Affects the Query Loop Block labels May 5, 2021
@desrosj
Copy link
Contributor Author

desrosj commented May 5, 2021

Related: #31421.

@getdave
Copy link
Contributor

getdave commented May 5, 2021

This sounds like a reasonable idea to me. Different descriptive text per element with links to further information - ideally on WP.org but otherwise on another site.

@carolinan
Copy link
Contributor

carolinan commented May 6, 2021

This is used in 3 blocks, but with different elements available.
In case of the template part, the <header> element is not meant to be inside another element, it is meant to be the banner role, the site header. And the footer is for the site footer, the contentinfo role.
Since template parts are not always available, the header element is also available for the group.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Group Affects the Group Block (and row, stack and grid variants) [Block] Query Loop Affects the Query Loop Block [Block] Template Part Affects the Template Parts Block [Package] Block library /packages/block-library [Status] In Progress Tracking issues with work in progress [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants