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.)
Related
strong textSeems like a common problem, but in my case it's complicated by a few extra requirements, so what I found on SO and MDN didn't lead me to a full solution.
Simple premise:
Horizontal nav bar, full width of the page, semi-transparent background, variable number of tabs (extra space filled with same background as tabs).
Easy, right? Give the container element rgba background, set nav items display:inline or float them left and you're golden.
Complication 1: Active tab has to have a triangular cutout (see pic).
Ok, I can have a cutout by setting background-image to a png with transparent bit. The background of the parent element would get in the way - so set background to individual elements instead of parent.
What about the variable width "empty space" past the tabs (see pic)? Ok, put an empty element with a larger than life width, and cut it off with overflow:hidden on the parent.
Complication 2:
Buttons need tooltips on hover.
Ah, the thrill! The suspense! overflow:hidden won't do unless I put tooltips outside of nav div altogether (which would probably work - but seems smelly).
So, here are a few things I tried:
Old implementation which doesn't have the "filler" element width problem but clips off half a tooltip (with overflow:hidden):
http://codepen.io/istro/pen/aHcdi
Messing with display:table seems to give little control over how display:table-cell div width is decided, also needs content to display the div in the first place. Content can be moved away, but still no good (didn't even add a tooltip here):
http://codepen.io/istro/pen/uIcfn
Messing with floats (tooltip sorta where I'd want it to be more or less), but clueless how to make the last "filler" element fit remaining width:
http://codepen.io/istro/pen/aIGxB
So the question - how could I make a div to fill the remaining width with CSS only? Or perhaps I'm asking the wrong question altogether, in which case what ideas would I use to implement it cleanly?
Thanks!!!
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.
Whenever i use a large line-height like 1.6em it always adds a margin in the very top of the text which i don't want.
Example: http://jsfiddle.net/EstpJ/1/
i want the text to be sharply lined with the borders and not have any kind of top or bottom margin.
How to fix that?
That's exactly what line-height is, it's a manual way to set the height of a line of text for the purposes of wrapping text and such. The actual visible size is determined by the font-size and to a lesser extend by the font-family. The average line-height for normal text/font is around 1.2em. Anything larger than that will cause visible letterboxing, which is exactly what you are describing. Using a smaller value will cause successive lines to overlap each other.
The only way to fix your exact example is introduce more markup to determine line numbers so that you can style the first/last line differently.
You could maybe slightly alter your markup (I prefer wrapping <p> tags around lines of text) and use a negative top margin?
As Matthew said, this is what lineheight does.
You could try to set the line height on an inner div (inside the one with borders), and counteract the top and bottom effect by also setting a negative top and bottom margin. But it's likely that the negative margin won't work in all browsers.
Just looking at some CSS here, and I noticed:
.head{position:relative;overflow:hidden;margin:-30px 0 0 -25px;width:820px;padding:20px 25px 0 25px;background:url(/images/bkg.gif) 0 0 no-repeat;}
Why would you put -30 and -25px margins?
I started typing an answer, and then found a much better one here (Wayback Machine backup). Some salient points:
Negative margins:
are valid CSS
don't break page flow
have high levels of cross-browser compatibility (although if they break your link or floated image, then try adding position: relative; that should fix it)
Their effect on unfloated elements:
applying them to the top or left of an element "pulls" that element in the appropriate direction(s)
HOWEVER, applying them to the bottom or right of an element "pulls" immediately subsequent elements into them, making them overlap
Their effect on floated elements:
this is more complex and I can't summarise it better than the article. Have a play around in Firebug to get a feel for them.
There are some brilliant examples of negative margin use in that article (especially the 3-column layout! Magic. I've used a similar technique for page layout before.) The most common use for them I've found is just to move an element a small amount to correct its position, and to make one element overlap another for visual effect.
A lot of tricks and nice effects use negative margins:
Image Replacement Trick - when you want to use that particular font and you just can't tear away from it, image replacement is the trick. Uses negative margins to push out the regular font and replace it with the "picture" font.
Image Rollovers with borders - giving a negative margin to the image the same size in pixels as the border size will keep the image, and therefore the layout, from shifting on a rollover.
Center screen positioning - using negative margins the same dimension as the height and width of the object you want to center, you can center an object in the middle of the browser.
Negative margins can be helpful when you have other element "around" that you want to e.g. have a padding for all other elements. I use it very often, read here, why:
http://www.simplebits.com/notebook/2005/05/23/negative.html
Actually i think there is an use case where negative margins are the only right thing to do:
You want an part of a box to extend over the whole parent, even over the padding. So instead of removing the padding of the parent element an apply it to all children exept for your special case, you give your special case a negative margin. Also no haggling with positioning. Works great and is very readable.
Example: http://codepen.io/anon/pen/DpHvu
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.