Is it wrong to change a block element to inline with CSS if it contains another block element?

html css w3c xhtml

20,587

Solution 1

When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box(es). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, any resulting translation also affects the block-level box contained in the inline box.

This model would apply in the following example if the following rules:
p    { display: inline }
span { display: block }
were used with this HTML document:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<HEAD>
  <TITLE>Anonymous text interrupted by a block</TITLE>
</HEAD>
  <BODY>
    <P>
      This is anonymous text before the SPAN.
      <SPAN>This is the content of SPAN.</SPAN>
      This is anonymous text after the SPAN.
    </P>
  </BODY>
The P element contains a chunk (C1) of anonymous text followed by a block-level element followed by another chunk (C2) of anonymous text. The resulting boxes would be a block box representing the BODY, containing an anonymous block box around C1, the SPAN block box, and another anonymous block box around C2.

The properties of anonymous boxes are inherited from the enclosing non-anonymous box (e.g., in the example just below the subsection heading "Anonymous block boxes", the one for DIV). Non-inherited properties have their initial value. For example, the font of the anonymous box is inherited from the DIV, but the margins will be 0.

Properties set on elements that cause anonymous block boxes to be generated still apply to the boxes and content of that element. For example, if a border had been set on the P element in the above example, the border would be drawn around C1 (open at the end of the line) and C2 (open at the start of the line).

Some user agents have implemented borders on inlines containing blocks in other ways, e.g., by wrapping such nested blocks inside "anonymous line boxes" and thus drawing inline borders around such boxes. As CSS1 and CSS2 did not define this behavior, CSS1-only and CSS2-only user agents may implement this alternative model and still claim conformance to this part of CSS 2.1. This does not apply to UAs developed after this specification was released.

Make of that what you will. Clearly the behaviour is specified in CSS, although whether it covers all cases, or is implemented consistently across today's browsers is unclear.

Solution 2

Regardless if it's valid or not, the element structure is wrong. The reason that you don't put block elements inside inline elements is so that the browser can render the elements in an easily predictable way.

Even if it doesn't break any rules for either HTML or CSS, still it creates elements that can't be rendered as intended. The browser has to handle the elements just as if the HTML code was invalid.

Solution 3

The HTML and the CSS will both still be valid. Ideally, you wouldn't have to do something like this, but that particular bit of CSS is actually a handy (and syntactically valid but not semantically valid) way for getting Internet Explorer's double margin bug without resorting to conditional stylesheets or hacks that will invalidate your CSS. The (X)HTML has more semantic value than the CSS, so it's less important that the CSS is semantically valid. In my mind, it's acceptable because it solves an annoying browser issue without invalidating your code.

Solution 4

The HTML is validated independently of the CSS, so the page would still be valid. I'm fairly sure that the CSS spec says nothing about it either, but don't quote me on that one. However, I'd be very careful using a technique like this, as while it might render as intended in some browsers, you'd need to test 'em all—I don't see many guarantees being made.

Solution 5

Are the page elements still valid?

“Valid” in an HTML sense, yes; HTML knows nothing about CSS.

The rendering you get in the browser, however, is ‘undefined’ by the CSS specification, so it could look like anything at all. Whilst you could include such a rule in CSS hacks aimed at one particular browser (where you know how that browser renders this case), it shouldn't be served to browsers in general.

View more solutions

20,587

Matthew James Taylor

Artist, designer, web developer

Updated on December 14, 2020

Comments

Matthew James Taylor over 3 years
I know it's wrong to put a block element inside an inline element, but what about the following?

Imagine this valid markup:
```
<div><p>This is a paragraph</p></div>
```
Now add this CSS:
```
div {
   display:inline;
}
```
This creates a situation where an inline element contains a block element (The div becomes inline and the p is block by default)

Are the page elements still valid?

How and when do we judge if the HTML is valid - before or after the CSS rules are applied?

UPDATE: I've since learned that in HTML5 it is perfectly valid to put block level elements inside link tags eg:
```
<a href="#">
      <h1>Heading</h1>
      <p>Paragraph.</p>
</a>
```
This is actually really useful if you want a large block of HTML to be a link.
- JKirchartz about 12 years
  
  I'm glad html5 considers this valid, but valid code isn't the end-all be-all of the web. The Googles uses code that looks like horribly broken tag soup, but it works.
Guffa about 15 years

The problem with using browsers to validate the code is that you need to revalidate the page for every new version of every browser on every system where you want the page to work...
Sergei Kovalenko about 15 years

Yes, that is real problem, I know. Browser is not validator :) And I think, question about HTML+CSS result validating is a question of taste. Human factor.
mgPePe about 12 years

so then what do you do, when you need a whole row in a table to be clickable?
mgPePe about 12 years

and to ask you... how do you make a whole row of a table clickable?
Amit Patil about 12 years

@mgPePe: You put a link in every cell and set it to display: block so it fills the width of the cell.
mgPePe about 12 years

2 questions arise: can i have <a><span style="display:block"></span>[..more spans]</a> and also: can i then put vertical-align: middle to the span block, would that be valid?
Amit Patil about 12 years

@mgPePe: Yep! Possibly put the display: block on the <a> as well for clarity?
mgPePe about 12 years

yup, that too, but i still have the problem that vertical-align: middle does not work on span. :\ only tables can achieve it to my knowledge
Guffa about 12 years

@mgPePe: There are several options. You can put a link in every cell in the row, you can use Javascript to catch the click event on the row, or you can use something different from a table.
mgPePe about 12 years

Yes, JS is a good solution. What I ended up doing was to have an a with nested span display="block" according to this example: jakpsatweb.cz/css/css-vertical-center-solution.html
Chad almost 11 years

Just for clarification, it seems to me it is not wrong but part of the css specification that you 'can'. It requires extra work on the browser to create anonymous blocks. Also not consistent across web browsers.
Mark Amery about 9 years

Based upon the accepted answer, the claim that the behaviour is undefined (which is the meat of this answer) is wrong, isn't it?
Mark Amery about 9 years

@Guffa I downvoted, because it seems odd to me to simply assert that something is 'wrong' despite the spec stating that it is valid, and I can't tell from your answer when - if ever - the correct behaviour by the browser would be unclear. Perhaps there's something I'm missing, but it's not clear to me after reading this that the claim that "it creates elements that can't be rendered as intended" is true, or even what that means.
Guffa about 9 years

@MarkAmery: The spec doesn't state that it's valid.
Marius Mucenicu about 5 years

Hello @Alohci. I've got a situation that goes something like <div><a><span>Some text</span></a></div>. Here all elements have their normal display properties, however I use the ::after pseudo-element with <span>, with some text content and I set that pseudo-element to block. That element is a child of span which is a child of a which is a child of div. Since inline elements don't support width, how is the width 100% from being a block type work here ? I feel like I'm in this Anonymous box scenario, can you point me in the right direction? Thx
Alohci about 5 years

@George - You'll often see statements like "block elements [in normal flow] take 100% of their parent's width". That's not in fact correct. If you look at section 10.3.3 Block-level, non-replaced elements in normal flow you'll see that it's really "block elements [in normal flow] take 100% of their containing block's width". Inline elements like your span are not block containers. Instead the nearest ancestor element that is a block container (i.e. your div element) is used to establish the 100% width.
Marius Mucenicu about 5 years

@Alohci makes perfect sense. Thanks sir!