We recently examined
<b>, presentational HTML4 elements that have been given a new lease on semantic life. Two more elements that have undergone transmogrification to receive semantics in HTML5 are
<small>— was for smaller text, now used for side comments and small print (W3C:Markup, WHATWG)
<hr>— was horizontal rule, now used for a paragraph-level thematic break in text (W3C:Markup, WHATWG)
The small element represents so-called “small print” such as legal disclaimers and caveats.
<small> is now for side comments, which are the inline equivalent of
<aside> — content which is not the main focus of the page. A common example is inline legalese, such as a copyright statement in a page footer, a disclaimer, or licensing information. It can also be used for attribution. Don’t use it for block-level content (paragraphs, lists, etc.), as this would be considered main content.
<small> text does not need to be smaller than surrounding text — if all you want is smaller text use CSS instead. Use
<small> only on inline content. Finally,
<small> doesn’t affect the semantics of
The hr element represents a paragraph-level thematic break.
The “paragraph-level” bit means between blocks of text, so it can’t be used to separate sections of a site. Instead, While not widely used these days (given the dull default browser renderings), it can be replaced via CSS with an image:
<hr> now separates different topics within a section of prose, or between scenes in a novel.
IE7 and lower live up to reputation by adding a border around the image regardless, but this can often be worked around. Alternatively you can just hide it via an IE7-and-lower stylesheet. Use a CSS border or background image on another element instead if the transition is obvious (for example between weblog comments), or the intended use is solely presentational.
When HTML4 was released, the presentational elements
<u> were already deprecated in favour of CSS. HTML5 completes this by removing
The remaining HTML4 presentational elements — the long-ignored
<hr> elements (along with
<b> from last week) — have been redefined in HTML5 with useful, media-independent semantics that relate to their typical use. Will you be using them? Let us know in the comments!
50 Responses on the article “The small & hr elements”
Knee-jerk reaction….I don’t like it. At all. This is going to introduce lots of confusion. Changing the meaning of existing tags? No.
@Joe Devon, thanks for your comment. Out of curiosity have you used
<hr>recently? If so, how did you use them? If it was for purposes other than copyright text and adding a horizontal rule between two paragraphs respectively I’d love to hear about it.
I know there are some sites whose usage of these elements doesn’t agree with HTML5’s new definitions, for example
<hr>is used as a section separator quite frequently in Japanese design. They’re generally hidden via CSS but visibile when viewed on cHTML cellphone browsers, which only support very basic CSS & don’t get the visual design (and with it the visual separation of sections). However I think the new definitions cover the majority of current uses ‘in the wild’.
Updated to make cHTML sentence make sense
Great article. The elements in this article need to be updated in the glossary.
I was less bothered by the new HR and SMALL than by B and I, just because we’ve been trying to get rid of I and B for a long time. It seems like we’re giving up.
But I guess part of my reaction is that the people putting in extra effort to do it “right” for so long wound up wasting their time because the others got it wrong for so long and we just changed the meaning so the lazy would be right for the wrong reason, if my circular logic makes sense in the end :)
I guess the intention is good, so I’ll withdraw my knee jerk reaction. It’s all good.
I was hoping they’d ditch them too. They probably had to keep them for one reason or another and just decided to make them as useful as possible.
I actually am glad now that the tag was kept – I use it exclusively for icons.
As for HR tags, you can style the ever loving crap out of them in CSS3 and are an option to break up sections without closing/opening containers. I used them in a documentation project last year and styled them with a shadow code that styled them like creases in paper. They worked nicely.
Speaking of old tags, I came across an HTML5 doctype’d website today that had FONT TAGS. And it was a digital agency’s site. I was speechless, so I just exited out of it and went onward with my business.
The Small element really doesn’t bother me, as I’ve mostly been using that for copyright info recently. The hr change, on the other hand, seems a bit surprising. I hadn’t realized that in reading over the spec. I can’t honestly think of the last time I’ve used it (I almost used it a few months back, but I decided against it), but it still sorta seems weird. Ah well, I guess.
These actually both make a lot of sense. I’ve seen <small> used for this purpose rather often, and I was bugged by the fact that <hr> didn’t have a proper replacement, though it served a unique purpose. I like this.
I find for new meaning for hr element logical, and almost obvious way to use it.
[…] The small & hr elements | HTML5 Doctor […]
[…] via The small & hr elements | HTML5 Doctor. […]
@all — thank you for your comments! Although after last week I feel like I’m doing something wrong because they’re all so … positive :D
@Earle Clubb — Thanks for the reminder!
@Joe Devon — I can understand your reaction :) However I think for
<b>the standardista idea wasn’t to stop using them, but to use
<strong>where appropriate, for (HTML4) emphasis and strong emphasis. As the vast majority of uses were for this and not, say, using
<i>to write foreign words, this did appear to be a general censure. However the standardista mantra of “use the most appropriate element” is still 100% true, and people using
<b>when they mean
<strong>are still doing it wrong.
Also there was never any hope for
<b>to be dropped, as every WYSIWYG editor uses these because (for better or worse) they use the word processor model of applying styling rather than defining meaning.
First reaction is … confusing. The tags are now used for very specific cases I, as a front-end developer, not often encounter.
It sounds important for copy and “web masters”, but they often lack the understanding of html to make good use of these tags. And I’m pretty sure that most WYSIWYG editors won’t bother either with the renewed meaning of these tags. I might use them when I blog myself, but even then I think that in most cases I won’t need these elements.
I also find it a little strange that for structural tags html5 is trying to be as generic as possible, but for actual content it’s catering to rather extreme edge cases. If you made me choose between a tag and an tag for “introducing thematic breaks” between paragraphs, I think my initial reaction would be that the tag would be more useful on the web (note – I’m not saying we need a tag at all!).
<hr />tags feel much closer to style than to content. Should they be part of html at all?
Stompfrog: Think of the “* * *” that is often used in stories and essays. Is that style, or content?
I’d say it’s most definitely content since without it, the meaning of the rest of the content might differ—the author intended for a significant break or transition at that point, for whatever reason, and for the reader to not be aware of this change could be destructive. That’s what <hr> is for.
@Niels Matthijs — you don’t often encounter site copyright statements!? o_O I don’t think the specific use cases are such a big problem, as most people are using the officially sanctioned approaches now;
<strong>for important text (and not
<b>), CSS borders or background images for separating blocks of content (and not
<hr>) etc. In fact if anything it’s an increase in use cases from the “no
<br>eakfast markup” idea that many took to mean never use
<b>. Those that do continue to use e.g.
<b>when they mean
<strong>aren’t doing anything wrong per se, but that content just has less semantic meaning.
@Stompfrog — historically
<hr>was indeed a presentational element, but in HTML5 it now has media-independent semantic meaning. For example, a screen reader could take a longer pause when encountering one, indicating to the listener that there’s a change in content.
@John Holdun — well put. Thanks for the clear analogy! :)
I’m loving these posts about how older tags have been re-purposed, as this is the kind of stuff I’d never think to look up myself. Thanks for clearing a couple more things up, and keep up the good work!
I’m not sure there’s much justification for trying to repurpose these tags. I just can’t imagine that if we were coming up with a specification from scratch that we would come up with these tags for these purposes. Rather than trying to make old tags make sense by giving them new meanings, HTML5 might have been better off creating new elements with more apparent and obvious semantic meaning.
Also, unless I’m misunderstanding what hr is to mean, isn’t the separation of blocks of content what divs are for? Why do we need hr to fit in there, other than simply because people used to use hr for that purpose back in the early days of web design?
Added semantics in HTML is a good idea but I find in a day to day basis that I do not have control over the content. Nearly every site we build is in a CMS that means the clients add in the content. I find it hard enough to get correct use of basic HTML tags to be used never mind being able to use the new or re-factored elements in HTML5.
This is a struggle that I deal with all the time. I also feel that a lot of the new elements in HTML5 are trying to replicate layouts that are common in print and not developing for how we currently use the medium of the web.
With elements like <b>, <i>, <strong> and <em> we will have the problems of their use within a CMS, generally clients have no idea about the use and what happens in the background. They just want it to work like it does within something like MS Word.
I try to build sites with as much meaning as possible but if that happens to lie within an area that the client can edit then ultimately that will be ripped out and changed with a raft of crappy html, e.g. loads of non breaking spaces because they want to recreate tabs or tags instead of etc etc etc.
I will make an effort to learn HTML5 inside out but I can guarantee that a lot of my colleagues will not and I fear that some of the semantics of HTML5 make sense but will go in the too hard basket and lead to half baked implementations of the language.
Look at that: http://dkdenz.de/#nr4
This bothers me a bit, since I use the tag to divide text (I used to think hr meant “horizontal rule”.)
Thank you for posting this. :D
@Dan M — thanks! I’ll pay you later ;-)
@Patrick — the justification is removing solely presentational elements, and making elements media-independent. Making up new elements would be nice, but repurposing has the advantage of support in current browsers (IE, cough). Also while e.g.
<small>may not be as nice as
<©>, that’s actually what many people use
<small>for these days.
<div>the spec states (#), so there’s no explicit separation role, although there would be with
<hr>is for a “thematic break,” which may be different to what you mean by “separation of blocks of content”.
@Aaron Witherow — try finding a WYSIWYM plugin instead (WYM Editor, WMD), or at least customising a WYSIWYG plugin to only show semantic options and produce the code you want. I’d also recommend producing a style guide with instructions on how to get the effects the client wants in the plugin. If you’re allowing direct HTML input… well… :D Finally while people will surely write crap markup in HTML5 too, that’s what they’ve always done and the web still works. I think we just have to do our best.
@dkdenz — thanks for pointing out that IE7 and lower are crap at doing image replacement on
<hr>(surprise!). The old-skool technique is to apply the style to a wrapper
<div>and hide the
<hr>, but I’ve updated the article with a link to a workaround you can try. You could also just hide the
<hr>in an IE7-and-lower stylesheet :)
@Joannie — Why are you bothered? It sounds like the realigned definition matches your use! :D
about the technique, i would have think it wasnot interesting but your exemples are interstings
The whole concept of hr’s still confuse me. They’re the least needed.
hrdid represent Horizontal Rule in HTML 4.01. And, as much as I appreciate the narrow definition for use in HTML 5, I prefer to use
hras a thematic break in content section-level as well as paragraph-level. The HTML 5 Validator does not issue an error during validation when this element is used in places of the markup other than paragraphs; therefore, I will continue to use it as an all-level element since the specification states and Flow Content is defined as
The contexts exceed the
hruse in paragraphs only.
@agence internet — thank you :)
@Steph — the new definition means there’s less need of them than there used to be, but you can see their use in the sample article by disabling CSS. The default browser rules aren’t pretty, but they do indicate there’s a change going on.
@Sean Fraser — the paragraph-level bit in “” is defined as:
Apparently it doesn’t have to be between
<p>paragraphs, but I read this as it’s supposed to be between paragraphs ;-) Of course nothing terrible will happen if you use it between sections, but it’s possible that the validator may flag this at some later date.
Out of curiosity why do you want to use
<hr>between sections rather than, for example, a top or bottom border on
Yes, the Conformance Check may throw an error message someday. I prefer using
<hr>between sections for ease-of-use because setting top/bottom borders (with padding + a background image + adding a class on the appropriate last paragraphs in the section) becomes troublesome for me; and, it’s a branding/aesthetic/design thing: An example.
@Sean Fraser — I’m sorry, when you said “between sections” I thought you meant between
<section>s. However in checking your example page I started to worry I hadn’t been able to confirm where exactly
<hr>can be used. I read the spec to mean “between flow elements, but not between sectioning or heading elements,” but that was never stated explicitly.
So I asked Hixie and found out that my ‘stricter’ reading of the
<hr>element was incorrect (see changes above). The main difference between
<hr>in HTML4 and HTML5 is that it is now media-independent, so it represents a section or thematic break regardless of presentation. While
<hr>shouldn’t be used to separate
<section>s of a site, this is because the sectioning and heading elements already have the semantics of indicating a thematic break (so
<hr>is unnecessary), not my incorrect assumption that they weren’t paragraph-level content.
Hope that helps.
Thank you for the clarification. Still, I remember reading somewhere on this site that the
<section>element cannot be styled and, if styling is required, to use a
<div>so it still remains that – for stylistic presentation a second element must be used to visually divide content. Sectioning Content elements thematically divide content “sections” for the outline but not for visual presentation.
How does Ian find the time?
@Sean Fraser — there’s no problem styling the
<section>element as you would a
<div>, as it’s basically a formalised
<div class="section">. I think you may be thinking of something like “use
<section>if you only need a container element to apply styles to”. A great rule of thumb is to use the element with the most accurate semantics, then change the presentation as required via CSS. The only other time you may need a
<div>wrapper is for block-level links, but that’s only to protect FireFox from the vomit bug (not for styling).
I don’t recall the last time I have used <small> or <hr> tags…
It’s interesting that they are being used in this manner, as opposed to being removed totally… I’d like to see how this is treated by the design community. I think it’s pretty interesting.
I used HR a lot recently – well, over 5 years, actually. I was transcribing a 2 volume old book set, written in 1722. There were about 1200 pages. The layout of the pages was similar but somewhat inconsistent throughout the 2 volumes.
I transcribed each page as one HTML4 page. I tried to maintain a fair copy of the original look of each page, most of which began with a horizontal rule, then the page number at left, and the topic, centred. This was followed by another horizontal rule, then the text of the page.
At the end of some pages there was another horizontal rule, followed by footnotes.
Finally, at the end of every page I inserted a final horizontal rule that wasn’t in the original, followed by some info and links for more detail about the original page.
My point is that even though modern designers might not use HR, the line rule was used extensively in old printed books, and an easy method of inserting them in HTML replicas of these books is still needed.
PS: If HTML5 and a reliable CSS had been available when I started, my approach would have been different. But it’s done now, finished May 2009.
[…] But you should use it for, as Alex Ford says, a content separator. HTML5 Doctor has a nice example: http://html5doctor.com/small-hr-…11:56amView All 0 CommentsCannot add comment at this time. Add […]
Chris Coyier of CSS Tricks fame has come up with a nice way of using
<hr>: linear backgrounds to make a striped line.
I’m not a fan of repurposing old tags.
They have created other new tags why not create <separator> instead of using “horizontal rule” to mean “not exactly a horizontal rule but maybe a separation of this and that”?
– HTML 2.0 Specification
– HTML 3.2 Specification
– HTML 5.0 Draft Specification
I’d say that was pretty consistent really, and not a re-purposing at all. It was only HTML 4 that was out of step, in defining it (badly) only in presentational terms.
@Mark Boughter — presentational-only elements have been dropped from HTML5 (well, arguably :) If
<hr>didn’t have a semantic meaning it would have been made obsolete. As Alohci points out this is more a (very minor) realigning than a repurposing. Adding new elements is not to be done lightly either — it increases complexity, and requires updates to tools and browsers. Any new element will literally take years to achieve wide native support.
Have you ever used
<hr>when you weren’t separating this and that? And how should a screen reader convey a “horizontal rule”?
I see what you mean. I suppose my gripe should be with the name of the original tag. Perhaps it should have been called, more generically, “separator” instead of “hr” in the first place.
It seems I’ve always incorrectly considered its semantic meaning to be “draw a line here” causing me to avoid its use altogether due to what I considered its presentational nature. Questions that always came to mind were “is a flourish to be considered a horizontal rule?” and “shouldn’t I just use a border-bottom instead?”.
@Mark Boughter — completely agree, but this is what history has given us to work with :) Hopefully the new definition (and this article) will make deciding when to use
Personally, I hate using
b, and I hate it when I see them used incorrectly in someone else’s source. The HTML5 spec isn’t very unambiguous, so I’m always debating with myself which to use. One week I think
bis appropriate, then I think back on it and decide
iis better. They should just get rid of them completely and use
spans for stylistic offset.
I don’t like the HR tag.
What I dislike about them is that they does not have many styling ‘real’ attributes.
The automatically be default add a border in what it feels is a box. Essentially it treats is like a box with no heights. When you try to have better control over it’s border it won’t let you. I now use a div with the class of BR, which does the job.
As for HTML5, I can’t understand what’s going on there. XHTML for better coding practices. HTML5 has somehow reverted back to prehistoric tags, that being the
<b>. Why not introduce the
<font>tag whilst you’re at it!
Whilst everybody has jumped on the bandwagon of HTML5 securing a future for it’s self. I am not too convinced it deserves such a lime light. XHTML was hardly given such exposure but it’s use was pretty rock solid! I’ve used xHTML in all my sites, now I am not too convince I should jump into HTML5.
@Chris H — try reading my article on the
<b>elements, especially the notes about other more appropriate elements at the end of each section. Also, no element is ever “got rid of”, as browsers have to support every one for legacy content.
<hr>is for a thematic break, not for adding a border, and
<div class="br">is semantically completely different. XHTML and HTML5 are basically equivalent to a browser, assuming you’re sending XHTML as
text/html. What XHTML coding practices do you feel are better?
PS add the elements you forgot to escape if you reply, and I’ll edit your original comment
The HR property limits my control. The HR divide is very think and when I try to remove a border to make the divide thinner it won’t let me. Just to illustrate on your website you have nice thin borders, where are not HR tags, you simply but a border-top.
The only issue I have is that a HR tag would have good appropriate for my situation but considering is placed a double-lined space I think I would rather pass. If my HR tag was invisible it would have been ideal, but for styling I would not recommend it.
I look at things from a presentational point of view, I agree semantically it’s better, but presentationally it’s worse.
XHTML is valid code. HTML5 uses the tags such as the which act the same way as DIV’s. In other words you can have a footer in the header and vice versa. The tags aren’t closed any more, which is confusing since such a deal was made back in university on closing tags.
<hr>seems pretty styleable in modern browsers to me — here are some examples of styling
“XHTML is valid code” — this doesn’t make sense. XHTML is as (in-)valid as HTML5. You can’t have a
<header>or vice versa, the spec explicitly forbids this. You can use “XHTML style” closing tags if you want, as I wrote in point 9 of 12 common problems with HTML5 back in 2009. Actually please read that entire article, you might find it illuminating :) After that check out the HTML5 Doctor article archive ;)
Will do, thanks for your help :) Certainly something I need to take a deeper look at.
[…] [^2]: De hecho los enlaces son tratados como entradas en la base de datos de WordPress [^3]: Ver http://html5doctor.com/small-hr-element/ [gist]: https://gist.github.com/2904437 ↩ Posted in […]
Could you explain this point a bit? As far as I know, they can’t be exactly the same at least because hr element doesn’t affect document outline (so these constructs result in different outlines, and are hence semantically different). Could you help me with this confusion?
@SelenIT — yeah, you’re right, I phrased that poorly. Hixie’s original quote was:
So roughly equivalent inference, but not equivalent HTML semantics.
Related: This also demonstrates why a link in
<q cite>is metacrap. Hung in my own noose! :)
@Dr. Oli — thanks a lot! The next line of Hixie’s quote explains it all.
I am a little confused by the don’t use
smallfor block-level content, when it should be used for small print – which may contain multiple paragraphs.
For multiple paragraphs of small print, I see two possible markup patterns illustrated below.
1. Wrap full paragraphs content inside
<p><small>The figures presented in this article are the results of tests performed on a sample of 400 users, ...</small></p>
<p><small>Different use cases may result in different figures, as ...</small></p>
2. Put all paragraphs inside an
<aside>element (uses a
smallprintclass to apply the same styles as a
<small>element via CSS):
<p>The figures presented in this article are the results of tests performed on a sample of 400 users, ...</p>
<p>Different use cases may result in different figures, as ...<p>
I wonder what the differences are between each of these two patterns’ semantic implications, and when it is best to use one rather than the other. Does <small> is […] the inline equivalent of
<aside>mean that the markup in my second example is preferable ?
Another similar use-case I see is with side-notes, which are also side-content. Should every side-note’s text content be wrapped inside a <small> tag, or would it be better to put the whole list of side-notes inside an <aside> ?
I have similar confusions around the
<small>element for blocks of legal/disclaimer text.
Quite often terms and conditions are in an ordered list form. It seems to make sense to me that I should be able to mark the entire block or blocks as disclaimer text.
Although the spec doesn’t seem to support that, so do I then need to mark up disclaimers such as:
<p><small>Disclaimer intro paragraph.</small></p>
<li><small>Point one is often short.</small></li>
<li><small>Point two is usually a little bit longer..</small></li>
<li><small>Point three is usually quite verbose but who really reads it anway.</small></li>
It just doesn’t feel efficient. Surely it would make more sense to wrap the whole block?
<p>Disclaimer intro paragraph.</p>
<li>Point one is often short.</li>
<li>Point two is usually a little bit longer.</li>
<li>Point three is usually quite verbose but who really reads it anway.</li>
Leave a Reply to Oli Studholme