Re: should HTML have a <heading> element?

Your example can also just be marked-up with <h1> instead of <heading>, so
I don't really see any benefit in this case, but I do get what you're
saying.

I've mocked-up a little example of how I would like to see (sub)headings
being implemented: http://codepen.io/anon/pen/ykoce
I've used margins to make headings indent in sections, articles and asides.
Just to show the "levels". (nav should also be included btw). In the second
example I've used no semantics apart from the headings to draw a comparison
in outline.

Even with semantic mark-up, the second example is usually unfeasible in a
dynamic environment. What happens for example when we add a level above
"Fruit"? All our subsequent headings need to be changed to fix the outline
again, which is not something that's going to happen when using a CMS for
example to generate documents. This is my main problem with our current
heading mark-up.

The first example might be a bit of an utopia when it comes to mark-up (not
all documents could or should be marked-up this way), but it's the
direction I would like to see this thing going. A very dynamic approach to
headings, instead of a "fixed" one we have now.

I think in short what I'm trying is:
1. have one heading element;
2. have the document structure (implied sections) determine the nesting /
outline;
3. have a <subheading> which relates to the <heading>, but doesn't change
the outline (see it as an extension of the <heading> with "less" semantic
priority / meaning);

<heading> then would be what Adrian said: they're all on a equal level,
until a new sectioning element is encountered.

Thoughts?


On 10 May 2014 18:58, Adrian Roselli <Roselli@algonquinstudios.com> wrote:

>
> Not sure I understand how a "hybrid" document might work from the
> description below.
>
> If I have mixed <h#>s and <heading>s, sometimes within a sectioning
> element, the browser will have to make some nesting assumptions I may not
> want -- assuming a <heading> is what triggers a browser to drop into an
> outline mode.
>
> <main>
> <h1>Title</h1>
> <p>content</p>
> <h2>Subtitle</h2>
> <p>content</p>
>         <section>
>         <heading>Section Title</heading>
>         <p>content</p>
>         <heading>Section Subtitle</heading>
>         <p>content</p>
>         </section>
>         <section>
>         <heading>Other Section Title</heading>
>         <p>content</p>
>         <h2> Other Section Subtitle</h2>
>         <p>content</p>
>         <h3> Other Section Sub-Subtitle</h3>
>         <p>content</p>
>         <h2> Other Section Subtitle</h2>
>         <p>content</p>
>         </section>
> </main>
>
> I see that as:
>
> Title
>         Subtitle
>                 Section Title
>                 Section Subtitle
>                 Other Section Title
>                         Other Section Subtitle
>                                 Other Section Sub-Subtitle
>                         Other Section Subtitle
>
> I see all <heading>s as a peer to all other <heading>s within a given
> section. You can't know how to "nest" them otherwise (<h#> has that
> capacity built in).
>
> In my own writing I often drill down to an <h3>, through to an <h4>, back
> up to the <h2>, and down again [1]. Unless we start manually adding
> attributes with nesting level, I couldn't rely on <heading> alone to convey
> my document/content structure (maybe that's the point?).
>
> However, when you start throwing <h#> within a section (which includes
> <section>) that is opened with <heading>, perhaps the nesting order resets,
> treating <heading> as the next highest available nesting level for the
> page, and subsequent <h#>s maintain their relative nesting order starting
> below the <heading>. So <heading> resets subsequent <h#> to start below,
> regardless of a <h#> number.
>
> IOW, that's what my pseudo-code-tree above does.
>
> Conversely, if we simply discard all <h#> for document outlines and lean
> solely on <heading> then I suppose that removes my concern. I can still use
> <h#> in my content comfortably, provided they aren't factored into the
> outline. The drawback, IMO, is that <heading> can really only exist once in
> a section without implying peer-level content that may not be so. It also
> removes the value for users from a well-structured (via <h#>) document.
>
>
> [1]
> http://blog.adrianroselli.com/2013/09/new-ipad-browser-coast-by-opera.html
>
>
> > From: Steve Faulkner [mailto:faulkner.steve@gmail.com]
> > Sent: Friday, May 09, 2014 4:32 AM
> >
> > discussion starter:
> > HTML5 has the outline algorithm [1] (as yet largely unimplemented  )
> > which effectively removes the semantic meaning of numeric headings.
> >
> > example:
> > <body>
> > <h6>
> >
> > does not mean a heading level 6 it means a heading level 1
> >
> >
> > conversely:
> > <body>
> > <section />
> > <section />
> > <section />
> > <section />
> > <section />
> > <section />
> > <h1>
> >
> > does not mean a heading level 1 it means a heading level 7 It has been
> > suggested by marco zehe from Mozilla [3] that the only clean way
> > forward for the outline algorithm is this:
> >
> > 1. Leave h1 to h6 alone as they always were. h1 through h6 are always
> > that regardless of what they are nested in.
> >
> > 2. Introduce a new element named "heading" or the like that is the only
> > element participating in the outline algorithm. it gets a level of 1 by
> > default, and a level of greater than 1 depending on which section
> > elements it is nested in. So a section heading gets a level of 2, a
> > section section heading gets a level of 3 etc. And the calculation of
> > the levels is the sole responsibility of the browser, indicating the
> > calculated level as an implicit aria-level attribute. Styling could
> > then be based off the section nesting or the proposed DOM attribute
> > that would correspond to implicit aria-level.
> >
> > This is the only way where there is a clean choice for web developers:
> > Use the limited 1 to 6 heading levels, or choose a more free and modern
> > way of structuring documents, and the browser takes care of
> > communicating the level to assistive technologies.
> >
> >
> > A custom <heading> element [2] designed to explore how such a feature
> > could work in practice is in development.
> >
> > [1] http://www.w3.org/html/wg/drafts/html/master/sections.html#outlines
> > [2] https://github.com/ThePacielloGroup/w3c-heading#w3c-heading
> > [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25003#c18
>
>
>