What are good and recommended uses of percentage values for vertical CSS declarations?
In other words, under responsive design, are we overlooking something where % would be beneficial over em?
Because it seems that for most situations (except for cases where you want all sides equal; credit), em would be better served than %, consider:
Using percentages for the horizontal values of padding, margin or border of elements in CSS is fairly standard — especially in responsive web design. For example, take margin-left: 7.2% and padding: 0 5%. It also makes sense: the wider the screen, then the space will increase proportionally.
One can do the same for the vertical values:
margin-top: 5%;
padding: 10% 0;
border: 1% 0 2% 0;
As expected, an increasing viewport width will increase the corresponding vertical spaces.
However, in the cases I've come across, it can look a bit odd — unfitting to the design. It seems that em values may be better served.* But, on the other hand, where would it be beneficial to use percentages?
* Since these won't increase with the width of the screen, but will increase according to the font size of the page.
I don't think there's any right or wrong answers to this question. It really does depend on your design.
As you noted, % values, even on vertical-based properties on margin & padding, are still relative to the width of the document. So if your design requires even padding, then % values all round are great.
But, if the design is content oriented, and you're still using % values on the horizontal properties for responsive design, % might not be the best for the vertical properties. You may, for example, want the padding-top to be exactly the height of 1 line of text. So you'd use ems.
But I digress; it really does depend on your design and personal preference.
Yes, depending on the situation just like any other css practice.
Say you have a container div that uses 100% of the screen height and you have a header you want to appear at the top of your div. You could say margin-top: 15px on your header, which works, but then if I come and view it on my phone it will look very squished.
So instead you say margin-top: 10% then no matter what screen I come and view your site on your header is always 10% from the top of the div. which means the relative flow of your layout will always be the same.
The general rule is this: For any valid css you can write there is a use-case where it would be the best way to go about achieving your design goal. Forget anyone who says "Never use negative margins" or "always avoid absolute positioning" or any of the other crap they throw around.
I have been pondering this question as well recently and after reading around the internet the 'rule of thumb' I'm beginning to lean on is as follows. First, the reason why % is good responsive design for the horizontal axis is because as we all know the width of your browser can vary greatly depending whether the user is on a phone or computer. The vertical axis is different however because while it can also vary like the horizontal axis, many webpages are created for a vertical scroll and the user is expecting to scroll down. In such cases a little more vertical scrolling due to less responsive ems is fine.
To answer your question based on that assumption, a time in which you would use % for the vertical margin is when you have a design where you don't want to make the user scroll much to see a part of the page. Specific examples might be a single-page web app where you don't want any scrolling or a header or initial page content such as a picture that you would want the user to see in its entirety without having to scroll down.
Related
I like to think of myself as having some serious CSS swagger(I am also a PHP hack, and pretty good at Javascript), but today I was chatting with a designer about a specific situation, and honestly I just did not know the answer to it. I was hoping someone could elaborate on the problem.
Scenario:
I hear many a people say, "Oh I use percentages for everything because of responsive design", but then you go and look at their css, and they are using px all over the place for margins, padding etc.
My problem is that should I be using pixels at all? I'd say the main pain point I have in understanding this, is when it comes to high resolution screens.
For example, I was creating a pretty simple "hero" in which I set the height of my container to 700px tall with a background image and some text, while setting the width of it to 100%. On my screen I was creating it on, it displayed full height of my screen(which was the intention), but when I had someone else view it on a higher resolution laptop screen, the picture was significantly shorter in height, with white space underneath it, failing to fill the whole height of the screen.
I am looking for someone to explain exactly how pixels values are affected on higher resolution screens, and if you should always use percentages.
For example, If I set a container to be 300px wide on a "normal" resolution screen, will that same container be 150px wide on the higher resolution screen, and also look shrunken and terrible?
Say I start using percentages for things like margin and padding, I am curious as to how css would calculate that? For example, say I have a contact form with many inputs stacked on top of eachother, and I do something like the following:
input {
margin-bottom: 2.5%;
}
Where would the css be calculating that 2.5% from? Does it say, "Make that margin-bottom 2.5% of the height of it's parent? I am just confused as what it would be based off of.
Any input is greatly appreciated. Thank you.
First of all, I want to refer to an answer given on SO that explains the percentage property really good: https://stackoverflow.com/a/31032477/4459695
So should I use pixels?
Using pixels should indeed be avoided in modern Web Design, for a few simple reasons:
Pixels are fixed. They do not adapt to different screen sizes or viewports, scalings or layouts. Since mobile first is a goto pattern and responsive Web Design relies on adaptable units, and since pixels are avoidable, - avoid them.
High resolution screens are getting more and more mainstream, and if you do not want to adapt to even more media queries (for the larger screens), you should not be using pixels.
There are better, more dynamic alternatives. These include vw, vh, em, rem and of course %.
But when to use which unit?
em and rem are really good for font sizes or anything like that. They will easily scale and can be used for margins and paddings too, depending on content size.
% are best used in relative object positioning, not so much in margins, paddings or font-sizes, although they can (margins and paddings are okay, I guess). What I mean by this is that percentages work best when combining them with width, height or anything like that (they work great in flex-layouts, for example).
vw and vh are allrounders - I personally do not use them in specific cases, but they are quite handy sometimes. Best example would be an overlay which should fill the complete viewport.
All those units are dynamic and depend on the viewport. This is great, because this allows for flexible styling. Pixels do not.
% value in margin and padding is always % of the parent's width.
So say you have a <div> with margin-bottom: 25%;, inside another <div> which is 1000px wide, then the bottom margin of the <div> is 1000*25% = 250px.
.container {
width: 100px;
background: green;
}
.child25,
.child45,
.child-none{
background: yellow;
}
.child25 {
margin-bottom: 25%;
}
.child45 {
margin-bottom: 45%;
}
<div class="container">
<div class="child25">This one should have 25px margin bottom.</div>
<div class="child45">This one should have 45px margin bottom.</div>
<div class="child-none">This one has no margin</div>
</div>
As for your hero problem, if you want the hero's height to be full screen's height, use height: 100vh;, which mean 100% of the viewport's height.
A 700px height element will always be 700px high on any screen. The different in real-life perceived size is because of the screen's ppi (pixel per inch), or dpi (dot per inch) as they are usually called on mobile devices. The value refer to the number of pixel/dot that fill each real-life inch on that screen.
I may well be asking for the moon on a stick, here, but: I'm trying to figure out how to get a two-colour background to delineate the two columns of the main content.
The background must be full viewport width (edge-to-edge), and the central content is responsive with a max-width of 960px, split into two columns; the first column is 2/3 of the width (max of 640px wide) and the second column takes up the remaining 1/3 (max of 320px wide). Probably the easiest way to explain it is with a GIF:
As you can see, the left-hand part of the light blue 'sidebar' background colour always lines up with the left side of the actual sidebar column. It was pointed out to me that the checkout on woothemes.com has pretty much this exact same effect (although I think you need to add something to your basket to see it). They appear to have achieved it with linear-gradient, and it boils down to this:
background: linear-gradient(90deg,#fff 53.5%,#f0f4f5 46.5%);
background: -moz-linear-gradient(left,#fff 52%,#f0f4f5 46.5%);
The problems are:
I don't understand these declarations at all - why are the second color-stop's values lower than the first (and why is the -moz declaration's first color-stop a different percentage)? Adjusting it doesn't seem to make a difference, but I definitely need to update the values, as they don't match what I need... but I don't get it.
Although the effect is close, it unfortunately is not perfect: for a start, the stop between the two colours is kinda blurry; and worse, the line does 'drift' when rescaling. Although it's only by a small amount, unfortunately it's enough to kill the illusion with the design I've been given.
I've tried a couple of methods, including variations of linear-gradient and a pseudo-element with percentage & calc()-based offsets, but I'm totally not getting it. I've debated whether this is something I can achieve with some super-clever SVG element handling, but I seem to be totally stuck on something that looks deceptively simple.
Is there a way to achieve this with pure CSS?
I didn't look into the woothemes.com example, but here's my take:
http://jsbin.com/jofeseseyo/edit?css,output
This would need to be adapted a bit based on the rest of the site, but the idea is: one container of max 960px, with two children (66.666% and 33.333% width). Each child has a pseudo-element that is absolutely positioned at the point where the two columns meet. Then they are z-indexed behind everything.
I don't know how the rest of your site looks, so I left the rest a bit arbitrary. The background color columns have a fixed height, right now at 200vh.
When doing responsive designs I often need to have a percentage margin horizontally, but vertically I usually don't want to have percentage, but rather fixed pixels.
Are there any reasons why I shouldn't be mixing units in my margins and paddings like this:
margin: 10px 10%;
Browser performance? Cross browser rendering issues?
As long as you're maintaining that vertical is pixel based and horizontal is percentage based, you should be fine. Just don't mix the two (at least not within a single element), or you'll get undesired effects across the board.
I have this working fine: http://jsfiddle.net/uwcEw/ - a traditional border layout on css.
What I want to do is have another 5-region border layout within the "middle" of the border layout. Re-applying the same pattern from above I get this: http://jsfiddle.net/6bked/4/ (edited link), which does not work, clearly it is not relative to it's parent container, but i'm not sure how to fix this so i can apply this pattern as needed in a nested context.
Any help? Also if there's a better way to do this (Compass+Sass/blueprint/js layout) I'm open to suggestions.
UPDATE
I also wanted to make clear I only care about this working in modern browsers (Webkit, FF) mostly concerned with Webkit and I am not worried about users who don't have javascript enabled
I'm not exactly the biggest fan of fixed layouts, but if I understand correctly this should be what you're trying to do: http://jsfiddle.net/8Cq9A/.
The dimensions are relative to the browser window, even the nested set of div's. What you needed to do to fix your layout was adjust your inner dimensions taking that into account. For example if your outer left and right div's widths are set to 10% (meaning 10% of the width of the browser window) to split the center div into 2 equal halves, you'd set each of their widths to: (100% - 10% - 10%) / 2 = 40%.
Personally, I'd look into using floats: http://jsfiddle.net/Sf8Kp/. The issue you will run into here though, is if you're wanting equal height columns as seen in the link.
There are MANY articles floating around on how to tackle this though. A few good reads that have been around for a while: alistapart (1, 2), positioniseverything. Search around for faux columns and 3 column [liquid|elastic|equal height] layout.
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.