Font tails in headlines - css

Hello I have problem which you can see here: http://adrianwajs.pl/monika/. "coming soon" sign when you hover over h2,which wraps it you can see that, in firebug you can see that letter g doesn't fit the height of h2 element. I have seen it many times but I can't find solution for this, maybe someone has?

First of all your h2 says 'Comming Soon' Instead of 'Coming Soon'
I don't see a problem in Chrome, IE, Firefox.
There are two things you can do:
More padding on your h2 tag. for example h2 { padding: 30px; }
A line-height of for example like line-height: 1.5;

In general, a glyph may well extend below the bottom edge of a line box, even when text is set solid (line height equals font size). This is up to the font designer. If this causes a problem, use a larger line height or a different font.
On your page, the descender does not actually extend that far, as you can see by drawing an outline for the heading, for example. However it almost extends to the bottom of the font and far below the baseline; this is not uncommon in fonts that imitate handwriting.
Update: The features of the Pacifico font used on the page cause line boxes containing text in that font to have a largish height, larger than line-height. On the page, in Firefox, the span containing “Comming soon” is 128 pixels high for such reasons and thus extends past its container, the h2 element.
Line box heights are calculated by browsers on the basis of height requirements, including font properties, and there is no direct way to control this. You just need to live with it and provide sufficient spacing with margins or padding.

Related

Using "vw" to get 100% width headings

I have an h1 I want to fit the entire width of the viewport which consists of 13 characters in a monospaced font. After reading the CSS-Tricks article on viewport sized typography it seems like logically if I want to achieve this I simply have to set my h1's styles to:
h1 {
font-size: 13vw;
font-family: monospace;
}
This however is rendering with a bit of space left over (highlight the text to see the white space):
(There would be an image here but I don't have enough rep so click here for the JSFiddle)
I have tried other sizes, font-size: 14vw; is slightly too big, font-size: 13.99vw; seems just right, but strangely font-size: 13.999vw; is still too big?
Can someone explain what is going on here? Why would each character of a 13 character length string in a monospaced font require more than (100/13)% of the viewport width to fit the entire viewport width?
Before I begin I'm just going to say that I'm not going to give you a workaround due to issues I've raised in comments on Stoyan Dekov's answer. Instead I'm only going to answer your question of Can someone explain what is going on here?
font-size != width
The problem here is that you're assuming font-size is the same thing as width. It isn't. The CSS Fonts Module defines font-size as:
...the desired height of glyphs from the font.
This means that font-size is more comparable to height than it is to width.
This isn't specific to the vw unit, either. If you specify a font-size in pixels you'll also notice that the computed width does not match the font-size.
But even then it all depends on which font-family you're using anyway, as the same paragraph continues to say:
For scalable fonts, the font-size is a scale factor applied to the EM unit of the font. (Note that certain glyphs may bleed outside their EM box.) For non-scalable fonts, the font-size is converted into absolute units and matched against the declared font-size of the font, using the same absolute coordinate space for both of the matched values.
The key words here being scalable and non-scalable.
Even if a non-scalable font was being used though, 13vw would not reflect each character's width. This would never work with vw, but it may work with vh but only if the aspect ratio of each individual character matched the screen's aspect ratio.
The problem is if a text is the exact same size as the parent container, it will span across a second line.
body {
margin: 0;
width:100px
}
h1 {
font-family: monospace;
width:100px;
}
That will cause the text to go onto a new line as they are both 100px. That's why 14vw is too big, but 13.99 is just enough: Fiddle DEMO
However, you can use text-align: justify; to achieve what you want.
Take a look at this Fiddle DEMO.

How can <H2> size be larger than the text, with no size set?

I'm trying to create a border around an <H2> and the border is always rendered much larger than the <h2> text. No size is set anywhere. The H2 contains one sentence of text with a 25px font size, and let Chrome Developer Tools -> Metrics reports that the size of the H2 is 980x183, and I can visibly see that this extends beyond the text to the right, all the way up past the text to the top of the screen, and far, far to the left of the text.
So, with no size being set, how can the area of the H2 element be so much larger than the text? I might need to provide a lot more context for anyone to answer this, but it seems almost like the question should be able to stand alone.
The <div> containing the H2 is 0px x 0px, which also blows my mind a bit, but I've googled around quite a bit and don't feel that is likely to be related.
Try adding CSS:
h2 { display: inline; padding:0;margin:0}
h2 elements are displayed as blocks with default margin and padding
<h1> is a block-level element, which by default stretches to the full width of its container. That would mean that the width of the h2 box and the h2 text is not the same.
I'm not sure about your specific case, but you may want to change the display setting to either inline or inline-block and experiment with the results of those.

CSS Div with background image - how to allow for expansion of div on page?

I wasn't sure how to word the question for this topic...sorry.
I'm just starting to learn CSS.
I have a <div> with a background image and there is text within the <div>. I read that choosing font sizes in em is a good choice because some people might require larger text sizes in their browsers. So setting the font-size with em would accommodate these types of users better.
But the problem with allowing the text to be resized, is that in many cases, the text within my <div> is going to go beyond the size of the background image and make the page look terrible and poorly designed.
Is there a way to use CSS and allow the background image to 'match' or 'expand' to accommodate to larger text size?
You could set the width of the div to the img width so that it never expands wider (beyond the image).
Of course, the enlarged text would force the div to grow height-wise.
You could also set the background-img to repeat (if the image allows for it), so that when the text expands, the image is repeated.
background-image:url('whatever.png');
background-repeat:repeat-x;
// x = horizontal, y = vertical
Since you are starting out, you might want to read http://na.isobar.com/standards/#_pixels_vs_ems wherein they say:
We use the px unit of measurement to
define font size, because it offers
absolute control over text. We realize
that using the em unit for font sizing
used to be popular, to accommodate for
Internet Explorer 6 not resizing pixel
based text. However, all major
browsers (including IE7 and IE8) now
support text resizing of pixel units
and/or full-page zooming. Since IE6 is
largely considered deprecated, pixels
sizing is preferred. Additionally,
unit-less line-height is preferred
because it does not inherit a
percentage value of its parent
element, but instead is based on a
multiplier of the font-size.
Correct:
#selector {
font-size: 13px;
line-height: 1.5; /* 13 * 1.5 = 19.5 ~ Rounds to 20px. */
}
Incorrect:
/* Equivalent to 13px font-size and 20px line-height, but only if the browser default text size is 16px. */
#selector {
font-size: 0.813em;
line-height: 1.25em;
}

Should I define CSS margins in pixels or ems? Why? When?

We have a CSS file with some rules similar to the following:
.directory-result ul
{
margin-top: 20px;
width: 60em;
}
.about-text
{
margin-top: 1em;
margin-bottom: 1em;
}
Everything is working ok, but we're wondering specifically about the inconsistencies between the margin-top values. One is 20px and the other is 1em.
Which is the best one to go with? What are the points I should consider when deciding which to use? Thanks.
em units are used for better scalability of the page when the size of the elements depend on the page's scale. It's especially important for old browsers (e.g. IE6) and mobile platforms.
px units are used for absolute values, while em is relative to the font size of the particular element.
1em means one font-line, e.g. you have a box with font-size 12px that means that 1em will be equal to 12px
Also, using px seems easier because you know the exact value, but em units inherit the value of their container.
<p>Text</p>
<div class="box">
<p>Lorem</p>
</div>
p {
font-size: 1.2em;
}
.box {
font-size: 1.2em;
}
In this case, the first <p> will have font-size equal to the basic font-size * 1.2, and the second <p> will display with font-size * 1.2 * 1.2.
They're simply two different ways of measuring. Em is linked to the font size (traditionally, 1em is roughly the width of the letter M in a given typeface), while px is pixels.
If you build everything using em, everything will scale accordingly when the user adjusts their font size (e.g. using IE's Page > Text Size menu). It also makes it easier to work to a vertical rhythm.
Pixels are better when you want to build something "pixel-perfect". Be aware that a CSS pixel doesn't always equal a screen pixel - mainly because modern browsers and mobile devices allow for zooming. This isn't usually a problem though because the entire page is scaled accordingly.
Whatever you do, make sure you're consistent throughout - it makes life much easier later on.
The ems unit is relative to the current font size in the browser. So if the user increases the font size*, or if you change an element’s font size in the CSS, the margins should still look “right” in proportion to the text.
*(This ceases to matter if the user zooms the page instead of increasing the text size (as is the default in Firefox and Chrome now, and is an option in IE).
If you're using a margin to position something a set number of pixels away from something else, then you should obviously stick with pixels.
Also here is a very good in depth tutorial:
px – em – % – pt – keyword
In this example directory-result ul represents a block - some sort of list/menu where pixel dimensions are quite important. We can’t always rely on em which defines the text size, because if we need 20px space due to some background image – well, we need 20px, no compromises.
Note that you can't create and save the image i.e. 10em wide, therefore I see no reason why should I use different units on a web page. It just creates confusion and later on it is very difficult to maintain the layout.
There is a one place though, where using em is advisable – I’m talking about text blocks. I’m guessing in your code about-text is placed within other text where adding top/bottom margin of 1em (height of text) makes sense. It’s like in any text editor (i.e. line spacing in MS Word) – text looks best when spacing between lines is defined by multiplying the height of text
So in my opinion – everywhere where you deal with design and you use images by default measured in pixels – usepixels for all padding/margin.
Everywhere where you deal with text inside a text block, and you want to add even spacing between the text nodes – useem.

What are pros and cons to add line-height to body { }?

Is it good to add line-height in body{line-height:1.5} or it would be better if i add separately for tag by tag like p{ line height:1em} etc.
Edit:
body {line-height:in em} create problem with if we put image with float inside
Edit: 24 April 2010:
If i have to add different line heights to elements
like
p {line-height: 1.4}
h1 {line-height:1.6}
h2 {line-height:1.2}
ul li {line-height:1.1}
then shouldn't i use line height in body {line-height:1.4}
if body {line-height:1.4} and h1 {line-height:1.6} then what would be line height for h1?
It just depends. If you put it in the body then you get to be lazy and not worry about ever doing it again, but your going to lose control because everything on the page will have the line-height set to 1.5. Whereas if you declared it in each tag, you gain lots of control, but will have to do more work.
Personally I would go for the tag-by-tag solution, but I'm a control freak, so...
A word of caution on putting line-height on the body tag:
If you specify a height in percent, you would intuitively expect to enlargen / shrink all line-heights (e.g. 50% shrink to half, 200% duplicate space, 100% nothing happens).
body {
line-height: 120%
}
This is not the case. For paragraphs and normal-sized text it works fine. But for headings it's a disaster, since the same line-height as for normal text gets applied... See what happens here: https://jsfiddle.net/11jgwzzu/ .
It works, if you use for example 1.5 instead of 150%.
With this in mind, I think it's quite okay to use something like this:
body {
line-height: 1.61 // Golden Ratio
}
to make the entire page a bit more spacious. You can still overwrite this behaviour for some specific elements if you want to, but I often find I don't even have to overwrite it since I think line-height: 1.61 looks pretty good everywhere.
The obvious answer is specifying it once in the body is less work (and overhead).
There is a definite CON: if you use a unit (like 'px') in the line-height, and you specify it on the body, it will be used like that throughout the page. This may create crazy results with fe big page titles overlapping eachother or tiny aside text getting ridiculous whitespace between lines. If you dont use a unit, and specify it nowhere else, the vertical rythm of the page becomes messy.
Read this: http://www.alistapart.com/articles/howtosizetextincss/
Specifying a unit (in this case, px) when setting the line-height
enables the value to be inherited throughout the page. If a unitless
line-height had been specified, the multiplier would have been
inherited, resulting in line-heights being rendered proportionally to
the text size, thus breaking the vertical rhythm.
It is common in websites to never use a unit on line-height, which is one of the reasons why the most websites look a bit messy, designwise. Just look at this page, already :-)
I would specify a unitless line-height on the body element, and use a unit-based line-height on a designated 'content' area where you know exactly what sort of content to expect (the 'content body').
*-pike
put it where it's appropriate
if you want line-height: 1.5 on everything within the body, put in on the body
if you only want line-height: 1.5 on everything in the main content area, put it on the div id="MainContent"
etc.

Resources