i'm writing a website on which everything should be able to be zoomed except of one object.
Is it possible to prevent only this object from being zoomed (typical pinch gesture on ipad, iphone)? (I know you shouldn't do this because zoom should entlarge everything on the page... but i don't know a way around.)
It has only to run on mobile safari.
Thanks for your help.
In order to do this, you need to be able to detect the zoom, which is not possible... at least, not directly. This post introduces a rather novel way of detecting the zoom level by using javascript to compare the width ratio of two divs on the page: one with a pixel-defined width and the other with a percentage-defined width. When the user pinches/zooms, the pixel width will not change, but the percent width will, so if you use javascript to detect the offset width of these two objects and get the ratio you can get the zoom. Then, if the ratio is, say, 150%, you can change change the width and height of you "fixed" object (using javascript) and multiplying each by .66666.
The major challenge you face here is that you cannot detect the moment of a zoom, so you'd have to use a setInterval() call to constantly be checking the ratio of the two test divs.
Related
For my page, I run a calculation in JS that uses values that are measured in CSS pixels. This calculation happens every time the viewer zooms the page. If you'd like to know what the calculation is for, it's used for scaling a div to a desired size depending on the zoom.
This is working perfectly in Firefox across all zoom levels, but I get a certain problem when I test it in Chrome and other browsers. It works fine until you try testing zoom levels below 100% (zoomed-out views). When you're in a zoomed-out view the calculation becomes incorrect (it's bigger than it should be). I think it might be because CSS pixels become smaller than device pixels when you reach zoomed-out views (right?), and because my calculation is in CSS pixel units it no longer is accurate. But if that's the case, then why are my zoomed-out views in Firefox working? In an effort to try to fix the problem on non-Firefox browsers, I converted the calculation to operate in device pixels when in zoomed-out views and that fixed the problem (in Chrome and other browsers), but then when I went back to Firefox to make sure its zoomed-out views still worked, the calculation was no longer correct (it was smaller than it should be).
From my findings, it seems that...
Firefox expects you to only use CSS pixels (even in zoomed-out views)
Chrome and other browsers expect you to convert between CSS and device pixels depending on the zoom (CSS pixels when zoomed in, device pixels when zoomed out)
So what's the deal here? How does one create a solution that works for both without browser sniffing?
Also, is it normal to convert between CSS and device pixels depending on the zoom? Or should I just be doing it the Firefox way and only deal with CSS pixels? I don't know which way is considered the normal way, but it seems that most browsers make you convert.
I generally use .getBoundingClientRect().width when developing html5 banners to get the width and height in the JS. This is used to do animations per size with (if 120x600, if 160x600 etc). I have noticed on a recent Chrome update if the browser is zoomed in or out it returns an incorrect value (out by 0.0001px) which means the if statement / animations fail.
I tried .getBoundingClientRect().width with a round to nearest 10 function but i felt it was too hacky.
Another solutions was grabbing the height and width from the css style sheet.
Is there a better solution for doing this without hard coding in the dimensions of each banner size?
So basically, I created an Android WebView, in a 720 x 1280 screen. However when I evaluate screen.width and screen.height, the response is 360 and 640.
I understand that this may be partly so that content is displayed on a readable way, but, when I tried to set a static width to the WebView, like 1000px x 1000px, the Javascript still evaluates the same.
Is there a way to disable this, so that the content looks same as it would on a desktop screen, and the screen.width and screen.height return the real phone resolution or the one I manually set in the XML.
A Crosswalk (based in chromium) solution is also acceptable, even if it includes changing the source code, if WebView solution is not possible.
If I understand you right, you want to show websites in desktop mode, not in mobile mode. To achieve this you can use this custom subclass of WebView: https://github.com/delight-im/Android-AdvancedWebView
It has a method setDesktopMode(true) that will do what you want.
This maybe be due to the pixel ratio of the device.
see this thread for a detailed explanation
Note that different android screens will have different ratios depending on their resolutions. My experience is with iphone / ipad; and my solution was to detect the pixel ratio and use that as a multiplier for positioning all elements.
Also If feasible, I recommend positioning based on a multiplier rather than a fixed value. For example:
x = 0.5 * screen.width * xPixelRatio
will give you a relative position at 50% (i.e the middle) of the screen. By positioning elements in this way as long as your aspect ratio is the same the elements will always stretch to fit properly, and you can adjust for different aspect ratios by changing the xPixelRatio & yPixelRatio variables.
I am using JVectorMap to create a map Page on my Website. However I found that the scrolling zoom speed is much to slow. How do I adjust the scroll speed? There is no documentation for this issue. I found this:
zoomStep: 1.6,
This is however to specify the zoom step for the buttons, not the scrolling.
Another issue that I have found is that I cannot set the height of the Map Container to:
window.innerHeight;
But i can however set the width to:
window.innerWidth;
How can I specify to Height of the Map container to be in relation to the Window size? I've also tried using a % value.
Thank you
this might be quite late answer, even might have been already answered somewhere.
But i got the same problem with mouse scroll speed and found the solution.
It can be fixed in js file in line 2382
zoomStep = Math.pow(1.003, event.deltaY);
You can easily change speed by changing that "1.003" value. More you make it - faster the scroll is.
I didnt fully understand the second problem of yours. But if it is about container height, I just use % values for the height. Make sure your parent has some height value as well.
Re. the scroll speed I agree that it is far too slow in 2.0.1.
I had a look into the js file and found some comments on line 234 - " If this is an older event and the delta is divisable by 120, then we are assuming that the browser is treating this as an older mouse wheel event and that we should divide the deltas by 40 to try and get a more usable deltaFactor. Side note, this actually impacts the reported scroll distance in older browsers and can cause scrolling to be slower than native. Turn this off by setting $.event.special.mousewheel.settings.adjustOldDeltas to false.
On line 113 you will find the adjustOldDeltas set as true. I have set it as false but no change in the scroll speed.
Hopefully this works for you or gives you enough to explore the issue further.
W.
EDIT:
These issues appear to have been fixed by iOS8. Consider this issue an iOS7 and earlier bug.
I've got some content (subject to CORS) that I'm serving in an iframe, that I want to be always stretched across the bottom of the browser window. I need this content to keep the same aspect ratio and fill the entire width of the browser, otherwise things will look weird. Because I don't have access to the iframe's contents I'm using -webkit-transform: scale to properly size everything properly.
I'm calculating the scaleFactor:
width = 600; // this is the original width of the iframe's contents and never changes
scaleFactor = window.innerWidth/width;
Then I set some CSS based on that scaleFactor, whenever window.innerWidth changes size:
$container.css({
'width': (width * scaleFactor) + 'px',
'height': (height * scaleFactor) + 'px',
'padding': 0
});
$iframe.css({
'-webkit-transform': 'scale('+scaleFactor+')',
'transform': 'scale('+scaleFactor+')',
'-webkit-transform-origin': '0 0',
'transform-origin': '0 0'
});
This works perfectly everyplace except iOS where it starts to break down if you zoom in too far. The iFrame starts to drift off the page and isn't near wide enough. I have no clue what's going on here.
Images of what I'm talking about: Good scaling, Bad scaling.
I've got a test page setup here that clearly demonstrates the problem on any iOS.
Anybody have any ideas?
Here's the result of my extensive investigation before I gave up.
There are two major problems involved in applying transform: scale to content inside iframes on iOS. The first was what I pointed out in the original question, that content starts to drift away from it's specified location on the page if you are using fixed position elements. It works up to a point that seems to be based on the original size of the element, the scale factor, and presumably the viewport width. In my tests a large element might scale and position perfectly when scaled at any factor greater than 0.85. A small element might be positioned perfectly so long as the scale factor is at least >3.5. It seems almost random, so I didn't bother determining what the exact point was.
I didn't try this on relatively positioned elements, but I'm assuming they function similar to fixed position elements.
There is a rather kludgy workaround for this involving using absolutely positioned elements anchored to the bottom of the page using scroll offsets and innerHeight. i.e.:
container.css('top', (document.body.scrollTop + window.innerHeight - container.height()) + 'px');
container.css('left', document.body.scrollLeft);
And updating this on every drag, transform, pinch, resize, etc. There is some weirdness involved with this method (iOS doesn't update scroll offsets until after a drag has completely stopped) but it's workable if you absolutely had to do it.
However, even though that's a possibility, when you scale content inside iframes on iOS, if you have ANY anchor tags (or other elements that need to be clicked on), the clickable area stays unscaled. If you have an image in inside an anchor tag that's 200x100 and you scale it 2x, the image will be twice as big, but the anchor will only respond to the first 200x100. Using the iOS simulator, if you double click on an image outside the clickable area Safari is even helpful enough to darken the original bounds so you know where you could have clicked. It's pretty much a deal breaker if you want to display anything other than text/images that don't require clicking or other inputs. More information here:
CSS3 Transform scaling issue on IPad Safari
"-webkit-transform: scale(2)" doesn't affect click area of Facebook Like Button (on iPad)
Until Apple fixes these long standing bugs in mobile Safari, it seems that trying to scale iframe content using webkit-transform isn't a viable option unless you are only targeting Chrome.
Edit:
Demo of scaling issues here.
Combo of iframe, transform scale, and ios is tricky.
There are bugs with transform scale. Not always in your control.
You can try zoom property instead of scale, and use scale for firefox where its not supported.
I don't have ios here so I cant check but it often works wonders. Though you may have issues with line breaks in text with zoom.
zoom solves this bug in chrome