According to this quirksmode article, http://www.quirksmode.org/css/display.html
A block has some whitespace above and below it and tolerates no HTML
elements next to it, except when ordered
Are the whitespace above or below stated in pixels or is it just 'whitespace'?.
In the given context, "whitespace" is a gross misnomer. Whitespace in terms of text should never directly interfere with the layout of non-inline block boxes; what you should see between block boxes are margins (usually of said boxes), which are completely different.
Margins are indeed stated in pixels. In fact, they may be stated with any CSS length unit; see the margin properties in the spec. You don't specify a pixel length for whitespace directly for elements that flow inline; that is usually controlled by font-size instead, but when working with block boxes that should be entirely irrelevant.
The 'whitespace' is the element's margin and can be controlled via any standard CSS unit (e.g. px, em, %, etc.)
You can use the padding or margin properties of a CSS element to specify such a thing (in any CSS unit, including pixels). You many specify something like:
.class
{
padding-left: 4px;
padding-top: 3px;
}
The difference between padding and margin has to do with display. The padding property puts some 'whitespace' (rather clear space, whatever is behind the element will show there) between the element and its neighbor. A margin increases the size of your element around its content; the extra space will show up as whatever background the current element has.
Related
If the CSS text-indent will only do the first line, is there anything "wrong" with using the blockquote with the attribute of text-indent: xxx; that way everything within the blockquote attribute will be indented? Or, maybe that is the "right way" and I just don't know it (new/learning HTML and CSS)
The way to indent all lines of text in a block or, really, a block as a whole is to set margin-left or padding-left on it. The choice between these properties is relevant if the block has a left border (the border appears between margin and padding) or if it has a background color or background image (the background extends to the padding but not the margin).
Using the blockquote element means in practice setting a 40px margin on the left and on the right and a 1em margin above and blow. In the 1990s, and even later, blockquote was often used for indentation, because CSS was not available. It’s a blunt instrument, and using it is frowned upon as a matter of principle.
The text-indent property allows you to indent the first line of text within an element. The amount you want the line indented by can be specified in a number of ways but is usually given in pixels or ems.
It can take a negative value, which means it can be used to push text off the browser window. You can see this technique used in this example, where the element uses a background image to represent the heading. The text has been moved far to the left, off the screen. (Background images are covered on pages 413-418.)
I've set up a test here
http://jsfiddle.net/WZyF7/11/
Firefox seems to differ from Chrome and IE7-9 on how to calculate the width. Instead of giving the content as much width as it needs, it makes the div as wide it's widest child element. This stacks the elements vertically in FF, while horizontally in other browsers.
Is there any way to make all browsers handle this the same way without setting a width to the parent element or using JS? And does anyone have information on exactly how this is calculated across browsers? (width:auto; ? )
The relevant spec bit is http://www.w3.org/TR/CSS21/visuren.html#floats where it says:
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself. If necessary, implementations should clear the said element by placing it below any preceding floats, but may place it adjacent to such floats if there is sufficient space. They may even make the border box of said element narrower than defined by section 10.3.3. CSS2 does not define when a UA may put said element next to the float or by how much said element may become narrower.
And the part in http://www.w3.org/TR/CSS21/visudet.html#float-width which says:
If 'width' is computed as 'auto', the used value is the "shrink-to-fit" width.
and following. Note that the actual computation of preferred width, which is what matters here, is not all that well defined. So basically, per spec behavior in this situation is undefined.
In any case, what's happening here is that Firefox is giving the overflow: hidden block the width it should have per section 10.3.3 and then clearing it past the float, while Chrome and IE seem to take the "they may even" path. And in particular, it's assuming it will do that when computing the preferred width of the parent.
All that said, I think the Firefox behavior is more correct in this particular narrow case: your "container" is 400px wide. The "parent" has 20px of horizontal padding. The "floated" is 300px wide. The "content" has 20px of horizontal padding. That leaves 60px of width for the text inside "content", but the longest word ("available...") is about 70px wide with my fonts. In Chrome, for example, the only way "content" fits next to the "floated" is because the right padding of the "content" disappears entirely. Firefox will do the same thing if you give a fixed width to the "parent" here.... but then you're forcing a width, instead of asking the browser to pick a reasonable one via the shrink-wrap algorithm, of course.
Your best bet here is to just give the "parent" a specific width if you want it to have that width, instead of relying on shrink-wrapping to produce a width that's actually too small for the content.
I took a page whose DTD was HTML4 Transitional and changed the doctype to <!DOCTYPE html> and extra space appeared between the h1 and div beneath it. I didnt make ANY other changes to markup or CSS.
JSFiddle example: http://jsfiddle.net/ngordon/vSqkg/3/.
If you change the doctype from HTML5 to HTML4 Transitional, you can see the extra space appear and disappear even though the markup and CSS is exactly the same.
Any idea how to get rid of that space?
The HTML 4.01 Transitional doctype causes Almost Standards mode in browsers. The HTML5 doctype causes Standards mode.
This Microsoft article explains the difference: http://msdn.microsoft.com/en-us/library/ff405794%28v=vs.85%29 .
It says that for Almost Standards mode:
Inline elements contribute to line height if and only if one of the
following is true.
If the element:
Contains text characters
Has a nonzero border width
Has a nonzero margin
Has a nonzero padding
Has a background image
Has vertical-align set to a value other than baseline
Note that a line break is not considered a text character for this
definition unless it is the only content of a line box. In that case,
the line box height remains the uppermost inline box top and the
lowermost inline box bottom on the line, regardless of the specified
line height.
If an img element is the sole content of a table cell, the line box
height of the cell line box height is adjusted to zero.
Most critically in your case, it means that the calculation of the height of the line containing the image doesn't include the strut, an imaginary inline element that should increase the line height to the line-height value of the h1 element.
This jsfiddle shows a real span element with an as real text content standing in for the strut, and you can see that the layout is the same with both an HTML 4.01 Transitional doctype and an HTML5 doctype.
This jsfiddle shows the same idea, only this time the strut is fabricated using CSS, like this:
h1:before {
content: '\A0';
}
In the case of khurram's answer, what he is doing is reducing the line-height of the h1 and hence, in standards mode, the height of the strut to be less than the height of the image. This means that the height of the line as a whole is determined by the height of the image, not the height of the strut. The height of the image is the same in both standards and almost standards mode so again, you don't see a difference in rendering between the modes.
As for why setting the line-height of the h1 to match the height of the image (25px) doesn't work but setting it to 12px does, that's because the strut establishes not only a top and a bottom, but also a baseline for the line. The baseline is a little above the bottom to allow for text descenders, for normal size text that's usually about 3px. The image by default sits on the baseline so the gap between the baseline and the bottom is added to the height of image to establish the height of the line.
This can be resolved by moving the image off the baseline, by using img { vertical-align: top }, which is shown in this jsfiddle. If you tinker with the h1 line-height here, you will see that values greater than 25px increase the spacing between the lines, but values of 25px or less do not change that spacing.
Have you applied a CSS reset http://meyerweb.com/eric/tools/css/reset/ to your css before you start applying any other css effects?
Your bug deals with default line height.
The HTML4 transitional is ignoring the contents of your H1 wrt line height, yielding a 25px tall element. The HTML5 is respecting the line-height of the H1 tag, which equates to 29px.
just give the line-height:12px; or what you want.
TAKE A LOOK: JSFIDDLE. modification of your code.
This is why the HTML5 Boilerplate has a CSS reset.
You can also just set the div to a margin: 0; padding: 0; but you are going to have to do for every element until you hit them all. The answer about the CSS reset by Meyer in this thread is correct.
Here is an example of the workaround: http://jsfiddle.net/mikelegacy/vSqkg/5/
I was very surprised when I found that a <div> with a size of - say - 200px becomes 220px wide if you give it 10px padding. It just makes no sense to me, the external size should not change when an internal setting does. It forces you to adjust the size every time you tweak the padding.
Am I doing something wrong, or is there a reason for this behavior?
EDIT: I know this is how it's supposed to work, my question is why? Is it logical in a way I don't understand? Does this give any advantage over the opposite approach of keeping size and padding separate?
There are two different so-called "box models", one adds the padding (and border) to the specified width, while the other does not. With the advent of CSS3, you can luckily switch between the two models. More precisely, the behaviour you are looking for can be achieved by specifying
box-sizing: border-box;
ms-box-sizing: border-box;
webkit-box-sizing: border-box;
moz-box-sizing: border-box;
width: 200px;
in your div's CSS. Then, in modern browsers, the div will always stay 200 px wide no matter what. For further details and a list of supported browsers, see this guide.
Edit: WRT your edit as to why the traditional box model is as it is, Wikipedia actually offers some insight:
Before HTML 4 and CSS, very few HTML elements supported both border and padding, so the definition of the width and height of an element was not very contentious. However, it varied depending on the element. The HTML width attribute of a table defined the width of the table including its border. On the other hand, the HTML width attribute of an image defined the width of the image itself (inside any border). The only element to support padding in those early days was the table cell. Width for the cell was defined as "the suggested width for a cell content in pixels excluding the cell padding."
CSS introduced margin, border and padding for many more elements. It adopted a definition width in relation to content, border, margin and padding similar to that for a table cell. This has since become known as the W3C box model.
The reason why it's like that is that technically the width of elements is supposed to apply to the content, not the container.
According to the CSS1 specification, released by the World Wide Web Consortium (W3C) in 1996 and revised in 1999, when a width or height is explicitly specified for any block-level element, it should determine only the width or height of the visible element, with the padding, borders, and margins applied afterward.
More info about this behavior*
* Disclaimer: Yes, this is my own blog and I think I did a thorough job of explaining the box model so I'm putting it as reference.
Padding is supposed to be in addition to the given width of an object.
See the CSS 2.1 specification for box model.
While it is true that you can view padding as either an internal or an external attribute, the fact of the matter is that according to the current specifications it is an external attribute. It was a choice between two, as far as I can tell, equally valid options.
I haven't read up on the box-model attribute, but assuming that alex is right, then in the future you will be able to choose between the two ways of interpreting padding.
If the size increases with padding, it's working as intended. In browsers with broken box models like older Internet Explorer versions, the div will be 100 pixels wide, but that's incorrect handling of the CSS.
http://www.w3schools.com/css/css_boxmodel.asp
If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?
It's better that the default behaviour is that the width of the container is not affected by padding or margin values.
If your box is within a box, remove the inner box's width (the one with the padding) and it will fix the problem.
""If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?""
First of all, any good web developer would know better than to put an image into a container where it doesn't fit. That is developing 101. If the padding doesn't allow for the image, the image or the padding should be changed. Pure and simple. So the argument mentioned above is faulty.
Padding is an internal setting, internal to the boundries of the container. So when something is inside that container, and you increase the container's padding, the item(s) inside that container should coded so the can be reduced in size.
The word "padding" itself says it all. Can you imagine if UPS added padding to thier boxes to protect the contents inside, only to find that the box increases in size! Rediculous, right? Of course it is! Padding is meant to add space around the inside of a container WITHOUT the container breaking and expanding in height or width.
It's browsers like mozilla, gecko, and opera that have broken box models, not IE. The box model that the "consordium" implements is faulty at best and reaks havoc on web develpers.
If the "consordium" implemented the same box model as IE, than we developers would have a much easier time with the columns of our webpages. I think you have to agree with me on that point. Plain and simple.
I am so tired of people saying that IE is inferior. I can give tons of examples where IE holds strong while the cheaper browsers like firefox break under the pressure.
My two cents. Hate me if you want, but what I speak is common sense and nothing else.
The font size I need to match the design I have is 85pt, which is extremely large. In IE6 and IE7, my design is affected because the divs that contain these elements become larger than they normally are, and as a result, elements under these are pushed further down, somewhat breaking the design. I have the height defined for these elements and when I decrease the font size, the elements begin to shrink to the correct size. I've added line-height: 0; to the element and this works in all modern browsers.
Unfortunately, the design I'm working on cannot be shown publicly, but I was hoping to get some insight into other possible techniques that I could try to get the design to render correctly. The height of the parent element is 144px, which includes 10px padding on top and bottom and a top and bottom 1px border.
Unfortunately there's not a lot more that I can add to this, but I'll include whatever info I can if asked.
line-height:0 is a great start. However, I'm a little concerned about the 10px padding on the parent element. Whenever you mix padding with IE, you start to lose control over width & height.
I'd start by removing the padding-top on the parent and convert that into a margin-top:10px on the actual child element. If that still gives you trouble, remove the margin and try a position:relative on the child with a top:10px.
Finally, try adding a overflow:hidden to your parent element to force it to not budge when the font-size gets larger.
All this depends on what your child element actually is. If you convert it to an inline element (like a span, em, or strong) it might help alleviate some rendering issues, depending on your predefined styles.
Another thing to consider - are you using floats? Sometimes you'll get a double-float issue with IE and floats. A quick google for "IE double float" will show you why.
Does that help?
Convert the font-sizes to pixels and use px instead of pt. Make sure there that padding, margin and border is 0. Verify that there are no whitespace in your HTML except for between words. Whitespace can end up being displayed as a newline or space, making elements bigger than intended. Also don't set line-height to 0, set it to either auto or the same as font-size.
Thank you all for your input. Originally I needed absolute positioning on the element in question, while the parent element had relative positioning. However, using this with line-height: 0 caused the text to disappear in IE6 and 7; after trying to figure out where the text was initially, I removed absolute positioning and decided to leave the text left aligned in IE6 and 7, which affected the position of other elements as a result. I revisited the original absolute positioning and added border to the element to reveal its location. Doing this showed that it was exactly as I defined it: an element with a line-height of 0px, so the top and bottom borders were next to each other. For IE6 and 7, I defined line-height: 100%; and my text was almost where I needed it. I added top and the needed pixels and now my element is in the correct position with its line-height not affecting any of the other elements because of the positioning.
Thank you all again for your assistance.
My first thought when reading your post was to adjust the line-height, but since you've already done that, I'm not sure how much more can be done. From your summary, I gather that the design cannot be modified to account for the large font sizes.
Another answerer recommended using pixel sizes, but I would recommend using ems as they are percentage dimensions and will be more consistent across browsers, screens, and resolutions.
Line-height can be left as 0 (or set it to the height of the parent element), but you will likely see the text floating over other elements if the text's height surpasses the line-height.
Any possible way you could use an image for the text instead? That's really the only fool-proof method for getting all browsers to look consistent.