loony lineup…
some variations across browser‐land.
We all know that flexible layouts will never result in perfectly
identical lineups across browser‐land. Makes sense to jot down
a reminder though.
Here we have the 5 major browsers' attempt at rendering a page on this site in a 940px wide window – arbitrary chosen dimension. Borders are added on elements to make it easier to see how they line up columns and content. Right page‐edge is used as common guide‐line.
“Close enough for comfort” is my motto regarding web design (and most else), and I think the result is acceptable. A little more than ±1px deviation, which is what could have been explained as rounding errors.
I guess those rendering engines can't do any better with composite and responsive designs in 2012. Give them another decade or so… ?
crossing the divide.
What looks a bit like the Tower of Babel, is the same lineup. Parts of
the previous image blown up to 200%, and here I am focusing mainly on the
divide between main section and side‐column since that tells everything
about browsers' calculation models.
Only the content‐carrying side‐column container – red border – has been adjusted 1 or 2 pixels in individual browsers to line up more or less as intended with the edge of the visual layer – black border. Lineups of the black and the blue border, and the width of the divide between them, are the results of all browsers handling identical styling.
Left side of the divide – with blue border, is a float
(float: left;) containing main article. Right side of divide
– with black border, is the visual layer for side column (position:
absolute; right: 0;).
Testing lineup‐spread across browser‐land for pages on this site now, will yield different results. Browsers are hacked for slightly better consistency since these screenshots were made.
complicated series of calculations.
What is causing the varying lineup is how the individual browsers' rendering engines calculate width, margins and paddings declared in “%” for these elements that have their “zero edges” at opposite sides of a page that itself is sized in “%”, and how they round up or down to hit actual screen pixels.
So this lineup actually isn't too bad – on paper at least, as all browsers can be argued to be within the ±1px that we have to accept when declaring dimensions, margins, paddings and positions in “%”, and mixing in “px” and “em” values here and there.
If we accept that they are within ±1px, then none of the browsers get the lineup right as they all place the black border on either side of an imaginary zero line. If either group of browsers are right on the spot, then the others are 2px off.
Of course, if we also look at lineup of pictures on both sides, and take into account that images on the right are lined up relative to the individually ±1px adjusted red border, the loony lineup across browsers and screen pixels is far worse. And, on window widths other than the one I use for lineup on here, it doesn't get any better.
Figuring out which browser that rounds the right way for each calculation they have to perform in order to render a responsive design like mine, and which one that ends up with the most correct total screen rendering for a page, is hard. I won't call the challenge impossible, but until screen resolutions increase significantly I don't think it is worth the effort for us web designers.
no big deal.
I find large variations in alignment of elements between browsers irritating, but in practice it rarely ever matters. Apart from web designers and “specially interested”, few bother to compare between browser. Thus, it only has to look alright in each browser by itself – which I think my layout does.
Only have to check stress‐tolerance on sites where the creators claim to have achieved perfect alignment of design details in any browser, to see why I am not too “obsessed” about cross‐browser perfect alignments. Most such sites look like they're stricken by a disease when subjected to the slightest amount of stress, but so what… ?
I have to conclude that existing rendering engines are not very precise on calculations, and simply leave it at that since I won't attempt to program up a better one.
Would be nice if they left out all superlatives regarding rendering in their promotions though, since according to my more in‐depth tests (a couple can be found in addendum) none of them comes even close to living up to them.
sincerely 
Hageland 11.jul.2012
15.jul.2012 - included 2 tests in addendum.
18.jul.2012 - added note about browser hacks for better consistency.
last rev: 18.jul.2012
side notes.
more than meets the eye.
This side‐column – with red border on the image, is a float pulled out from after the main content blocks, and layered on top of a visual layer – with black border on the image.
The visual layer that is seen as side‐column with “brushed
aluminum” surface, is CSS generated content (:before). This
visual layer is absolute positioned relative to the page container so it grows
and shrinks with width of browser window and amount of content in the page as
a whole – a form of “faux column” that doesn't rely
on markup or background image.
Layer‐alignment of such a composite construction should be straightforward for browsers, but again, there is more to it than can be seen on screens. To get the alignment “close enough for comfort” in a responsive design like this, all browsers needed individual horizontal offset for this content‐carrying float on right.
Real variation across browser‐land is ±3px on side‐column construction alone, which I think is too much.
Could have done a lot more to make it appear the same across browser‐land, but then any future changes in how browsers “split the differences” to hit screen pixels at varying resolutions, may cause real problems.
hack with care!
Ideally one should not hack browsers – at least not reasonably new browser versions, as no matter how it is done it is not future‐proof. Minimal corrections can be quite OK though, as long as the layout/design don't depend on them.
Always interesting to see sites that was hacked in minute details to
“render perfect” across browser‐land a few years ago,
and not followed up on as new browser version arrived. Needless to say most of
them do not look too impressive now.
Only browsers that are at least a couple of generations and years old, and for which we have well‐known hacks that won't ever affect later browser versions, is it reasonably safe to hack. And, of course, we only bother to hack older versions that still have a significant number of end‐users, as hacking totally obscure browsers launched more than a couple of years ago, is nonsense.
After all that being said; playing around with minimal hacking of
rendering engines is often the only fun part of designing/coding web sites, so
why not have some fun. Show great care and pay attention to potential
consequences, and hack happily away at those browsers.
improved screen resolution?
Today (in 2012) I will regard screens in sizes from 17inces up with
a resolution of 300dpi and higher, to be “high resolution”.
Have yet to see one “in the wild”, but 300dpi is only about
4 times (4×4) the resolution computer screens had back in the late ‑80s
early ‑90s, so I find it reasonable to expect that much progress in
the making of screens over a 20 year period.
Resolution has increased some more on SSR devices than on larger screens in later years, but seems like “high resolution” screens on smaller consumer devices is also still just a dream.
For my birthday I want a 60inch screen with 450dpi or
better resolution. Should not be a problem, apart from what future birthday
it will be. Not sure if I can wait that long – Jakob Nielsen's
Alertbox, July 2, 2012 predicts 20 years, but then I won't need one
either so that isn't my problem.
