I have a web page as follows (see img)
A certain div has a width of 100% which is filling the whole viewport.
When checking on Chrome, the viewport size is 500px while the CSS size is 536.
Does anyone have an idea why it's different please ?
Thanks.
Cheers,
Many modern visualization techniques, such as parallax, require larger elements than the actual viewport size and a smart usage of transform properties in order to create particular visual effects and/or illusions.
Your picture is actually showing a part of the parent element displaying properties particular to such techniques, clearly showing: -webkit-logical-width:800px and perspective-origin: 400px 300px.
For any element with a position value other than fixed, width:100% usually results into the child having an equal width with the parent, not with the viewport. There are notable exceptions from this rule, though.
If you need a more in-depth explanation as to why does the parent have a different width than the viewport (and it's parent parent, and so on... - all the way to the viewport), you need to post a Minimal, complete and verifiable example and I'll lay down each of the ancestors of your element affecting its width.
If, on the contrary, you don't really need to know what's going on at parents level, but are looking for a way to make your current element as wide as the viewport, you probably want to give it a width value of 100vw.
Related
Im trying to align a jquery popup div to the center of my screen using top and left properties. I thought its better to give % values for these two properties so that the popup will be centered even if browser window is resized.
But when i actually resized the browser window its not resulting as expected.
So my doubt is, does the % value we specify for top, left properties depend upon the screen resolution? Or do they depend upon the parent container's size?
They might. The percentage is relative to whatever element contains it. If that element happens to be the window itself, then yeah, it has to do with the resolution. In fact, it will always depend on the screen resolution as long as its parent does. And the same goes for the parent's parent, and so on. Kinda tough to grasp.
Basically, if any element "above" your element in the hierarchy of things doesn't depend on the resolution, neither does your element. But in order to see if it's parent depends on the resolution, you have to look at that element's parent. And the parent after that. And so on all the way to the top. Or you could test it out and look :)
It there's an absolute-positioned/sized element somewhere above it in the "hierarchy", then chances are it doesn't rely on screen resolution.
The % depend on the next relative parent container's size.
Percentages rely on their parents' size. See here: http://jsfiddle.net/tqWhL/4/ the red div is as wide as #a.
Since body is 100% of the browser window width, you could make your div a child of body and set it to 100% width.
Is there a purely CSS-based way to size a block-level element such that it fills its parent as much as possible, but remains square?
An interesting use case
I have written a very simple analogue clock using mostly CSS, and a pinch of JavaScript.
http://jsbin.com/iqicuk
It has been written scalably:
http://jsbin.com/emiyer
I would like to scale it to fill the page, but stay in proportion, obviously.
If I set the width and height of #clock to 100%, of course, it will be pulled out of proportion:
http://jsbin.com/esubol
You can't do that with pure CSS, but you can do it with Javascript - and I assume you have Javascript running anyway to resize the parent element.
A solution in progress
thirtydot came up with a very clever technique that takes advantage of the fact that images with only one defined dimension scale proportionately, and he harnesses this to size the element. We now have a clock that can scale properly, but only if the viewport width is greater than the height, not the other way around:
http://jsbin.com/isixug
Likewise, if we change img and #clock to have a defined width, instead of a defined height, then we have a clock that can scale properly, but only if the viewport height is greater than the width:
http://jsbin.com/awucun
The solution
We can combine the two 'tricks' above, that each only work for one orientation, by using a media query for orientation, and specifying the right 'trick' depending on the viewport orientation. We now have a completely scalable clock, no matter what the viewport orientation or size:
http://jsbin.com/okodib
Any in flow block level element will already inherit the width from its parent. For the height however you will need to find an alternative.
I doubt this is something you will want to do but if you set your parent to position: relative; and then the child you want to make fill up that parent position: absolute;. Then specify where it needs to stick to relative to its parent with top:0;left:0;bottom:0;right:0;.
However this solution has compatibility issues in lower versions of IE and is rarely acceptable for application...
As Jens Roland already said, this is not possible through pure CSS.
Maybe LESS is helpful to you.
I'm working on a website for a client, and I'm not excellent at css... still in the process of learning a lot about divs. I made a div that is supposed to stretch 100% of the page, and it works, unless a user is browsing from a lower resolution (1024 x 768 for example) and has to scroll horizontally, the div will then only extend to the original length of the browser window.
That coupled with the fact that my footer is behaving the same way, and is not sticking to the bottom of the page.
The code/website can be found at:
http://cliqthis.com/temp/roadhouse/index.php
Thank you for any assistance, or an explanation of why this is happening would be helpful as I am still in the process of learning.
You see the scrollbar for resolution 1024x768 because <div id='container'> has a width of 1064 pixels set on it. The parent div will have a minimum width of 1064 due to this.
Are we talking about the black bars not extending all the way to the right?
You need to make sure not only that those divs' widths are 100%, but that all their ancestors' widths are also 100%. With normal (static) positioning, the 100% width means 100% of the element's parent's width.
Using the Web Developer addon in Firefox, with Outline Current Element turned on should prove very helpful in determining which elements aren't as wide as they need to be. (Move your mouse around the page and it will outline the element you're over, and tell you the css selector path to it).
Also you might want to compare the structure to the original template you used. It seems odd to me that, for example, you have an empty div.#footer element, and then a table.foot element after it, rather than inside of it. Perhaps you accidentally broke something there?
Set up a minimum width for the div.
div.class { /* ... */ min-width: ___px !important; /* ... */ }
I was very surprised when I found that a <div> with a size of - say - 200px becomes 220px wide if you give it 10px padding. It just makes no sense to me, the external size should not change when an internal setting does. It forces you to adjust the size every time you tweak the padding.
Am I doing something wrong, or is there a reason for this behavior?
EDIT: I know this is how it's supposed to work, my question is why? Is it logical in a way I don't understand? Does this give any advantage over the opposite approach of keeping size and padding separate?
There are two different so-called "box models", one adds the padding (and border) to the specified width, while the other does not. With the advent of CSS3, you can luckily switch between the two models. More precisely, the behaviour you are looking for can be achieved by specifying
box-sizing: border-box;
ms-box-sizing: border-box;
webkit-box-sizing: border-box;
moz-box-sizing: border-box;
width: 200px;
in your div's CSS. Then, in modern browsers, the div will always stay 200 px wide no matter what. For further details and a list of supported browsers, see this guide.
Edit: WRT your edit as to why the traditional box model is as it is, Wikipedia actually offers some insight:
Before HTML 4 and CSS, very few HTML elements supported both border and padding, so the definition of the width and height of an element was not very contentious. However, it varied depending on the element. The HTML width attribute of a table defined the width of the table including its border. On the other hand, the HTML width attribute of an image defined the width of the image itself (inside any border). The only element to support padding in those early days was the table cell. Width for the cell was defined as "the suggested width for a cell content in pixels excluding the cell padding."
CSS introduced margin, border and padding for many more elements. It adopted a definition width in relation to content, border, margin and padding similar to that for a table cell. This has since become known as the W3C box model.
The reason why it's like that is that technically the width of elements is supposed to apply to the content, not the container.
According to the CSS1 specification, released by the World Wide Web Consortium (W3C) in 1996 and revised in 1999, when a width or height is explicitly specified for any block-level element, it should determine only the width or height of the visible element, with the padding, borders, and margins applied afterward.
More info about this behavior*
* Disclaimer: Yes, this is my own blog and I think I did a thorough job of explaining the box model so I'm putting it as reference.
Padding is supposed to be in addition to the given width of an object.
See the CSS 2.1 specification for box model.
While it is true that you can view padding as either an internal or an external attribute, the fact of the matter is that according to the current specifications it is an external attribute. It was a choice between two, as far as I can tell, equally valid options.
I haven't read up on the box-model attribute, but assuming that alex is right, then in the future you will be able to choose between the two ways of interpreting padding.
If the size increases with padding, it's working as intended. In browsers with broken box models like older Internet Explorer versions, the div will be 100 pixels wide, but that's incorrect handling of the CSS.
http://www.w3schools.com/css/css_boxmodel.asp
If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?
It's better that the default behaviour is that the width of the container is not affected by padding or margin values.
If your box is within a box, remove the inner box's width (the one with the padding) and it will fix the problem.
""If the box model did not work this way, how would you deal with padding around an image? Would you prefer that the size of an img element with padding not match the image's pixel dimensions? Or that the padding covers the image?""
First of all, any good web developer would know better than to put an image into a container where it doesn't fit. That is developing 101. If the padding doesn't allow for the image, the image or the padding should be changed. Pure and simple. So the argument mentioned above is faulty.
Padding is an internal setting, internal to the boundries of the container. So when something is inside that container, and you increase the container's padding, the item(s) inside that container should coded so the can be reduced in size.
The word "padding" itself says it all. Can you imagine if UPS added padding to thier boxes to protect the contents inside, only to find that the box increases in size! Rediculous, right? Of course it is! Padding is meant to add space around the inside of a container WITHOUT the container breaking and expanding in height or width.
It's browsers like mozilla, gecko, and opera that have broken box models, not IE. The box model that the "consordium" implements is faulty at best and reaks havoc on web develpers.
If the "consordium" implemented the same box model as IE, than we developers would have a much easier time with the columns of our webpages. I think you have to agree with me on that point. Plain and simple.
I am so tired of people saying that IE is inferior. I can give tons of examples where IE holds strong while the cheaper browsers like firefox break under the pressure.
My two cents. Hate me if you want, but what I speak is common sense and nothing else.
Hi I am trying to learn CSS and have been looking at the source of websites to learn how it works in practice. I came across the 960 grid system the other day, and found a really beautiful site design that is using the 960gs framework >> OneHub
At this stage, I don't think it is very wise for me to use a CSS framework until I have a better understanding of CSS. So my question is in regard to how they have achieved a centered content box on the website whith a background that fills to expand to your browser width.
I have firebug installed and I can't figure out why the divs on their site eg. #gutter, #navigation will expand to fill the entire browser width. I don't see how these divs are calculating their width value, because it seems that none of the child elements are large enough or have a rule which would force these divs to become larger.
I don't understand how the width is 100%, I would have expected to see some margin auto rule or width 100% specified somewhere in the CSS but I can't find it. Other websites using the 960gs may be doing the same thing but I just used this site for reference since I think it has a nice design.
I hope my question makes sense and thank you for any help with this
DIVs, unstyled, will always fill 100% of the parent element. If that's the body, or another element that fills the browser window, it will fill 100%.
It's called a "block level" element. All block level elements behave this way: div, p, form, ul, etc.
If you specify no rule for width, the width is by default 100% -- that is, it expands to fill its parent element. In this case, the parent element is the body, which is also the full width of the viewport.
With the 960 grid system, when you say entire browser width, you mean 960px. Agree with rpflo, above.