the gophers

are exposed.

While stress-testing this layout, I found some weak­nesses 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 hori­zon­tally 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 improve­ments, and fewer proper­ties declared with pixel values.
So, here I am exposing the various tiny pixe­lated and/​or mis­alig­ned “gophers” that have been hiding under­ground in my style­sheets 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 them­selves in those align­ments, 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 modifi­cation 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 regard­less 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 condi­tions, but I modi­fied some of them to scale to get a better overall balance. Images in main head­lines 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 “” (with link) in upper left header corner, was a back­ground 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 opti­mally 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 modi­fied so it doesn't create unwanted effects for large fonts.

Most images, separators and other deco­rations are left at basic sizes tuned for default font-size (12pt/16px) on the 800px to 1400px wide screens they were opti­mized 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 head­lines them­selves, one defi­ni­tion covers all head­lines.

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 weak­nes­ses in web designs, regard­less how well they are coded. Haven't run into a single design that cannot be broken some­what 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 hand­carved design should work flaw­lessly under any condi­tions, don't you think?
Apparently that is not the case, but the flaws can be corrected…

sincerely  georg; sign

Hageland 13.aug.2016
last rev: 17.aug.2016 advice upgrade advice upgrade navigation