Styling headings is either a deceptively complex problem, or maybe the design of CSS made it appear complex when it need not have done.
When styling headings (or really anything) we want three big goals to be met:
- DRY – Do not repeat yourself. We want to set headings once and never (ok, rarely!) repeat those font styles or selectors. This will make our site easier to maintain.
- Predictable – The heading should look the same no matter where on the page it is placed. This will make creating new pages and content easier.
- Keep specificity low and selectors as simple as possible. This will help with performance and keep the site from growing more and more tangled over time.
The html5 section tag is weird. It dramatically changes the way we use headings. It also changes the way browsers and assistive technologies are meant to interpret those headings. The spec says:
“The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.”
The HTML5 Spec
The spec goes on to warn us that sections are not really meant to be used just because you want to attach a style a particular piece of content:
“The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.”
The HTML5 Spec
People seem to have blocked out this last (very important) bit, so I’ll reiterate. Sections aren’t really meant to be used by CSS for style purposes (at least not *only* for styles). So, if sections aren’t meant to be used to make my headings purty, why do they exist? They change the way the browser and assistive technologies interpret the importance of a heading relative to the other headings on the page. To understand this, you need to know a bit about the pitfalls of the way headings have been written up until now.
HTML Headings
Think back to the outlines you wrote for term papers in high school. Each bit of a website is meant to be like that, each heading corresponds to a piece of that outline, and you know when you go up or down a level by the heading level chosen. H2 is down one level from H1. And h6 is down four levels from H2.
THE TITLE IS THE H1
I. Big roman numerals are the H2s
A. This is an h3
B. This is also and h3
i. Now we have an h4
ii. And another h4
II. Big roman numerals are the H2s
III. Big roman numerals are the H2s
IV. Big roman numerals are the H2s
The trouble is, on a modern website or web app, this model isn’t a really natural fit. Especially if a site “mashes up” content from sources they don’t control (say for example adding a twitter feed to a blog), they may not be able to set the heading levels used by the mashup content. In this case, most developers, just include the new content, and the outline gets a little murkier.
A murky outline may be somewhat normal, because I’d take it a step further and say that, on most modern websites, the idea that the site has much in common with a high school term paper outline is a bit of a stretch — The section element tries to bridge the gap between the w3c’s outline view of the web and the way developers are really building sites. The section element essentially reorders the heading tree so that whatever headings are used, if they are wrapped in a section element, they will be made to fit in with other content on the page. They need only be internally consistent within each section.
<h2>Me on the web...</h2> <h1>My Twitter Feed</h1> <ul class="tweets"> <li>Mmmm, cornflakes.</li> <li>Something inane...</li> </ul> <p><a href="more.html">More stuff on the web</a></p>
HTML5 Headings & Section Elements
If you wrap it in a section, the browser will interpret it as one level down from it’s parent heading.
<h2>Me on the web...</h2> <section> <h1>My Twitter Feed</h1> <ul class="tweets"> <li>Mmmm, cornflakes.</li> <li>Something inane...</li> </ul> </section> <p><a href="more.html">More stuff on the web</a></p>
The section element also makes it clear that the list of tweets belongs to the Twitter feed, and the more link does not. This makes content more portable, which is okay — even if it maybe isn’t that important. However, it does seem to be confusing people about how they should style their headings. I think this bit of the spec might be confusing people:
Notice how the use of section means that the author can use h1 elements throughout, without having to worry about whether a particular section is at the top level, the second level, the third level, and so on.
The HTML5 Spec
This has lead people to think that they should only ever use h1s (which, is a fair interpretation of the working group’s note). However, lots of people have taken it a little too far because they didn’t read the second quote [1], where it says additional section elements shouldn’t really be used only to apply CSS styles. Admittedly a subtle difference, but important! Section elements are meant to help the browser figure out what level the heading really is, but not necessarily to decide how to style it. By tying styles to browser heading level interpretation, developers (trying to implement html5 from the spec) are ending up with selectors that look like this:
h1{font-size: 36px}
section h1{font-size: 28px}
section section h1{font-size: 22px}
section section section h1{font-size: 18px}
section section section section h1{font-size: 16px}
section section section section section h1{font-size: 14px}
section section section section section section h1{font-size: 13px}
section section section section section section section h1{font-size: 11px}
(Note: This is vastly simplified as I’ve only included sections and not the other sectioning elements like articles or asides. This is a more realistic, real life code sample.)
Let’s see how well this meets our goals:
Q: What if, semantically speaking, you need to add an additional section to a bit of html?
It will unintentionally change the way your headings look. If it is high enough on the document tree it could change your entire page. That seems badly unpredictable.
Q: What happens if the design calls for a 14px heading in a part of the site that is only nested two sectioning contents deep?
To make it work with the existing code, you would need to add additional unnecessary section elements. The spec pretty clearly states that section elements are not meant to be added just to change styles. Plus, that is just kind of gross.
Q: What if we create another rule that duplicates the 14px property value pair?
section.special section h1 {font-size:14px}
This clearly isn’t DRY. We’re repeating the code to set the font-size to 14px, and our specificity is starting to get weird. If we want a normal two-section deep heading (22px) we now can’t have it in the special section. We also can’t reuse the new rule anywhere else. Continue in this direction for a while on a project and you can end up with hundreds or even thousands of heading declarations. Eek! This isn’t meeting our stated goals at all.
(For more info about how this can get out of control, check out this video on how our current methods for styling headings are leading to bad outcomes.)
So, how do we style headings in an HTML5 world?
The answer is right there in the spec, next to the place where we learned to use only H1s. We shouldn’t use sectioning elements for styling. We should let them do the job they were designed for, which is sorting out the document tree, and solve styling issues another way that meets our goals better: with simple reusable class names that can be applied to any of our headings no matter how deep they may be in the sectioning content.
I recommend abstracting site wide headings into classes because then they are portable, predictable, and dry. You can call them anything you like. Jeremy Keith recommends something like:
.Alpha {}
.Beta {}
.Gamma {}
.Delta {}
.Epsilon {}
.Zeta {}
or
.tera {}
.giga {}
.mega {}
.kilo {}
.hecto {}
.deca {}
.deci {}
.centi {}
.milli {}
.micro {}
.nano {}
.pico {}
I keep it simple with:
.h1{}
.h2{}
.h3{}
.h4{}
.h5{}
.h6{}
It doesn’t really matter what system you choose as long as it is something easy for your team to remember. Then, no matter how many section levels deep your heading is nested, you can make it look just how you want:
<h1 class="giga">Me on the web...</h1>
<section>
<h1 class="kilo">My Twitter Feed</h1>
<ul class="tweets">
<li>Mmmm, cornflakes.</li>
<li>Something inane...</li>
</ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>
So now, your twitter feed, from the previous example, can be in the sidebar on an article page, or in the footer of your homepage, and it will still look the way it was designed to. Whether you are using html5 sections or not, you don’t want to repeat code or have it be unpredictable, so I think separating styles from how the browser generates the page outline is just sensible.
UPDATE 9/6: If you truly cannot change the HTML, even to add class names, then the only way to style that bit is to put a wrapper around it with a unique class and use descendent selectors to force the style you want. This should be the exception, not the rule! (Thanks Simon for pointing out that I wasn’t addressing one of the use cases I had talked about above)
<h1 class="giga">Me on the web...</h1>
<section class="tweetfeed">
<h1>My Twitter Feed</h1>
<ul class="tweets">
<li>Mmmm, cornflakes.</li>
<li>Something inane...</li>
</ul>
</section>
<p><a href="more.html">More stuff on the web</a></p>
If you would like a far more eloquent walk through all the new html5 elements, get Jeremy Keith’s book HTML5 For Web Designers.
Thanks to Alex Kessinger and Josh for helping me solidify my thoughts around this by bringing up good questions on the CSS Lint Google Group.
Comments
33 responses to “Don’t Style Headings Using HTML5 Sections”
In the second exmaple, with the Twitter feed having h1 class=”kilo” etc, you’re doing exactly what you said you couldn’t do earlier – modifying the content from other sources to fit your style. If we assume that all of those h1 tags are external content, you’re not going to be able to target them using classes.
It looks to me that the HTML5 spec isn’t really saying “don’t use for styling” at all. It seems perfectly acceptable to put a class of “twitterfeed” on that and apply your styles to the heading tags within from there. In that case, you’re still maintaining the division between headings within the section of (external, uncontrollable) content and the rest of the page, and you’re not using as a generic container. You do however need the for more than just semantic markup – it’s the only way to target that external content without extra wrappers.
Ahh, good point Simon. That’s what I get for pushing “publish” in the middle of the night. My example wasn’t great because it was an exception rather than the rule. Perhaps the right way with truly uncontrollable content is one wrapper div that controls all internal display (like you suggest), because in fact the thing is a single object since you have no fine grained control.
The comment system (predictably) ate my section tags. Try again (also, spelling):
In the second example, with the Twitter feed having h1 class=â€kilo†etc, you’re doing exactly what you said you couldn’t do earlier – modifying the content from other sources to fit your style. If we assume that all of those h1 tags are external content, you’re not going to be able to target them using classes.
It looks to me that the HTML5 spec isn’t really saying “don’t use sections for styling†at all. It seems perfectly acceptable to put a class of “twitterfeed†on that section tag and apply your styles to the heading tags within from there. In that case, you’re still maintaining the division between headings within the section of (external, uncontrollable) content and the rest of the page, and you’re not using the section tag as a generic container. You do however need the section tag for more than just semantic markup – it’s the only way to target that external content without extra wrappers.
I think you’ve probably got the right idea with just wrapping it all in a single section tag. As long as you’re ok with targeting the internals of your “black box content” using a class attached to the section (seems like the expected use of the tag anyway), then barring some really odd situations, you don’t need any wrappers other than the section tag itself.
Nice article – made me think a lot about document flow.
I have also struggled with this topic, and pushed it really (too?) far: https://github.com/nhoizey/HTML5-Titles-Inception
I think default rendering of titles should still be based on the outline, as before HTML5. Sadly, AFAIK browsers still don’t render them using the HTML5 outline, even with a HTML5 DOCTYPE.
So I use a minimal subset of my “HTML5 Titles Inception” experiment in my reset — only h1’s and h2’s —, and then add classes when needed, as you explain.
I see what you are saying, but I’m not sure that I agree that the spec says “do not attach styles to sections.” It certainly says that it is not a generic container and should not be added merely in order to apply styles, but I fail to see how that is the same thing as “do not attach styles to sections.” I agree that something like “section section section h1” is a bad idea and likely to get you in trouble, but isn’t that just exactly the same bad idea that “div div div h1” has been for years now?
@Tim Arnold – Yes! Absolutely. It is exactly the same problem as we’ve had for years. It is just as bad to write:
#sidebar #clientsection .help h1{}as it is to write:
section section section h1{}but people think html5 somehow changes things. My video Our Best Practices are Killing Us goes into some detail about the former.
Yay,
cool writeup. I have also thinking about a way to style headings in html5, though you have collected more examples and arguments, I came up with the .h1 to .h6 classes. Whatever system we use here, it only works once we write the html. Obviously this has changed long time ago when cms spread. WordPress is a good example too. WordPress consists of posts and gives us a function in templates to display them wp_posts(); (as I remember correctly) – which acts in case of heading like a black box. The function can be called in different contexts. On the index page, where it each post is in tag (thinking in html5). These articles are in the “main” part of the website (in this one, it is the white box). Let’s say this is a div, and the article is our first section level here. Over on the search page we have the “search results” section around the posts and the post article itself are down on level 2. So, the .h1 to .h6 classes actually should be set according to the context and in this situation we cannot do this. This gets even more complex, when thinking of cms systems, where deeper contexts are possible.
I can think of 3 solutions to fix this:
1) Adding the classes dynamically on the server side (php, python, whatever we got) before sending the content to the client.
2) Adding the classes dynamically on the client side through javascript.
3) Mess up CSS.
Well, I’m not happy with any of my solutions. Got ideas for that sort of problem?
Whoa! I didn’t realize anyone else was also using the .alpha, .beta, .gamma names!
That’s been our goto for a couple of years now in order to get fine detailing and keep semantics.
Nice!
I think of primitive elements h1-h6 as “reserved for content loaders”, and then use a set of classes to define the wide array of headings created by the designer.
Nicole, this definitely helps me connect some dots with your OOCSS techniques. For instance, with .alpha vs. .h1, they’re more or less the same thing, but .alpha feels more semantic, while .h1 is actually more clear, so I could probably reconcile that without feeling too dirty.
Very nice article.
Unfortunately, for accessibility we still need different level headings. Since assistive technologies generally lag well behind competing browser implementations of standards an H1, no matter how nested it is, will “look” no different from the first H1 in the DOM tree or the last H1 to most screen readers.
From my point of view it’s one of those document vs application things. In structured documents (e.g. documentation, ebooks, or whatever) it makes a lot of sense to handle it this way and it does indeed work perfectly fine there. I really like to use nested sections for my documentation. It’s easy, straightforward, and its behavior is clear defined and easy to predict.
However, most of today’s websites are something entirely different. They aren’t plain structured documents. Unsurprisingly, it absolutely doesn’t work there.
But that’s fine, really. As long as you remember to use the right tool for the job. 😉
@gossi
The generic answer: Keep your content in a transformable state. If the source material perfectly describes your content’s structure, you can transform it to anything you like.
If it turns out that you don’t like one particular transformation, you can always try a different one.
Nicole,
firstly, IMO, the document outline algorithm, sectioning and headings in HTML5 are
1. useless, needless overkill (pretty much all document systems have been generating TOCs from heading levels for decades)
2.aren’t backwards compatible
3. are unlikely to ever be used for anything interesting in browsers (only Opera AFAIK, has ever had any sort of auto TOC feature in the nearly 20 years of browsers)
4. will unlikely work for the majority of assistive device users for years to come given the slow rate of uptake of expensive browsers like JAWS
5. make styling, as you observer here with CSS close to impossible
I frankly think heading levels should match the level in the document outline as created by sectioning, and forget the sectioning algorithm as a badly designed, over architected and essentially useless self indulgence.
Secondly regarding your reading of the specification and sections. The spec says
“When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead”
I don’t read this as saying you shouldn’t use sections for styling purposes. And if it does really say that, we are suddenly special casing some semantic parts of our documents as being not for use by CSS, which would be absurd. I see it as saying that if you need to denote a chunk of content purely for styling purposes (which I think in a properly structured document is a vanishingly small case anyway) then use a div. But, if a section is there for appropriate reasons, I simply can’t read the spec as admonishing users against applying style using it.
Back to editorial mode (yay)
The fact that we are still debating all of this, and trying develop ways of actually styling properly marked up HTML5 in a sensible way, (let alone ongoing boring conversations about what is an article, what iOS a section yadda yadda yadda continues to demonstrate the core of the HTML5 spec is poorly thought out, to say the least.)
The HTML5 spec doesn’t say that <section> elements shouldn’t be used for styling. It merely notes that it shouldn’t be used only for styling.
That is, if the reason you wish to add an element to your HTML is solely so that you can hang some style off it, then <section> is not an appropriate element to use (because using it will also, erroneously, convey the semantic that the element’s contents are a section); <div> is the correct element for such a situation, because it implies no semantics.
For example, if you need a container for a search box, or a log-in form, or a list of the top 10 links on your site, or some T&Cs, none of those are sections and it would be an abuse of <section> to put one there simply because you needed a hook for styling.
However, if a <section> element is being used appropriately, to convey the semantics of a section, then it’s fine to refer to have CSS selectors which make use of the it. In that case you would be styling a section (or something which you want to style a particular way inside sections, such as a heading or a blockquote). That’s appropriate, just like it’s appropriate to use <ul> for styling lists or <p> for styling paragraphs (and entirely different from mis-using <section> to denote a log-in box or similar).
Your point that it’s currently hard to style <h1> elements based on their section nesting is a good one, because CSS has not yet caught up with this way of denoting section levels. There have been suggestions of something like a :heading-level(n) pseudo-class which would match the appropriate heading elements based on their nesting. But there isn’t anything like that in browsers yet.
Until then it may be not worth bothering with the <section> element at all; I note that the HTML Living Standard itself doesn’t, despite being very sectional.
Or you could just stick with <h1>, <h2>, <h3>, etc inside the sections. It fails DRY, in that you’re specifying a heading level both by its nestedness and its element name and have to keep the two in sync yourself, but that’s also the case with your suggestion of using class names to indicate the nesting level. <h1 class=h3> offers no advantages over the much simpler <h3>, and is worse for users who don’t see CSS.
FYI: Related HTML5 bug
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14058
@Laura – seriously? The spec is very clear. It says not to use sections *only for* styling. Divs are better for that. Which is also exactly what I said in the article. That said, if you tie styles to section level depth, people will be *forced* to add sections to get the heading they need. The two should be independent.
Hi Nicole,
I agree. Thanks for commenting on the bug.
To me sectioning elements seem like a helpful addition. I always thought it awkward to figure out the “level” of a header in terms of the entire document scope, when I’m writing a semantically very separate section (in the everyday English sense of the word “section”).
One place this particularly bites is in blog posts. When I write a blog post in my CMS, should I start it with an h1 or an h2? An h1 would be most natural, with subheadings as h2 and so on. That works perfectly when rendering that post on its own page.
But then how do I render the same post in a listing with other posts? I’ve used content transformation to do this–incrementing all headers by one with a regex replacement.
That’s all fine, but using seems simpler. It lets me reuse the same content with no acrobatics.
Furthermore, I can’t think of any case where I would want sections within sections. I’m sure I’ll hit one some day, but for 95% of websites, I would think that allowing for one level of sections would make for a pretty DRY, robust set of styles that keeps extra classes out of our markup.
h1 {}
h2, section h1, article h1 {}
h3, section h2, article h2 {}
h4, section h3, article h3 {}
…
Is that really so bad? Just stay away from the extremity of “only using h1.” Therein lies madness.
It has already been pointed out that the main problem with classes is that they are not always applied to external content, and one of the most important aspects of sections is to enable cut-and-paste-ability.
Until there is near universal support for the standard that will evolve from -moz-any() the number of permutations makes the practical use of sections for styling practically impossible, though. But when that day arrives we will have to chose between running a script that removes and attaches classes on the imported headers, depending on their depth on the page where they end up – not the original page – and using descendant selectors.
The fact that it’s the receiving page that decides what class to apply will make any such script very complex, especially if run server side, but also client side, since it first would have to establish the position for every snippet and adapt accordingly.
Since descendant selectors would represent the easier and speedier solution, I think this is a case where they are preferable to classes.
Adding hgroup to the mix will however make the maintenance nightmare even worse, regardless of solution. I do hope that the decision makers will scrap hgroup – at least for now – according to my propsal. http://www.w3.org/html/wg/wiki/ChangeProposals/dropHgroup
Thanks for writing this up. Us folks involved with the Drupal 8 HTML5 update initiative are right now batting about heuristics for module developers regarding inclusion of HTML5 elements in their code. This helped me articulate my fears of telling developers to use semantic elements wherever they can. I have nightmares of modules with section section section where once we had div div div just because they’ve understood that semantics is good, so divs are bad.
The interesting thing about section is that it allows for sandboxing of external content that you don’t control, or that you want to insert in multiple places within a site without changing the actual markup. For example, a post could have the same headings whether it is on its own page or in a list of posts. That’s pretty powerful. It’ll be nice when browsers and assistive technologies catch up.
@Smylers: I agree that the
:heading-level(n)pseudo-element is a good idea, but it’s a little incomplete. Because of the power of the new outlining algorithm, you may sometimes want to style something based on its relative position in markup, which implies something like a descendant selector, but with arguments. That’s a bizarre idea, and doesn’t really look like anything else in css. By this I mean thatdiv :first-childdoesn’t mean the first child of adiv— it means any first child that is a descendant ofdiv. The parser probably wouldn’t like going backwards like that, even if you made up a new syntax likesection.external :>subheading(3).The
.h1, .h2class method works quite well in a broad set of circumstances that we’re not yet ready to deal with using pure css, though it simply can’t handle certain html5 use cases. Nicole, do you have any info on how badly the combinatorial explosion of [section h1, article h1, section section h1, etc] slows down browsers?@Jesse I’ve been thinking of that ever since I heard of section.
Frankly, all the earliest materials I read about div made it sound pretty much like a section. It was a generic container, certainly, but one that was provided to surround related content and provide bolt-on semantics via classes where semantics were missing from HTML.
There were identical phrases used in the early days of div… such as ‘generic section of a document’, ‘division of a document’, ‘section of a document’, ‘structure hierarchy of divisions within a document,’ etc. Envision ouroboros…that’s how div became meaningless. People used it whenever they needed a block, or a place to hook a style, that fact created the reality, which meant the two went hand-in-hand more, which influenced the next spec, etc. Until we make up a new div and call it section.
I’ve had people get all huffy and try to explain to me that they’re COMPLETELY different, but it’s not convincing. They’re completely different right NOW. But that’s not what I’m talking about. I’m not contradicting the fact that div had both practically and also has officially become meaningless. I’m saying that if you compare the long ago then and now there’s not really a material difference between the two. Come knocking in 5 or so years, then we’ll see if history repeats itself.
I hope it won’t, but a few experiences I’ve recently had with coworkers creative ways of interpreting HTML5 has me feeling rather … skeptical.
Adding classes to headings is not so handy for CMS and dynamic content. The end user has to add styles to headings. That is not userfriendly.
It’s good to see someone point out something so important so elaborately. When reviewing sites for HTML5 Gallery, I’ve far too often seen people simply replacing their former div tags (used for styling purposes) with section and/or article tags which add no semantic meaning whatsoever.
As both you and John Allsopp said, styling section and article tags is fine, as long as the tag itself is being used appropriately.
This isn’t a new issue, its been around since the dawn of the printing press. Designers of pages will often need to ensure that there are different heading styles for different parts of the document so that there are visually clear levels of importance placed on the different levels of content. However, the designer always reserves the right to modify these stylings at any time for a variety of reasons (contrast and visual interest to name a couple), so long as a visually clear leveling of hierarchical importance remains. And, yes, the complexity of the issue can be exacerbated when including other source material–each with its own set of hierarchical headings.
The concept of “H1”..”H6″, born out early systems for printing large documents with consistency, is now only here so that machines can interpret these levels of importance (semantic mark-up), not humans. Of course, the utility of consistency remains for large documents as well, where the designer isn’t going to consider what the correct style for each and every heading should be (although, if it weren’t for the machine-reading advantage, we could just use classes). Good web-designers will of course adopt these semantic elements in their markup if they wish to serve their clients (or themselves) well, but CSS will allow them to continue to apply whatever styles they require for each usage of a heading. It is the CSS that allows the designer to modify the base styles as required as the content deems appropriate, adding contract and visual interest as required.
To a good web-designer, being DRY isn’t paramount, Communication is.
I can only ask myself, what is CSS for if not to apply styles to semantic markup?
With all this said, what could ever be wrong with something like this:
/* Default styles */
h1 { … }
h2 { … }
h3 { … }
/* SECTION.sidebar */
.sidebar h1 { … }
.sidebar h2 { … }
.sidebar h3 { … }
.sidebar h3.interest { … } /* alternate for visual interest */
/* SECTION.featured */
.featured h1 { … }
.featured h2 { … }
.featured h3 { … }
/* SECTION.featured ARTICLE.cover_story */
.cover_story h1 { … }
.cover_story h2 { … }
.cover_story h3 { … }
.cover_story h3.interest { … } /* alternate for visual interest */
/* SECTION ARTICLE.regular_column */
.regular_column h1 { … }
.regular_column h2 { … }
.regular_column h3 { … }
.regular_column h3.interest { … } /* alternate for visual interest */
According to a DRY-über-alles mentality, this is all wrong (and CSSLint will make that plain), but I doubt many COMMUNICATORS would agree.
Also, as a side note, I think embedding SECTIONs within SECTIONs would be a rather rare thing when actually used semantically correctly, requiring a very complex document indeed. Anything greater than 2 levels of nested SECTIONs would be met by very dubious eyes from me (I think we agree on this one).
Interesting discussion, but you said: “If you wrap it (the H1) in a section, THE BROWSER will interpret it as one level down from it’s parent heading.â€
So you mean that the relevance for search engines (SEO for the record) remains intact if I leave the headings inside the section tag?
I’ve been setting my headers as follows, and applying any additional styling to the cascade where necessary:
h1, .h1{}
h2, .h2{}
h3, .h3{}
h4, .h4{}
h5, .h5{}
h6, .h6{}
I then kill all styles on the page verify the flow still works if I have to do something like: to maintain presentation without losing structure…
Thoughts?
I love your tera/giga/kilo naming convention. I think it’s a great way to handle the issue that you presented in this article.
Thank you for writing this article because I did not fully understand the magnitude of the issue of styling heading elements. My implementations of HTML5 so far have used the old heading convention, ignoring the section h1 restart, due to my desire to avoid this issue. And you have presented the issue as far worse than I ever could have imagined, which makes me glad that I have avoided it thus far.
Your naming convention is brilliant. I love it and will implement in a future revision and use section/headings properly from here on out. Thank you for sharing.
[…] Stubbornella develops a brilliant heading class naming convention to handle this new development in front end writing. Typically, I disapprove of classitis in headings. However, with this growth in HTML regarding sections and headings, my opinion must evolve in like manner. […]
Ew. Maybe it’s time to ask your friendly neighborhood CSS preprocessor developer to implement :-moz-any()?
[…] Don’t Style Headings Using HTML5 Sections – Nicole Sullivan addresses the issue of styling heading tags now that section nesting conveys heading rank. […]
THANK YOU! I was just starting to think about this situation and found your article. My gut was saying: Style H1-H6 with basic styles then create classes that I could apply to make work with site design; doing this would allow me to not have to worry about what section/level things were nested and make it easier for my co-workers to build stuff on-the-fly. 🙂
Thanks for clarifying this situation and providing solutions.