edited

Hi @mrmadhat, thank you for your contribution. Previously we used headings in the cover image, but a change was applied and we intentionally changed to a paragraph. That can still be observable in the deprecations code.
I think this chnage was related to the semantics of the markup.
The change was applied in commit 77cd75d. @samikeijonen would you be able to provide some context on the reason of this change?

This comment has been minimized.

From my part, I don't see blockers given that @samikeijonen the original creator of #2902 is open to this idea.@afercia would it be possible to share some thoughts of this change regarding the a11y point of view?

@mapk regarding the UX do you think this change is valuable? Also, what are your thoughts regarding the usage of nested blocks on the cover block? If we think the user experience using nested blocks is preferable we should probably go directly there.

This comment has been minimized.

The argument that hardcoding a heading (ie. H2) may cause an incorrect heading hierarchy makes sense. I see the reasoning for changing it to a p. However, I do believe a common usage of the cover block is for headings as outlined in the documentation.

That being said, I'd like to add back the heading capability to the cover block, but allow the heading level to be user selected. This appears to align best with the concept of nested blocks at this point as @jorgefilipecosta points out; a nested heading block inside the image block, to make up the Cover block. Let's go that direction.

This comment has been minimized.

This appears to align best with the concept of nested blocks at this point as @jorgefilipecosta points out; a nested heading block inside the image block, to make up the Cover block. Let's go that direction.

I also share a similar view in regards to that. I also sense some accessibility challenges introduced by this proposal due to the fact that tag name would have to be updated in the sidebar. In general, taking the approach of nested blocks gives it much more flexibility in terms what kind of blocks could be nested (not only heading) but also would open room for further customizations inherited from individual blocks. I would vote to stop working the original issue and this PR and focus on converting Cover block to use nested blocks internally. I think @jorgefilipecosta was exploring that in the past. What blocked it from getting in WordPress 5.0 release?

This comment has been minimized.

Let's still be careful with using headings. Users might pick heading just based on the size, not the correct hierarchy. Document outline info helps with this though.

It might be also an interesting challenge to provide automatically adjusted heading type based on the surrounding content. I think this is something that could be explored on its own. The idea is that you add the heading without any size provided and it detects and sets the proper one depending on the previous headings.

This comment has been minimized.

It might be also an interesting challenge to provide automatically adjusted heading type based on the surrounding content. I think this is something that could be explored on its own. The idea is that you add the heading without any size provided and it detects and sets the proper one depending on the previous headings.

I'm not sure if that's is possible, at most we can just discard some headings in a given context. For example, if the previous heading is h3 we know that the next heading cannot be h5. But it can be an h4 heading inside the previous h3, it can be another h3 heading sibling of the previous h3 or it can be another h2 heading sibling of the previous h3 parent. It is not possible to automatically know the user intent.
Another option is showing some visual feedback with the heading sections to improve the probability that the user is going to make the correct choice.

@jorgefilipecosta points out; a nested heading block inside the image block, to make up the Cover block. Let's go that direction.

I would vote to stop working the original issue and this PR and focus on converting Cover block to use nested blocks internally. I think @jorgefilipecosta was exploring that in the past. What blocked it from getting in WordPress 5.0 release?

There were two tries to get nesting in cover, and in one of the tries, it was decided nesting was not polished enough. On the second try, we extracted from that the PR the video options and some refactors to cover but decided the nesting part would not go as part of phase 1.

So as an action item I can try to revive the nesting mechanism in cover. We then can review it and if concluded nesting is ready for that block we advance in that direction if not we may take a new look into this PR.

This comment has been minimized.

I'm not sure if that's is possible, at most we can just discard some headings in a given context. For example, if the previous heading is h3 we know that the next heading cannot be h5. But it can be an h4 heading inside the previous h3, it can be another h3 heading sibling of the previous h3 or it can be another h2 heading sibling of the previous h3 parent. It is not possible to automatically know the user intent.

I'm sure it is possible to make some inform decisions based on the previous heading or the fact that this is the first heading in the document. There are three states really in such scenario:

the same level which would be the default

child level

one of the parent levels which is the most complex one

Anyway, this is something nice to have which could help to work on larger documents and doesn't differ that much from lists which are handled this way using identation levels.

This comment has been minimized.

So as an action item I can try to revive the nesting mechanism in cover. We then can review it and if concluded nesting is ready for that block we advance in that direction if not we may take a new look into this PR.

@mrmadhat thank you for your work invested in this PR. We think that there is a more flexible approach which is going to solve the same issue which we want to revive given that the UI for nested blocks is getting better with each plugin release. It would be great to have you involved in the further work on this capability given your experience learned with this code exploration.

This comment has been minimized.

Thanks @gziolo I've been away for the past week and I'm just catching up now, I agree with what's been said and would like to be involved with the work on the nested blocks. I think I've found the main issue for this functionality (4900) but could someone confirm what the go to issue for this is?

This comment has been minimized.

#4900 is a bit different. This is meant to provide a general purpose container block which might be a way to build Cover block yourself. However, let me copy my comment from a different PR:#10746 (comment)

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.