Re: [whatwg] Thoughts on the <nav> element

I'm (obviously) +1 on this.

Navs are great semantically, but very, very impractical as sectioning
content.
I'd rather see them being implemented more loosely. You can always add a
heading if that's justified or practical. But implying it forces the ugly
and pretty useless structure Andrea outlines.

A very common occurence is:
[Untitled body]
  1. Navigation
1. Page/article title

Simply because the main nav (that is not tied to the page, but is global)
HAS to come before the main element.

I'm not sure how easy/hard it is to do some sort of automated test on the
top X sites, to see what the outlines are, which elements are used and how
we can propose better solutions, but that would be immensly helpful.

Cheers,
Reinier Kaper.

On 27 March 2015 at 22:42, Andrea Rendine <master.skywalker.88@gmail.com>
wrote:

> After a mail confrontation with Reinier, as well as some very simple models
> I saw at work, I have to admit that I support this idea.
> <nav> has a strong semantic value, for sure. It deserves UAs to easily
> highlight navigation elements.
> Thus said, is it really needed that <nav> necessarily defines a section? I
> think not.
> A first point is what Reinier underlined. With a structure as follows:
> [header with no heading elements]
> [navigation]
> [main with its own heading elements]
> an author would end up with an ugly and impractical (as stated by Reinier
> himself) structure: an untitled body, a navigation, and a main content
> presenting a heading, which is no longer the page content title as it was
> logically intended. Some authors (I'm among them) prefer different
> structures with one title for the page and one for main content, but
> defining <main> element as *not* sectioning allows a more agile
> structure... actually made non viable by a sectioning <nav> placed before
> <main> (and note that this is both a layout choice AND one dictated by
> logic, as site navigation is not to be considered part of the main
> content).
> On the other hand, consider a long navigation element enclosed in an
> <aside>. The spec suggests it can group a series of <nav> elements, but
> even a single <nav> list qualifies as "content tangentially connected to
> the page topic". But <aside> is sectioning content too, and when using a
> single <nav> in <aside>, it forces an unnecessary further nesting
> [body]
>   [aside]
>     [nav]
> also forcing authors to put different titles when they want to avoid the
> poor default choice of "Untitled <xxx> element".
> Having a strong semantic doesn't necessarily mean defining a section for
> the document, as emerged for <main> element too. I previously suggested
> that <main> itself could become a sectioner, but I have to retract because
> this solution is highly impractical... yes, as well as sectioning <nav>.
> This element is not even logically suitable to define anything - it just
> helps users retrieving navigational structures. Then, if authors need to
> *also* use it as a sectioner, nobody can stop them from defining it as a
> section, either implicitly (through a heading element) or explicitly
> (wrapping it in a strongly sectioning elements such as <aside>).
>

Received on Saturday, 28 March 2015 02:56:04 UTC