First of all, I've seen this question IE Compatibility issue, but I have a slightly different issue:
I have a span with display: block and I want to put a H2 tag inside it. Will this look good in every (major) browser?
The answer on the previously stated link, was to make the H2 display:inline, which I don't want, and also I don't want to replace the span with a div, because I would have to change a lot of CSS.
PS. I don't want my HTML to validate (using the validator), I just want it to work.
When you say "I don't want my HTML to validate (using the validator), I just want it to work." You're making a very big mistake. If HTML doesn't validate, there's no telling what might happen. The standards are there for a reason.
Replace the span with a div, you don't need display block on the div as it has this by default. A span is an inline level element, whereas an H2 is block level. An inline element cannot contain a block level element (true up to HTML5, where you can wrap block level elements in anchors)
This will validate, and will work!
It works on current browsers (including old versions), and it is unlikely that this will change. Errors like this are common enough to make it rather pointless to browser vendors to change their error recovery mechanisms. HTML5 is about to make the error recovery rules mandatory.
On the other hand, what is the point of using span with display: block, instead of using div? And CSS should be written so that it does not depend on specific choices of markup elements where different choices could make sense; for example, as a rule, .foo is a better selector than span.foo.
Any extensive change to markup or style sheets has a nonnegligible risk of causing problems even when the change is a such an improvement and a simple one. (For example, a global search and replace often does too much, or misses something.) This could be a reason for continuing the use of invalid markup, in cases where it has minimal risk in practice.
we can solve IE second line problem first
h2{}
h2 span{ float:right;}
Correct way in all browsers
<h2><span>sub content</span> Heading</h2>
wrong way ie browser
<h2>Heading<span>sub content</span></h2>
Related
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.
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.
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.
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.
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.
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.
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!
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.
I think, (x)html is valid, css is valid. Is the result valid? Yes, if it is looking in the browser as You want.
No, It is not a wrong choice. We can use as per requirements.
I am working on a website where users can post comments. I intend to use the <ins>-element herefore. When comments are inaccurate, they will be marked as deleted using the <del>-element.
My first question is whether I use the semantics of these elements correctly?
It surprised me when I saw at W3C that these two elements can contain block-level-elements inside it since that is usually not the case for text-elements who are set to display: inline; (cannot have a width, height etc.). I checked the computed browser value which is definately display: inline; for both <del> and <ins>.
So my second question is how the browser makes this special behavior to work? (Or is it even special? - am I missing something?)
Try not to confuse styling (CSS) with the HTML content model. These are deliberately separate and orthogonal concepts. The only link is that some HTML elements have a consistent default styling.
Although ins and del could be used the way you describe in HTML4, HTML5 makes this separation much more distinct, because it does not use the terms "block" and "inline". These terms are left to CSS. HTML5's content model uses separate categorization, including "flow", "phrasing", and important in this case, "transparent"
The content model is used to assist a document content's meaning. But browsers do not care about the meaning, only how to render it.
CSS provides clear rules about how to render block elements inside inline elements, completely regardless of HTML's content model restrictions. See this answer: Is it wrong to change a block element to inline with CSS if it contains another block element? .
So, no the behaviour isn't "special", and browsers do not have to do anything except use the normal CSS rules to handle it.
As for your first question, it's hard to tell whether "inaccuracy" should imply use of <del>. If the commenter intends to withdraw that inaccuracy, then <del> would be appropriate, otherwise probably not.
I passed a style sheet with the following to the W3C validator and it passed:
a {
display: block;
}
So want to make sure, is it valid markup to use an inline element as a block one?
I know it will work but is it valid?
Thanks
Yes, it's completely valid. And useful too.
One small note (since the above answer is very short), this method of styling normally inline elements as block elements is quite common. For example, when creating a horizontal navigation menu from a list, you'll often see <a> elements styled with display:block in order for the links to be able to take up the full width and height of the parent list item.
Yes it's valid but also you can use inline-block to use an inline element while keeping the block properties.
Yes, it is valid.
There are elements, as you know, that are inline or block by default. But it is completely valid to then go and override this in CSS.
Yes, it is valid. However, if you really don't want to do that, you could wrap the a in a div. That would be useless though, because it is completely valid; that's why the display attribute is there.
The style sheet is valid, in the sense that it conforms to the CSS specifications. This is a purely formal thing. In CSS, the selector a has no special meaning, it is just an identifier; CSS has no information about the meaning of a in HTML, such as being an inline element, and the style sheet could in fact be used to style an XML document, where a means something completely different.
HTML validity, on the other hand, does not depend on CSS at all. It is a formal thing about markup, and style sheets aren’t markup.
Whether it is “valid” in some other, informal sense (like “good practice” or “useful” or “conforming to a style guide”) is a different issue, and a debate issue rather than a technical question. Anyway, it is common usage to set display: block on an a element to make it possible to set its dimensions the way we can do for blocks (e.g., to make a link fill a table cell).
Are both <h1><a ...> ... </a></h1> and <a ...><h1> ... </h1></a> valid HTML, or is only one correct? If they are both correct, do they differ in meaning?
Both versions are correct. The biggest difference between them is that in the case of <h1><a>..</a></h1> only the text in the title will be clickable.
If you put the <a> around the <h1> and the css display property is block (which it is by default) the entire block (the height of the <h1> and 100% of the width of the container the <h1> resides in) will be clickable.
Historically you could not put a block element inside of an inline element, but this is no longer the case with HTML5. I would think that the <h1><a>..</a></h1> approach is more conventional though.
In the case where you want to put an anchor on the header, a better approach than <a id="my-anchor"><h1>..</h1></a> would be to use either the id or the name attribute like this: <h1 id="my-anchor">..</h1> or <h1 name="my-anchor">..</h1>
In pre HTML 5 this one
<a><h1>..</h1></a>
will not validate. You can use it in HTML 5.
However, i would use this:
<h1><a>..</a></h1>
unless you need to add more than < h1 > inside the < a >
<a><h1></h1></a> is not W3C valid... Basically, you can't put block elements inside inline elements
<h1><a>..</a></h1> and <a><h1>..</h1></a> have always behaved almost the same, when style sheets do not affect the rendering. Almost, but not quite. If you navigate using the tab key or otherwise focus on a link, a “focus rectangle” appears around the link in most browsers. For <h1><a>..</a></h1>, this rectangle is around the link text only. For <a><h1>..</h1></a>, the rectangle extends across the available horizontal space, since the markup makes the a element a block element in rendering, occupying 100% width by default.
The following shows how a focused <a href=foo><h1>link</h1></a> is rendered by Chrome:
This implies that if you style elements e.g. by setting a background color for links, the effects differ in a similar manner.
Historically, <a><h1>..</h1></a> was declared invalid in HTML 2.0, and subsequent HTML specifications followed suit, but HTML5 changes this and declares it as valid. The formal definition has not affected browsers, only validators. However, it is remotely possible that some user agents (probably not normal browsers, but e.g. specialized HTML renderers, data extractors, converters, etc.) fail to handle <a><h1>..</h1></a> properly, since it has not been allowed in the specifications.
There is seldom a good reason to make a heading or text in a heading a link. (It’s mostly illogical and bad for usability.) But a similar question has often arised when making a heading (or text in a heading) a potential destination for a link, using e.g. <h2><a name=foo>...</a></h2> versus <a name=foo><h2>...</h2></a>. Similar considerations apply to this (both work, there may be a difference since the latter makes the a element a block, and before HTML5, only the former is formally allowed). But in addition, both ways are outdated, and using the id attribute directly on the heading element is now recommended: <h2 id=foo>...</h2>.
H1 elements are block level elements, and anchors are inline elements. You are allowed to have an inline element within a block level element but not the other way around. When you consider the box model and the HTML spec this makes sense.
So in conclusion the best way is:
<h1>Link</h1>
do you want to use a hyperlink <a href="…">/a:link, or do you want to add an anchor to your heading? if you want to add an anchor, you can simply assign an id <h1 id="heading">. you can then link it as page.htm#heading.
if you want to make the heading clickable (a link), use <h1><a></a></h1>/h1 > a – blocklevel elements first, and inline elements inside
Also, there is style hierarchy differences. If you have it as <h1>Heading here</h1>, The styles of the anchor will overrule the styles of the h1 element. Example:
a {color:red;font-size:30px;line-height:30px;}
WILL OVERRULE
h1 {color:blue;font-size:40px;line-height:40px;}
I think the <h1>text</h1> is the least problematic with weak or old browsers, but modern browsers and powerful search engines are supporting both it and <h1>text</h1>; So it's a good freedom and useful to use both to improve our web page.
«Hope that could be useful»
Both are correct. They depend on the sizing of the anchor tag which you want and how you want your website laid out.
You can do <h1>Home Page</h1>, in which case it would return: Home Page But with an Anchor.
Or you can do <h1>Home Page</h1> and it would return a H1 hyperlink instead of just heading an anchor to the H1, like so:
Home Page
However, mostly you cannot add links within H1 because it will just render it as an anchor onto the h1 rather than adding a hyperlink. However, I think I'm right in saying that you could see a difference in behaviour for this on different browsers.
But correct me if I am wrong. :)
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.
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.
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.
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.
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.
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.
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!
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.
I think, (x)html is valid, css is valid. Is the result valid? Yes, if it is looking in the browser as You want.
No, It is not a wrong choice. We can use as per requirements.