How can I normalize units from CSSStyleDeclaration object? - javascript

I was working on a project transitioning the left CSS property of an element, which was defined as a percentage (e.g. 100% to 0%). I was developing in Chrome which was giving me style values for left as a percentage, this was working the way I wanted, until I tried it in another browser (any other browser actually). I set up this simple fiddle to demonstrate. Generally, most values are converted to pixels before being reported, but not chrome.
The second part of this question would be; Is there a way to get the other browsers to report the style property as it was originally set? (e.g. px, %, em, in, etc.) without an ugly conversion? and if not is there some other reasonable workaround? Thanks.

This is apparently a bug in chrome. Otherwise, All of the other styles and browsers, with the exception of IE, should convert everything to pixels. IE leaves everything in it's own units but also uses a propritary method in browsers older than IE9. Here's a page I found that talks about that and shows how to convert IE to px.

Related

Getting CSS top value with fractional pixels of an element exactly as it is set in DOM

I have a bit of a puzzling issue. I am trying to set the CSS top using jQuery 3.5.1 in Firefox and I was expecting to be able to retrieve it again as the same value. Try this on any div element:
$('#test-div').css('top', 1.11111);
alert(parseFloat($('#test-div').css('top')));
The alert is:
1.11667
It is not the same as 1.11111 due to the way different browsers handle fractional pixels. It seems to work alright in other browsers I've tested it with (Edge and Chrome, for example, which seem to have a six digit granularity).
When I inspect the HTML, the value is set correctly from the jQuery side to 1.11111. Is there any way to fetch this value exactly as it is set in the DOM such that I get back 1.11111?
Try using window.getComputedStyle(element).top
This was exact for me.

ScrollTop property of HTML DOM element giving integer/double values on different monitors

While doing some debugging, I was messing around with some html and javascript in the TryIt editor on w3schools. I have a curious problem where the scrollTop property of a html dom element returns integers when viewed on one monitor and double values when viewed on another.
This happens on Chrome 68.0.3440.106 but not on Edge 42.17134.1.0.
Here's my code:
https://www.w3schools.com/code/tryit.asp?filename=FV27R380RB8R
Can someone tell me why this happens and if there's a way to force it to return integers please?
zoom value on both browsers might not be 100%

Randomly inconsistent height returned by Javascript in Firefox for Android

I am working on a web app, visible here.
On desktops, I don't have any problems. However, in Firefox for Android, $('#station-'+id).height() takes two values, and it seems to be one of the two, at random.
I can't find why I have such inconsistent behavior… It only happens in Firefox for Android (but I only tested desktop browsers and Firefox for Android).
Do you have any idea ?
Thanks !
I had the same problem with screen.height, changing it to screen.innerHeight fixed it. I don't know if this approach is going to work on any element on the page though. Note that you'll have to subtract the padding values if you want to convert the innerHeight to the height.

IE7 Text Resizing

I've used pixels to determine the size of my fonts on a website. All the text resizes fine in Chrome, Firefox etc, using the zoom feature. However in IE7 (and IE6/8, I guess) the fonts don't resize using the Text Size menu, they just stay the same.
Now I'm thinking the only solution to this is switching to ems - but is there any solution I could write in JS to target / fix only IE?
Unless you know otherwise, assume that hardly anyone has IE7 or 6 anyway. IE8 has a zoom feature, so that's OK. On approximately 50 small business sites I have data for, in the last month 0.5% of visitors were using IE6, 4% had IE7 and 12% had IE8.
We don't support IE6 or 7, but we do test and check things look basically right there.
Assuming that you do want to allow this minor feature (assumedly people who need accessibility the most will not be using these notoriously inaccessible browsers!) in IE6 and 7, you do need to use ems rather than px, and you'll really need to use it for everything, not just font-size, as otherwise the boxes won't scale properly either.
in internet explorer 6 & 7 you cannot increase or decrease font-size that is set in pixel in your css.
For that to work you have to use EM's as font-size value.
Read this article

Detect Zoom in Firefox

I want to detect if the browser is zoomed in or out (don't really care to know the value, but I assume it will need to be found anyway in the decision process). I have read a lot of other SO posts on the topic, but none of the solutions given work on FF (although there is an IE7/8 and chrome solution).
Oh, and I can't use flash, so the flash solution is out of the question.
Edit: And I must be able to detect this on the initial page load
With modern versions of FireFox, you can now do the following:
DPR = window.devicePixelRatio;
if ( DPR <= 0.999 || DPR >= 1.001 ){
// User has zoomed in or zoomed out
}
If by zoom you mean that the user pressed ctrl/cmd+[plus] and not css transformation you can detect computed font-size. Just checked in FF 4.0.1/Mac and it worked for me. To detect computed font-size I used code from this question: Get computed font size for DOM element in JS .
The value changed after zooming. You need to know what the font-size of a certain element should be (as set in css) and compare it with what it really is.
I suggest you look at this generic question. And possibly close your own as a duplicate (not voting to do this myself, since it's not "an exact dup".
Did you try to detect the resolution, which may help you to detect the zoom.
Maybe instead of detecting the zoom you could detect the error.
For example if your layout expects an elements' offset to be at 100,200 and a query shows it's at 300,450 you'll know it's in the wrong place and you can apply your fixup/workaround.
This has the added benefit that if the zoom issue is fixed in a future version of the browser you won't be applying your fix needlessly or incorrectly.

Categories