Seems promising! :)

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.

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?

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.

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.

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.

This is nifty! What do you see is left to do, @gziolo?

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. header, main, aside. They should be very useful in the context of full site editing. It also makes me think that maybe variations should also support the parent field.

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

_{compressed-size-action}

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.

@youknowriad

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.

I think aside, header, and footer would be good to expose intitially. I've used aside in a few of my blog posts (and had to use the Custom HTML block for the entire thing), and it would be nice to just use the Group block so I can keep using blocks for the nested paragraphs. header and footer will both be useful in the context of full site editing, and for those looking for extra semantic markup, those elements can be used for the headers and footers of document sub-sections made using the section element.

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.

I found the reason, I will push the fix tomorrow and land this PR. The migration function needs to set tagName to the default value. I'm not sure why it isn't automatically exposed. Well, maybe it makes sense since this attribute wasn't defined earlier.

All issues resolved, Travis seems to be happy now. We can land this PR once the last job on Travis finishes.

Thanks @gziolo