I am implementing a fluid layout, which implies that sizes of elements on screen are computed using percentages rather than hardcoded in pixels.
One thing I've notice is that, on the same screen with maximized window, different browsers simply have different body sizes to start with! As a result of that, a same div in different browsers will have slightly different sizes as well as positions.
I've tested in Chrome, FF and Safari, and their body sizes when maximized are: 1280 x 702, 1279 x 687, 1280 x 684 respectively. It seems that the main difference is in the height, which might be explained by different designs/positions of the URL bar, tabs, etc?
Is this something a developer just has to live with (especially when using a fluid layout)? If so, is there any remedy to ensure that an element always has exactly the same size in different browser? Or is there something else I've missed which causes such discrepancies?
Using a fluid layout means that your layout must be able to adapt to pretty much any resolution, so the slight differences between maximized browsers on your 1280x768 monitor are the least of your concerns. People have different sized monitors (or phone screens, or tablets), and they don't only view pages maximized. Your layout needs to flow without breaking to match whatever width the person resizes their browser to. This is difficult, which is why fixed width pages with gutters are more popular for simple sites.
P.S. If you're going to be doing web development, you should get a monitor with at least a 1920x1080 resolution. That is what a lot of people are going to be viewing your site at these days, and unless you have a monitor to match, you won't be able to see what it looks like. Plus it will give you way more screen space to work with your code.
Related
I am currently working on a template for a webpage and I'm currently working on the responsiveness for it. I have the desktop version and the mobile phone versions working just fine. The problem that I'm having with it right now is I'm trying to make a version for tablets. The "tablet" I'm using right now is a surface pro which has a 96 dpi. My desktop has and older 1080 monitor. So when I open chrome up with dev tools on the surface the pixel width is the same or close to my desktop but is looking completely different. Text that is on a single line on the desktop is on two lines for the surface and not all is showing. The reason this is an issue is that this is the header of the page. At full width on the surface it's acting more like half width on the desktop. I thought it might be because the screen for the surface is higher DPI on the surface but not sure. Is this what is causing this and if so how do you fix it. Setting a media query of say 800px for tablet works for say desktop and some tablets but doesn't seem to be working for something like a surface. So is there a different way to set up width? I have code of the site but I don't think any of it would be helpful. If needed let me know.
Try using vh(viewport height) for height and vw(viewport width) for width, it uses percentage of the window. 100vh would use 100% of the window height and 100vw would use 100% of the window width. It's better than using pixels and requires less work to make the page responsive, pixels are inconsistent and break easily.
I have a screen with resolution 1680 x 1050.
I work as a web developer and while building websites, we use font-sizes that are easily readable on laptops with resolutions ranging between 1366 x 768 to 1920 x 1080.
While using Chrome developer tools, I chose Amazon Kindle Fire HDX which has resolution of 2560 x 1600. On this device (which chrome is simulating), the font-size renders very small due to high-res. I tried many font-size units such as vw, vh, % so that the font-size appears same on all resolutions but failed.
I even opened StackOverflow using Chrom Dev Tool and saw the font-size appearing to be too small. I don't know if the font size that appears on the real Kindle HDX is the same as what I'm seeing on Kindle HDX that chrome is simulating and I don't have a real 2K res device to test my websites as well. How to counter this issue? I want my websites to be readable on all resolutions.
If your font sizes are in relative units then you are likely just fine.
I think what you are seeing in Chrome Dev Tools is the "Zoom to fit" feature that will zoom the page of the targeted device to fit your browser window. Uncheck "Zoom to fit" and I think you will see the text is legible. And take notice that the ruler values will change to be more accurate representation as well.
You can see in this screenshot that the rulers indicate that the device simulation is being rendered at 1600px wide even though this screenshot was definitely not taken at 1600px wide. It was zoomed to fit my window.
I suggest you use em as the unit for fonts to make it more cross-browser/device compatible. em should work off the browser's own built-in font sizes to make things more readable as well as the browser's zoom settings.
Also, you may want to try out various CSS frameworks that may try to handle more consistent cross-browser/device consistency to keep fonts at more relative sizes according to device/dpi settings. (Unfortunately, I haven't experience in this scenario, but should be a good place to start your research).
When I use
.class { width: 800px; }
what does it actually mean?
When I view it on my laptop screen, it shows up exactly 800 pixels wide. When I view it on my tablet screen, it shows up as 1600 pixels wide. I am guessing because my tablet might have a higher pixel density. However, the physical (when compare side-by-side) width of the element if much smaller on the tablet than on my laptop
So, my question is: When I define a dimension in CSS to an HTML element, what is the reference? How is it computed or scaled on different displays?
The reference is a logical coordinate system that might be scaled in relation to the physical screen.
It's most common on a PC that the scale is 1:1. However as screens get larger it's becoming more common with computers that have scaled up display, which may also affect the browser.
The user can also zoom in the browser, which natually affects the scaling.
Devices like tablets and phones usually have a 2:1 scaling in the browser, sometimes even more. That means that the browser reports a smaller screen size, and everything is scaled up. This also affects the media queries, so even if the physical screen is larger, your CSS might not apply as the media query uses the screen size that the browser reports.
Also, if you don't lock the viewport using a meta tag, the mobile browser will scale the page to fit the screen, so whatever page width you specify will show up the same size.
(Started over my question because people downvoted and locked it because I didn't add pictures ... so here we go, since I got the answer from other sites, and this is actually important to large scale responsive sites, I also provide the answer)
I am trying to overcome the pixel density (real vs hardware) of viewports, that basically breaks/collapses Bootstrap sites even on huge tablets just because they have huge resolutions (alas, they default to a huge zoom, which causes bootstrap to collapse the content even though it would fit).
Here, Bootstrap own site, Desired effect:
But, instead, even on devices with higher resolution, I get this:
The reason is the viewport standard, that "enforces" a zoom according to dpi to prevent sites rendering too small (example: a 12px font on a 400dpi device would be almost unreadable). However, I would like to let the user decide if he wants to zoom or not, and not be constrained to the hardcoded zoom (example, my xperia Zq with 1920px have a hardcoded 220% zoom, leaving less than 900px of viewport, which will collapse bootstrap out of responsive mode).
Tips?
As per the specification of the viewport (which is still a draft but most certainly will become a standard soon, reference can be found here: https://developer.mozilla.org/en/docs/Mozilla/Mobile/Viewport_meta_tag), if you set a fixed value to the viewport width, that does not mean the viewport will have THAT width, but that the viewport should have AT LEAST that width. So, for instance, if I set the viewport to 1000px, than the viewport WILL be enlarged to that size, causing a smaller zoom, and also causing bootstrap not to collapse.
As per the specification, if the device cannot enlarge the viewport to the requested size, it will enlarge to the maximum possible size (alas, the real pixel width of the device), but will still enforce a zoom, probably causing the collapse.
So, the solution to prevent the collapse on a site that can handle a screen, say, 768px (Bootstrap's definition of tablet), is:
<meta name="viewport" content="width=768, initial-scale=1">
This will prevent the collapse if the device have 768 or more real pixels, while collapsing otherwise, thus the site will show just like it would on a desktop if there is enough rooms.
why do that?(a.k.a. pros)
The mobile version on such high dpi devices will look like the desktop version and won't collapse even though it clearly can handle the site
The responsiveness will remain on those devices, instead of auto-collapse whatever mobile it is due to the high viewport constrains (often above 200% zoom), you are only changing the default "start zoomed" to "start unzoomed"
why not? (a.k.a. cons)
By reducing or disabling the zoom effect of the viewport, fonts and other components will render on "real size", which on a high dpi device might be too small (like a 12px font on a 400dpi is almost unreadable) - yet, the user still has the freedom do zoom in, which will cause the site to collapse as needed just like if you resize a window on the desktop version. This solution, therefore, does not break anything, just change the default behavior.
On really small but high DPI devices, this is still annoying since you will have to zoom every time, so the size you specify should really be the SMALLER possible size, and not just, say, force the device real pixel count and totally disable zoom
I recently put together a website exclusively using a computer with a wide screen monitor. Later, When opening the same pages online using a computer with a smaller sized monitor, I suddenly noticed that all the div positions are completely out of place. My question is how to use the widescreen monitor to continue to develop my webpages without messing up div positions for views on regular sized monitors?
Re replies:
Thanks for the advice guys. I agree that the design of the page should be flexible enough to accommodate most browser window sizes. However, when u are working with a widescreen monitor and not paying attention it is easy to overcompensate div placements and element sizes. My next question is on how to be sure of regular browser window dimensions and how to force my browser window into that size?
Thanks Cyrena for giving me directions with the development tools. I do use them and check across browsers. But My problem here was working exclusively on a widescreen monitor with the browser maximized. I don't want to make the same mistake, so I need to figure out how to resize my browser window with the right dimensions.
Two basic approaches off the top of my head:
Resize your browser to be the width of your minumum supported desktop/browser size.
Set desktop preferences to be different sizes (like profiles) and switch between them during testing phase.
The truth is that a really good looking site will never work on all browser configurations. Choose a bar and work against that.
Don't maximize your browser window? Just shrink it horizontally a bit?
But any website that has such a high dependence on the shape of your display is poorly designed. It should fit to any size display that's bigger than some minimum (no use spending extra effort to make it fit on a 100x100 pixel screen)
If you use IE's Developer Tools, you can resize the window to see what it would look like at different resolutions.
Check it out in:
Tools > Developer Tools > Tools menu > Resize.
You will also want to make sure you are testing your website on other browser / OS combinations at the very least.