Does W3C allow <h#> elements to be display:inline;?

Question

Doing a code review, I noticed that a heading was using <span> tags instead of headings, so I suggested using an <h4> tag, to gain the semantic benefits. The context is a website footer, where there are various lists of links under different headings.

<span>Category 1 Links</span>
<ul>
    <li>Link 1 in the footer</li>
    <li>Link 2 in the footer</li>
    <li>Link 3 in the footer</li>
    <li>Link 4 in the footer</li>
    <li>Link 5 in the footer</li>
</ul>

The counterargument was that <h4> is a "block-level" element, whereas an inline element was needed. Therefore he didn't think the element should be changed. (And yes, he knows CSS and is familiar with the display: inline; property.)

That sounds absolutely insane to me--goes against everything I always thought was best practice: separation of content and presentation, semantic web, the very purposes of HTML and CSS... yet in trying to formulate a response, I came across this section in the HTML 4.01 spec:

Certain HTML elements that may appear in BODY are said to be "block-level" while others are "inline" (also known as "text level").

...

Style sheets provide the means to specify the rendering of arbitrary elements, including whether an element is rendered as block or inline. In some cases, such as an inline style for list elements, this may be appropriate, but generally speaking, authors are discouraged from overriding the conventional interpretation of HTML elements in this way.

The alteration of the traditional presentation idioms for block level and inline elements also has an impact on the bidirectional text algorithm. See the section on the effect of style sheets on bidirectionality for more information.

So here is the question: does this section make the issue sufficiently vague for there to be valid difference of opinion here, or is it (as I had thought) pretty clear in one way or the other? If this section is open to interpretation, are there any other W3C guidelines that are more concrete?

I don't want to get into opinions on this, I just want to make sure I'm understanding the spec and the W3C guidelines correctly: is there true ambiguity here, or not?

Answer 1

First of all, the quoted section is indeed from the 14-year old HTML 4.01 specification. I do not remember ever reading anything of the type in the HTML5 specs. I personally think it was deemed a good remark at the time but has since been obsoleted by experience. Don't forget that HTML4 was the one to actually properly separate HTML and CSS, and as such contains 'mistakes' like the quoted remark that were later 'corrected'.

In essence, there should not be any implicitly locked relationship between your semantic markup and your styling. Like the hX elements, a div is also a block level element, but only because of the way it interacts with other elements, most specifically which elements it can contain - an inline element must not contain a block element while a block element can contain both inline and block elements, bar explicitly defined relationships such as ul > li and table > tr > td. Essentially the separation of semantics and presentation should be kept so strict that the specifications of the markup language HTML should never even mention the existence of the concept of stylesheets - stylesheets can be applied to anything, not just HTML, and HTML feeds so many more technologies than just browsers.

From a web developer's perspective, you are absolutely right. The block nature of a h4 element merely implies its relationship with potential child elements, and its default representation in the browser's default stylesheet. What the CSS developer then wants to do with his stylesheet is his own choice - for all you care he applies a display:table-cell rule to it if that properly fits his design.

TL;DR: There is no ambiguity, and you should always write your CSS to conform to how you want to display your HTML, not adapt your HTML to the requirements of the CSS. Using a span where an h4 is required is just plain wrong from a semantic (and SEO) perspective.

Answer 2

W3C specifications allow display: inline on heading elements. In general, HTML specifications do not restrict what you can do in CSS, and vice versa.

The section Block-level and inline elements that you quoted contains a recommendation (“discouraged”). It is a “should not”, not a “shall not” statement, i.e. not a conformance criterion. The motivation for the recommendation is not given, but generally such ideas are based on the fact that HTML documents may be processed by software that ignores style sheets, or may have author style sheets overridden, or otherwise gives preference to the defined meanings of elements rather than their CSS styling.

Even though the possibility of making a heading an inline element (in the sense of setting display: inline) is not mentioned here, doing so is part of one way of creating “run-in headings” (headings that appear inline at the start of a paragraph, rather than on a line of its own). Nowdays a better way to achieve that is display: run-in, as exemplified in the CSS basic box model WD. The basic point is still the same: it’s OK to turn a heading element from its default display: block to inline-like presentation.

Regarding the specific case presented, I don’t quite see why an inline element would be needed. The next element is ul, causing a line break (and vertical spacing) by default. And if the rendering of the ul is changed to inline with CSS, it is difficult to see why you could not do the same to an element that is logically a heading for the list.

Answer 3

In my opinion, any typographic convention that you have ever seen in a book or other printed media is fair game for modeling a web page.

For example, I have seen text books with several columns, each with a header, and one could achieve this effect by using display: inline to a h4 tag.

In this example, whether h4 is on a stand-along block or part of a horizontal sequence will depend on the content and how you are trying to communicate ideas to your readers.

Consider how your page would render in a text-only browser that does not support CSS, would the raw ordering of the text make any sense? If so, then, your choice of HTML are probably valid.

On the other hand, if you took table tags and turned them into headers or list items, then you are probably going to get HTML that would not sound right if the page were read by some type of audio browser (think visually impaired people using a page reader).

Let semantics dictate the tags that you use and use CSS to get the visual layout that you need.