What's the official position on HTML5 semantic tags?

[AlchemyUnited]

Is it on the roadmap / radar for the Gutenberg content layout "model" to suppose HTML5 semantic tags? For example, section article, aside, etc.

I've seen this: #14898

Perhaps there are others issues/discussion? I'm considering adding a select to (some of) my blocks. Or probably just adding a universal wrapper that would be optional, but there if wanted / needed. But maybe native GB is going to address this? Soon?

Perhaps this can (read; should) be incorportated into the (new) Group functionality? That is, that adds a div but could - I presume - just as easily add any tag. That said, in theory, you can have an aside within a section "group", etc.

Again, just trying to get a sense, if there's one to get, on Gutenberg and any thoughts/efforts to enable HTML5 semantic tags.

[mtias]

For sure. There's not yet a proper plan for how much we should try to automate vs how much should be configured by the user. The way we are approaching things — like headings and document outline — is to both try to surface semantic options but also help the user not make mistakes, or inform them about implications. We don't want to be in a position where the user sees all these options but don't know what to do: "should I pick an aside for this group block"?

There's also the point of not knowing the broader structure a theme provides since the editor is only handling post_content for now. As that expands, semantic capabilities should also expand.

I think there will also be cases where context dictates semantics rather than the block itself — a cover image placed in a certain theme area could use a different element tag, and so on.

[AlchemyUnited]

@mtias - Thx. Mind if I reply :)

"We don't want to be in a position where the user sees all these options but don't know what to do: "should I pick an aside for this group block"?"
Unless there's talk of "AI" or some sorta of wizards or bots, etc. there are going to be more demands on the "Content Constructor." As they say, "With rights (to a better editor), comes responsibility." :) It's not easy. I get that. But it's close to unavoidable (without a tool to help).

As it is, for many of the non core blocks I've seen, there's a nasty (and self-defeating) sense of (Inspector panel) TMI. Picking a border radius, border width. etc. I can see a "Content Constructor" sitting down to do content and suddenly being faced with (too many) design decisions. Anyone old enough to remember MySpace knows that most ppl are not good or even average designers.

My point is, decisions are decisions. And currently the "global decision space" of the tool is being crowded and cloud (with things that have less to with with laying out content, and more to do with too many other things.) imho, of course ;)

"There's also the point of not knowing the broader structure a theme "
Well, yes. But that's because there's no standard for the themes to follow. At some point GB is going to have to take responsibility for having been given the lead role in a broader "design system." At some point it's going to have to define it's assumptions / expectations, yes? When might this happen?

Long to short (and correct me if I'm wrong)
I should move forward with creating my own (simple) wrapper block(s) for doing semantic groupings since this doesn't seem to be on GB shortlist road map.

p.s. Off the top of my head, something like the Editor group function would probably be a good way to go about this, but that's probably above my current React pay grade. None the less, I'll offer the thought and have a look myself later.

thanks again.