Why use .h1 instead of actual h1?
HtmlCssTwitter BootstrapTwitter Bootstrap-3Html Problem Overview
Within the Bootstrap CSS project, styles are provided for your heading tags (H1, H2, H3, H4, H5, H6), but there's also a series of class names based on the headings as well (.h1, .h2, .h3, .h4, .h5, .h6). What is the benefit gained from using the class name of a H1 without properly using the H1 tag? I would think that you always want to make sure your HTML mirrors your visual importance.
Any thoughts explaining a good reason for using .h1 instead of using a h1 tag would be appreciated.
Html Solutions
Solution 1 - Html
You ask:
> Why use .h1 instead of actual h1?
Short answer:
The goal is to use both, together.
The usefulness of the .h* classes comes into play when the size of the typography in the design does not correlate with the semantically appropriate heading levels. By splitting the problem in two, we can cleanly solve for both.
The first bit is the element/tag. The '<h*>' takes care of semantics, accessibility and SEO.
The second bit is the class. The '.h*' takes care of visual semantics and typographical hierarchy.
Long answer:
I believe that the origins of these classes come from OOCSS project:
The latest iteration of OOCSS has changed a little since I last looked at it, but here's the relevant heading.css file, from an older commit, that has the .h1 - .h6 classes that I'm familiar with:
6e481bc18f oocss / core / heading / heading.css
From the comments:
> .h1-.h6 classes should be used to maintain the semantically appropriate heading levels - NOT for use on non-headings
> ...
> if additional headings are needed they should be created via additional classes, never via location dependant styling
Note the emphasis above.
For a good explanation as to why one would use these classes, see:
- stubbornella.org: Don’t Style Headings Using HTML5 Sections (Nicole, the author of this post, is the creator of OOCSS)
- csswizardry.com: Pragmatic, practical font sizing in CSS
- Google Groups › Object Oriented CSS › Headings question: Basic concept/usage? (A question I asked back in September of '12)
Relevant quotes from the above links:
1. stubbornella.org
> ... [HTML5] 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. > > So, how do we style headings in an HTML5 world? > > ... 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.
2. csswizardry.com
> Another absolutely stellar nugget of wisdom [Nicole Sullivan has] given us is what I call double-stranded heading hierarchy. This is the practice of defining a class every time you define a heading in CSS. > > ... By assigning a class along with each heading style we now have those styles attached to a very flexible selector that can be moved anywhere, rather than to a very specific and non-movable one.
3. groups.google.com
Here's a pseudo-html5 usage example (h/t Jamund Ferguson):
<body>
<div class="main">
<h1>Main Heading</h1>
<section>
<h1 class="h2">Section Header</h1>
</section>
</div>
<aside class="side">
<article class="widget">
<h1 class="h3">Sidebar Headings</h1>
</article>
<article class="widget">
<h1 class="h3">Sidebar Headings</h1>
</article>
</aside>
</body>
Please read full articles (and thread), via links above, for more detailed information related to this question/topic.
Solution 2 - Html
Most stylesheets have a set of font-sizes that correspond with heading styles 1 through 6. Sometimes, elsewhere on the page, web designers want to use those same font sizes on text which should not be a part of an actual heading element, for semantic reasons. Rather than providing names for each of those sizes like .size-12, .size-14, .size-16, etc, it's easier just to name them all with class names similar to your headings. That way, you know that the text will be the same size as an H1 element, even though it's not actually an H1 element. I've done this a few times myself.
Solution 3 - Html
A few reasons I can think of:
- Using div instead of proper tag to get the visual of a header without an impact on SEO
- To avoid complications from browser inconsistencies
- Compatibility with other libraries and frameworks that choose to do the same for reasons 1 and 2
- Design flexibility (as noted by @scrappedcola in the comments)
Solution 4 - Html
This allows for a separations of visual hierarchy form semantic hierarchy. eg, I want to tell the viewer one thing, while telling a computer (search engines) something else.
<article>
<h1 class="h1">Page Title</h1>
<p>Some content</p>
<section>
<h1 class="h2">Section Heading</h1>
<div class="h6">Sub Heading</div>
<p>Some content</p>
</section>
<section>
<h1 class="h2">Section Heading 2</h1>
<div class="h6">Sub Heading 2</div>
<p>Some content 2</p>
</section>
</article>
See:
Solution 5 - Html
The only thing I can think of offhand is for search engines. Many will look at an actual h1 tag as the title or subject of a page and use that for searches, etc. Having multiple h1 tags can confuse the search engine spiders and may screw up searches that would return results for your site (I've also heard it may get you on the "bad site" list with some spiders like Google).
Having the styles allows you to have the same visual look to an element without screwing up search engines.
Solution 6 - Html
Another reason I have come across recently... this is not particular to Angular but it serves as a good example:
I want to create dynamic/declarative forms in Angular (see Dynamic Forms in the Angular Cookbook) and allow styled text elements. Maximum flexibility would call for allowing me to declaratively add arbitrary HTML elements to my forms, but this is open to scripting attacks, and requires explicit subversion of the Angular compiler to even allow it. Instead, I allow text elements to be added to forms, along with a class for controlling style. So I can use the .h1 style but not the h1 element.
Solution 7 - Html
This would definitely help in-terms of SEO and google crawlers to understand your page better. When it reads h1, it assumes that whatever is in there must be the focal point of the page. H2, would be the second components and so on. This way Google can understand the "scope" of what your page is covering in-terms of content.
Not entirely sure, but a big variable in my opinion would be the "read" mode of pages. This would allow devices and readers to organize content especially for devices used by visually impaired people.
Also it provides structure to the page and a sense of order.