Is it wrong to change a block element to inline wi

2019-01-01 07:24发布

站内问答 / HTML/CSS
2049 9 5

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.

标签： html css w3c xhtml
举报
9条回答
大哥的爱人
2楼-- · 2019-01-01 07:48

If there is a logic you follow and you end up implementing it like this, it's NOT WRONG. Working things are not "wrong" just because they're weird. Yes, it's quite unusual but it HELPS and it's not a mistake. It's intentional. HTML and CSS should serve you, not the other way around so don't ever listen to comments telling you not to do it just because it's ugly.

It's typical to call a solution "invalid" and suggest a long way around the block. Sometimes you can rethink what you did. But there can be many reasons for what you did and they don't consider them.

I do use blocks inside inlines regularly. It's valid and it's working - it's just not necessary in most cases. So what. Remember when XHTML told us to always put quotes around properties (and everyone yelled at you if you didn't!), now HTML5 allows to omit them if there's no space inside. What happened to that last slash after singular tags? "<br />" ? Come on. Standards change. But browsers keep supporting non-standard things as well. CENTER is deprecated; we're in 2013 and it still works. TABLE for vertical centering? Sometimes it's the only way. DIV inside A to make it hover as you planned? Just go ahead.

Focus on important things.

查看更多
0人赞 添加讨论(0) 举报
一个人的天荒地老
3楼-- · 2019-01-01 07:51

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.

查看更多
0人赞 添加讨论(0) 举报
还给你的自由
4楼-- · 2019-01-01 07:57

From the CSS 2.1 Spec:

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.

查看更多
0人赞 添加讨论(0) 举报
时光乱了年华
5楼-- · 2019-01-01 07:57

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.

查看更多
0人赞 添加讨论(0) 举报
余生请多指教
6楼-- · 2019-01-01 07:59

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.

查看更多
0人赞 添加讨论(0) 举报
大哥的爱人
7楼-- · 2019-01-01 08:06

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!

查看更多
0人赞 添加讨论(0) 举报
1 2 下一页
登录 后发表回答
相关问题
查看全部
相关文章
查看全部
收藏的人(5)