The Problem:
I've been seeing problems with the native iOS UIWebView with regard to CSS3 transform:scale3D(scalar, scalar, 1)
We have an <iframe> which contains pixel-perfect art, consisting of many elements (text, rectangles, videos, etc), and my task is to scale the <iframe> where it fits fullscreen, not just the designed 320x480 or whatever
First of all, touch events aren't propagating through at all. Secondly, when the user holds down on the <iframe>, they can see DOM outlines for the elements at the prior, incorrect locations, at incorrect sizes (before the <iframe> was scaled to fit the screen)
The blue area should be the entire screen, not the original location
To top it all off, sometimes the scaling introduces random horizontal / vertical lines where the UIWebView decided not to repaint
My Attempts:
I tried using css zoom: which I understand is somewhat of a replacement for the <meta> tag viewport zooming, but I was still seeing random unpainted lines. I'm not exactly sure if I tried using hardware acceleration (transform in z / 3d space) but I'm pretty sure I did, the same as with the regular transform:scale3d approach
I also tried to crawl the configuration object, which has properties like x, y, width, height, but it seems like some properties need to be rounded where others do not (text font size and letter spacing for example, border widths etc). Rasterizing is causing a headache and I can't seem to get a pixel-perfect, scaled <iframe> I'm not sure which elements support decimal px CSS, so I'm considering converting everything to em
I haven't yet used an actual <meta> tag because it can't be dynamically appended.. needs to be on the HTML before the DOM is rendered. Another reason I didn't use the <meta> is because I need to know the viewport size prior to writing the <meta> properties (I can possibly query from out native counterpart if someone confirms this solution works)
The Question:
Has anyone encountered this problem before? Is it possible to get a pixel-perfect, scaled representation, given that the scalar may be 1.333333? I know that Apple is replacing the UIWebView with an embeddable Safari implementation (mobile web works fine for my usecase, just not native iOS), but in the meantime, is there any hope for iOS? Links highly appreciated! Thanks in advance..
My coworker found the answer!
Answer:
You can't scale an <iframe> from the outside DOM, you have to postMessage() into the <iframe> and use document.body.style.webkitTransform = "scale(1337)"
Hope this helps somebody else in need!
Credit ultimately goes to http://adexcite.com/iframe_scaling_test.html
Related
I have a fairly simple button symbol that I'm adding dynamically to the stage. The button has a background layer and a text layer. Everything works fine in the standard browsers but on iPad the background layer unexpectedly covers the text (as if on a higher z-index though no value shows in the DOM and attempts to override the z-index via css do nothing). Further more this issue only seems to trigger when I go to a label in the button such as;
button.stop("Idle");
Has anyone else had random layering issue on iPad that may relate to this?
For anyone who may be searching; Apparently vector shapes do not appear smoothly and consistently in all webkit browsers (the primary culprit mentioned was Android native browser). As an artificial optimization you can apply a 3D transform (but without actually scaling or rotating) in order to improve the vector rendering. In Adobe Edge this is done by applying a 'translateZ" transform to all of the elements on the stage. However this also causes random issues with any item I'm trying to layer with "z-index".
The solution is to clear out this transform on the problematic elements (or edit the edge classes to removed them globally) like so;
buttonFrameSym.$("select_arrow").css("-webkit-transform", "none");
I have a script that lays out these circular icons on the map, you hover over them, they spring up, text appears, etc. The icons are scaled relative to their position on the map, ie, the distance from 0 on the y-axis. I've tried to set the scale through CSS's width and height attributes and through the html width & heights on the img tag and still have the same problem:
Basically, in their dormant state, such as when the page is first loaded, or the user flicks between tabs, the images (trans' PNGs) are anti-aliased. However, when the hover() function, and thus the animate() function, is invoked, the images suddenly become jagged and horrid. I've noticed that this behaviour doesn't exist in firefox but does in safari and chrome. I don't know whether this is to do with Webkit, jQuery or just javascript itself but maybe someone could shine some light as google resulted in nothing. Any thoughts? :)
Please also note that the bottom left and bottom right icons look fine in both attached screenshots- they're unscaled ones!
Thanks a lot :)
Matt
i can only guess on this, but my assumption is that gecko and webkit use different scaling algorithms for images. thus it has nothing to do with javascript, jquery or png at all.
in fact, the image still has antialiased edges even in the webkit screenshot. (you see that when you zoom in)
the border is just messed up which is usually the result of a bad scaling algorithm.
try the following to confirm this assumption:
<img src="youricon.png" width="90%" height="90%">
and compare the result in the two browsers. you should see the same problem.
possible solutions:
make a smaller version of the image and replace image with the smaller one on hover instead of scaling it.
use a scalable vector graphics format like SVG for your icons.
I opened the Stack Overflow website on my 47 inch LCD TV (resolution 1920 * 1080, 16:9) and found the text and website right in the middle of a lot of whitespace. The text was unreadable because Stack Overflow, like many other websites, is optimized for standard 1200/1024 viewports.
In order to make the website readable, I pressed 'ctrl' and '+' keys and sort of got the content to occupy more screen width. I am sure this is not "zoom in" because what the browser is actually doing is scale up the content size (i.e. reduces the no. of pixels per character).
Can this 'ctrl +' behavior be achieved using Javascript as a pre-render exercise after detecting the resolution/size parameter of the viewport?
Update: I tried #media-queries which scales font-sizes and other few things, but it doesn't help to scale images and rest of the content (such as padding etc.) in a balanced way. Most importantly, it doesn't satisfy the condition to restrict the size of a given div to say "610px and yet occupy 75%" of the available screen-width.
Which is like a resolution change if we press ctrl + on Gecko/Webkit based browsers. Sorry can't accept the answer below.
Mostly yes.
IE6,7 have zoom and IE8 has -ms-zoom
Everyone else has 2D transforms and scale() so you're covered. see zoom css/javascript
I havent seen anyone apply this sort of effect to the entire document, so things might be buggy. Enjoy!
I'm sure it's possible with javascript, as most things seem to be, but I think that this is the exact kind of problem that CSS Media Queries were specifically designed to solve.
Check out the article on Responsive Web Design over at A List Apart
my site is aimed purely at the laptop market (dont ask why or argue!), all my users (or 95%+) we on a screen width of 1200+,
netbooks are now taking off, with a resolution of 1024 wide.
my site still looks great on a netbook if you zoom out once (ctrl-minus), but i don't want to rely on users knowing about ctrl-minus.
what are my options besides redesign? I'm keen not to have zoom buttons on my page.
is there a javascript zoomer outer?!!!
While this doesn't sort out your zoom, you could try a little trick based on CSS & relative sizing.
If you have an image or a container that is 100px wide, try setting it to 10em wide (or faff with the em amount until you find the appropriate value). Eventually, if you do this to every single dimension specified upon your site, you'd be able to actively shrink the page by changing the default font-size. E.g. from 1em, to 0.91em.
People often use the relative sizing to allow people the flexibility of being able to shrink and grow font sizes as they want. It's not as commonly used on images (because they are by requirement, fixed in size). This needn't be the case though, and in this instance, might offer you a way out of a "full site redesign" and giving the effect of "zooming".
This might solve the problem without redesign, but may be tricky and would require a bit of testing. The way stylesheets cascade, shrinking the font a little more, element by element, might cause a few issues.
detect screen resolution via JS
apply appropriate CSS
ctrl + - is the browser feature and you should never rely on that.
try this article http://www.alistapart.com/articles/alternate/
or try to google "javascript switch css"
this is a bad idea for many reasons. zooming is client specific so you will run into cross browser compatibilities if even possible at all. your best bet is to use css and set a min and/or max width. you don't need to redesign but (assuming proper html structure and usage of external css) changing some width values should do the trick.
Simple - I have a layout that is 800 by 600. When I press Ctrl and +, it zooms in and looks wonderful.
I want to know if there's a CSS/Javascript way to do the same? Without the user having to do it (because users will not do it and see the small layout).
Same question was posted by someone Setting IE "Optical Zoom" feature using Javascript/CSS that got no good replies.
There is a zoom CSS property, but it is part of CSS3 and is most likely not widely supported. By setting this on the body element using JavaScript you can zoom the entire page.
I would agree with the sentiments of the answers to the question you linked to though in that it should be up to the user to choose their own zoom settings. If your site is too big/small to see, it indicates a problem with your site design.
You can set all sizes as dynamic (use em for fonts, % for divs/images sizes). Then change the main wrapper and the main font size using javascript.
You can also use CSS switching. Put all the colors and such in one css file. Then create 3 or 4 levels of zoom and inside hardcode different sizes for all the existing classes.
Example:
main.css
a{color:red;}
small.css
a{font-size:10px;}
medium.css
a{font-size:12px;}
Not all designs (in fact I'd wager, none, without targeted style sheets) can cope with the vastly different sizes of screen out there today, from portrait orientated screens at public libraries, to ultra fine artworking Macs with giant landscape screens and tiny little laptops - the latter two often used by executives that have NO understanding of how the zoom features in a browser work and also often have terrible eye sight and little patience.
My suggestion is to use relative sizing like Marcgg suggests. If you're really looking to be super flexible the you could use javascript or browserhawk (or equivalent) to measure the screen sizes and switch out style sheets for those that are really not going to work with your layout.