My Google Chrome on WIndows 7 has just been updated to the version 32 and the scrollbars look different.
The new width seems to be 15px. Was the scrollbars a bit wider in previous versions?
Yes, the scrollbars are indeed different in Chrome 32.
The scroll bars in Chrome 32 are Chrome OS style: flat, and without arrows at either end. They are also slightly narrower. I took a screenshot of an old one and a new one. The old one appears to be 16px wide while the new one is 15px wide.
Related
What's the best way to fill a table with a 1px grid (internal and external)? Or, possibly, do Chrome and Edge have a problem with borders in some cases?
This Codeply does the obvious thing - it sets border-right and border-bottom on the table, and sets border-top and border-left on td,th. However, this doesn't work well. It looks good on Android and Firefox (HD/1080 on Windows, UHD/4K on Linux). It's flawed on Edge and Chrome (with Chrome on both Windows and Linux). It's mostly Ok, but some internal and external borders look like 2px.
Note that I'm not, I hope, just being dumb here. There are lots of similar questions on the web, but I can't get any consistency across browsers. This SO answer, for example, has a jsFiddle which displays differently on Firefox (108.0.2) and Chrome (108.0.5359.125). The Chrome version shows a double-width border for the top and bottom vertical lines, and a single-width one for the middle line. Firefox looks good.
Chrome (and, by extension, Edge) are broken when scaling 1px borders.
This doesn't apply to Firefox (I haven't noticed it, anyway). For Win10 and Win11, a 1px border sometimes displays at the minimum width when the display scaling is not 100%, and sometimes gets wider. If you have two lines next to each other one can appear to be "1 pixel" on a 125% display (most laptops), but the next one can appear to be "2 pixels". This means that you can't, for example, just set all borders to 1px when filling in the grid on a table.
There's an easy fix, though - just set the borders to 0.1px instead. This Codeply is the 0.1px version of the one in the question, and displays correctly on:
Win 10, UHD/4K, display 150%, Firefox, Chrome, Edge
Win 11, HD/1080, display 125%, Firefox, Chrome, Edge
Android
Ubuntu 22, Firefox and Chromium
Not sure how display scaling is handled in Ubuntu, and I'm also viewing the results on Win10 with VNC, which might complicate the issue.
I have a very long vertical sprite which i am loading in my web application.
But unfortunately in windows 8 mozilla browser my sprite doesnt load entirely.
It loads upto a fixed height and ignores the remaining part of the image.
Every time i clear the cache or refresh it load upto that the specific height and ignores the remaining part of the image.
Can anyone give me a reason and the solution to this problem ?
The same sprite image loads absolutely fine in other browsers and also in mozilla (same version) in windows 7.
I find this issue only in Mozilla for windows 8.
Large images is a known issue for Mozilla: https://support.mozilla.org/en-US/questions/973667
I don't know if that one qualifies, or the reasoning for having a long one, but I would suggest just going wider, cutting the length down.
Column 1 10px wide 7,000 high, column 2 10x wide, 7,000 high.
http://jsfiddle.net/7yda75v0/8/
If I open the fiddle on my mac book air on latest chrome (38.0.2125.104) the height is 8, in Safari (7.0.3 (9537.75.14)) it's 10, in Firefox (32.0.3) 4.
My coworker have 9 on almost the same machine (my mac has 1.7 Ghz, his 2.0Ghz).
Mac book pro device has also a different value.
It looks like a floating point inaccuracy, but why? It's not the browser and not the display. You can get some funny values when you enable browser zoom via CMD +
Changing the font-size to 1.0em of .t2 results into no differnces, even with browser zoom.
The problem is not limited to very small em values, it's also present for non natural number, like 1.1em
// edit: this is not just for rem the problem occurs for em as well.
Note that rem is calculated based on the root font size. Each browser and display calculates a different pixel value. Also, css pixels don't necessarily correspond to a screen pixel, or the browser's calculations with the resulting screen pixels. The value changes with browser zoom, because the root font size changes when you zoom in.
Edit:
The actual size of .t2 relative to .t1 appears to be correct for every browser I have except Chrome, on Linux, OSX, and Windows. When zoomed out all the way, .t2 appears larger than .t1. Values such as 0.2rem and 1rem display properly, however. Safari on OSX (7.0.6), Firefox on Linux, and IE on Windows all display properly when zooming in.
I have a web page which is displaying much smaller in Chrome than Firefox on Windows. This is on the same screen. According to the Chrome developer tools and Firefug they have essentially the same computed width in pixels.
This screenshot shows both browsers (Firefox at the top/back with Chrome in front of it). I have double-checked that both have zoom level reset to 100%.
I have checked with both browsers in "private" mode in case there was some external plugin causing an issue. My colleague tried on a Mac in Chrome, Firefox and Safari and they were all the same (and more similar to Firefox than Chrome on my machine).
According to the Chrome developer Tools the internal width of the main content area is 951 pixels while according to Firebug the same element has a width of 953 pixels. The difference looks a lot more than two pixels to my eyes!
Any ideas what could be causing this and how to avoid it would be gratefully received.
I am about to design a series of tabs with an 11px x 11px "X" for the close icon.
In IE9, if I zoom it to 95%, I saw a image distortion of the "X". I did a test of displaying multiples of the same icons and zoom it, it works perfectly in Chrome and Firefox but not in IE.
I think there is something to do with the custom zoom, because in Chrome and Firefox you can only zoom it by 10% each time.
Please correct me if I'm wrong about this.
Confirmed ^^
I don't think you can solve this. You can't control how Internet Explorer resizes images during zoomchange. Because this is a problem concerning one/two pixels it's only noticable when the image is very small. Internet explorer is obviously calculating the height and the width in different manners.
Why do you expect that an 11px x 11px image would look good displayed at 95% size? If you want it smaller, create a 10px x 10px version.
IE uses a completely different rendering engine to the other browsers.
Internally, when a zoom occurs, it will re-draw the browser area with scaling applied. Some browsers use anto-aliasing and other techniques to remove or mitigate artifacts.
Unfortunately, this isn't something you have any control over.