[whatwg] wrapper element

[Ian Hickson]

Thanks to everyone contributing on this thread -- though it has not so far 
resulted in a change to the spec, this was a model discussion.

On Sun, 27 Feb 2011, usuario wrote:
>
> Tiis may seem somewhat silly, every front-end developer have ever used a 
> a wrapper div, shouldn't it be more semantic to have a wrapper element?

On Sun, 27 Feb 2011, Bjartur Thorlacius wrote:
>
> If said wrappers don't have any semantics but grouping loosely related 
> elements, for which no semantic container exists, div seems appropriate.
> 
> What semantics would such an wrapper element provide over <div>?

On Sun, 27 Feb 2011, Jukka K. Korpela wrote:
> 
> I guess you mean a group that is not best describable as <nav> or 
> <footer> or <section> or some of the other semantic elements. The most 
> obvious candidate is the "content proper", as people often use, mainly 
> for styling purposes, grouping together any content that is not a 
> header, a navigation block, or a footer. In some cases, you might make 
> it <article> or <section>, but if those don't apply naturally, it should 
> be <div>. It is better to be semantically empty than to be semantically 
> wrong, or even bordeline.

Indeed.


> Thinking purely logically (if we dare), <wrapper> would have the benefit 
> of explicitly saying "this is a wrapper for grouping, for no semantic 
> reason", thereby distinguishing it from <div> which may, and often does, 
> involve semantic or logical grouping. For example, <div id="footer"> is 
> probably a footer of some kind, not arbitrary grouping.
> 
> But thinking pragmatically, it is difficult to see strong reasons to 
> distinguishing wrappers from legacy use of <div>. Moreover, I don't 
> think people would use <wrapper> much, since they can use <div> and are 
> accustomed to <div>.

Indeed. Also, grouping is, to some extent, a semantic reason. It's rare 
that people wrap completely unrelated things in a <div> just for the sake 
of it.


On Mon, 28 Feb 2011, Tab Atkins Jr. wrote:
> 
> <div> carries no semantic meaning.  If you are using it for such, the 
> semantic is purely internal to your application, and thus doesn't carry 
> the common meaning of "semantics" as used on the web.
> 
> <div> is the wrapper element.  That's its entire purpose for living.  

Indeed.


On Mon, 28 Feb 2011, usuario wrote:
>
> Wrapper:
> a container element whose solely purpose is to isolate flow content for 
> visually appealing purposes. It it usually used for applying margin, 
> padding to inner elements, and dimensionally separating them from its 
> real parent.

That's <div>.

Etymologically, <div> comes from the word "division", which is the result 
of wrapping.


> <header>
>     <div class="wrapper">
>         <h1>Header 1</h1>
>         <p>this content is centered because margin: 0 auto is applied to
> parent of div.wraper element</p>
>         I have always worked, I'm almost standard, sometimes people don't
> call me wraper but 'container' or 'content' instead
>     </div>
> </header>
> 
> *Against:*
> 
> <header>
>     <wrapper>
>         <h1>Header 1</h1>
>         <p>this content is centered because margin: 0 auto is applied to
> parent of wrapper element</p>
>         I think I'm more semantic because I'm specifically designed for this
> task, and I do it very well. What do you think?
>     </wrapper>
> </header>

Yeah. <div> is the right element here. That's what it's for.


> Answer this, Are wrappers purely internal to my(of mine) application? 
> that's a capitalized lie, just think on it. Most applications use a 
> wrapper-like div. You had, and i don't know you.

The spec explicitly says of <div> that it can be used "to mark up 
semantics common to a group of consecutive elements". If that's not 
wrapping, I don't know what is!


> We have to start deciding what do we want from html5, at what degree do 
> we want a more semantic web? why just <header>, why just <footer>.

Because those are commonly styled separately from other parts of the page, 
basically.


> I can assure you the world was fine with <div id="header">, but so, why
> <header> was created for?

It's shorter.


> It was created because being so widely used, somebody believed it was 
> *more semantic* to convert it into an element.

Not really. It was created because being so widely used, it seemed 
convenient to have a shorthand way of doing it.


> > <div> is the wrapper element.  That's its entire purpose for living.  
> 
> <div> was not creating for wrapping things, but for contain them. When 
> you wrap something, you are giving it a different implicit meaning to 
> that wrapper div.

This is splitting hairs thinner than I can see. Wrapping and containing 
are the same thing. :-)


On Mon, 28 Feb 2011, Tab Atkins Jr. wrote:
> 
> Yes, we found a small set of wrappers which were so ubiquitous that it 
> was worthwhile promoting them from a private semantic (only the page 
> itself knows what it's talking about) to a public semantic (everyone 
> knows what a <header> or <section> is).
> 
> I believe you're arguing that the "wrapper" semantic, being similarly 
> ubiquitous, thus needs its own new element as well.  What you're missing 
> is that the "wrapper" semantic is precisely what <div> already 
> expresses.

Indeed.


On Tue, 1 Mar 2011, Markus Ernst wrote:
> 
> I do understand usuario's <wrapper> proposal slightly different from 
> <div>: Section 4.5.13 of the spec generally states that the <div> 
> element is conveying structure, but not semantics.
> 
> Usuario's <wrapper> is not structural, but purely presentational. It 
> should actually not be there at all from an HTML point of view, but is 
> necessary for CSS reasons.

I have no idea what this means. What is the difference between "conveying 
structure" and "conveying semantics" and something being "not structural" 
but instead "purely presentational" at the block level?


On Tue, 1 Mar 2011, usuario wrote:
>
> My idea of wrapper or content was to identify actual content from the 
> rest of the window space. Like <header><wrapper>actual content centered 
> at 960px</wrapper></header>

On Tue, 1 Mar 2011, Bjartur Thorlacius wrote:
>
> That seems like a presentational problem, better solved by fixing the 
> CSS box model or a related technology. It'd be hard to see where to put 
> wrapper elements without knowing the ultimate rendering of the document, 
> causing either a lack of wrappers somewhere, or wrappers being injected 
> everywhere.

Certainly improving CSS would go a long way towards resolving many of 
these "wrapping" issues. There haven't been many good proposals for doing 
this, though (my own proposals being amongst the worst!). If we could find 
a way to wrap things for CSS, it would solve problems across many aspects 
of the language, including e.g. the commonly requested <di> for <dl>.


On Sun, 27 Feb 2011, ddailey wrote:
>
> Why not borrow the <g> from SVG (meaning "to group together" -- the 
> semantics may be a bit more accessible in some cross-linguistic sense 
> than <wrap>, particularly because of the silent "w" in "wrap" which 
> throws a lot of folks for a loop)?
> 
> <g> has very rich semantic connotations inherited from MacDraw, circa 
> 1983, but the distinction between denotative and connotative semantics 
> within HTML5 isn't altogether clear to me. Maybe it is clear in 
> someone's brain.

<g> and <div> are essentially identical, as far as I can tell (modulo 
their specific roles in graphics and text respectively).


> The distinction between <span> and <div> isn't all that obvious since we 
> have CSS N.x waiting in the wings to override whatever behavioral 
> semantics we might offer from script and markup, so perhaps a study of 
> parentheses is in order.

<span> is just the inline version of <div>, that's all. The only 
difference is that <div> introduces line breaks in the default rendering. 
They are otherwise identical.


> Given that SVG and HTML are now interminglable in the same document, why 
> not start intermingling their tag definitions?

Well there's the practical issue of the namespaces, not sure how we'd 
solve that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'