I have a set of A tags with display set to block. Each each is specifically has a border on the right. They fit perfectly into a container. However, when the page is zoomed out using the browser's zoom control, everything but the borders scale and the layout is broken. Is there a way to fix this?
This behavior can be replicated in Firefox 3.6.10 and Safari 4.
I had never before noticed that the borders do not scale.
try to set the border-with in em instead of px - if your font-size is 12px, you could write
border-width: 0.09 em;
this will be 1px width in normal size, and hopefully it scales correct (can't test it now, sorry).
There are other things that won't scale either -- radio buttons and select boxes are the classic ones, though it does differ between browsers.
Also, you'll get different effects depending on the sizing units you use for your CSS -- ie whether you use %, px or em, etc. Again, this will vary between browsers.
So the bottom line is that using the browser's zoom function is likely to break things on your layout. I honestly wouldn't expect things to be perfect with zoom, nor the same results in different browsers.
Related
i wanted to jump on the icon font train, but was quickly put off by the renderer.
When an icon is sitting inside a div that has either percentage width or is automatically centered the icon can be aligned to a half pixel causing it to be rendered blurry.
I was in contact with Icomoon support who intoduced me to a bug that said it is Chrome specific. (https://bugs.chromium.org/p/chromium/issues/detail?id=426333) unfortunately I was able to reproduce the issue in all of the major browsers.
The recommendation I got was to avoid auto margin and to use only float left which in today's world isn't really possible. And even if I do that i'd still clash with precentage widths.
Question
Is there any way to preven't the blur from occuring? I guess using inline-svgs would be an option right? But that kinda beats the whole purpose of the Icon Font. Or having a script that rounds everything up to whole pixels but that sounds extreme as well.
Steps to reproduce the issue
I have created a 24px set of icon on Icomoon, downloaded the set which comes with a demo.html. Then I just to the main wrapper of the demo, and gave it a fix width and margin 0 auto. Then by resizing the browser width I was able to make the icons blur or be crisp..
Chrome
Blurry:
Crisp:
Firefox
Blurry:
Crisp:
Opera
Blurry:
Crisp:
Edge
Blurry:
Crisp:
Internet Explorer
Blurry:
Crisp:
If someone can provide evidence that this is what's actually happening in the browser implementations that would be ideal, but this answer is based on your even/odd pixel values you mentioned in the question and is what I believe to be the most likely cause.
Fonts and Icon Fonts are Vectors
On a basic level, icon fonts are vectors. This allows the icons to scale regardless of font size and not become blurry. Blurriness can however occur when the edges of the vectors do not line up with the edges of pixels.
Vector vs Pixel Rendering
To steal from the Font Awesome Icon Design Tips Guide, you can see two demonstrations below. The top image is a vector with a bunch of 1px wide lines, spaced 1px apart, but they're offset by 0.5px. When rendered as pixels without being zoomed in, this causes them to become blurred as the pixel must take 50% of the line colour, and 50% of the background colour.
Vector edges that don't line up with the pixel edges. (The blue representing the 0.5px offset from the pixel edge).
On the other hand, the image below has the vectors lined up, so that either edge of the lines/bars, lines up with the edges of the pixels. Therefore when rendering at a pixel level, no pixels have to merge the background and line colours.
Correctly aligned vectors
To see more examples to explain this in more detail, I'd recommend reading the full guide which also explains crisp diagonal edges too.
Browser Rendering and High DPI Screens
Browsers now have to deal with high DPI/retina screens, which make it really easy to have "centered" text because you have 2 actual pixels per CSS px width; therefore you can draw crisp lines every 0.5px.
Judging by your images, you're using a regular DPI screen to view the fonts, and therefore when the browser is forced to render the icon at a 0.5px value, the edge of the vector lies in the middle of a pixel, rather than half way, meaning that pixel has to take 50% of the background colour, and 50% of the icon colour, causing the blurred edge.
As for a solution, I sadly don't have a lower res monitor on hand to test. Your aim is to make the edge of the icon render on the edge of the pixel boundary which will require some fiddling, but here are some things you could try:
Setting your icon to display: inline-block instead of the default display: inline that text tends to have. (Unlikely to work, but it might).
Wrapping your icon in a fixed-width div just larger than the icon size that can then be centered.
If using the div method, try the difference with left aligning or center aligning the text.
In my experience, blurry fonts are often the result of how the icon was created. Font Awesome has some good tips on designing crisp icon fonts.
I have a conceptual question about photo galleries like this:
http://www.nikesh.me/demo/image-hover.html
If you open this in a browser that supports CSS Transitions (for example Chrome), it will smoothly scale the hovered image whilst the zoomed version remains of a high quality.
This is accomplished by showing the non-zoomed images into a slightly smaller version than they really are, in essence the zoom shows them in their true dimensions.
So, normal images are first scaled down:
-webkit-transform:scale(0.8);
And then upon hover scaled up:
-webkit-transform:scale(1.2);
My question: How is the initial scaling down supposed to work for browsers that do not support this method of scaling down? Try opening that gallery in IE to see what I mean, it shows the images not scaled down, which makes them too large and thereby they break the layout.
What I want:
The full effect in browsers that support it. Important is that the zoomed version remains quality.
No effect at all for browsers that do not support it, yet a solid original dimension so that no layout is broken
It should work for both image orientations and there may be variety in image widths and heights too
Anyone? Preferably an elegant solution that does not need browser sniffing or javascript, but all answers are welcome.
If you are wanting it to work without the use of javascript then it seems the only method you have is to forgo the initial scale down with css. You will want to do this in the "antiquated" way of adjusting the width and height of the image in the markup.
<img src="yourImageSrc" width="80%" height="80%">
This would allow you to still keep your layout in tact if the user agent is not up to date.
** I don't know if the percentage works in the literal height/width definition. But you can always figure out the ratio you need and plug it in.
I read somewhere on a site :
In principle, using a px measurement for font-size is not a good idea. A handful of browsers will prevent the font from being resized by the user if you do this.
Is this right??
Is this right??
Well, yes, certainly there are a few (generally older) browsers that won't let you resize the text when it's sized in px, pt, in, mm and so on.
But even in browsers with a working zoom, it's polite to work relative to the user's stated preference for font size, so they don't have to resize the text or zoom the page manually to make it comfortable. (Fixed fonts plus fixed width page can be particularly bad for this in page-zooming browsers as zooming up is likely to make the columns of text too wide to fit the screen.)
In principle, using a px measurement for font-size is not a good idea.
I wouldn't go so far as to say it's always a bad idea.
There are often elements on the page where you want the text to be sized to match an image (say, a header with text below it that should fit more-or-less without wrapping, or text above a background image made to fit it). In that case you should use px to make fonts and images line up nicely.
For the page's main body text, yes, it's nicer to use em/% and let the user decide the size. But for text that plays a part in the page's graphical layout, px fonts are typically the best bet.
The issue is mainly with aspect ratio. Let's say my resolution is 1024x768 for an aspect ratio of 1.33. For 1920x1080, the aspect ratio becomes 1.77, meaning that any image displayed at a specific pixel width and height will be a different size in inches due to the scaling effect of the aspect ratio. The same basic issue exists if you zoom as you are effectively using the aspect ratio in the zoom window.
Most websites get around this by using em which, to be honest, suffers from some of the same downfalls as any other rendering mode. Even "device independent pixels" are based on the DPI of a monitor. So, use em knowing that it just has less faults than px, not because it's perfect.
Read the following article if you want a more in depth study.
http://www.w3.org/WAI/GL/css2em.htm
Yes, at least IE6 & IE7 do that. Take a look at How to Size Text in CSS.
Quoting CSS: The Definitive Guide by Eric Meyer
There is one more value that is
potentially the same as 36pt, and
that's 36px, which would be the same
physical distance if the display
medium is 72 pixels-per-inch (ppi).
However, there are very few monitors
with that setting anymore. Most are
much higher, in the range of 96ppi to
120ppi. Many very old Macintosh web
browsers treat points and pixels as
though they are equivalent, so the
values 14pt and 14px may look the same
on them. This is not, however, the
case for Windows and other platforms,
including Mac OS X, which is one of
the primary reasons why points can be
a very difficult measurement to use in
document design.
Because of these variations between
operating systems, many authors choose
to use pixel values for font sizes.
This approach is especially attractive
when mixing text and images on a web
page, since text can (in theory) be
set to the same height as graphic
elements on the page by declaring
font-size: 11px; or something similar,
as illustrated by Figure 5-15.
Using pixel measurements for font-size
is certainly one way to get
"consistent" results with font-size
(and, indeed, with any length at all),
but there is a major drawback.
Internet Explorer for Windows up
through Version 6.0 does not allow
users to easily resize text that has
been set with pixels. Other browsers,
including Mozilla, Netscape 6+,
IE5+/Mac, Opera, and even IE7, allow
the user to resize text no matter how
it's been set. Thus, using pixels to
size text is no more of a guarantee
that it will stay the same size than
is any other method. The other
approaches discussed in this chapter,
such as keywords and percentages, are
a much more robust (and user-friendly)
way to go, as they can be used to
scale text from the user's default
font size.
That said, the issue here is what unit to use for your body element. In most cases, you should use the em unit for other elements like headings and paragraphs.
in my projects i use em for sizing of font only with body {62.5%}?
with this method i can easily calculate em value.
so what are pros and cons if i use em sizing unit for width, height, padding, margin, line-height, even for inline images also along with font for fixed width layouts?
Ems are wonderful units for a good designer. It all rests on what you're taking as pixel perfect. Since most front-enders will only get an image (maybe a .psd file) from the designers, it might seem a good idea to keep every pixel as is. Which is good, except that you can't rely on web browsers to be pixel perfect.
Imagine a browser with a different font, or a font with a different aspect. Imagine a user who enlarges the default font or who zooms in (using those browsers that only enlarge the font). A margin set in px will still show up with the exact px value you gave it. An em-based margin will stretch according to the font-size.
Also, they're not that hard to work with. Define a base font-size and line-height and apply it to your (after a good reset, of course). Then change it only for the titles (you shouldn't have more than 6 titles) and for any region where it makes sense to change the font-size (a sidebar or footer). You will do 3 or 4 calculations, everyone will be happy :)
The biggest downside is in indentation and text-block alignment with fonts of different sizes with em-sizing. It gets hard to line things up exactly – if that's important to you (and it should be).
Well if you understand how em work you can do just about anything you can do with pixels for example but with a bit more calculation.
Actually you could do more, for example, if you have a h1 header you could specify line-height and bottom margin in em's to they always reflect the font size of that header. As you increase a font size of header you increase the margins and line-height too.
This can be used to create a dynamic vertical rhythm for example.
Also if you build a complete web site in relative units you can achieve zoom effect in older browser, etc.
But with modern browsers and if you can afford to not to support behemonts like IE6 you can use absolute units and still get a full page zoom.
Em-sizing is useful for liquid layouts, but less so for fixed layouts. Not to say that it is useless, but a fixed layout is easier to set up using pixels. You can of course continue using ems for font sizing.
I noticed that when the dpi is set high than 96 to like 120 my site gets messed up using either Firefox or IE7. The CSS basically breaks. Anyone know how to fix this?
Link to web-site
Thanks
The site uses a fixed-size layout, but mixes the units px and pt. When changing the dpi of your screen, the relative size of these units changes, ie the site is broken by design.
What you should do:
don't use pt for screen layouts - pt is for printing only
read up on liquid layouts and the relative unit em
There's not really a fix that can prevent anything happening if a user has adjusted their Windows DPI setting. Altering Windows to 'large fonts' mode, or setting it to a DPI setting other than the default, affects all layout in IE.
However, this should never cause a site to massively break. A few things shall be slightly misaligned, perhaps, due to rounding of values.
The site you've pointed to indeed does break quite massively when the font size is changed - for instance, change the default font in the browser (or set Firefox to "Zoom Text Only"). Text from the buttons completely leaves the buttons and starts hovering elsewhere.
It looks like the main cause of this, at least with the buttons across the top, is that the whole row of buttons is single background image and the text inside them are floated elements which match up with the background image only at a given font size - any adjustment to their size and position and they become out of whack with their background.
When designing, always change the zoom setting (in IE7 and Firefox) and the font size (eg in Firefox using "Zoom Text Only") and make sure that those things that do change in size, don't break the site. In some conditions, things specified in "pt" will scale while things specified in "px" won't.
How you could fix it
It's clear that you've designed everything to be a certain size in pixels, including the header and all the buttons/tabs. If you want to do this, declare the header DIV to be position: relative, and position the H1, H2, and UL inside it absolutely, using pixel values (relative to the containing div). Remove the margins, padding etc from the DIV to simplify. Specify widths, heights and top margins of the LI elements using pixels.
What I would do
Normally, I would build things like this to be flexible, so that if for some reason a person had really big fonts enabled on their browser, it would stretch nicely to handle it. That isn't really possible with your background images, because they are build especially for one given size only. So I'd have a repeatable background on the header, and I'd do each background for each button separately. Obviously, this is going to be more work.