views:

647

answers:

8

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?

A: 

Hi Matthew, I don't know off the top of my head if this validates any rules but I would recommend using the W3C HTML Validator and the W3C CSS Validator to determine that. Hope this is helpful!

Adam Alexander
A: 

I think, (x)html is valid, css is valid. Is the result valid? Yes, if it is looking in the browser as You want.

Sergey Kovalenko
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...
Guffa
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.
Sergey Kovalenko
+8  A: 

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.

Guffa
+2  A: 

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.

Samir Talwar
+3  A: 

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.

VirtuosiMedia
A: 

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.

bobince
+2  A: 

From the CSS 2.1 Spec

When an inline box contains a block box, the inline box (and its inline ancestors within the same line box) are broken around the block. The line boxes before the break and after the break are enclosed in anonymous boxes, and the block box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, the relative positioning also affects the block box.

Example(s):

This model would apply in the following example if the following rules:

body { display: inline } p { 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> This is anonymous text before the P. <P>This is the content of P.</P> This is anonymous text after the P. </BODY>

The BODY 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 an anonymous block box around the BODY, containing an anonymous block box around C1, the P 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 BODY 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.

Alohci
A: 

No, It is not a wrong choice. We can use as per requirements.