I heard that relative units are better then absolute, but sometimes browsers round it wrong and it's hard to calculate. Do you know any tool that can help?
I used SASS/Compass. It's good and very easy, but not perfect…
As per the comment, “vertical text rhythm” seems to refer to line grid. Line grid has generally been ignored in CSS, largely because it is mostly relevant in print media and in multi-column text layout. Basically, the way to make things snap into a line grid is to use consistent sizing in vertical direction, using the same units. For example, if you set line height in em units, set heights and vertical margins in those units, too. To make an image fit into a line grid, wrap it in a container with a height in em units. Alternatively, do all vertical sizing in px units.
It is true that rounding may cause problems, since em dimensioned things ultimate get converted to pixels. So if you set line height to 1.3em and in image container height to 3.9em, the latter might not yield exactly 3 times as many pixels as the former but one pixel less or more. If this is crucial and you consider using pixels, remember that a CSS pixel need not correspond to a physical pixel in a device.
In CSS Line Grid Module, currently existing as an Editor’s Draft only, there are properties for using a real line grid. They have been partly implemented in Chrome, with the -webkit- prefix. If a line grid is desired, it can hardly hurt to add code that tries to snap content into the grid and may do so in Chrome:
body {
line-grid: yourNameForLineGrid;
line-snap: baseline;
-webkit-line-grid: yourNameForLineGrid;
-webkit-line-snap: baseline;
}
Related
I’ve been working on this for over 10 hours, searching the web for a solution, to no avail.
Here is the screen capture of the sketch:
I need to produce a grid layout with the following requirements:
The whole thing is in a horizontal scrolling layout.
Responsive in height, relative to its container (which is already responsive relative to body, using the Stretch-to-margin technic).
3 lines of equal height (33.333%)
Composed of square images anchors
On mouse over: color overlay with white text
The square images need to keep their proportion (reduce the height of the window, image width must scale down.
The width of the whole layout must be dynamic, since the number of squares may vary.
I’ve seen tons of examples where the width is defined, and using the padding-top value to define the height. It would not work here since the Height is the defining value.
I will be posting again with updates tomorrow.
I’m kinda desperate. Thinking of taking up drinking (kidding).
The Question is Answered!
I finally used the "vh" unit, and applied it to HEIGHT and WIDTH of all the squares.
Goes something like this:
.c-squares{
width:30vh;
height:30vh;
display:inline;
}
So clean, can’t believe I’ve never knew about "vh" unit.
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.
When working with multiple resolutions, the "em" based approach seems a good way to code your css file. However, if you have say two resolutions 480x800 & 540x960, then the width ratio ( 540/480 = 112.5% ) is NOT same as height ratio ( 960/800 = 120% ).
So, if I have an em font size = 112.5% for moving from lower resolution to higher, the width seems perfectly aligned to new resolution but height ( which expects font-size of 120% ) seems to fall short and therefore there is a white blank space created at the bottom after rendering all elements for the page.
Any solution to this problem would be great help.
em is a unit of choice for fonts, not so much for element dimensions. With it evaluating to element's font-size, it's simply not reasonable to be setting widths using this unit.
You may be trying to refer to a vertical rhythm, which is a concept of maintaining text readability and should not be confused with the rest of the page layout.
For aesthetically pleasing rendering under different resolutions, you should look into fluid layouts - try playing with the browser width on that page. As you can see, the content flow is altered to make best use of space available, however the font size/line-height are not adjusted since the two techniques are independently implemented.
Should i keep #wrapper{ width:100%} in print css? because on screen my design is a fixed width design 960 px. but there are so many paper type and sizes in the world and anybody can take print on any size paper, bigger and smaller.
So if in print css i do not specify relative width then i think print of page will cut of from right size if user will take print on the paper size which can smaller or larger width than my site #wrapper width (960px). then it can create problem.
http://www.dpandi.com/paper/index.html
printer also leave some margin when printing.
So should keep everything is relative size in print css?
update:
And should i also change float left or right to float:none in print css?
Yes, you should. If you stick to a definite pixel size, you could even run into a situation where different visitors could see different amounts of the page cut off because of their printer DPI and/or browser. You might want to also consider adjusting your font sizes to be relative as well (using em or %).
Word of caution: make sure all your elements flow correctly when you switch over to a relative width, or you could have other parts of your content cut off or pushed into strange places.
The browsers tend to translate pixels to a similiar size before sending to printer, so it will look similar to what you see on screen. It will not send the pixel size to the printer.
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.