Consider adding a general purpose Link block or block supports about gutenberg

[andrewserong]

Nice issue! It reminds me of an earlier issue about making the entire post item within a query loop clickable. Potentially related issues:

• #38014
• #60499

[colorful-tones]

I would be careful with the final markup. Typically a clickable card solution relies on CSS positioning and a pseudo-element. A good reference for implementation would be Inclusive Components > Cards

[cbirdsong]

There is a longstanding issue for this over here:

• #12684

I concur about Inclusive Components being a good reference and that you'd have to be very careful with the markup as well as the editing experience – getting the implementation of this pattern right is difficult.

For instance, in the OP's example screenshot, the whole card is presumably clickable, but there's also a "add comment" link inside of it. The usual recommendation for this pattern is to avoid nested links, but if they have to exist they should have a large clickable interactive area. There is not really a way for that to be applied in the block editor in a generalized way.

There's also the question of what bit of text actually is linked, which is important for accessibility. As described in Inclusive Components, you can't just wrap the whole thing in an <a> without creating accessibility issues. Additionally, a common thing you see in this pattern is having a "read more" tease at the bottom of the card, but if that's the linked text it's an instant accessibility failure. The headline needs to be what's linked so it would be unique.

Needless to say, this all would be very difficult for the average user to understand and manage in the editor UI. My inclination would be to make it so that you could only engage "stretched link" option if the container has one link and no other interactive elements inside of it, and once it is a stretched link then additional interactive elements could not be added.

[mtias]

Also any solution that changes the root element to a is going to be a bit troublesome for block validation and could create too much complexity at the block functions level. It seems a wrapper block could keep things more organized and we could explore enforcing certain restrictions or warnings for nested links or interactive elements. With the support group has for alternative tags, maybe it could even be explored as a variation of group.

[noisysocks]

I bet @richtabor has some good ideas here.

[noisysocks]

Good point on block validation. I could see a "Link to" setting in Group and Cover working pretty well. The complex part is getting the UX right around forbidding nested interactive elements.