I try to wrap my head around the auto property in CSS 3's font-size-adjust. The spec says:
Behaves just like <number>, except the number used is the aspect value calculated by user agents for the first font in the list of fonts defined for the initial value of the ‘font-family’ property. Effectively this is the default font used when ‘font-family’ is not otherwise specified.
Authors can use this value to specify that font size should be normalized across fonts based on the x-height without the need to specify the aspect ratio explicitly.
In my narrowed little world I thought, font-size-adjust is necessary, when your first choice of font doesn't load. Then you can adapt the size of the fallback font.
Now, how does the browser calculate the aspect value for a non-existing font? If it doesn't and isn't intended to, where did I take the wrong turn and what does auto really do?
The expression “the first font in the list of fonts defined for the initial value of the ‘font-family’ property” means the browser’s primary default font, typically (but of course not necessarily) Times New Roman. “Initial value” is something defined for every property in CSS specifications. It is usually browser-independent, but for font-family, it has explicitly been defined to be defined by the browser.
So the auto value in this case means the aspect ratio of that default font.
Assuming the user sets his default UA font to have the perfect legibility for himself, then any FSA:auto font would match that. In CSS the presumption is that the user (not the designer) is ultimately right, so this just goes along with that.
Related
The vertical position of text rendered in Helvetica and the size of its content area differ between Firefox and Chrome for Mac. For example, in Chrome, the descenders are clipped if the line-height is identical to font-size.
(I’ve adjusted the position of the block elements in this picture—keeping the baseline consistent—to illustrate the difference in size and text positioning). If you have a Mac, you can see what I’m talking about in this JS Bin.
Now, I'm not directly interested in how to fix this specific discrepancy. I realize there are hand-tuned reset stylesheets that attempt to eliminate or paper-over the differences, but I'm specifically interested in the factors that caused these browsers to render differently in the first place.
I'm making some assumptions here:
Standards exist for both the rendering of fonts and the sizing and positioning of glyphs within the standard box model, but may be unspecified in terms of how they interact.
Bugs exist in browser-makers interpretations of the aforementioned standards, which may influence how text is sized, positioned and rendered.
For these specific browsers, much of the design discussion and actual implementation is public in some form. Therefore, it is possible to learn the source of such discrepancies, if one knows where to look.
Both browsers start in the same place - the markup, styles and font definitions are consistent between them. At some point, they diverge in how they use these to produce the final output.
Therefore, my specific question is: where in the process does this divergence occur, and what causes it to occur?
I feel that, armed with this knowledge, I can better understand how to correct for such discrepancies. Both in this case specifically, and in similar situations that I may encounter in the future.
Unfortunately, re: rendering of the content area based on the font, CSS2.1 does not say much at all:
The height of the content area should be based on the font, but this specification does not specify how. A UA may, e.g., use the em-box or the maximum ascender and descender of the font. (The latter would ensure that glyphs with parts above or below the em-box still fall within the content area, but leads to differently sized boxes for different fonts; the former would ensure authors can control background styling relative to the 'line-height', but leads to glyphs painting outside their content area.)
In other words, typesetting, and how exactly to draw and position the content area of a line box, is left up to the browser's own implementation, at least in CSS2.1. This may however be better defined in a future specification (likely the Fonts module, if not a separate module1).
Section 10.8.1 contains some details on how the line-height property affects the rendering of the content area around text that flows inline, but again it depends on the height of the content area itself, which as stated above is undefined in CSS2.1.
Note that auto is not a valid value for line-height; you probably meant to use normal, which incidentally is also its initial value (but not necessarily the browser default). Also, this is what the spec says about the value normal:
normal
Tells user agents to set the used value to a "reasonable" value based on the font of the element. The value has the same meaning as . We recommend a used value for 'normal' between 1.0 to 1.2. The computed value is 'normal'.
As you can see, there's not much to go on, even with regards to comparing line-height: normal and line-height: 1 (or 1em or 100%), because what constitutes a "normal" line height is up to the browser to decide as well. However, it looks like Chrome and Firefox do a good job of keeping glyphs within reasonable boundaries when asked to use a normal line height.
By the way, Chrome does not clip the descenders. It does render them outside of the content box, but it should never clip them to the bounds of the box unless you set overflow: hidden.
1 A CSS3 definition of the line-height property currently resides in this module, but it's immediately obvious that it's been long abandoned, or at least pending a rewrite. The module in its current state is extremely detailed, but suffice it to say that it's been largely ignored by both browser vendors and the working group.
'Line height is auto' => the browser gets to choose.
'Line height = font size' => user error: the text will be illegible, and again it is reasonable, indeed essential, for the browser to make some adjustment.
You must use some leading. Books for example may be set 10pt on 12pt line spacing.
So I know that my question is pretty technical, but basically I would like to know specifically how the following CSS affects the display of text in <p> tags.
p {
letter-spacing:2px;
font-family:"Georgia";
}
I know that Georgia is a proportional font, that the designer has spent time crafting the spaces between letters to make the font more readable and visually pleasing.
But my question is how does the letter-spacing property affect this proportionality? Does this code add two pixels onto the spacing already defined by the type designer, or does it reset that spacing to two pixels?
This property is additive to what the font would normally use. So, 1px will increase it by a pixel. Sitepoint calls it "extra" space (with negative values allowed).
The W3C docs say the same thing:
"This value indicates inter-character space in addition to the default space between characters. Values may be negative..."
It is in addition to any default spacing.
See: https://developer.mozilla.org/en-US/docs/CSS/letter-spacing
From my experiment on Firefox on OSX, using a kerned font (Arial) as opposed to Georgia which does not appear to have kerning on my machine, I can testify that the spacing is in addition to existing spacing, and kerning, and can be either additive, or subtractive.
It is also worth mentioning that different browsers and operating systems replace fonts, and handle them slightly differently to each other, making it impossible to predict 100% how any font will be rendered.
When I look on the font-family of an HTML element (from js, firebug or similar) it's always a list. How can I see which of the font is actually used from the list?
I realise it's not ideal, but you can copy the text from the viewport and paste it into a rich text editor, and it will tell you.
It's a bit fiddly, but using Firebug you can tweak the name of each font in a font-family, working left to right until the element's font changes, meaning it was the last font you changed is being used. On the latest Firebug at least, you only need to add or remove a letter from a font's name for the change to be reflected.
The Font Finder add-on for Firefox can do this. Since it’s clearly possible, it sure would be convenient if this were built in to Firebug.
Update 2012/2/4:
I examined the Font Finder source to find out how it works, and it’s actually a clever little hack. The relevant code is in the Detector class in fontfinder.js. To quote the source:
Inner class that's used to determine which font is rendered. It
operates under the foundation that each font has a unique height &
width when given a large enough font size & sample string
What’s it doing is almost like an automated version of Marcel’s answer.
So how it works is that a dummy element — with the text “mmmmmmmmmmlil” — is added to the DOM. It is set to use the browser fallback font, “serif”, at a font-size of 72px. With that, Font Finder knows the width and height of the element when the fallback font is in use. Next, it just iterates through all the fonts listed in the font-family, setting the font on the element in turn, for each one in the list. If the width and height of the element matches the width and height when the fallback font was set, we can deduce that the given font is not present. The first font in the list which produces a different width or height on the element will be the font that is actually being rendered (note: there is a special case involved when the fallback font, “serif,” is in the font-family list).
There is also a Chrome version of Font Finder. It differs (relevant source) in that the browser fallback font appears to be “sans” — not “serif.” Any code using this method will have to have browser-specific knowledge of the fallback font.
I still use EM's in the CSS to specify the sizes of elements in my templates.
Today most browsers are able to correctly scale websites where the sizes are given in PX.
My argument for using EM's was / is: if a person that has a sight disability and changes the base font size in the browser, the design still fits.
I'm asking because for me its still a source of errors to use EM's. When i specify a different font-size then the base font-size on a element, I often forget to adapt my EM calculation for the children elements.
Now i have 2 questions:
How do people with a sight
disability configure the browser (do
they use the browser zoom or do they
still change the base font-size)?
Does it still make sense to use EM's
for element sizes nowadays?
Based on what I've read, neither. Users with mild-to-moderate sight difficulties often use applications distinct from the UA itself to provide zooming functions. These tools can magnify all or part of a display, but (in my limited experience) they don't zoom the text out-of-relation to the setting.
It still makes sense to use 'em'. First of all, accessibility isn't the only reason to use 'ems'. I think the inheritance model of relative sizes makes more sense with ems and percentages than it does with pixels. Second, you can do calculations in CSS3 itself, if it helps you to not need to remember to adapt your calculations.
refs:
http://www.championinternet.com/rwa/Ann.pdf
http://davidbcalhoun.com/2010/does-it-still-make-sense-to-use-em-rather-than-px
http://www.w3.org/TR/css3-values/#calc
Physical dimensions (px) are generally worse than logical (pt, em, %) because physical devices' size and resolution may vary wildly (from a small handset to a desktop screen to a wall-mounted plasma screen). Unless you're tightly bound to a piece of raster graphics, there should not be any disadvantage in specifying dimensions in logical units.
If you always specify font sizes as percent of base size, it's harder to forget to use the logical units :) Also a user can just specify base font size in the browser and your entire design adapts automatically.
When font size is too small for me to read, I zoom a little. Also I specify quite large base size for Japanese pages so that I can make out the glyphs. But if a page resists to adapt to font change, I usually just hit my 'Readability' bookmarklet, and the offending design disappears completely.
I'm still in favor of using EM as a unit. But like you said, modern browser scales size pretty well even with other units.
I think the most important is to always use the same unit across the website. As long as you don't start to mix different unit, the browser should handle everything well.
The only real advantage I see nowadays to use EM, is that someone who has increased is default font size will see your site with bigger elements without doing anything. If you use PX, the person probably have to change the size manually.
I have an < mx:Label > tag that has a set width, which is usually large enough to display the text it needs to show. Every once in a while though the text is a little too long and gets chopped off and "..." gets appended. Instead of this happening I would like to decrease the font-size just low enough to show the whole text.
Does anyone know of a nice way to do that?
Thanks
Fonts are a complicated beast. For a given text, you can find the string length and calculate the maximum allowable font-size very simply using the following approximate formula:
var max_allowable_size:int = yourLabel.width / yourLabel.text.length;
This could lead to serious issues for some fonts, namely:
Remember not all fonts are equal i.e. they cannot all be resized gracefully.
Anti-aliasing may break
Fonts may not look good/text may become illegible
The above naive formula will probably break when applied to non-roman characters
Also, this is an inefficient way.
I would rather suggest that you define two different styles, one regular and another fallback one with font-size set to the smallest, which you switch to when you encounter longer label texts. You can calculate the threshold limit to switch by using the default font-size on the above mentioned formula. Of course, some experimentation is in order, if you have to support localization/multiple languages.
Finally, always embed the fonts if you are going to use anything other than the most common fonts.
There is a measureText function. Check out:
http://frankieloscavio.blogspot.com/2008/01/flex-use-measuretexttxt-to-calculate.html
http://livedocs.adobe.com/flex/3/langref/mx/core/UITextFormat.html#measureText()
You can probably use measureText and decrease the font size till it fits.