CSS usage with the hr element

[batti3004]

Hi, i have a problem, i use a hr on my site with css it works on all browsers exept ie6-7, what can i do?

{
  border-bottom: solid #ffcc66; 
  width: 81%; 
  margin:0 0 0 auto; 
  margin-top: 5pt; 
  margin-bottom: 5pt; 
padding-left: 5pt;
}

[alt131]

the w3schools page I quoted suggests the opposite

It does too! Also the draft is changing, so that could be the reason, but reassuring (not great), that others are noting the same issues.

I meant more that it's not a container

I ignored the container part of your comment because there are a lot of elements that don't need to be closed, so I think the distinction is a bit arbitrary. I think it was xhtml that put the focus on making elements are closed, but that's about code processing, not semantics.

- most other elements are given context by what they contain, they are inherently linked to a piece of content by containing it - where as the HR depends on being preceded and followed by text content in order to have a semantic meaning.

Again, not to be picky, but I believe it is exactly the opposite: content is placed in context by using semantically correct html elements. In simple terms, a para and a heading will always look like a para and a heading in the content. They gain context in html by marking them up using the semantically correct <p> and <hx>.

An hr (like any element) always has meaning/semantics - it separates (and signals) a low-level change of theme in the content. So the question isn't "does an hr have meaning if it isn't preceded/followed by text content?". The question is "has the theme of the content changed so it is necessary to signal that change by inserting an hr?".. or developing Suzy's approach: "is there a natural pause in the content that should be signalled to the user by inserting an hr separator"

The ideal way to use HRs for me would be with :before or :after selectors.

Nope ;) That's exactly what I don't think is helpful. Leaving aside the idea of pre-processors (where we write everything as a text file and run it through a pre-processor that inserts the html before pushing it to the user agent), to me that approach is based in using elements as a way to achieve style, not looking at the content and marking it up using the semantically correct html. However, I think the exciting point you make is how the new selectors make it so easy to signal structural changes to visual users without the need for masses of classing.

Also, as we've figured, hr is not at the level of separating <section>s, but at the level of para's. Has the draft changed? ... I drop in an out of the evolution as I can't use html5 yet, but I distinctly recall thinking I would be coding things like:
<section>
<article> </article>
<article>
<aside> </aside>
</article>
</section>
.. there was even an article posted at sitepoint that used that structure. But reading the draft in the course of this discussion, I'm now sure its more <section> OR <article> ... OR (the really fun part <div> ;)

Suzy, I think you're brave - I looked at headings and chose denial ;) The BIG issue in the article you linked was whether <section> should be nested at all. My reading of the current version of the draft suggests not. Now wonder if that's a job for <article>, or, depending on the reason for the distinction, maybe a <div> Sheesh.

However, most of the issues being discussed seem rooted in the overall code structure. One test has always been the document outline, so I'm off to read the "outline" section (not <section> ;) ) of the draft. Looking for clarification on how these "blobs" ;) relate to each other

[milosevic]

I can see what you are saying ƒ,

But I think we will have to agree to disagree about usage of <hr>s! ;)

I feel if the semantic use of <hr>s is limited to screenreaders, there should be an element called <pause> or something for this. Even that would not be as good as a CSS property "pause-before" or "pause-after", which would completely remove any structural aspect from markup.

Is a pause (silence) an actual semantic meaning anyway, or the audio equivalent of structural markup? It means literally and technically nothing without proceeding and following unconnected content, unlike other elements like <form>, <article>, <title>, <h1> etc.

Thinking about it, it's logical that with html5 in particular, a screenreader would pause between different <section>s of content. Stating that there is a pause should not be necessary with HTML5 unless the pause is in the middle of an element (in which case, is it semantic, and shouldn't you be subdividing the element rather than using a hr?)

<hr> to me seems to be a structural element with a semantic meaning 'bolted on' to it, a compromise.

[SuzyUK]

I tackled the HTML5 blogs again ;)

and I think I see it, the end of <sections> are meant to be a semantic pause but not necessarily an actual <hr>, i.e. the end of <section>s will, or should denote a natural low level thematic change

but <section>'s are intended to be nested as it would seem that the semantic wish for them is to dictate a logical hierarchy, like the DOM.. apparently it's recommended that only H1's should be used ever.. but their actual heading level, i.e. per the HTML H1-H6 values is ascertained by how deep the section they are in is nested, : see HTML5 Heading demo [brucelawson.co.uk] for a better explanation, and follow through to the outliner as this shows quite clearly the "levels"

So it wouldn't necessarily be feasible to expect the end of EVERY section to be the equivalent of the <hr> though you may want to style one as a visual separator as a background to the outermost one.

My reading suggest, to me anyway, that there is still a place albeit reduced for an actual <hr> to be used - but it's not a change in <section>.

<sections> should always have a heading apparently, but poetry or change of tack especially within a chapter of a book may not have a heading, when you're reading a book you often see a change of "scene" indicated by flourish/separator within a single page without a heading (chapter or verse title) .. this would appear to be the only use left for the <hr> element.. once, that is, all browsers/SE's/screenreaders are <section> aware ;)

The advantage of section aware heading does appear to be numerous should make the "should I use more than h1 on my page discussions redundant, thankfully ;)

the idea is that when you pull in content to an existing web page, you wrap it in a section of it's own, the hierarchy of the page then re-adjusts itself per the number of <section>s there is..

phew.. well that's my interpretation anyway, so I'm sticking with pretty hr's for now, as technically all they're doing is being the "end" of where a main <section> is likely to be anyhow

milosevic, there does seem to be a "bolt on" or a least a subtle change in the role of <hr> no longer is it just a "horizontal rule" it is now a "thematic break".. though if this discussion [html5doctor.com] is anything to go by it's still not clear, I would suggest that "paragraph level" is still a bit misleading, I think it's easier to think about whether or not your "section" (not <section>) has a heading is possibly the easier way to tell :o

[alt131]

The section on outlining didn't help much, but the current draft [w3.org] makes it quite clear <hr> is not used between sections - for the reasons identified by Suzy. Simply, they would be a redundancy. Also, they are flow level, not sectioning content - which as I read the draft, means they belong inside a <section>, (or other sectioning content), not between. But I couldn't find anything that required a non-visual user agent to "pause" for either the end of sectioning content, or hr. What am I missing?

I'm not seeing a "bolt on" semantic meaning. (But I like the phrase very much.) <hr> has always had a meaning because it has always been a horizontal rule used to indicate a change. The difference in html5 is that it provides some "higher order" sectioning elements to mark-up some of those changes - case in point is <section> - which I think reinforces hr is to be used per its original use in print. The example SuzyUk used is exactly the one that struck me, right down to writing a first post using the phrase "change of "scene".

All that also explains why <hr> does not affect the document outline - something that puzzled me at first.

In terms of semantics though, the semantics of <hr> have never been limited to screen-readers because the pause is not the meaning - just the equivalent in the same way mandarin uses characters, sign uses hand/face/body movements. <hr> 's do have literal and technical meaning on their own - the relevance of preceding/following content isn't an aspect of the semantics of the element, it's an issue of whether the element has been used in the semantically correct manner. On hard analysis, few elements have meaning in isolation. For eg, an h1 sitting on a page with no other content is actually meaningless because nothing has been intituled. But the critical issue is that if content is marked up using the semantically correct element then the user agent knows how to signal that meaning to the user. So I disagree milosevic, but thanks for the opportunity to think this through!
Suzy, thanks for confirming <sections> can be nested. That was the result of my further reading too. And that sectioning content can usually be identified by having a heading. Now its the relationship between the "sectioning content" elements that needs to be figured out - which was a tangential point made much earlier . I've decided to remain in denial about headings for a bit longer ;)

[milosevic]

because the pause is not the meaning - just the equivalent in the same way mandarin uses characters, sign uses hand/face/body movements.

Good point and something I hadn't really considered!

an h1 sitting on a page with no other content is actually meaningless because nothing has been intituled.p

This is quite a philosophical point I think. I will have to concede to you because while it seems like a heading without following content is obviously missing something, technically you could say that a <hr> on it's own is missing preceding and following content, which objectively isn't really any different.

Thanks for that Excellent link @SuzyUK, I think I need to read that HTML5doctor site regularly!

I particularly like how the <small> element will now have semantic meaning - this is something I have been trying to use more in my coding recently anyway to allow simpler CSS.