Re: [WSG] semantics : was-[HR tag and Semantics]
On 07/02/07, Designer [EMAIL PROTECTED] wrote: I feel very restricted by the use of div (even with a descriptive identifier or class) because div means very little. I'm glad we have such things as p (and the rest!) because they make code easier to read. Well, the thing with a separator is, it doesn't in itself specify anything else than that the content on one side belongs does not belong to the same grouping as the content on the other side. But if you instead mark up each grouping with the appropriate semantical element, then you get the separation with the boundary. And while a separator element doesn't tell you at which semantic level the separation is, wrapping semantical elements for the content before and after the separation clearly specify this. The separator element signifies LESS than div element boundaries do, because the divs at least tell you at which level the separation takes place. However, a separator element can be used to strengthen the semantic importance of that boundary if placed between the wrapping elements. However, consider a node tree like this: h1 p h2 p h3 p hr p hr p.copyright Okay, we can assume the copyright paragraph is conceptually at top level, since it's likely a footer. Could a machine tell? No, because the hr doesn't give any information more than it being a separator, not at what level the separation takes place. It's our knowledge of language that tells us it probably doesn't belong to the content sections of the h1, the h2 or the h3 however. But tell me, the paragraph before that hr, does that paragraph belong conceptually at the top level, at the h1, the h2 or the h3 level? Compare to this: section h p section h p section h p separator (redundant) p separator (redundant) p.copyright Suddenly, the separation by wrapper boundaries makes it very clear at which level the separation takes place. The separator elements are redundant, but can be used to emphasise the conceptual separation. And if you want an emphasis on the separation level, a better choice would be to wrap the paragraphs in question by a headless section element instead of preceding them with a separator element. Roll on xhtml 5! However I suspect this is way way down the line and everything will have changed anyway. Well, if by XHTML 5 you mean WA1.0, then it'll probably be a standard years before you can find two implementations, not to speak of interoperable implementations, of XHTML 2. In the meantime, the less divs I can use, the better . . . As long as there's something that semantically fits better than this content is conceptually closer grouped than the surrounding content, go ahead. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] semantics : was-[HR tag and Semantics]
@liorean:
We're getting somewhere! You suggest that separators are an aberration,
something inherently ambiguous (and this ambiguity is not desired) and
we should use this opportunity to get rid of it.
The problem, again (if I may be so bold), is that you don't actually
believe the horizontal rule was ever useful. Instead, like many people
arguing against it, you suggest that all instances of its use are in
fact better replaced with alternatives.
In your example you suggest that these separators denote depth, coming
at the end of nested containers - Rob used them as objects appearing
above headings (and yet they were properties of whichever element
preceded the headings): You're giving us crisps when we want chocolate,
and adding chocolate flavouring to the crisps isn't going to make anyone
happy!
If I'm to play this game (may as well), I would suggest this:
div class=grouping
p/p
p/p
p/p
/div
div class=grouping
p/p
/div
.grouping + .grouping:before{content: [separator]}
This is better than Rob's and your examples because it doesn't assume
the separator is incidental to the presence of other objects, which
cause some kind of separation anyway.
I think the 'grouping' element is still unnecessary - it creates a
superfluous element. With this method, the author would have to be in a
'grouping' at all times, and would create a separation by closing it and
starting a new one - but the author shouldn't have to create the
grouping in the first place, to account for the fact that they may at
some point desire a separator.
I use this example to prove to points:
1) Semantically, the separator object does not rely on the attributes or
pre-defined relationships of other elements. Therefore it needs its own
specific indicating element.
2) The simplest, cleanest and most logical way to implement this element
is to have a literal separator tag.
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] semantics : was-[HR tag and Semantics]
On 07/02/07, Jens Brueckmann [EMAIL PROTECTED] wrote: On 07/02/07, liorean [EMAIL PROTECTED] wrote: But if you instead mark up each grouping with the appropriate semantical element, then you get the separation with the boundary. I do question this. The boundary is void, nothing, whereas a specific element denoting a separation of two different sections is itsself part of the overall content. Well, it could be a conclusion, and ending. Or for that matter a beginning, a clean break. Or the transition, if the boundary is fuzzy. If either of the first two, it should probably be part of the grouping it concludes or begins. If the third, I'm not sure there's any semantically fitting element. Maybe the transition itself should be a separate, short, grouping of it's own. In this case, the separator element is possibly even the best solution. Monty Python's Flying Circus would certainly miss something if the words And Now For Something Completely Different did not exist. This phrase is actually a separator, it has meaning. I think the same applies to separators in markup. Well, that is what I would call a transition. And you're right, it's a separator. But it's also content. It's definitely say it's not equivalent to an hr; the hr may be a separation semantically, but it isn't content. The problem of trying to fit a greyscale world - or maybe even hsla colour with gamma correction - into black and white. Markup always has the problem of trying to put semantics to well defined areas, excluding it outside those areas. -- David liorean Andersson *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] semantics : was-[HR tag and Semantics]
-Original Message-
From: listdad@webstandardsgroup.org
[mailto:[EMAIL PROTECTED] On Behalf Of liorean
Sent: Wednesday, February 07, 2007 12:47 PM
To: wsg@webstandardsgroup.org
Subject: Re: [WSG] semantics : was-[HR tag and Semantics]
snip
div class=grouping
p/p
p/p
p/p
/div
div class=grouping
p/p
/div
.grouping + .grouping:before{content: [separator]}
This is better than Rob's and your examples because it
doesn't assume
the separator is incidental to the presence of other objects, which
cause some kind of separation anyway.
In fact, that is exactly the use I think my example was indicating was
a better idea - semantically. It's a bit more code, true. It's a bit
more hassle, true. It's a lot more descriptive semantically.
No, no, no! A DIV is semantically neutral, ie has no meaning
whatsoever. The addition of a class name does not change that. So how
can a pair of DIV's have more meaning than a specific HTML element?
Even if you could answer that correctly, the above example is completely
inaccessible, whereas a distinct element used correctly cannot possible
be more accessible.
Regards,
Mike
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] semantics : was-[HR tag and Semantics]
[EMAIL PROTECTED] wrote: No, no, no! A DIV is semantically neutral, ie has no meaning whatsoever. The addition of a class name does not change that. So how can a pair of DIV's have more meaning than a specific HTML element? I think what liorean means by more semantic is that the meaning of two items of text divided by grouping is clearer to her than two items of text divided by a divider. But you're essentially right in your thrust - that by introducing a solid element that would otherwise only be hinted at through styles and class, we are creating a semantic object rather than simulating one using less meaningful methods. Even if you could answer that correctly, the above example is completely inaccessible, whereas a distinct element used correctly cannot possible be more accessible. I beg your pardon? If paragraphs inside classed divs are inaccessible, we've got a bit of a global disaster on our hands. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] semantics : was-[HR tag and Semantics]
Martin Heiden wrote: I admit that the HR is an expression of the fact that something is finished, but I doubt that this as easy to understand as some text. Please don't admit this, it's not true. Everybody from the anti-HR camp seems to be saying Why create an object to signify an end, when you could have you DIV and end /it/? - but that's not what HRs do. There is no end. There is a break. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] semantics : was-[HR tag and Semantics]
liorean wrote: How is an element any more accessible (theoretically of course, considering how bad the support situation for generated content and styling of pseudo elements is) than a pseudo element? The question half answers itself - one is real, the other pseudo (Def: being apparently rather than actually as stated - Merriam-Webster Online Dictionary). Using pseudo elements and CSS will give you a visual rendering that is not always going to be exposed to various forms of adaptive technology - the elements are not real. Or, as Andrew said, ...has semantic value/is content: the meaning may be subtle but nevertheless IS meaning. Earlier in this thread, I reported how the current batch of mainstream screen readers are currently processing the hr / element. While we may not be happy or agree with their implementation, the simple fact remains that there is an element in the DOM that these tools acknowledge and process - how and why the do what they do is a secondary conversation/thread. We can discuss the appropriateness of a separator element or a soon-to-be deprecated Horizontal rule element, and it's role in (visual) semantic structure, but to me we must also consider it's role in the DOM hierarchy, and what role it may play there. This is something that CSS pseudo styling cannot yet address, and may in fact never. JF *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] semantics : was-[HR tag and Semantics]
Oh dear god, can someone please stick a fork in this thread... it's long past done. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
