Just like I have mentioned in the title.
How do you guys manage the fonts , when you do a web design
because different browsers even you set equal in pixel but the result seems to be different.
It makes other element collapse with the things I have designed.
so please advice me.
Eg: most browsers are okay , but IE is bad.The fonts appear to be very big than in others.
For main body text, you don't. Some people want bigger text so they can read it more easily; get in their way at your peril. Use relative font sizes in units such as ‘em’ or ‘%’.
For small amounts of presentational text where you need text size to match pixel-sized on-screen elements, use the ‘px’ unit. Don't use ‘pt’ - that only makes sense for printing, it'll resize more-or-less randomly when viewed on-screen.
You can still never get the text exactly the same size because fonts differ across platforms—and Lucida Grande and Helvetica look very different of course.
Related
I'm trying to use the Oxygen font from Google Fonts in my website, but I'm having strange problems with it.
Firstly, it doesn't seem to want to render at certain sizes, like I can't make it 19px. It will do 18px or 20px, but not 19px.
I also notice that the heights of the letters are borked. Take a look at the attached pic, how the 'S' is out. That's a screengrab of the font at 19pt. However, everything is 18px tall except the 'S' which is the one thing that sticks out to 19px.
And at larger sizes to this, other letters start antialiasing oddly too.
Whether I try ems or pxs or pts, I'm getting these glitches.
If you go to Google Fonts and search for Oxygen at the left and type in some text at larger sizes, it does the same thing, strange S's, etc. But strangely, if you search for specimens of this font in Google Images, it seems to render and antialias much better than this (Oxygen specimens in Google Images). Any way to fix it or is this font broken at source?
I hate to tell you but the font is broken at the source. It was obviously made unprofessionally or designed to be exactly that way. I'd recommend just using a new font or dealing with it as a regular user wont exactly mind it. Maybe a web analyst would but it's a nice font to a normal user.
So I'm reading using pt as a screen font size is bad as it's an absolute measurement and can render differently, but mostly these are old articles.
I've tried outputting text in 18pt/12pt/9pt alongside 1.5em/1em/0.7em and using various browsers' built in zoom capabilities the output adjusts consistently and similarly for both.
Additionally, when I'm reading the WCAG2 guidelines everything it says about font sizing is based on pt (e.g. 18pt for large text).
I guess the question is as the title, is pt really such a bad idea, and why and where does it fall over outside of my simple test?
thanks.
Advice against pt and other physical units is still valid from the accessibility point of view. The reason is that different people need different font sizes, and physical units fight against that, in the digital medium where font sizes would otherwise be adjustable.
It is true that all modern browsers have zooming capabilities, which work around some of the problems caused by physical units. But zooming is different from changing font size.
You can see this by testing with a page that sets some font size in pt and contains an image, too. When you zoom, all dimensions get changed. But when you change font size, using the browser controls for the purpose, IE 11 still refuses to adjust a size set in pt units. And this is, maybe arguably, correct behavior. And generally, when people want increased font size, they want just that—not zooming. Everything should work as otherwise, just with a larger size set for text. This works well when you, as an author, don’t set font size at all. If you set font size in pt, it doesn’t.
Do all font ascenders/descenders have the same space above/below? I'm trying to write a global stylesheet which will take away top and bottom space from h1-6 elements which I found to be no more than 8 pixels or so (which lowers as the h elements lower.) The reason I'm considering this is because I won't have any tall characters which will occupy the ascender/descender so I really have no usage for it (plus I need exact precision in the positioning of my elements.)
My question is if all fonts have the same ascending/descending space, or if it varies by font or OS or browser.
Do all font ascenders/descenders have the same space above/below?
Nope
It varies by font, by OS, by Browser, and probably lunar cycle as well. You can expect fonts to consistently be inconsistent.
Some fonts don't even have the concept of ascenders/descenders. What would you do if an icon font was used? Some fonts align descenders such that they don't even descend below the baseline. Others, such as calligraphic fonts tend to drop below the baseline, whether or not the character has an actual descender.
When I'm building pages off of comps that don't include font-size descriptions, I often have to render a large set of varying font-sizes of a particular family. I have a utility webpage that I use locally so that I can determine which font size must be used, and what font alignment will work.
Example:
This example uses Arial, and even Arial renders differently for some sizes between Chrome, Firefox and IE. When you're using sets of fonts you then also have to worry about all the other options in the set, in case the user doesn't have that font installed.
If you absolutely must have an exact rendering, you should be using an image to render the text. Use the [alt] attribute to reference the text in the image. It's not as manageable as text because it requires re-rendering every time a content change is desired, but it works well enough, especially for things like logos which absolutely must render in a specified manner.
My website, for the most part, uses relative fonts and fluid layout techniques, so our site layout will scale based on what the browser's default font size is set to. But there are certain elements that have fixed widths, and our layout past a certain font size just doesn't work well or look good. It's not feasible at this point to go back and change all of those elements.
So, I want to allow the site to adjust based on the user's chosen default font size in the browser--within certain limits. For example, things start to look a bit wonky at a browser fontsize of 22px; I'd love to have the site be relative, up until it hits a maximum base size of 22px.
From what I can gather, there doesn't seem to be any easy way to specify this purely in CSS. I was thinking the best approach is to use Javascript to detect the base fontsize on page load, and if it's >22px then I'll set a style on my body tag to fix font-size to 22px. If it's less than 22px, I won't do anything (and leave our default relative style in place). I don't care as much about handling font size changes while the page is loaded, as that seems like an edge case (that would get corrected on next page load).
Is this the best approach, or are there better ways?
You cannot prevent users from increasing font size (even if you set the size in pixels, users can just Ctrl +), and many people think this is good – people may need larger font size than you expect, and breaking layout somewhat may be better than not being able to read at all. So what you can do is to make any reasonable effort to ensure that the page works reasonably for a wide range of font sizes.
CSS is not my forte so this might be something simple. I have set my footer font size in a stylesheet using 0.8em but on different pages it is a different size. I'm only editing someone elses work and he did a poor job at not closing tags so its a bit painful.
Is there a way to clear all font settings so that the footer is the same across all pages? Or is this a problem that can be solved some other way?
Cheers for any help.
I notice no one has touched on how em works as a font size unit, so I'll try to clear that up for you.
There are two ways to tell the browser how large your fonts should be rendered.
setting an absolute size
For absolute sizes, like px or pt, you're telling the browser exactly what size you want the text to be. If you write 12px, it's going to come out as exactly 12 pixels tall.
setting a relative size — em is a relative size.
For relative sizes, like em, you're telling the browser how big to make the text with respect to other text on the page. This works sort of like a percentage, so if your footer text is sized at 0.8em, it will be rendered 80% as tall as the main text on the page.
This explains why you're getting different sizes on different pages. If the font size of the body is set explicitly on one page, but not set at all on another (or set explicitly to a different size) that will make your em-sized fonts render at different sizes.
This is also why it's really bad to use <font> tags. It's going to be a serious pain to dig around those tags and figure out what explicit sizes are being set that might be throwing off your ems.
When you set your font sizes using CSS, this is not only an information which is easy to find, but also a property which is easy to modify.
As David Thomas says, the use of <font> is deprecated. If you have a software tool to do global edits, you might try deleting all the <font> tags and then add classes back to the HTML that actually needs to be different fonts and add the font info to the CSS.
The other option is to get through one at a time, which I imagine to be time consuming. At least you would have cleaner HTML when you were done.
In a weak defense, the previous designer may have used a WYSIWYG web design tool that created the HTML for him/her and didn't see the resulting code.
Try using an exact size with px or pt units rather than em.
Sizes in percent and em can get screwed up by unintended levels of inheritance but not px or pt.
My solution was basically to do inline styles to correct any problems. Using px rather than em was an option but we preferred to keep accessibility rather than best practice against using inline styles (any best practice was out the window anyway).