I have a div that contains several inline-block children:
The DOM looks like this:
It has the following CSS:
Each child has the following css:
If one unchecks and rechecks the display: block line marked above in the Chrome debugger, the div now looks like this:
Note that there is now space between the labels, and they are more readable. However, the CSS used to render this is presumably identical. Moreover, the div is actually still display: block when the specific selector's display: block is unchecked; it just obtains this from a less specific selector (in my case, the UA stylesheet for div).
I want the div to render the second way - is there a way to make this happen? How is the div supposed to be rendered, and where does the spacing between the display: inline-block elements come from?
UPDATE: This is probably caused by a weird interaction between Chrome's renderer and Meteor's Blaze rendering engine, and won't be seen except on highly dynamic pages.
This is a result of whitespace being evaluated. You can throw:
font-size: 0;
on the parent div and this will go away. Alternatively, adjust your markup to remove space between the list items.
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 have a situation where I would like an HTML img which has not yet loaded to have a pre-set height. The reason is that this height will be used in a calculation that may fire before the image is fully loaded and needs to remain accurate. I tried the following:
<div>hello<img src='http://example.com/invalid.gif' class="testimage"> there</div>
and put in some css
.testimage {
height: 200px;
width: 200px;
}
and at least in Firefox 5, the extra space is not rendered (and oddly, the broken image doesn't show either, just a blank space). That is, until I add display: inline-block. In at least some other browsers the default display of inline produces the desired result. Is this expected? If so, why?
Here's a jsFiddle as well: http://jsfiddle.net/uYXD4/
it says here that images are inline elements - http://htmlhelp.com/reference/html40/special/img.html
On the other hand take a look here - Is <img> element block level or inline level?
It looks like the <img> element is kind of both inline and block. No strict rules defining it, so probably the browser vendors make their own decisions about the defaults. So your best bet is to reset their assumptions to display: inline-block
Images are replaced elements:
An element whose content is outside the scope of the CSS formatting model, such as an image, embedded document, or applet. For example, the content of the HTML IMG element is often replaced by the image that its "src" attribute designates.
For replaced elements, display: inline-block is supposed to have the same exact same efffect as display: inline, which is the default.
So this may be a possible explanation for that strange behaviour in some browsers*:
They treat only completely loaded images as replaced elements, and otherwise treat them as non-replaced elements. That makes sense after all, and the standard does not explicitly disallow that. As a consequence, there's 3 possible scenarios:
replaced element, inline or inline-block doesn't matter, height property works
inline non-replaced element, height attribute has no effect
inline-block non-replaced element, height property works
Loaded images always qualify as 1., and broken/loading images may qualify as 1. or 2. (or 3. if you set display: inline-block explicitly)
*Not sure if that's how things actually work though.
Why not use something like
<img src="..." width=400 height=200>
I'm doing the exact same thing and it works quite well. Another option is...
$('.myimg').load( function() { /* ops */ } );
though I don't know if that waits to load the image in ALL browsers or not
<h5>Category</h5><h6>auto</h6>
places Category and auto on separate lines, like this:
Category
auto
How can I place them both on the same line, like this?
Category auto
h(n) elements are 'block' elements, which means they will grow to take all available horizontal space. This also means they will push anything "right" of them down to the next line.
One easy way to accomplish this is to set their display to inline:
<style>
h5, h6 {display:inline;}
</style>
Note that inline-block is not supported in all browsers.
You can also float block elements, but that can become a sticky issue as floating can be fairly complex. Stick with inline for cases like this.
<h5 style="display:inline-block;">Category</h5>
<h6 style="display:inline-block;">auto</h6>
You must change the display mode of the elements. H tags are rendered as BLOCK elements by default. To override this behavior add the following style definitions to your website or CSS
h5,h6 { display: inline; }
You can also decide to let them "float" next to each other you can do that via:
h5,h6 { float: left; }
Please note that floating only works on block elements (so using both styles will perform no float because inline elements cannot float).
Is there an "invisible" tag in HTML (4) that I can use to make CSS distinctions
tag.myclass tag.mysubclass h1 { }
without having any visual impact on the HTML rendered?
My background is that I have areas in a form that belong to different groups. As I am opening those in lightboxes (long story involving DOM operations and such, not really important) I don't want to rely on the usual div class=x or span class=y to style the subsequent elements, as I would have to reset margins here, paddings there, and so on.
A layout-neutral wrapping tag would be just what I need in such situations.
No, there is not.
(And that's because such an element wouldn't really fit into the rest of HTML. The only reason DIV and SPAN affect the surrounding area is because they're block and inline elements, respectively. What would an 'invisible' element be? If you need something that's completely independent, absolutely (or relatively) position it and give it a higher z-index.)
If you want to group elements use a div or a span tag as a wrapper element. Apply your id or class to this, and style it accordingly.
EDIT
There isn't an 'invisible' tag - but margins and padding can be easily reset 'margin: 0; padding: 0;'
While all browsers give default styling to many HTML tags, at it's core HTML only describes data, it doesn't format it.
What you're probably looking for is a DIV tag, because no browser gives any default styling to that tag.
I think you want a <fieldset>.
I'd say a span tag is as neutral as they come. I don't think there's any browser that applies a margin nor a padding and it just wraps around it's contents.
I suspect you can use <object> tag without usual attributes for that purpose, but I haven't tested it thoroughly yet. It's even in HTML5 (unlike FONT tag).
The right answer is use a div tag and define a class for it. Here is an example:
<h2 style="font-size: 14px">Project 1 - Project 2
<div class="username">{% if request.user.is_authenticated%} Welcome {{request.user.username}} {% endif %}</div>
</h2>
then in your css file you can have a class like this:
.username {
color:white;
float:right;
padding-right: 100px;
}
voila!! It all belongs to h2 tag but the user name has a different css applied.
You can add display: none; to it. That won't display it (obviously).
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.