I'm trying to make my own grid which does fit al my needs but I can't find a way to make it the full width at Safari (Mac & iOS). It works nicely in other browsers (Chrome, Firefox, IE10) but in Safari and Safari mobile it leaves a space on the right side.
Are there any solutions for this? I'm a pixel perfectionist so this frustrates me so much.
Image preview:
Demo: http://codepen.io/PatrickVerwoerd/pen/wImcu
This is a sub-pixel rounding error. It's common in any fluid layout, but becomes most obvious when you do the same math over and over (12 equal columns in a row). When you have a fluid layout, there are times when your container (as measured in pixels) doesn't divide evenly by the % you set. Say the viewport is 966px wide, and your columns are 10%. That means each column should be 96.6px wide. Browsers just don't know what to do with that partial pixel. If you resize your container, you'll see that the layout jumps now and then, and lines up exactly right when the container is evenly divisible.
It's an old problem, and browsers have mostly been getting better at handling it. IE used to round up, which caused even worse layout problems. Now, most browsers are smarter about it, but Safari still rounds down.
There's no way to fix the problem entirely. There are no pixel-exact, fluid, floated layouts, but there are several work-arounds. I start with the simplest, and work my way through the list:
When possible, avoid repetitive percentages. Any one element will only ever round down a partial pixel, meaning you never have more than 1px error at a time. If you don't stack the errors, they are easier to hide.
Float the last item in a row to the right. That moves the rounding error in-between columns, where it is generally less noticeable.
If you really can't minimize or hide the errors, in a gallery-style layout for example, try Jon Albin Wilkins' float isolation method. It's a bulky approach, so I don't recommend it everywhere, but it can be real helpful in some cases. Layout systems like Susy and Singularity will also give you that as an option.
With a combination of those techniques, you can keep all your rounding errors to a single pixel. If your designs can't handle a single pixel rounding error, you shouldn't use fluid floats, or you should maybe consider the Dao. :)
The issue is that SCSS in the CodePen is calculating the margin and width to a certain decimal level.
/* Actual Math */
53px / 966px * 100 // = 5.486542443%
/* Codepen Math */
53px / 966px * 100 // = 5.48654%
As you can see the remaining decimals are ignored and therefore your grid is technically not adding up to 100% and therefore a space at the end.
It seems the other browsers are compensating for that by assuming you mean to extend the full 100% whereas Safari is being more accurate (whether that's the correct appraoch will depend on what you're trying to achieve).
Related
I'm using Electron to try to make a native app. The interface has an image of a scanned document as a div background image, with the OCRed text as content. I'm able to match almost all the styles of the scanned document (to a degree that satisfies me, anyway), but line-height is problematic.
The correct size of the font seems to be 10.5pt. When the line-height is set 100%, the content text is a little too high and the text drifts beyond the scan. Set at 99%, it's too small... and 99.5% doesn't seem to make any difference in rendering. This isn't a problem with using percentage values either, as I find the same thing occurs whether I use pixel values, em, or whatever. There are values that cause different rendering, and any fractional values between those are ignored.
If I use the magnification/zoom on this (control-+), fractional values start working, but fail once I've unzoomed.
Are these values being ignored by Chrome, or is it something else which causes this behavior (my montior's dpi, some aspect of font rendering in general I'm dumb and don't understand, etc)?
Is there a work-around for this? I don't need pixel perfect matching on this, but the difference amounts to about 3 lines worth of text, which isn't close enough for my purposes.
I've been working on an interface for a website. I'm stuck on a simple thing that I've spent hours and not get it fixed. I'm giving the prototype of my project. When you zoom in to page or minimize the page the alignment gets messed up. How do I fix that?
http://www.thewebblog.net/server/sosyalagDenemem
You are using floats and this is how they work. As many as possible will fit on the same row and the rest will wrap below. When the container is resized, any floats that fall off the edge are again moved below.
The easiest band-aid solution would be to add a wrapper div with a fixed width which is large enough to fit all of your floats without wrapping, or at least a min-width. Note that this will cause a horizontal scroll-bar on any window smaller than this width.
If by "minimization" you mean window resizing, it is because you are floating those columns. There are two ways you could go about fixing this.
1) Make your website responsive. You can find tons of information online about this, but here are some resources to get you started:
Ethan Marcotte's Dao of Flexibility talk
Looking Beyond Common Media Query Breakpoints
2) Add a min-width to the <div> that contains all of your floated elements. Make sure the width is more than all of your floated items lined up. This will make sure that if the window gets smaller than the container, instead of pushing those elements below each other, it will just keep the container from getting farther and create a scrollbar.
Note, this isn't necessarily the best way in terms of designing for mobile, tablet, etc., but it will certainly keep your site from breaking on "normal" desktop monitors. If this is your only target audience, then there's no problem with it.
An example of this would be:
.container {
min-width:960px;
}
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
what is the difference px,em and ex?
I have a question for all the coding geniuses on StackOverflow.
I am a newbie, and I am about to start building my third website. Being that I had some problems with the layouts of my first two websites, I am asking this question before I start on my third:
What measurement is it best to use for
the css elements? Percents,EM's or Px?
Which form of measurement will ensure that I have a site that will not get distorted on different browser sizes/resolutions? Is there anything else that I have to be careful of when building my site so that it will not get distorted when a user zooms, or looks at the site from a different browser size/ resolution? (as was he case on my other sites)
Thanks for your time, guys. Any help would be greatly appreciated!!
Thank you.
Whichever is easier for you to work with.
Modern browsers (i.e. everything in use today except for IE6 and IE7) have a concept of "CSS pixels" which is different from "actual pixels," so e.g. zooming changes the size of a "CSS pixel." Fonts will scale just fine; if you say the font is 14px, it will start out that way, but if the user zooms it'll get bigger. Thus, if it's easy for you to measure in pixels, for example to size page elements relative to an image of a given pixel size, you should do pixels.
Sometimes you want to size things relative to text, though. If the width of an em-dash is a useful measurement, somewhat representing the "longest possible character," go ahead and use ems.
And finally, if you're trying for a fluid layout, percentages can be great: a gradient that starts fading 50% across the page is often what you want, as opposed to one that starts fading after some fit number of pixels. Even if you're not fluid, and the width of your container is fixed to e.g. 900px, it's still often useful to say "this goes at the 50% mark" or "I have one thing at the 33% mark and one at the 66% mark." That's much easier to work with than figuring out what the corresponding pixel offset is every time, and makes your intent clearer to anyone reading your code.
Short answer: it depends.
Longer answer:
There is a place for all three units, frequently in the same design. There is no "best" unit; they serve different purposes.
Pixel units generally offer the most precise control over the size of the elements in the user interface, but also restrict that size such that it does not change with regard to the other elements of the page design. The size of pixels themselves may change. For example, a Retina display packs more pixels into the same physical space as a non-Retina display, so images which were designed for traditional displays get scaled up. Similarly, traditional desktop web browsers may adjust the size of pixel in response to the user zooming the size of a page. In these cases however, the pixels change sizes throughout the entire document, and retain the same proportions with regard to one another, so you can use px values and expect them to work sanely in most conditions.
EM units vary according to the size of the text. They're most commonly used for setting the size of text, and for line heights; but there have been some interesting things done with "elastic" layouts such as the elastic lawn zen garden (turn off page zoom for this site; switch to text-only zoom and change the size a few times).
Percentages vary according to the size of the containing element, expanding and contracting depending on how much room is available to them.
And, really, it's very common to see web designs that use all of these. For example, suppose you have a site with two columns. The main column must expand and contract with the browser width, but the secondary column needs to stay the same width. The main column might have a width of 100%, but also a margin set in pixels for the secondary column to float in. And the text and line height might be set in ems.
So, the real answer is: they all have their uses. Keep practicing, and pretty soon you'll figure out how it all fits together.
EDIT: In the example above, I should have said "a width of auto" -- meaning take up all available space after margins, padding, and borders are accounted for. Sorry, I tend to think of that as a percentage even though it's actually a keyword.
from accessability point of view need to use EM's. You need you layout to adapt to very different fonts sizes so if allmeasurements are in EM's everything will scale as accessability tools increase font size
When creating liquid layouts, it makes sense to use percentages for the widths of your blocks, so they shrink and grow with browser size changes.
For heights, pts have a specific spatial value, and em are related to your current point size. This is useful because things specified in those units will be roughly the same size on everyone's display (unless they have different zoom factors applied). em are also useful when working with a dimension driven by an amount of text.
Browsers will also scale values specified in pixels, so they are not any more a "trap", but they are rarely the "natural" choice for layouts, unless working with raster images.
As Will and Domenic say: use all three, when appropriate. As you get more experience, you'll get a better feel for when to use which.
If you want to design a fixed layout website then use px or em.
If you want to design a fluid layout website then use percentages.
Percentage is always relative so page content with dimensions in percentage will automatically resize on window resize and on different screen resolutions.
px and em are one and the same thing. Same in their nature. They define the absoluteness of the dimensions. Btw for the difference, 1em=current font size. So if your html or body has css font-size:19px; then 1em=19px.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Evenly distributed height of child elements with CSS
Lets say i have a design with 6 DIVs that are float left with a width of 16.666%.
So the document size is splited in 6 parts.
Now if i have a document size of lets say 620px wide this would make each part 103.333px. Since i don't know screens that can show partial pixels :) I wonder how the browser handles the partial pixels.
Here is my testcase:
http://jsfiddle.net/dhQh2/ (Just resize the window to get a result)
When resizing it seams that the 6 DIVs keep the same size. But it some cases it can't be. How does the browser handle those partial PX values?
If, for example, you're using a % width, and the exact width should be 103.333px, then the browser must make a decision on how display that.
Different browsers make different decisions, read these links for more information:
http://ejohn.org/blog/sub-pixel-problems-in-css/
http://elasticss.com/determination-of-algorithms-used-for-percentage-based-rounding-divs-on-browsers-and-css-frameworks/
I particularly like this explanation from John Resig/David Baron of why this is even a problem:
I was talking this over with some
Mozilla developers and David Baron
explained the situation quite well:
We’re trying to meet a bunch of
constraints that can’t all be
satisfied at the same time (the proof
is left as an exercise to the reader,
though I may have actually written it
out once in a Bugzilla comment):
4 adjacent objects of width/height 25% (for example) starting at one edge
of a container should end exactly at
the other edge; there should never be
an extra pixel in the container and
they should never be wrapped due to
being a pixel to wide
objects that are logically adjacent should always touch visually; there
should never be a pixel gap or a pixel
of overlap due to rounding error
objects given the same width should occupy the same number of pixels
object boundaries should always (visually) be aliased to a specific
pixel boundary in the display (they
should never be blurred)
The one [Mozilla] sacrifices is
typically (3), except for borders
where we sacrifice (1) by rounding the
widths to pixel boundaries much
earlier.
See this question for a JavaScript fix that forces consistency:
Evenly distributed height of child elements with CSS
Another relevant question:
Are the decimal places in a CSS width respected?
They go in the heaven of pixels ;)
Just joking. Most likely different browsers deal with it in different ways.
The first approach coming in my mind, is to calculate the width of each area. Then round it to the nearest int. The rest of the pixels gets just left empty.
Another approach, could be filling the last area, whatever it is the width (with a small margin of errors).
Very interesting question: it could be nice to have the control over this behaviour with css indeed.
See this post:
Are the decimal places in a CSS width respected?
Depending on what browser you are using changes what happens. Some browsers may round the value. Some force it to round up (math.ceil in some langauges) and some round down or "truncate". For example, Google Chrome truncates the decimals.
You can easily test the effects of this by print screening and then later checking the size in a paint editor (paint, paint.net, adobe photoshop, etc.)
Very interesting question, however :)
Firefox 4:
THe div around these 6 divs has a border. When you slowly resize the whole window you see that the border "jumps". This means all the divs have the same width, but the sum is less/more that 100%.
When you resize just the containing div pixel by pixel, you see that not all the divs change the width simultaneously.
I've been working on a personal website (so, time is not an issue here) and I made a base stylesheet where I take care of all the font-sizes, border-widths, line-heights and the like.
I made an effort to use ems all the way, but when I tested the website on other browsers (eg. Chromium) the content didn't match my "pixel-perfect" grid.
So, my question here is, should I use px instead? I mean, I know ems are "the way to go" but nowadays most browsers implement fullpage zoom (they don't resize just the text) and when it comes to dealing with border-width and line-heights, px are more comfortable, because I can avoid subpixel rounding altogether.
What's your take on this? (btw, supporting IE is not one of my goals; i couldn't care less about it)
the content didn't match my "pixel-perfect" grid.
If you're working with a pixel-perfect grid, use pixel values. em is a relative value that works well only if the layout is able to adapt to different content sizes.
I would use em only for elements which size depends on font size.
Elements like borders (and its width) usually does not depend on font size.
When using em for margin and padding, I've found that the relative measurement can do some funny things.
The em can accumulate in nested elements and you find yourself bumping some values back up to align them with outer elements.
This looks fine until you shrink the browser window in very slowly and find that sometimes the values for the nested elements round to a pixel different to the outer parent.
To combat this, I've used rem at the parent level to set the font size and found that this allows parent and descendents to work from the same base relative value.