-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Block library: Try variations for Group block #20218
Conversation
Seems promising! :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I've been waiting for this feature for a long time.
I think it would be a good idea to add a dropdown to change the tag in the Inspector, so you can change the tag on existing blocks. Actually, maybe this is something that could even be placed in the toolbar.
@@ -13,6 +13,10 @@ | |||
}, | |||
"customTextColor": { | |||
"type": "string" | |||
}, | |||
"tagName": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should probably be some way of limiting this attribute to certain whitelisted values (div, section, header, footer, and aside are what I'm thinking).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking it could be less of a hard limit and more of a recommendation while in the editor, similarly to how the editor advises against incorrect heading levels or against low-contrast colour combinations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I imagine it could also have support as a wrapper for custom-elements.
This is something to think about in the broad context of block variations (and patterns?). I do believe there are some interesting opportunities in terms of how a block is aware of its own "degree of variation" from the base block type or chosen variation, and offering to convert in-place between variations. |
This is nifty! What do you see is left to do, @gziolo? |
It's something that it's on the radar. It needs some experimentation because in some cases it might cause content loss. We discussed some strategies with @mcsf how to mitigate it and one possible solution would be to show a snackbar notice with an option to revert changes. In the case of this proposal, it would be safe to allow changing block variations.
The proposed variation could have a unique icon and description. In addition, we might want to cover more variations listed in the parent issue, e.g. |
eff60bd
to
2eb409a
Compare
In an attempt to move this forward, I've rebased it and make the required adjustements. IMO, this is ready for a v1, the question for me remains about the variations: What variations do we want to expose initially if any. Right now there's just a "section" variation, but let me know if you think we should add more now. |
Size Change: +77 B (0%) Total Size: 866 kB
ℹ️ View Unchanged
|
'section', | ||
'aside', | ||
'footer', | ||
'main', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
form
is also missing on this list. See: https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you would do with form
since there are generally no granular blocks to make sense of it. Blocks that perform form-like functions would already define the element for themselves.
There are some unit tests failing, we need to investigate further whether it's fine to regenerate snapshots or we need to add deprecation entry for the block. |
I think |
I'm still hesitant on the variations here, they have the potential to confuse regular users. So I'm thinking we should just remove the variations for now and merge the PR to move forward and allow FSE themes to use the new attribute. |
2eb409a
to
b7dff62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test failures actually look related (maybe the branch needs to be rebased?), but other than that, I think this is good to go. Just having the attribute that I can manually edit will allow me to start using Group blocks in some places on my site where I'm currently using Custom HTML blocks. 🙂
I found the reason, I will push the fix tomorrow and land this PR. The migration function needs to set |
This is an experiment which allows to use `section` tag as a wrapper used with the Group block. It uses new block variations API.
b7dff62
to
6897d7d
Compare
All issues resolved, Travis seems to be happy now. We can land this PR once the last job on Travis finishes. |
Thanks @gziolo |
Description
closes #20200.
This is an experiment that allows using
section
tag as a wrapper used with the Group block. It uses new block variations API and registers Section block variation to use in the inserter.Screenshots