[whatwg] The real issue with HTML5's sectioning model (was: "Headings and sections, role of H2-H6" and "Should default styles for h1-h6 match the outlining algorithm?")

On 30.04.2010 21:47, Greg Houston wrote:
> On Fri, Apr 30, 2010 at 1:57 PM, Eduard Pascual<herenvardo at gmail.com>  wrote:
>
>    
>> So, that's enough of a problem statement (at least for now). My
>> suggestion is to clean things a bit: consolidate the sectioning model
>> into a single element+attribute pair, like this:
>> <section>  stays as is.
>> <nav>  becomes<section kind="nav">
>> <aside>  becomes<section kind="aside">
>> <article>  becomes<section kind="article">
>> <address>  becomes<section kind="address">
>>      
> I haven't been following this thread, but for just the styling aspect
> of it, the same thing can be accomplished by adding a "section" class
> to each of these elements:
>
> <section class="section">
> <nav class="section">
> <aside class="section">
> <article class="section">
> <address class="section">
>    
I think this defeats all the purpose of the different sectioning 
elements. They want to save code, not let you state the obvious by 
class="section"
> So that this...
>
>    
>> h1 { styling for top-level }
>> section h1 { styling for second-level }
>> section section h1 { styling for third-level }
>>      
> Becomes this:
>
> h1
> .section h1
> .section .section h1
>
> Regarding your proposal, if I wanted to style the following element
> only, what would the CSS look like?
>
> <section kind="aside">
>    
section[kind=aside]
or if you want to style all *containing* aside (kind="asid nav"):
section[kind~=aside]
> Another option along the lines of your proposal, is you could still
> have the same functionality without the kind="*" so that rather than
>
>    
>> <nav>  becomes<section kind="nav">
>> <aside>  becomes<section kind="aside">
>> <article>  becomes<section kind="article">
>> <address>  becomes<section kind="address">
>>      
> <nav>  is treated as<section kind="nav">
> <aside>  is treated as<section kind="aside">
> <article>  is treated as<section kind="article">
> <address>  is treated as<section kind="address">
>
> In this case nav, aside, article, and address are all types of
> sections, and so any style added to a section is added to each of
> these, with any style added to one of these specific elements
> overriding the section style rules.
>
> In both cases you lose the ability to apply CSS to a plain old section
> that will not be automatically applied to the other elements. A third
> option is to have a quasi-element that refers to all of these but is
> never actually used in the HTML. It would just be a tool for CSS and
> outlining algorithms. I can't think of a good name for it, but for
> example, "sectional" could reference all of the following and anything
> else one might thing should go in this list: section, nav, aside,
> article, and address. Now you can style section without having to
> override that styling in nav, aside, article, and address.
>
> h1
> sectional h1
> sectional sectional h1
>
> I think this last option might solve the problems without changing the
> current html or css, and would simply add a hook for outlining
> algorithms and other use cases where you want a clean way to get a
> particular element at a particular depth.
>
> Just some thoughts.
>
> G.
>    
I think introducing pseudo-elements that actually do not exist is a step 
in the wrong direction. It tries to solve a side effect of the problem, 
instead of solcing the problem at it's root.

@Eduard: I thing your concept is quite good. I only do not like @kind. 
@type (as you already said) would be more intuitive.
PS: Mozilla solved the exponential problem using :-moz-any(), others 
will probably do it this way, too.

Received on Friday, 30 April 2010 13:04:17 UTC