Re: [whatwg] wrapper element
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 ? On Sun, 27 Feb 2011, Jukka K. Korpela wrote: > > I guess you mean a group that is not best describable as or > or 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 or , but if those don't apply naturally, it should > be . It is better to be semantically empty than to be semantically > wrong, or even bordeline. Indeed. > Thinking purely logically (if we dare), would have the benefit > of explicitly saying "this is a wrapper for grouping, for no semantic > reason", thereby distinguishing it from which may, and often does, > involve semantic or logical grouping. For example, 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 . Moreover, I don't > think people would use much, since they can use and are > accustomed to . Indeed. Also, grouping is, to some extent, a semantic reason. It's rare that people wrap completely unrelated things in a just for the sake of it. On Mon, 28 Feb 2011, Tab Atkins Jr. wrote: > > 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. > > 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 . Etymologically, comes from the word "division", which is the result of wrapping. > > > Header 1 > this content is centered because margin: 0 auto is applied to > parent of div.wraper element > I have always worked, I'm almost standard, sometimes people don't > call me wraper but 'container' or 'content' instead > > > > *Against:* > > > > Header 1 > this content is centered because margin: 0 auto is applied to > parent of wrapper element > I think I'm more semantic because I'm specifically designed for this > task, and I do it very well. What do you think? > > Yeah. 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 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 , why just . Because those are commonly styled separately from other parts of the page, basically. > I can assure you the world was fine with , but so, why > 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. > > is the wrapper element. That's its entire purpose for living. > > 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 or 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 already > expresses. Indeed. On Tue, 1 Mar 2011, Markus Ernst wrote: > > I do un
Re: [whatwg] wrapper element
Am 01.03.2011 23:50 schrieb Jordan Dobson:
On Tue, Mar 1, 2011 at 2:03 PM, Markus Ernst wrote:
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.:
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 already
expresses.
I do understand usuario's proposal slightly different from:
Section 4.5.13 of the spec generally states that the element is
conveying structure, but not semantics.
Usuario's 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.
Isn't that what the section::outside{ ... } is for? Presentational pseudo
elements in CSS?
http://www.w3.org/TR/css3-content/#wrapping
Granted it's not available as far as I know... but it seems like it meets
usario's needs.
::outside covers only a part of the use cases for wrapping elements -
wrapper containing more than one child elements cannot be replaced by
::outside - consider the very common case of a centered page:
#container { margin:0 auto; width:50em; position:relative }
#contents { margin-left:10em }
nav{ position:absolute; top:50px; left:0; width:9em }
This case would require some kind of body::inside pseudo element, which
I cannot find in the CSS3 Generated and Replaced Content Module spec
right now. (Well, sorry if I get too much off-topic now.)
Re: [whatwg] wrapper element
On Tue, Mar 1, 2011 at 2:03 PM, Markus Ernst wrote:
> Am 28.02.2011 19:56 schrieb Tab Atkins Jr.:
>
>
>> 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 already
>> expresses.
>>
>
> I do understand usuario's proposal slightly different from :
> Section 4.5.13 of the spec generally states that the element is
> conveying structure, but not semantics.
>
> Usuario's 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.
>
Isn't that what the section::outside{ ... } is for? Presentational pseudo
elements in CSS?
http://www.w3.org/TR/css3-content/#wrapping
Granted it's not available as far as I know... but it seems like it meets
usario's needs.
- Jordan
>
> I agree with Bjartur Thorlacius' point that it makes more sense to enhance
> CSS the way that presentational markup gets totally obsolete in the future -
> but the idea of an element that is explicitly non-structural does not look
> that odd to me.
>
--
Jordan Dobson • Designer / Developer • 425-444-8014 •
About.Me/JordanDobson
Re: [whatwg] wrapper element
Am 28.02.2011 19:56 schrieb Tab Atkins Jr.: 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 already expresses. I do understand usuario's proposal slightly different from : Section 4.5.13 of the spec generally states that the element is conveying structure, but not semantics. Usuario's 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 agree with Bjartur Thorlacius' point that it makes more sense to enhance CSS the way that presentational markup gets totally obsolete in the future - but the idea of an element that is explicitly non-structural does not look that odd to me.
Re: [whatwg] wrapper element
On 3/1/11, usuario wrote: > [resending reply, sorry again with problems] > My idea of wrapper or content was to identify actual content from the rest > of the window space. Like actual content centered at > 960px > 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. If you need compatibility, consider using JavaScript element injection. > Thanks, I hope i can still contribute to the list, even if my thoughts seem > odd. > Straight from my mind, and the reason I'm here.
Re: [whatwg] wrapper element
[resending reply, sorry again with problems]
My idea of wrapper or content was to identify actual content from the rest
of the window space. Like actual content centered at
960px
Thanks, I hope i can still contribute to the list, even if my thoughts seem
odd.
2011/2/28 Ashley Sheridan
> On Mon, 2011-02-28 at 18:46 +, usuario wrote:
>
> [Had problems sending my mails to the list, resending message]
>
> Some of you may be questioning why a wrapper element if it has not
> semantics, the thing is, It DO have semantics.
>
> 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.
>
> *example, consider:*
>
>
>
> Header 1
> this content is centered because margin: 0 auto is applied to
> parent of div.wraper element
> I have always worked, I'm almost standard, sometimes people don't
> call me wraper but 'container' or 'content' instead
>
>
>
> *Against:*
>
>
>
> Header 1
> this content is centered because margin: 0 auto is applied to
> parent of wrapper element
> I think I'm more semantic because I'm specifically designed for this
> task, and I do it very well. What do you think?
>
>
>
> Moreover.
>
> > Why not borrow the from SVG (meaning "to group together" -- the
> > semantics may be a bit more accessible in some cross-linguistic sense than
> > , particularly because of the silent "w" in "wrap" which throws a lot
> > of folks for a loop)?
> >
>
> Don't know if that's the solution, i just don't discard it.
>
>
> > 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.
> >
>
> We have no problems with definition. But i think you are not right in
> your statement.
> 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.
>
> We have to start deciding what do we want from html5, at what degree do we
> want a more semantic web? why just , why just .
>
> I can assure you the world was fine with , but so, why
> was created for? It was created because being so widely used,
> somebody believed it was *more semantic* to convert it into an element.
>
> is the wrapper element. That's its entire purpose for living. ^_^
> >
>
> 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.
>
>
>
> By it's very nature a tag is a wrapper already. Your above code could
> be written as:
>
>
>
>
> Header 1
> this content is centered because margin: 0 auto is applied to
> parent of div.wraper element
> I have always worked, I'm almost standard, sometimes people don't
> call me wraper but 'container' or 'content' instead
>
>
>
> And the CSS used to reference the elements would be
>
> header div{/* css here */}
> header div h1{/* css here */}
> header div p{/* css here */}
>
> Your proposed wrapper serves no semantic purpose other than grouping the H1
> and p tags together, but if they are the only siblings of any element that
> is already happening, there's no need to call the element a wrapper, it is
> one anyway.
>
> I don't understand the difference in your context of wrapper and container,
> but it seems to me one is a synonym for the other.
>
> --
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
Re: [whatwg] wrapper element
On Mon, Feb 28, 2011 at 10:46 AM, usuario wrote: >> 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. > > We have no problems with definition. But i think you are not right in > your statement. > 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. > > We have to start deciding what do we want from html5, at what degree do we > want a more semantic web? why just , why just . > > I can assure you the world was fine with , but so, why > was created for? It was created because being so widely used, > somebody believed it was more semantic to convert it into an element. 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 or 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 already expresses. >> is the wrapper element. That's its entire purpose for living. ^_^ > > 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. I don't understand the difference between "wrapping" and "containing" something. ~TJ
Re: [whatwg] wrapper element
On Mon, 2011-02-28 at 18:46 +, usuario wrote:
> [Had problems sending my mails to the list, resending message]
>
> Some of you may be questioning why a wrapper element if it has not
> semantics, the thing is, It DO have semantics.
>
> 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.
>
> *example, consider:*
>
>
>
> Header 1
> this content is centered because margin: 0 auto is applied to
> parent of div.wraper element
> I have always worked, I'm almost standard, sometimes people don't
> call me wraper but 'container' or 'content' instead
>
>
>
> *Against:*
>
>
>
> Header 1
> this content is centered because margin: 0 auto is applied to
> parent of wrapper element
> I think I'm more semantic because I'm specifically designed for this
> task, and I do it very well. What do you think?
>
>
>
> Moreover.
>
> > Why not borrow the from SVG (meaning "to group together" -- the
> > semantics may be a bit more accessible in some cross-linguistic sense than
> > , particularly because of the silent "w" in "wrap" which throws a lot
> > of folks for a loop)?
> >
>
> Don't know if that's the solution, i just don't discard it.
>
>
> > 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.
> >
>
> We have no problems with definition. But i think you are not right in
> your statement.
> 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.
>
> We have to start deciding what do we want from html5, at what degree do we
> want a more semantic web? why just , why just .
>
> I can assure you the world was fine with , but so, why
> was created for? It was created because being so widely used,
> somebody believed it was *more semantic* to convert it into an element.
>
> is the wrapper element. That's its entire purpose for living. ^_^
> >
>
> 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.
By it's very nature a tag is a wrapper already. Your above code
could be written as:
Header 1
this content is centered because margin: 0 auto is applied to
parent of div.wraper element
I have always worked, I'm almost standard, sometimes people
don't
call me wraper but 'container' or 'content' instead
And the CSS used to reference the elements would be
header div{/* css here */}
header div h1{/* css here */}
header div p{/* css here */}
Your proposed wrapper serves no semantic purpose other than grouping the
H1 and p tags together, but if they are the only siblings of any element
that is already happening, there's no need to call the element a
wrapper, it is one anyway.
I don't understand the difference in your context of wrapper and
container, but it seems to me one is a synonym for the other.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
Re: [whatwg] wrapper element
[Had problems sending my mails to the list, resending message] Some of you may be questioning why a wrapper element if it has not semantics, the thing is, It DO have semantics. 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. *example, consider:* Header 1 this content is centered because margin: 0 auto is applied to parent of div.wraper element I have always worked, I'm almost standard, sometimes people don't call me wraper but 'container' or 'content' instead *Against:* Header 1 this content is centered because margin: 0 auto is applied to parent of wrapper element I think I'm more semantic because I'm specifically designed for this task, and I do it very well. What do you think? Moreover. > Why not borrow the from SVG (meaning "to group together" -- the > semantics may be a bit more accessible in some cross-linguistic sense than > , particularly because of the silent "w" in "wrap" which throws a lot > of folks for a loop)? > Don't know if that's the solution, i just don't discard it. > 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. > We have no problems with definition. But i think you are not right in your statement. 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. We have to start deciding what do we want from html5, at what degree do we want a more semantic web? why just , why just . I can assure you the world was fine with , but so, why was created for? It was created because being so widely used, somebody believed it was *more semantic* to convert it into an element. is the wrapper element. That's its entire purpose for living. ^_^ > 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.
Re: [whatwg] wrapper element
On Sun, Feb 27, 2011 at 12:46 PM, Jukka K. Korpela wrote: > Bjartur Thorlacius wrote: > [quotation reorganized by me] >> What semantics would such an wrapper element provide over ? I'd >> rather discourage, and provide alternative features to wrapping. >> Providing another element for that purpose goes against that. > > Thinking purely logically (if we dare), would have the benefit of > explicitly saying "this is a wrapper for grouping, for no semantic reason", > thereby distinguishing it from which may, and often does, involve > semantic or logical grouping. 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. is the wrapper element. That's its entire purpose for living. ^_^ ~TJ
Re: [whatwg] wrapper element
I agree with Bjartur, does the work fine. On Sun, 27 Feb 2011 19:40:15 -0500, ddailey wrote: Given that SVG and HTML are now interminglable in the same document, why not start intermingling their tag definitions? Please don't start mixing SVG+HTML properties or one day it will be a hell of a mess..
Re: [whatwg] wrapper element
Why not borrow the from SVG (meaning "to group together" -- the semantics may be a bit more accessible in some cross-linguistic sense than , particularly because of the silent "w" in "wrap" which throws a lot of folks for a loop)? 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. The distinction between and 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. My first study of parentheses in the 1970's suggested there were at least twelve different kinds, including all the obvious mathematical ones. Why might you wish to group things? If the grouping is presentational, then that would be one obvious category; if it is semantic, then that would be another, at least according to the zeitgeist. Given that SVG and HTML are now interminglable in the same document, why not start intermingling their tag definitions? cheers David - Original Message - From: "usuario" To: Sent: Sunday, February 27, 2011 3:20 PM Subject: [whatwg] wrapper element 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?
Re: [whatwg] wrapper element
Bjartur Thorlacius wrote: [quotation reorganized by me] On 2/27/11, 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? If said wrappers don't have any semantics but grouping loosely related elements, for which no semantic container exists, div seems appropriate. I guess you mean a group that is not best describable as or or 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 or , but if those don't apply naturally, it should be . It is better to be semantically empty than to be semantically wrong, or even bordeline. What semantics would such an wrapper element provide over ? I'd rather discourage, and provide alternative features to wrapping. Providing another element for that purpose goes against that. Thinking purely logically (if we dare), would have the benefit of explicitly saying "this is a wrapper for grouping, for no semantic reason", thereby distinguishing it from which may, and often does, involve semantic or logical grouping. For example, 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 . Moreover, I don't think people would use much, since they can use and are accustomed to . -- Yucca, http://www.cs.tut.fi/~jkorpela/
Re: [whatwg] wrapper element
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 ? I'd rather discourage, and provide alternative features to wrapping. Providing another element for that purpose goes against that. On 2/27/11, 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? >
[whatwg] wrapper element
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?
