the gophers
… are exposed.
While stress-testing this layout, I found some weaknesses on larger screens/windows when using the text-only zoom option in browsers. While none of these weaknesses broke the layout, it could do better.
A max-width
in em
allows page to grow horizontally
with text-size settings in browsers. That behavior needs stress-testing, again…
No problems with text-zoom up to 125%, and not too bad at 150% either. Above that it could do with
some improvements, and fewer properties declared with pixel values.
So, here I am exposing the various tiny pixelated and/or misaligned “gophers” that
have been hiding underground in my stylesheets and made perfection a bit hard to achieve. Not that
perfection is a goal in itself, but I certainly don't mind if web pages appear more or less as intended even when
stressed.
To max out page-width for stress-testing, I increase text size in browsers in steps up to beyond 300%, and zoom down whole page till space shows up on both sides for each step. This way I can roughly emulate browser-windows up to at least 4000px in width, and at the time of writing there aren't all that many computer screens with such a large size/resolution on the market.
I expect most of those who want increased text-size on larger screens to apply whole-page zoom, but the idea
behind this stress-test, and following corrections, is that text-only zoom should work acceptable for those
who prefer that method.
Tested range: 62.5% to 300%, based on default (12pt/16px). Can not make any promises beyond that range.
NOTE: Default font-size
for this main article section, is 107%
of your browser's default text-size setting, whatever it happens to be. Declared font-family
is
“Georgia”, and text softening is applied.
issues found and dealt with…
#1:Side-notes – the right-side column on regular screens
– had a max-width
in px
. Not the best choice when text-size is increased much
beyond default, as the column looked pretty slender and left lots of unused white-space on wider screens.
Redefining the column's max-width
in em
fixed the problem. But, as it
is a faux column with width
defined in %
, a number of generated content
elements had to be tuned individually to line up with the content-container to create the intended illusion.
(Several gophers had buried themselves in those alignments, but most of the problem-causing ones are gone
now.)
Main article containers have been limited to around max-width:41em
since the site
went on line in 2011, and now the side column follows suit with max-width: 27em
. With default font
size settings in browsers the modification equals the max-width
in px
I used
earlier.
The site also has a min-width: 28em
declared on body
, that is smaller than the
px
defined break-point between “wide screens” and the one-column “small screens”
styling for mobiles. Thus, the min-width
will only kick in when text-size is increased in browsers.
#2:Images – especially the smallest ones – may not look like much when left at inherent sizes while text gets blown up around them, but that isn't a design-flaw. This is how text-only zoom should work.
Although there are images that are styled to auto-resize with their containers regardless of cause – also
on this page, not many images will resize with the text on this site. Only in very specific cases do I use
em
for sizing images with text, as doing so goes against the whole text-only zoom idea.
#3:The visual header definitely shows up a little less crowded when text is blown up on wide screens. The birds look undersized and somewhat displaced on a full-scale cloud background, and the image in the main article-headline lined up too far above its own headline.
The birds show up as they should under those conditions, but I modified some of them to scale to get a better overall balance. Images in main headlines are just not raised as high on widest screens – reduced negative margins.
The cloud background didn't scale properly all the way, so had to redefine an @mediaquery
min-width
in rem
for it.
#4:The signature, and image of me, down at the bottom of main article, would not work at inherent sizes when text is blown up. Had to revise styling for that area.
Those are two of the very few images that are sized in em
, and images and text are lined up using
calc()
for some properties.
#5:The “gunlaug.com” (with link) in upper left header corner, was a background image that didn't scale well, and leaving it at original size wasn't an option.
As it is the site-name rather than a logo, I replaced it with generated content
using real
text (with background images). This not only solves the problem with text-zooming, but also looks better overall.
The “home-page” link is overlayed and defined to scale with font-size
, to appear to be
part of the visual header.
#6:Still a few details that should be fine-tuned to work
optimally with text-only zoom as well as whole-page zoom, but it will all be done, sooner or later.
The following details are pretty much done…
Written content is taken care of, with my favorite text softening technique modified so it doesn't create unwanted effects for large fonts.
Most images, separators and other decorations are left at basic sizes tuned for default font-size (12pt/16px) on the 800px to 1400px wide screens they were optimized for.
Rounded corners on images are defined in px
, and these will not be changed. Same
goes for rounded corners on page elements, as these shall not reshape with text-zoom. Sharp-looking corners are
OK. An exception is the navigation buttons near bottom of page, that have corners, borders, box-shadows and
text-shadows redefined in em
to make them stand out regardless of zooming method.
Headlines rely on text-shadows to stand out, so these are redefined in rem
to follow text-zoom.
By not having shadows relying on the font-size of the headlines themselves, one definition
covers all headlines.
excuse me?
The text-only zoom option may not be much to spend time on now that all major browsers have properly working whole-page zoom, but I needed some time off from more serious on-line matters.
Stress-testing always reveals weaknesses in web designs, regardless how well they are coded. Haven't run into a single design that cannot be broken somewhat by applying regular browser options on them, and mine are no exception.
No real surprises found in my layout/design, but I have made every possible mistake in the past, and
should have learned enough by now to avoid repeating them. This handcarved design should work flawlessly under any
conditions, don't you think?
Apparently that is not the case, but the flaws can be corrected…
sincerely
Hageland 13.aug.2016
none
last rev: 17.aug.2016