Accessible CSS

This is a “best practices” technique, and doesn’t affect accessibility, but consider the following email excerpt from the CSS Discuss list:

I fail to see how referring to HR by a ‘style’ name is any worse than referring to them by ‘structure’ names, at least in this case. Perhaps I simply don’t understand what is going on here, but the use of ‘thin’ and ‘thick’ make much more sense to me now and probably also in the future. I can just imagine wanting to use a ‘headingRule’ at some point, but deciding that, since this is not a ‘Heading’ I should not. I see and use HR more as a visual aid to differentiate sections, topics, page breaks, and ‘Return to Top of Page’ points than for showing outlines or page structure.

Right. I absolutely understand. I know I was being really picky... However, since I got your attention, I’ll throw out a few more reasons why I suggested the other classes.

You are definitely right to not use a ‘headingRule’ if it is not a heading. That was just my example class since I didn’t know how you were planning to use the HRs. Since you’ve given some more info, I’ll extend the example to include some small but practical benefits.

You mentioned sections, topics, and page breaks. Let’s use those classes for the rules: hr.section, hr.topic, and hr.pageBreak. Now, I’m just guessing, but let’s assume you want ‘topic’ and ‘pageBreak’ to be thick lines and ‘section’ to be a thin line. Instead of ‘hr.thick’ in your CSS, you have ‘hr.topic, hr.pageBreak’, right? They both look the same in a browser, but now you have the added benefit of semantically differentiating between the two different types of HRs. Imagine that you later added a print style sheet. You have a class for page breaks so you can add the following rule to the printer stylesheet.

hr.pageBreak {
  page-break-after:always;
  }


Now you have two different HRs with the same visual style, but a different functional style because of a slightly more semantic class name. Arguably, however you could also have named your classes ‘thick’, ‘thin’, and ‘pageBreak’ with the same effect. The pickiness there comes from a scalability perspective. In your case, I doubt it would make a difference but I'll give the example anyway.

Pretend you are a developer on a large-scale site that utilizes CSS. You set up a class for error messages and named it ‘redtext’. Sometime later, you need to make an style change and decide that the red text should now be blue. Because there are several hundred thousand pages, a re-edit of all the markup is unacceptable for redesigns. You need to be able to change the style of the whole site by modifying one CSS file (or at least that’s what you told your boss when you sold him on the idea of web standards)...

Now you are stuck with a class for blue text that is called ‘red text’. While this is not an error, and probably won’t cause you any confusion, you can already see the irony. Now the other developers come in and have to use/edit your code. It would get to be even more confusing to them when there are 20 or 30 of these rules that have implied style in the classname that doesn’t necessarily relate to how the class is styled. The problem could be resolved by using a class name of ‘error’ from the beginning.