-
Notifications
You must be signed in to change notification settings - Fork 550
example in 4.3.6 doesn’t make sense #584
Comments
@Zambonifofex The 2 styles are implicit sectioning via heading elements versus explicit sectioning via section elements. I think, the bit that doesn't make sense is
I will remove this. The example you quoted from the whatwg spec was intentionally removed, it does not make practical sense, as its semantics are not supported in user agents and we don't want to continue promoting a coding method that results in a loss of meaning for users. |
Sorry, but while you (the W3C) don’t recommend using nested Either way, this was my preferred style for marking up sections with headings. I really think it’s a much more dynamic and beautiful approach to marking up headings; I was really delighted to find this style in the WHATWG’s spec, and I’m really sad to see it out of yours 😢 😭. |
Yes it is true that having a mechanism to nest headings without having to declare the level in advance would be far more useful. Sadly, no browser actually implemented that. Instead, they did implement the stylesheet in 10.3.7 to which you refer, which makes it look like they did something useful - and because that's what they implement, that is what is in the spec. Unfortunately, the underlying semantics conflict with the visual semantics - which is why it is not valid for authors to use this approach. |
Sorry, but is it, then, conforming according to the spec (even if not encouraged by the W3C, and not implemented in browsers) to use only <body>
<h1>Foo Bar</h1> <!-- Looks like an h1 (OK) -->
<section>
<h2>Foo Bar</h2> <!-- Looks like an h3 -->
<section>
<h3>Foo Bar</h3> <!-- Looks like an h5 -->
</section>
</section>
</body> |
There is a should conformance requirement in W3C HTML:
The HTML validator emits a warning about use of incorrectly nested headings. You example code appears to suggest that headings with a rank equal to their nesting level results in an adverse styling effect: Which it does not. in this example the
The rendering section of the spec includes quite a few style declarations for non conforming elements and attributes, for example
Even when features become obsolete or non conforming it still makes sense to include the rules for their rendering. |
You are correct. It seems browsers (at least Chrome) only style Sorry for asking here, but I’ve been reading the links you posted, and eventually I got to this thread. It’s very sad to me that it has lost traction two years ago. What do you think I should do to get that feature a little more attention again? |
no problem
I am unsure how to proceed, the browser vendors have show little interest in implementing :-( |
Seems we can close this... |
Currently, an example in the
h1
–h6
section doesn’t make sense. It shows how two different code fragments mean the same thing, and mentions how you can mix both styles, yet doesn’t say how. The thing is: the second code fragment it mentions is supposed to be the mixed style. Compare the WHATWG’s version (makes sense) to the W3C’s version (doesn’t make sense).Here is how the second code fragment is currently:
Here is how it’s supposed to be:
The text was updated successfully, but these errors were encountered: