Black is firefox, light blue /azure is chrome (barely noticable against firefox), and the dark purple is IE10.
Their font sizes (11px) and font-family (Helvetica) are all exactly the same, however you will notice how much larger IE10 renders its font.
It also seems to apply very heavy anti-aliasing to each character.
I know part of the 'challenge' is creating a site that will work across multiple browsers, but has anyone got any solutions that could correct IE10's increased font size?
I faced the same problem, in IE some parts on my page were broken.
I changed the font-size unit from px to pt, but you have to recalculate the values(divide the px value by approx. 1.36367, 15/11 exactly).
Now the font is rendered with the same size in IE8-10 and FF, no broken parts.
IE9+ uses sub-pixel rendering for fonts, and it results in slightly different size of text boxes (sometimes with non-integer pixel size) compared to other browsers. But here the problem seems to be more in line-height value, which probably is default (based on the font itself) and results in different values in different browsers because of rounding. Setting the explicit line-height value in pixels should minimize the difference.
Related
I understand em sizes are relative to the parent font size. As discussed in other threads (such as Font-size issues comparing chrome and Firefox), the default font size could be different for different browsers, so one should set it and/or use some reset css stylesheets.
I also understand that different browsers may render things in different size if they have a different zoom size.
Nonetheless, for a given parent font size, 1 em should translate to the same number of px, regardless of the browser.
However, in some cases (e.g. https://openlayers.org/en/latest/examples/custom-controls.html, https://github.com/openlayers/ol3/issues/6194) some elements with the same size in em are translating to a different number of px in Firefox and Chrome.
How is that possible?
Edit: On further testing on the same computer:
Firefox 50 on Windows and Chrome 55 on Windows 10: map icons are 25px
Firefox 50 on Linux and Chromium 53 on Linux: map icons are 33px
As mentioned by #Pedro_Costa, the .ol-touch style is being triggered only in some browsers, this is making the fonts bigger as per the following CSS rule:
ol-touch .ol-control button{font-size:1.5em}
So, the issue is that Open Layers is detecting touch capabilities only in some browsers and OS.
Checking the OpenLayers code I see:
ol.has.TOUCH = ol.ASSUME_TOUCH || 'ontouchstart' in window;
Which looks all right. So, apparently it is an issue of Chromium in Linux and Firefox in Windows that are not detecting correctly the touch screen and therefore not exposing the ontouchstart element.
Basically I am designing a jquery plugin to create circular presentation using vw to get rid of font size.
Everything works fine except for IE9, which renders the size of the font bigger than the other browser.
You can take a look at the example here:
http://www.rubenrizzi.com/circularslideshow/example-cell-encrypted/
Looks how bigger looks on IE9 than in the other browser.
Is there a way to handle this behavior with a polyfill, or a css trick to make IE9 respect the vw size?
I am working on adaptive site, and have made everything in em values. Despite that, I have differences between Chrome and Firefox in interpreting em. Website is dev.morodeer.ru/stroymoidom; problem is with the metal bar with icons. On the width of about 670px everything in Chrome is great, but Mozilla cuts the right edge (as width of centered wrapper is set to 90%). Also, with same width of browsers, metal bar in Firefox is smaller, which leads me to a thought, that Mozilla counts smaller font-size.
The em and ex units depend on the font and may be different for each element in the document.
quoted from: w3.org
maybe you use default fonts and firefox uses a different one as e.g. chrome does?
i'd suggest you to use px or % values instead of em for block-layout size values.
use em for font sizes, 1em = font size of the browser, 2em = 2* font size of the browser, 0.5 em = 0.5*font size of the browser .. and so on ;)
If you already knew that part: yes, firefox and chrome can have different font-sizes and em might influent your font size in a different way then.
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.
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.