I'm familiar with two approaches for scaling content in UIWebViews that are on the smaller side (>~320 points in width).
The first approach is to set the appropriate frame size on the web view and the scalesPagesToFit property. This works fine but may easily result in content being presented at such a size that it is not easily consumed.
Another approach is to inject JavaScript to set the content's viewPort width programatically. This works on sites that are intended for mobile presentation (eg, responsive web design). If you're presenting a website that was coded for mobile consumption, the results with this are far superior in terms of content legibility than using the scaleToFit property.
The trouble is that these two approaches are mutually exclusive, or so it seems. If you scale the contents of a site that doesn't feature responsive design and then inject the JS to set the viewPort, you end up with an illegible content frame that scuttles the good work of scalesToFit.
Is there any way to detect programmatically, when a page will respond to the javascript injection as expected and optimize the site for the presentation size, versus when the page will not respond to the javascript but injecting it results in the undoing of the auto-scaling?
Related
We have a web based LOB application and currently we are shrinking the content of the app when it goes onto a smaller resolution browser i.e. IPad, using the viewport. using javascript:
document.querySelector("meta[name=viewport]").setAttribute(
'content',
'width=device-width, initial-scale=0.8');
This works fine asthecially but it seems to produce a performance hit when the browser has to scale everything down, especially with our kendo controls (the grid takes a massive hit).
Just wondering if anyone can advice a better was to scale down the viewport without hitting any performance issues?
I'd be surprised if you're getting a performance hit from scaling the page since that happens on the GPU and is expected to be very fast.
Additionally, your viewport descriptor as-is wont scale the page unless you have content that's explicitly wider than your layout size (for example, a very wide image). The browser will automatically zoom out to show all the content on load so your best bet is to pick a good layout width for your page (e.g. width=1200) and not set an initial-scale. width=device-width will attempt to lay your page out into the size of the device's screen, which is not what you want if you're trying to scale your page down.
I'm only just getting my head around how to build a responsive design site and in addition to a changing layout, I've also been tasked with functionality which should be responsive at various sizes. For example, on desktop, a link might not exist on a particular element, but then at mobile size, it should not only exist but it should also do something it didn't do at larger sizes.
I can understand using media queries to change the size or position of any particular element in CSS, but how does one go about changing functionality (i.e. JS & HTML) at various breakpoints?
(I'm not sure if the term exists or not, but for lack of a better name I'm going to call it responsive functionality.)
You're describing the difference between responsive design and adaptive design.
Responsive layouts respond to different screen sizes (using flexible
grids and media queries). They will often hide content or apply
different CSS rules on smaller screens.
Adaptive layouts adapt to different screen sizes and/or devices by taking a premeditated approach and optimizing the content that is served to the user.
For example, a responsive design might simply hide a sidebar on smaller resolutions while an adaptive design might show content specific to mobile devices (because the website knows the user is on a phone).
There are some good blog posts on the topic:
The biggest similarity between the two methods is that they both allow
websites to be viewed in mobile devices and various screen sizes,
ultimately providing visitors with a better mobile user experience.
Where the two methods differ is in their delivery of the
responsive/adaptive structures: RWD relying on flexible and fluid
grids, and AWD relying on predefined screen sizes. One of the main
distinctions between the two is that RWD might take more code and
implementation strategies with the fluid grids, CSS, and flexible
foundations, while AWD has a streamlined, layered approach, which
utilizes scripting to assist with adapting to various devices and
screen sizes.
Responsive functionality could be achieved a couple different ways:
You could use media queries to hide and show different segments of HTML that have different behaviors tied to them.
You can trigger your behavior with javascript where the javascript in the event handler examines the size/platform and decides what behavior to call.
You could dynamically generate different portions of HTML and their corresponding event handlers with javascript based on the size.
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.
I'm trying to display an iframe, which can be pointed to various urls, and would like to dynamically resize it to display its contents without a scrollbar.
How can I find those dimensions?
I don't think this is possible. Many sites resize their content to fit their container, so resizing the container to fit the content will be messy at best. Additionally, due to the single-origin policy, JavaScript won't be able to inspect the page loaded in the iframe if it comes from another site, so I don't think you'll even be able to tell if it needs to scroll or not.
You could approximate it by calculating the dimensions ahead of time, but even then it would only be a guess, since the exact size of objects in the browser is controlled only by the browser. If the user has picked a large font size, for example, there may be no size you can expand the iframe to that will be big enough for the user to see the entire page without scrolling.
You can only do it by communicating between the iframe and your website. This is the technique OpenSocial gadgets use for example. This is only possible if both the iframe and the parent are under control, in which case you can use HTML5 cross-window messaging and fall back to other cross-domain hacks if the browser can't deal with that.
You could also try to avoid the iframe by pulling the site directly and serving its content. That would only be possible for a very limited number of sites, mostly just static sites, and even then, not ideal by any means.
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.