I'm having a tricky CSS issue. This is exacerbated by the fact that the CSS for the "theme" of the web site is third-party (it can't be changed, but we can override with another stylesheet), and everything on the page uses absolute positioning for layout and sizing (this cannot be changed).
Somewhere in this third-party CSS, we have this declaration:
body {
line-height: 1.3;
}
A div on the page has a font-size of 14px, making its line height 18.2px. This is fine for typical web sites. However, since everything is positioned absolutely using pixel positions, font rendering differences are coming into play. Specifically, Google Chrome in Windows is rounding this line-height down to 18px. This means that the large block of content in the div renders substantially shorter in Chrome for Windows than in any other browser. All other browsers seem to support sub-pixel line heights.
Is there any way to force Chrome for Windows to respect sub-pixel line heights so that it doesn't render so differently than other browsers?
Update
Here's a JSFiddle demonstrating the difference. If you compare the heights in Chrome for Windows and, say, Firefox for Windows, you'll see that there's a 0.2px difference per line.
What I would do is changing the line-height to something that multiplies up to a whole pixel. In your case:
line-height: 1.2857142857142857142857142857143; /* = 18 / 14 */
This changes the output only a little, and results in cross-browser compatible result.
I've tested it with your fiddle on Chrome and Firefox on Windows and it works.
Related
I've built a layout for a list of items, and I'm running into some line rendering discrepancies between Firefox and other browsers, specifically with my custom font. Firefox renders the text above where I'd expect the baseline to be within the line height.
Firefox rendering:
... while Chrome seems to be putting the text lower in the bounding box.
Chrome rendering:
I'm aware that Firefox & Chromium browsers have different default line heights, so I've set this explicitly. The lines are the same height to the pixel between browsers (26.88px), but the text is positioned differently within them.
You can see that I've adjusted the top padding to be smaller, which looks how I intend on Chrome; if I make the top & bottom padding equal, the text renders closer to an apparent vertical center on Firefox, but lands too low in Chrome.
Is there a way to address this, without doing browser-specific padding values? This is the site in question, the styling for this component can be found here, and my font-face definitions can be found here. Thanks for your help!
I ran my font files through the Font Squirrel Webfont Generator optimization, and this fixed up my vertical metrics! Using the Font Squirrel edit, I no longer need to apply different padding values to achieve a vertically centered appearance on Chrome.
That said, the optimized fonts are still rendering higher within the line height in Firefox. This is the case even when I'm using the default font instead of my custom font:
I think this means Firefox is just eccentric, and must be special-cased accordingly. Here's my CSS, which achieves approximately the same appearance in Chrome & Firefox:
.project-row {
padding: 0.7em;
}
/* appear vertically centered in Firefox */
#supports (-moz-appearance: none) {
.project-row {
padding-top: 0.75em;
padding-bottom: 0.65em;
}
}
It'll do. Please holler if you have any better ideas, and until then, this is the answer!
I'm working on a responsive website and when checking it on my iPhone (iOS 13, June 2020) I found that the font size was different between Safari and Chrome.
I tried several things to account for it, but had trouble finding the cause.
I suspected it was related to some CSS I had from long ago: -webkit-text-size-adjust: 100%; Removing and changing this value had no effect on the difference though, so it was a red herring.
What would cause a discrepancy between the rendering of the same site and CSS on these two apps?
Here are two potential causes, there are surely more, but these were the ones I found and solved my problem.
Chrome obeys the system-wide "Text Size"
If you use the "Text Size" slider in control center, or the related settings at the system level, Chrome automatically alters the text of sites!
From what I can tell, there's no setting in Chrome for iOS to disable this linkage with Text Size.
So if you want Safari and Chrome to match, make sure that the Font Size state of your phone is in the middle position that's marked as "Default".
Good to know both in case you use the Text Size controls day-to-day like I do, or your users or clients do!
Safari has a "Page Zoom" setting in Settings app
On the other side, Safari has a setting called Page Zoom that goes from 50% to 300%. It's found in the Settings app under Safari > Settings for Websites > Page Zoom.
This setting can cause total chaos with CSS layouts at sizes like 200%.
Either way, if there's a discrepancy between the two apps, this Page Zoom setting is worth checking out as well.
Thank you for pointing me in the right direction - I've been having horrendous problems working out why Chrome on my iPhone SE was rendering text larger than Safari!
I don't seem to have a "default" setting for Text Size (Settings > Display & Brightness > Text Size).
However, -webkit-text-size-adjust: 100% did work for me - at least for Chrome which was where I was struggling.
In iOS 13, Safari exposes the media font-size to the final user, it means that in your root page (html tag) the css "font-size" rule is overrided, forced by the user and not possible to change.
And Chrome for Safari is not using rendering engine "Blink" as for Android, it's using Safari webKit render engine, so, Chrome for iOS is "Safari"
Anyway, you can react to this adjusting your media queries to work with "em" units instead of "px" in other words:
Change bootstrap (if used) breakpoints to "em" instead of default pixels.
Make your components border, paddings and other stuff pixel based.
Another way is understand what are the users needs and react before they need to adjust the font-size:
Adjust font size based on viewport (css clamp)
Use responsive layout
Use css border-box, box-shadow...
Another way is recalculate everything, at much cost:
What if the user changes the root’s font size?
I had a weird problem with paragraph on iOS14 ,13, it was enlarged, this has worked for me for Safari and Chrome:
-webkit-text-size-adjust: none;
I hope it will help someone too.
So this is a doozy...
Our QA department reported a bug that only exists in Chrome in Windows 8. Works fine in all other browsers on all other platforms. The bug? Text within a span element drops down well below where it should be placed, almost the entire height of the element trying to be aligned.
I was working from home when this was reported, so I actually freshly installed Windows 8 on my iMac and installed the latest Chrome -- same version tested by QA -- but could not reproduce the bug. Everything aligned perfectly. Tried every possible screen resolution available and all was great.
So I'm back in the office today, and a QA guy handed me the laptop with Windows 8 installed, and wouldn't ya know it? The text is not aligning properly. It's a Lenovo Ultrabook. The one difference, though: a touch screen. But even disabling the touch screen (and verifying through the dev console that Chrome no longer recognizes the touch screen) didn't fix the problem.
Neither Chrome installation had any add-ons.
What should I be looking for?? Here's the code:
<div id="text_container">
<span style="padding:0x;" class="textName" id="text_page">Problem Text Is Right Here</span>
</div>
Now...the "text_container" CSS consists of:
margin: 0;
padding: 0;
width: 1024px;
"textName" is defined with:
font-size: 10em;
margin-left: 1.55%;
opacity: 0.7;
position: absolute;
text-transform: uppercase
top: 0.8em;
#text_page has no CSS defined. Again, all looks PERFECT except on the one Windows 8 device on Chrome, a touchscreen laptop that doubles as a tablet.
Thanks for your help, folks. Even though the suggestions didn't help, I still appreciate the time.
Anyway, I fixed the issue, and yes, it was based on my observation that the font size was measured in "em". Now, I've been doing web site programming of some kind of another for literally twenty years, and this definitely falls under the "learn something new every day" category...
I always use "px", but again, the person who coded this wanted the font to be scalable, so "em" was the way to go. Now, what I didn't know was that "em" calculates itself based on the base font size...and since the base font size wasn't defined, I guess it's up to the browser to decide on what the base font size should be. Using the dev tools, it seems that the browsers were defaulting to 16px as the base font size...
...except for Chrome on the Windows 8 laptop we have, which was setting the base font size to 24px. Upon further examination, the laptop has a pretty freakin' high screen resolution: 3200 x 1800, so I'm guessing that had an effect on it somehow. It would also explain why I couldn't reproduce the problem on Chrome in Windows 8 on my iMac -- my iMac only goes up to something like 1920 x something, so I couldn't get nearly the screen rez.
So I went into the CSS and set the body's font-size attribute to 16px, and that fixed the problem.
May be the default value of the vertical-align property on your span tag is not set, so it is defaulting to "baseline".
According to the HTML spec, <span> is an inline element and <div> is a block element. Now that can be changed using the display CSS property but there is one issue: in terms of HTML validation, you can't put block elements inside inline elements so:
<span>...<div>foo</div>...</span>
is not strictly valid even if you change the <div> to inline or inline-block.
So, if your element is inline or inline-block use a <span>. If it's a block level element, use a <div>.
Imagine CSS like:
.x {
background: blue none;
border-radius: 6px;
}
and HTML like:
<div>Words and <span class="x">decorated</span> words</div>
The height of the span reading 'decorated' is going to vary wildly between different browsers, and between different OSes running otherwise the same browser.
Is there any way to make it be the same height?
(I don’t want to move to inline-block or sacrifice the text using exactly the same baseline.)
My experience with avoiding of different height is setting exact line-height and font-size
Sounds like there is something else causing your problem. I just tried a basic html5 document with the snippits from your question and compared the alignment on Windows with Chrome, Safari, FF & IE. They all rendered exactly the same except for IE9 which had a 1px gap above the span only.
Granted Mac renders fonts differently from Windows, and I didn't test on linux or mac, but 9px!!!??? Here are some things I'd investigate:
First, try a basic test file if you are working in a larger project, this will limit your variables.
Second, try setting explicit fonts and ensuring they exist on all of your test machines - perhaps linux is falling back to a different font.
Third, make sure you are not zoomed in or using a custom font size browser setting on any of the browsers (I ran into this one a while back where somehow my IE was set to 105% zoom.)
Finally, if all of that fails, you might want to try using a web font (#font-face) and see if that renders more strictly.
Edit:
In lieu of the new information in your comment, another strategy would be to use JavaScript to inspect the rendered heights of some off-screen elements and then programmatically adjust styles accordingly. You'll probably get a huge FOUC, but you can use a whiteout div to minimize the shift.
I am having alignment problems with a website I'm designing on IE6. It works great in all browsers (Firefox, Opera, Chrome, Safari, etc.) including IE7, IE8 and IE9. Basically, I troubleshooted and found that there is 25 extra pixels that are being added to either the main body of the page or the right body column of the page (these are divs #body_box or #right_box in the JS Fiddle below). They should be displayed inline but instead the #right_box overlaps and is displayed underneath #body_box and floating to the right.
The way I know this is that I expanded the div #Complete_Layout to 1025px (as opposed to the 1000px that it's set at now) and that's when it worked in IE6. I tried 1026px and 1024px and it didn't line up. I checked the dimensions of the background images which are accurate and I even attempted to change the width of the two divs (body_box and right_box) to percentages (75% and 25%) but it gave the same result. I'm out of ideas on what else to try.
http://jsfiddle.net/cRcXq/
It should be noted that I am doing this in PHP and the body_box and right_box sections are part of include files (don't know if that changes anything). I've added a comment on the HTML of the JSFiddle on where index.right.php begins. Thanks for the help.
This looks like the infamous "IE 6 box model bug," a well-known difference between IE 6 and other browsers from the time. Essentially, IE 6 counts the padding and the border as part of the width and height of an element, but any other browser from that time follows the same model as newer browsers.
Seriously, though, why are you designing a website for IE 6? It's ten years old and insecure, and it has less than 1% market share in the US. Microsoft has put up a website devoted to getting people off of IE 6. You wouldn't write code for Office 2000, or Mac OS 9, or PHP 3, so why are you developing code for a browser that was popular around the same time as those products?