Incorrect usage of the small element as subtext

[iandevlin]

The suggested usage of the <small> element within a <h> element in order to markup a subtext is incorrect usage of the <small> element.

The HTML5 specification states that:

The small element represents side comments such as small print.

It then gives examples of small print:

Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.

A subtitle or subtext within a <h> element does not match the specification definition of small print and therefore the <small> should not be used in this manner.

[mdo]

I'm not too concerned with the spec honestly—it's an easy convention that folks can use, so we'll stick with it for now. Thanks though.

[iandevlin]

You don't care about what the spec says? Don't you think you have a duty to
promote good practices and proper use of tags rather than the complete
opposite?
On 5 Apr 2013 23:14, "Mark Otto" notifications@github.com wrote:

I'm not too concerned with the spec honestly—it's an easy convention that
folks can use, so we'll stick with it for now. Thanks though.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7482#issuecomment-15981038
.

[mdo]

I didn't say I didn't care, I said I'm not too concerned about it for this particular convention. To me, this is a good (and practical) practice that folks already use regardless of the spec. And having just reread the spec and their examples, I think you're mistaken on the validity of this convention. Take a look at that first example—sounds like a perfect use case that parallels our code.

[dtex]

@iandevlin The spec says <small> is valid anywhere phrasing content is expected, which fits with Bootstrap's usage. The word "typically" makes it clear that the specification's examples are not all-inclusive and implementors are free to expand on this list.

@mdo, don't disrespect the spec :-P

[iandevlin]

I disagree.
On 6 Apr 2013 00:33, "Donovan Buck" notifications@github.com wrote:

@iandevlin https://github.com/iandevlin The spec says is valid anywhere
phrasing content is expected, which fits with Bootstrap's usage. The word
"typically" makes it clear that the specification's examples are not
all-inclusive and implementors are free to expand on this list.

@mdo https://github.com/mdo, don't disrespect the spec :-P

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/7482#issuecomment-15984277
.

[mdo]

@iandevlin Normally I don't go any further into a discussion than this, but your brief reply has enticed me for one reason or another. Allow me to elaborate.

The spec you linked to says the following:

The small element represents side comments such as small print.

And...

Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements.

And...

The small element should not be used for extended spans of text, such as multiple paragraphs, lists, or sections of text. It is only intended for short runs of text.

The convention you disagree with, <small> tags within <h*> tags, fits both those applications. Our own documentation a great example of this as well on http://twitter.github.io/bootstrap/base-css.html#icons:

<div class="page-header">
  <h1>Icons <small>by <a href="http://glyphicons.com" target="_blank">Glyphicons</a></small></h1>
</div>

The link and naming of the icon library is not necessary, nor is it primary content. It's an attribution, which the spec lists as an example. Moreover, it's a "side comment" or a "short run of text"—both of which the spec encourages.

[FagnerMartinsBrack]

It is a similar thing to <i class="icon icon-home"></i> instead of <span class="icon icon-home"></span>. Ppl like to use the first.

[boulox]

Just check with http://validator.w3.org it doesn't throw error on this one.

[iandevlin]

The validator is not very strict and can only be used as a guide.

The use of for an icon is also contrary to the spec.

Back to , a sub title or sub text is not considered small print.
Your example is an attribution but it is not a sub title which your
documentation is implying would be acceptable.

The content of the element is key in deciding whether the element
is suitable or not. The bootstrap documentation makes it appear that any
content can appear in this context which, as you've shown, is not true.

[mdo]

Back to <small>, a sub title or sub text is not considered small print.

@iandevlin That's an opinion, not an objective fact or statement from spec you're trying to defend. The spec says nothing about prescribing the use of small for subtitles or subtext. And we're not limited to the examples in the spec—those are examples and cannot, nor should they ever, represent all possible implementations.

The content of the element is key in deciding whether the element is suitable or not.

Of course, which is why any "side comment", "short run of text", or in this case a subtext or subtitle, can make use of the <small> element. That content is secondary.

The Bootstrap documentation makes it appear that any content can appear in this context which, as you've shown, is not true.

I call bullshit. Put nearly any phrase, string of words, attribution, links, or Emoji in there and you'll be fine. It's supporting content and that's just fine—by the spec, by me, and by everyone else.

Specs aren't law—they're technical guidelines. Moreover, specs are almost never applicable or practical when building large scale design systems like Bootstrap or any other product.

[JamieKnight]

To inteject. I can see the point @mdo is making. From an accessibility point of view the exact semantics of inline elements are of limited importance.

To that end, using the language this way has no downsides, a subtitle or subtext does seem appropriate here.

Just my 2c,

(Edit, fixed typo)

[FagnerMartinsBrack]

@iandevlin

... The use of <i> for an icon is also contrary to the spec...

My point is in a huge app 6 chars can be a significant improvement if used in conjunction with a lot of other optimizations, and the change have no draw backs since the tag is empty and renders as any inline element.

I never used, but as I said, ppl like to use.

[mdo]

Keep it classy @FagnerMartinsBrack—no need for attitude or sarcasm. We're all just trying to make shit on the Internet here and have a debate. My general attitude is the best argument wins, and right now leaving it in makes a lot of sense to me. Hope others can see that as well given this thread.

<3

[stevefaulkner]

I have started a discussion on the HTML WG mailing list about use of to indicate subtitles
http://lists.w3.org/Archives/Public/public-html/2013Apr/0022.html

[Alohci]

@stevefaulkner, I first encountered using small in this way in a suggestion by Toby Inkster in 2010 here: http://lists.w3.org/Archives/Public/public-html/2010Nov/0405.html. Made a lot of sense to me then, and still does.

[necolas]

hgroup would be more appropriate (in the future) for exactly these sorts of title-subtitle patterns, but unfortunately it's being marked for removal from the HTML5 spec at this late stage…which is unfortunate.

[stevefaulkner]

hgroup would not have been more appropriate as it promotes a markup anti-pattern of using multiple headings when not needed. h1-h6 do not make good subheadings/subtitles/taglines.

[necolas]

There's nothing inherently true about that, Steve.

[zbnauj]

The validator is not very strict and can only be used as a guide

@iandevlin So we need to use you instead as a perfect practice advisor ? right now I think there is not a only one or perfect way to do html5, everything is changing, that's include the specs, look at hgroup... as you said, the validator is a guide, specs are a guide too, to make a good practice of html5 not to convert developers to specs Nazis

[patrickhlauke]

regarding @iandevlin's comment about the validator, and to counter the snark he got just now from @thinkxl : the validator does the equivalent of a fancy spellcheck. using spellchecking in your word processor does not guarantee that you're a good writer...

the most important shortcoming of validators is that they can't check whether or not semantics are being appropriately conveyed. and that's what ian meant by that. heck, i can mark up an entire book as a single-page HTML file using only spans, and the validator wouldn't care...but any human looking at it would immediately see the problem.

[patrickhlauke]

back to the topic: this is, once again, an issue with nebulous spec language (and the original desire to retrospectively bless clearly presentational old-school tags with some form of "semantics" instead of ripping them out). it comes down to divining "what did the spec authors really mean by that" and drawing your own conclusions from it to fit your view. i'd actually say that there are bigger issues to tackle, and that - whether or not it's a slight misuse or not of the particular element - at least it doesn't do any harm (or good either, as no screenreader, scraper, etc actually care about small or misuse of i etc).

[stevefaulkner]

@necolas how so?
The practice of using multiple headings to indicate subtitles had been no more common that other methods. as defined hgroup promoted this one method. As defined hgroup would have resulted (if the semantics were implemented) in the same outcome for assistive technology users as the small pattern in discussion i.e. the hgroup was defined to be the heading and the semantics of the individual headings removed.

[patrickhlauke]

"My point is in a huge app 6 chars can be a significant improvement"

in an age of minifaction, gzipping, etc, i'd really like to see some evidence of this sort of statement (which has often been quoted when it comes to the use of things like and )...

[korywka]

In the Name of the Moon specs will punish you!