- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 08 Jun 2005 22:07:42 -0400
Christoph P?per wrote: > Matthew Raymond: > >>Christoph P?per wrote: >> >> The <div> (as well as <span>) does indeed have semantic meaning in >>that it can group things. However, in the case of replacing <hr>, I >>don't see how this semantic information can actually be used to benefit >>the user. It's certainly useless on modern browsers from a presentation >>standpoint if I turn CSS off. > > Okay, with the goals of WHAT-WG and HTML5 it's maybe acceptable to > retain 'hr', but for XHTML2, which wants to make a clean re-start, this > unsemantic element type (under whatever name) must go. How is a separator unsemantic? Just because it may be a different way of defining the beginning and end of structure within a document doesn't mean it's unsemantic. >> Oh really? So you're saying that if I have some text... >> >>| Paragraph 3 >>| * * * >>| Paragraph 4 >> >> ...it's more natural for an author to do this... >> >>| <p>Paragraph 3</p> >>| </section> >>| <section> >>| <p>Paragraph 4</p> >> >>(...) instead of this: >> >>| <p>Paragraph 3</p> >>| <hr> >>| <p>Paragraph 4</p> If you're going to quote someone, don't remove portions of the quote without indicating you have done so. > Yes. It's just like > > Foo > <br> > Bar > > versus > > Foo > </p><p> > Bar. The first would yield the following: | Foo | Bar The second would yield this: | Foo | | Bar So it's not even equivalent. Also, consider the fact that while paragraphs have visual queues that can be used to identify them, the sections you speak of have no such identifying presentation, so anyone converting text to HTML is forced to make their own judgment about the scope of the sections. >>| <section> >>| <p>Paragraph 1</p> >>| </section> >>| <section> >>| <p>Meanwhile, Paragraph 2</p> >>| <p>Paragraph 3</p> >>| </section> >>| <section> >>| <p>Paragraph 4</p> >>| <p>Paragraph 5</p> >>| </section> >>| <section> >>| <p>At the same time, Paragraph 6</p> >>| </section> > > That's why I said that you could also use 'class' on 'p' instead of > 'div' around 'p' to do the grouping. So now the web author not only am I forced to define sections and CSS for the sections just to get a separator, but I have to give the sections names as well... > I also don't see a problem with > 'div' here, though, because it does just have to group the perspectives > inside a chapter. Of course you would have to add 'div' in all 'section' > of a kind---it doesn't make sense to add that structural layer only > where you want visual separators (at the moment). Sure it does. If I want to treat a chapter as one big, flat section, and the only exception is where I have the separator, then it makes perfect sense. > I know that dropping > 'hr' means more mark-up, but also better. If the markup isn't used, then more is worse. Period. >>>in all the alledged use cases that have >>>presented in favor of 'hr' or 'separator', I see a structure (or >>>hierarchy), that demands not a divider but a grouper. >> >>The presentation doesn't demand grouping, it demands a separator. > > No, it demands visual /separation/. No, the separation could be aural. Or you could use it to insert content, link "...Meanwhile...". > A separator like 'hr' is just one > way to achieve this. Perhaps the main problem for many (here) is, that > current browsers don't render adjacent 'div' notably. Of course they don't. The <div> element is essentially a generic element for styling. It's semantically a blank slate. That's why we need things like <section> elements. >> I can't think of any behavior implied by <hr>, and you don't >>provide a use case for why we need the extra grouping elements or how >>they will be used. > > I don't want extra grouping element types (if you meant that), 'div' is > just fine. No, I'm referring to the use of grouping element of any type to replace <hr>. Unless the author intends to specifically do something with those grouping elements, the they've created "superior" markup structure that serves only to duplicate the presentation of <hr> via CSS. > I already gave examples like extraction or background visuals or audio; > many other stylings are possible (e.g. alternating alignment). The problem here isn't about how powerful CSS can be. The problem is that scenarios where you'd need to use that kind of power probably don't fit the use case for <hr>.
Received on Wednesday, 8 June 2005 19:07:42 UTC