The Headings are guessed

[umbobabo]

** Currently not a priority, but feedback are welcome, this seems more a Spark and FEs issue, but posting here for C&M visibility **

A document follows a hierarchical structure, where each section nests under the correct heading level.
In HTML, this is represented with heading elements (<h1>–<h6>), with higher-level headings introducing subsections.

Correct hierarchy example:

Cooking Basics (h1)
├── Ingredients (h2)
│   ├── Vegetables (h3)
│   └── Meats (h3)
└── Techniques (h2)
    ├── Boiling (h3)
    └── Frying (h3)

Current situation

• <h1> is reserved for the main title.
• Editorial can add <h2>/<h3> in Spark via Chapter / Sub-Header.
• Some components inject their own headings (often <h2>,<h3>, <h4>, <h5>).

This can create an inconsistent hierarchy, e.g. headings jump levels and order:

Cooking Basics (h1)
├── Vegetables (h3)   ← Added via a component, it skips h2
├── Ingredients (h2)   ← Added By Editorial
│   └── Leafy Greens (h4) ← Added via a component, it skips h3

This H1 → H3 → H2 → H4 sequence is incorrect because it skips levels and reorders structure, which harms accessibility and navigation.
Potentially, this could be a bigger problem in the future where most advanced cases relate to machine readability could require a correct hierarchy.

[debugwand]

label also turns things into h4s but editorial might be picking this for its styling rather than its hierarchy in the document.

this will become more apparent when we try to do internal navigation for pages. Editorial will need to be able to indicate what is a new section and what is a child of that section (and possibly even what is a child of that), to a maximum of 4 children (h3-h6)of a section (h2).

the styling and the hierarchy should be able to be set as separate things, or maybe even only design gets to specify what the headings look like and editorial get controls called something like 'hierarchy' or 'structure' rather than 'format'

[umbobabo]

editorial get controls called something like 'hierarchy' or 'structure' rather than 'format'

Yep. I just create this related issue. The Content Tree doesn't have semantic information. We may need though to think at how component reflects in a semantic way.

We agreed with @adgad to try to create more specialised components (Less open to free compositions) but I'm not sure it may be enough to guess the exact semantic to present them accurately.

This may affects also the bodyHTML.