I have not been able to get IE mobile to stop automatically resizing my site design. I am using three stylesheets with media queries to display the site differently on different device screens. I've included the meta tag so it shows the mobile stylesheet on IE mobile but it keeps setting the viewport at 320X480 instead of using the actual size of 480X800. How can I force it to display at the actual screen size instead of scaling for a smaller resolution?
IE Mobile interprets width=device-width as width=320 (in portrait mode) and as width=480px (in landscape mode) for compatibility reasons. See http://blogs.msdn.com/b/iemobile/archive/2010/11/22/the-ie-mobile-viewport-on-windows-phone-7.aspx for full details.
As far as I can tell, the only way to force IE Mobile to display at "actual screen size" is by hardcoding the viewport value to be width=480 (portrait mode). Note that this might have unintended side effects in other browsers, or even already when you switch to landscape mode (too small/large zoom level).
Personally I always use the following:
<meta name="mobileoptimized" content="0" />
This is a very helpful page: http://msdn.microsoft.com/en-us/library/dd938878.aspx
Related
I want to know the benefits of using Picture tag vs the CSS media query in-terms of pure performance (website load time).
I am developing a website and clients are forcing me to use picture tag but I think both are same. Let me know your input.
<picture>
<source
media="(min-width: 650px)"
srcset="images/kitten-stretching.png">
<source
media="(min-width: 465px)"
srcset="images/kitten-sitting.png">
<img
src="images/kitten-curled.png"
alt="a cute kitten">
</picture>
or
using media query and targeting separate image tags.
Media query works this way:
Even when you are viewing a website in Desktop, it still downloads the styles of mobile.
Example: If you are hiding a small image in desktop, in a desktop still small image will be downloaded but won't be shown (if it is hidden).
Picture tag: If you have 3 different images for mobile, tablet and desktop.
Picture tag will download only mobile device image when a page loads (when on mobile), it will neglect other 2.
If you want to test:
1. Write HTML code as you have above for 3 different images.
2. Once you are in desktop, load the page. Now you have a desktop image which you can see.
3. Disconnect the internet from your laptop.
4. In your browser responsive mode, keep reducing the screen
5. When it hits the tablet width, you will see the image won't be visible and it will be broken.
6. That means the image for tablet was not downloaded earlier when page load.
I think the accepted answer/question is lacking some real world contextual details. When talking about performance, we're usually talking about performance on slower devices such as mobile devices, not desktops.
Example: If you are hiding a small image in desktop, in a desktop still small image will be downloaded but won't be shown (if it is hidden).
This is usually not a problem as desktops have faster processing and they don't run on data (larger bandwidth) unlike mobile devices.
The accepted answer never mentioned how CSS media queries behave on mobile devices - this method actually only applies the styles that satisfy the smallest media query. The reason why this method 'downloads' all styles on desktop is because of how media queries are usually written with mobile-first design, by setting a min-width criteria. So when loading the page in desktop, all your media queries would be satisfied thus they are all applied and the last one in the source order wins.
So in terms of performance on mobile devices, both methods are the same. Ultimately, the <picture> tag is still the most robust solution due to additional configuration options with the srcset attribute. However, sometimes you need to use CSS media queries instead of <picture> tags such as when dealing with background images.
Here's a recent guide from Google recommending CSS media queries for optimizing background images: https://web.dev/optimize-css-background-images-with-media-queries/
My site have a fixed viewport width set like so:
<meta name="viewport" content="width=1260px, maximum-scale=1">
This makes the site "shrink" to fit the width of the device, and works well on any browser I use on iOS or Android.
I want to know if there's any way to preview this on developer tools responsive mode in a Firefox or Safari desktop browser. I'm only able to preview this on Chrome.
In Chrome it shrinks according to the width. In Firefox/Safari it keeps 1:1 pixel ratio.
The Responsive Design Mode of the Firefox DevTools currently doesn't take the information of the <viewport> element into account.
This feature is requested in bug 774055.
I have the task of testing a web application where it is given that this app should fit a screen with the resolution of 1280*1024.
My work monitor is, however, a 20 inch screen with resolution 1680*1050.
Will resizing the Firefox window to 1280*1024 meet the test criteria or should I always change the resolution of my monitor? (Obviously, the second option is not preferred).
And also: Is there a Firefox plugin which will help me to set the window size appropriately?
Sometimes asking the question out loud helps to realise what you really want :)
There is Firefox addon called More Display Resolutions which helps to show the page in given resolution, even in 1280*1024
After you install it, just go to Tools -> Web Developer- > Responsive Design View and here you can turn on the preffered resolution:
Ok, the above died. What now?
Since time of writing this answer I changed jobs and do not have to test specific resolutions. But I did quick google search and this site seems to be working: http://quirktools.com/screenfly/
Responsive Design Mode is a stock part of Firefox which is available from the Menu Bar: Tools -> Web Developer -> Responsive Design View in all Firefox versions (keyboard shortcut: Ctrl + Shift + M, (or Cmd + Opt + M on OS X)). No extension is needed to access this mode.
Within Responsive Design Mode, you can set the exact display area used for the webpage. There are several preset dimensions. Alternately, custom display dimensions can be used by either directly typing the dimensions in, or dragging the display to the size desired. What is being set is the pixel dimensions used for the area containing the display of the webpage.
These dimensions are not the same as setting the pixel dimensions used for the entire screen, which would include the Firefox user interface. If you set it to the dimensions of a specific physical display size it is the same as would be displayed using Full Screen mode (on desktop versions, keyboard shortcut F11). If you want to see what your page will look like including the Firefox user interface, you will need to determine how many pixels the user interface consumes at the screen resolution you are interested in and on the platform you are intending to use (e.g. desktop, Android, iOS). You will then need to use a custom display size. Note that the amount of room used for the Firefox user interface will depend on many factors which include—in addition to the OS and resolution of the physical display—any theme the user has installed, which toolbars the user has chosen to display, and, potentially, which add-ons the user has installed.
This is what Responsive Design Mode looks like:
If I limit WebBrowser's height, and content is longer, scrollbar is created inside the WebBrowser (effectively, HTML page is long), similar to IE in WP7. This scrollbar behaves the way I want to - after swift swipe it continues to scroll, slowing down.
But if I place a div with a scrollbar in the WebBrowser content, this scrollbar behaves like regular HTML scrollbar, it does not keep scrolling after user stops touching the display.
Is there a way to make this work too ?
Thanks
No, not easily. The WP7 IE9 browser control supports the overflow:scroll CSS property that allows the user to scroll content within the current page. It is worth noting that most Android and iPhone browsers do not support this, although it has been added in iOS5. None of these browser support inertia scrolling for overflow:scroll, WP7 included.
The only way to get inertia scrolling for overflow content is to do it yourself using JavaScript. For WebKit browsers there is a popular library, iScroll, that provides this functionality. However, it does not work for WP7 (due to lack of CSS3 3D transforms that are used to push the scrolling content onto a different layer for hardware acceleration) - so you will need to write your own implementation. Good luck!
We have a website that currently serves drawings to users via the SVG Viewer plugin. We have one client that sees it through IE8. With IE8, when they do a Change Zoom Level on the browser to anything other then 100%, the viewer tries to occupy the new space and zooms correctly. However, when the user tries to manipulate the frames inside that bound the viewer (it's a frameset website with the viewer being in the center) the entire site hangs. IE8 also shows that it takes up CPU cycles on the client computer, so it's trying to do something but hitting a loop.
I don't think this is actually our code and might just be something with SVG and how IE8 handles plugins and it's zoom. Does anyone know if this is a real problem and if there's a good solution?
If you are referring to the Adobe SVG Viewer plug-in, then I recommend that you (ideally) get your clients to start using a web browser that supports SVG natively — i.e. Chrome, Safari, Firefox, Opera; even IE9 (to some extent) — or use a different shim like SVGWeb to provide SVG support for those users of older browsers who also have Flash installed.
I found out what the problem was. I thought it was the SVG viewer trying to do something with the frames, when it turned out that I was just setting the frameset's initial size to the clientHeight and clientWidth, and then subtracting something from the height. That subtraction was a toolbar based in the frameset and, when you change the zoom level in the browser, there's a lock up that can occur with you trying to pull a components size and the client's size. At least, this is what I was seeing.