MDN seems to have contradicted itself. Here are a few statements made on the doc:
Definition of a layout viewport:
The area within the innerHeight and innerWidth is generally considered the layout viewport.
Properties of the layout viewport:
When the user pinch-zooms the page, pops open a dynamic keyboard, or when a previously hidden address bar becomes visible, the visual viewport shrinks but the layout viewport is unchanged.
Contradiction:
The viewport was originally 1200 x 800 (window.innerWidth; x window.innerHeight) pixels. Upon zooming in, the viewport became 800 x 533 pixels. This is the layout viewport.
So, they claimed the layout viewport's size cannot change upon zooming. Window.innerWidth is the width of the layout viewport. If Window.innerWidth is the width of the layout viewport, and the size of the layout viewport cannot change, how come Window.innerWidth's value changed upon zooming in?
Well, pinch-zoom on mobile is simply not the same as zooming on desktop. The zooming done via an pinch-gesture does not change the page layout. It performs the magnification effect on the page as is.
Related
I know we can make horizontally responsive content in ionic 2. What i want to know is how to make pages height responsive for all type of screens for example if a screen cover whole area on iphone 5 then it should cover whole height wisie area in iphone 7 also ? whats the best approach to achieve this ?
As some have already mentioned, you can use vh for the height property on your css. The catch here is that the viewport may change even if the screen orientation stays the same. This happens when you place an input in your app and it gets focus. The keyboard of the mobile device pops up on the screen, and the height of the viewport changes because the keyboard took part of it. f your mobile screen is 430x710 (some random number here) 1vh would be 7.1px, but when you tap on an input and lets say the keyboard is 430x300, now 1vh will be 4.1px (( 710 - 300 )/100)
That could be a real problem with responsive design. My advice is to use vw, the only thing that might alter it is the screen orientation (you can lock it). The extra step is that you have to use conversion to get the right number in vw that you wanted previously in vh.
I hope I have understood your question correctly, you want to make the page height the same as the height of the device viewing it?
Well, let me introduce you to....
viewport height (or vh)
One vh is equal to 1% of the height of the viewport. So, as you can probably imagine, 100vh would be equal to 100% of the height of the viewport! The viewport is basically the view of the page. However beware, the vh unit is not support in Internet Explorer 8 or earlier.
I hope you will get good idea to make the responsive properly from the follow parameters.
vw: 1/100th viewport width
vh: 1/100th viewport height
vmin: 1/100th of the smallest side
vmax: 1/100th of the largest side
Actually vh is a perfect solution to make the responsive based on viewporot. The viewport is the area where the browser renders the site. This is your screen minus the reserved space of the browser chrome. Sometimes you want to size an element based on that viewport, like a sidebar. This can be done using a unit we’re all familiar with: percentages.
I am reading A tale of two viewport and I could not follow the explanation at Consequences. He claims that when one zooms into his page, the upper right corner is not blue anymore even though it has width:100%.
I do not understand why this should be the case. In fact, I cannot even reproduce it:
Could someone explain me on a more simple example what the author's point is?
You can see the effect by using "browser zoom" (not pinch zoom), i.e. ctrl+/-. You need horizontal scrolling to see the effect in the author's example.
When you hit ctrl+ a few times, you're increasing the size of a CSS pixel. This means fewer CSS pixels will fit into your browser window (viewport) and thus zooming in shrinks your viewport. For example, say your viewport is initially 800px wide. You zoom in to 200%. Since each CSS pixel is now double the size, your viewport only fits 400px.
The article's point is that even though the viewport shrunk, the content on the page hasn't (in terms of CSS pixels), it's still ~800px (or whatever the author specified it to) since only the pixel size has changed. This means sizes that rely on the viewport will now look disproportional to the rest of the content. In his example, the top bar is set to fill the viewport width 100%. When the content becomes larger than the viewport, the bar will not extend the same width as the content.
Quick Overview of my Problem:
I made a site for mobile, it looks great. Move on tablet it looks horrible. As in it's like 5x stretched out from left and right. Imagine your face stretched horizontally up to 4ft.
Research and Possible Solution
I had a feeling i could viewport. As I thought, if i could just SCALE the layout instead of having browser provide more width and then my layout spreading to accommodate.
Article told me that if i set viewport meta tag width=300 or anything custom then browser scales whole page to fit the current viewport's actual width so 300px would be covering 1200px, at least that's what my impression was.
However, it DIDN'T work. No matter what viewport settings I do they appear to have no effect on scaling.
What i want
I want my page to scale up. I don't want to specify every border width in em units than create dozen media query checkpoints to increase font size. Especially since my layout remains the same only it needs to scale up.
If i was going after different layouts then obviously i'd've used media queries.
I've tried this:
<meta name="viewport" content="width=300">
I solved it using some javascript
first add (i'm using jade)
meta(id="myViewport", name="viewport", content="width=device-width")
Now window.innerWidth will give correct browser width and not some arbitrary number set by browser like 960 which was being reported by chrome on 360 width phone and 2100+ tablet.
Now just check if screen is wide then limit the viewport's width that way browser will scale it up so, for my tablet, 500 pixels will take up 2100 pixels.
if (window.innerWidth > 450) {
var mvp = document.getElementById('myViewport');
mvp.setAttribute('content','width=500');
}
//- first set device width so window.innerwidth shows actual width then change accordingly.
I'm trying to make a horizontal layout (with columns) where the content scales based on the browser window height.
I came across answers about perfect ratio based on width, but I want to have an infinite width (as the amount of content won't always be the same).
Is this possible just using HTML/CSS?
It is going to be hard to maintain the aspect ratio with css, but if you set the height of the maincontent box to 90% and the height of the containers to 100%. They should respond to
the browser window. But only in height, never in width.
From there you can use javascript to set the with to be <height> * 1.5 (or similar) you will have to do this in the document ready event, but also in the window resize event.
I need some help:
http://www.stansellelectric.com
If you go to any page on this website and re-size your monitor (or Firefox browser if you use the Web Developer toolbar) down to 1024x768, a horizontal scrollbar will appear both in the #contentwrap div and the page itself. Now, increasing the width of the window to 1039px fixes this, however I need it to stay at 1024px and not have a scrollbar anywhere.
I'm stuck, help please?
1024 pixels is the total width of the screen.
In order to fit content on a 1024 pixel screen, you need to account for the vertical scroll bar (usually 16-24px in width) and (in some browsers) the window's edge. These will take away horizontal space.
Bottom line: You need to use a smaller width for your content than 1024 pixels. A number that is popular among designers is 960 pixels, also because that can be evenly divided; it's used e.g. by the 960 grid system, a popular CSS framework.
However, in my experience, a slightly higher number (like 980 or even 1000) will also work well for the majority of devices.