about the page layout

basic 2-column

I started to test out this very layout back in the fall of 2008 – as this template on my other main web site shows. Had nothing to use that template for back then though, as the site it originated on already had and still has a pretty heavy construction made in 2003 tailored to keep styling for IE5.5/6/7 easy.

This “new” layout has too light a construction and too high demands on CSS styling to make anything easy in IE7 and older – not enough elements to hang their many bugs on. Thus, I “stored it” for a later project.

Now, a couple of years later, that project is a reality with this new site, and with the demise of IE6/7 everything has become so much easier.

The HTML source-code is structured for a very basic 2-column, without actual header but with a “fat footer”. You can find similar layouts everywhere, and there is nothing very smart or ground‐breaking about mine.

It is its simplicity and adaptability when styled for the latest and most standards‐aware and ‑compliant browsers, that in my experience gives it “a responsive edge” over the majority of layouts found across the web.

conditional elastic™

I prefer web pages that adapt to the browser-window as well as possible on all screens and devices. At the same time I don't want too wide or too narrow text-lines, so there has to be limits.

The page and its elements will become as wide as possible but not wider than the browser-window or the max-width – whichever is smallest in any given browser on any given screen. A few mediaqueries keep track of the space needed for this layout across varying browser windows and devices, and introduce adjustments at logical crosspoints to handle stress and preserve optimal access to content.

When “em sizing” of main elements is used, we often refer to the layout as “elastic” as it expands and contracts with font-size. My layout becomes “elastic” only if given enough window-width, as a width:100% and a max-width:84em on outer container give it a “conditional elastic™” upper limit.

As font-resizing may make text overflow container-elements and be cut off at the edge of narrow browser windows, the page's min-width is redefined from px to em on windows narrower than 660 in width. This forces the page to become wider if font is sized up too much on narrow windows, producing horizontal scrollbar if/when necessary to preserve access to content. Thus, the lower limit is definitely “conditional”, and also pretty “elastic”.

small screens/devices

Nearly all that can be seen and interacted with on larger screens/​devices, is also made available for small screens/​devices. Only elements and functions that either won't work well or just take up space for no gain on small screens, are hidden or removed.

The transformation to a 1-column layout that in my opinion is best suited for very small screens, takes place at/​below 643px window-width. There are 3 steps with minor adjustments for 1-column, down to the absolute lower limit at around 140px window-width.

Browsers on small devices must either adhere quite closely to existing web-standards and my styling, or they simply have to do a decent job at re-styling my pages for small devices on their own, without my help.

As web designer I am quite agreeable, and it doesn't really matter much to me what my web pages look like on mobiles as long as visitors using such devices are happy with them.

As of 2020, actual testing on/​for mobile browsers is per­for­med with Vivaldi on Android soft­ware.

addendum on most pages

I chose to take the unusual step of attaching an addendum to/​below the footer, to have a space for additions to the main article and for larger images. Different layouts can be “injected” into the addendum, giving me freedom to put anything down there without bothering about restrictions I have placed upon the main page‐layout.

The addendum is by default closed on all but a few pages, as I realize not every visitor is interested in going through long pages. The addendum button is at the very bottom of the regular page – below main navigation.

To draw attention to the addendum opening button, and to indicate what can be found down there on any given page, icons (small images) are generated at the right end of the button where applicable. The following icons are in use…

  1. general info and “legal” stuff.
  2. light additions and general info.
  3. more pictures and text.
  4. more to read on the article-subject.
  5. more pictures.

Older browsers may not support generated content, but the addendum button works the same in most old and all new browsers with javascript turned on.

page zoom makes font‐resizing irrelevant…‽

Not so fast. I have used “page zoom” for more than a decade in Opera – long before other browsers adopted that feature, and have always applied font-resizing. Setting “minimum font size” large enough to be able to read stuff on web sites was necessary 10 years ago, and is just as necessary today the way so many web designers/coders keep on cramping unreadable small text into web pages.

Of course: clueless “web designers” will continue to implement designs that make web sites unreadable and inaccessible no matter what. Thus, often the only way to access a site with modern browsers on modern screens/​devices, is to ditch their designs by turning off CSS support.

This very layout takes all existing options in major browsers into account – also the ones most end-users and web designers either don't know about or choose to ignore. This broad approach assures this layout “just works” in major browsers – within reasonable limits, and I have never found good reasons to ignore or try to disable any browser-options.

image control

Regular web images usually only look good at inherent size and smaller, so I only set max-width on images so they don't overshoot their containers' width (whatever that width happens to be). I do that by declaring max-width for images in percentage(%).

In addition to a general rule of 98% as max-width for images, there is a series of classes stepping down to 15% max-width spread around on images that should not be allowed to fill their containers for whatever reason.

As of 2020 styles are added to make selected image- and text-con­tainers over­shoot the width of main con­tainers on both sides, which this is an example of. Most effective on large screens, as mobiles do not provide much space to over­shoot onto.

Apart from general optimization of images for the web – small file-size and all that, images are not tuned for such resizing. Most images take down-sizing well, but the odd image may degrade a bit too much for my liking at certain down-sizes. Replacing and/or rearranging is my solution if it looks too bad.

added features

To facilitate presentation of whole series of reasonably large images with text in addendum, in the summer of 2012 I marked up and styled a “simple CSS slideshow” I called sketchbook (named so because of its styled appearance).

Pure CSS slideshows like sketchbook don't “slide” in older, less CSS capable, browsers. No big deal.

I needed a “looping CSS slideshow” for images and/or text for a project, and then also coded up the very flexible Sketch which can be used anywhere on my own site. Typical example of Sketch is found in sidecolumn on ToC: articles, and you will notice that it is “looping” – has no apparent beginning or end as you click through the slides in either direction.

Sketch is intentionally styled so it won't show up in most older, less CSS capable, browsers since they can't handle it anyway. Again: no big deal.

More features get added when I find suitable uses for them. No features are added for their own sake on my site.

HTML/CSS standard(s)

From the autumn of 2013, mixed markup is spreading throughout this site. In essence this means XHTML 1.0 and HTML5 markup are both used, and also the “in-between” variant of XHTML 1.0 markup under an HTML5 doctype can be found.

As visitor you should not notice any difference, as all HTML variants are served/​styled with the same stylesheets – selecting the general XHTML 1.0 and the more specific HTML5 element chains using CSS forking.

Stylesheet arrangement behind this site may seem increasingly complex, as flexibility slowly takes over for optimal efficiency and a more modular model for adding and modifying styles spreads. Going from a few large stylesheets into more fine-grained CSS modules has many advantages though, so that is the way I'm going.

sincerely  georg; sign

Weeki Wachee 15.feb.2011
last rev: 05.may.2021

side notes.

responsive web design?

Yes, most defi­ni­tely.
I have marked up and styled web sites in ways that fall nicely into what is now known as “responsive web design” (RWD), for the last 10 years or so. Now that browsers on large and small screens and devices are finally responding more or less correctly and as I want them to, I see no point in changing methods.

I do approach layout/​design “slightly backwards” compared to general RWD wisdom, in that I do not lay out and style for mobiles first and then restyle for larger screens. Rather I start at medium sized screens, and switch style­sheets between medium and small screens.

In reality these apparent differ­ences in working order makes no difference for the outcome. It is only a question of web design semantics and the ways our minds work, and also makes for lighter stylesheets for the smallest devices and heavier for the medium/​large.

styling for LYNX…

… is of course impossible since LYNX does not read stylesheets. Never­the­less, as frequent user of that and other “text only” browsers, I do take rendering in such browsers into account when laying out and populating web pages.

LYNX renders linearly minus graphics, and this “raw HTML rendering” does not allow for much in the way of “unorderly markup” tricks to facilitate fancy CSS styling. This does of course explain why I organize markup and content the way I do, to be natur­ally acces­sed linearly.

It then becomes easy to style for respons­ive­ness in graphic browsers across various window sizes, while split­ting and spreading content in columns or groups as design dictates and space allows for.

Weak and buggy CSS support in graphic browsers, will always complicate coding of web pages. NO CSS support is easy to deal with though, and weaker graphic browsers usually play along a lot better when the source-code is clean and well organized.

minor details…

Example 1: We can absolute-position generated content, using ::before and ::after, any­where. Plenty of such posi­tioning in this layout, just look up at those birds on top of page – in one of the latest browser‐versions of course.
This side‐column also relies on absolute‐posi­tioned generated content stacked as background, to appear full height on larger screens no matter the amount of real content.

Example 2: The “home” link on the logo (site-name), top left on this page, is positioned from the very bottom of source‐code, with its left end with a regular and descriptive text positioned outside the page, and right‐padding used to space it out correctly on top of the logo. The site-name itself is absolute posi­tioned text as generated content.
Add in a width‐transition on :hover with the (generated content) bird sweeping in, and the “home” link is complete.

Example 3: the visual misalignment between top of main column and right column is inten­tional. Perfect line‐ups in web designs is a weak point – easily broken by end‐user settings in browsers, and in my layout the main column actually overlaps the logo‐area (since it carries the logo).
 The “sheets” in the main column will be pushed down to provide space if the main head­line on top wraps into two or more lines, but the right column isn't affected. The alignment is always correct since this is how it is defined.
 And, to make sure those columns' vertical alignment don't get in the way of elements added on the indi­vidual pages, both are adjust­able in suitable steps to create more or less space in the header area.

The above are typical uses of “fluid CSS constants” on this site. The whole idea is to make fluidity work both for me as designer and for you as visitor, utilizing a simple layout with a few smart design solutions on top.

“Smart” web design solutions are of course only smart when they actually work for most visitors, and on average I spend as much time testing – and if necessary throw out – smart solutions, as I spend implementing them in a design.
I like to make everything look and work as simple and straight­forward as possible, avoiding solutions that are too fancy and/or complex to use. What goes on behind the screen and out of view is another matter entirely, and back there I can play around with all the complex stuff that doesn't disturb visitors.

enforcing IE edge

You will find the following meta in page-heads…

<meta http-equiv="X-UA-Compatible" content="IE=edge" />

…as I would not dream of letting IE switch to its “broken page” rendering – ever. Battling one IE7 is enough for life, and I don't want its ghost to do its dirty work in later versions.

It is of course ridiculous that we have to explicitly tell a browser to render in accordance with web standards – doctype-switching is stupid enough. Of course: with standard-adherence his­toric­ally being what it is both in IE and amongst web designers/​coders, having to confirm twice that we want proper behavior and rendering in IE does carry a certain logic.

That meta element is the only element that prevents my HTML5 pages from validating. Keeping older IE versions under control is more important than vali­dity though, and validity in itself has next to nothing to do with cross‐browser func­tion­ality anyway.

Anyway, it is a temporary solution while we wait for old IE to go the way of the Dodo.

actual screen‐size

The following meta can also be found in page-heads…

<meta name="viewport" content="width=device-width" />

This is to make reasonably sure most modern browsers on small devices render my pages relative to actual window sizes on the devices they are running on.

The spread of prepared and unprepared designs on sites people want to access via mobile phones, may make faking window sizes neces­sary simply to get access and reason­ably OK rendering. My site work best with real dimen­sions though, as that's what it is designed for.

I am not playing around with “dif­ferent content for dif­ferent resolu­tions” – yet. The varied land­scape in this field and lack of good and well‐sup­por­ted solu­tions, makes “resolution nego­tia­tions” totally unin­ter­esting to me at this time.

navigation and link rela­tions

Not all visitors like that main navi­ga­tion is in the footer of a page, as they are not used to having it there. But think about it: where are you in a page when you have read through it? … at the bottom of it.

Of course: such logic is not always appre­ciated, but it is never­the­less logical to have main navi­ga­tion near the bottom of a page. Thus, that is where I put it on this site.

My pages also contain “link relations” in page‐head, coupling pages together in the right order in and across the various site‐sections…

<link rel="home" href="../../index.html" />
<link rel="index" href="../index.html" />
<link rel="contents" href="index.html" />
<link rel="search" href="../../search.html" />
<link rel="next" href="../basics/links.html" />
<link rel="copyright" href="../basics/copyright.html" />
<link rel="author" href="../basics/author.html" />

Some browsers and other soft­ware make use of “link rela­tions” in many ways, including pre‐fetching and by providing users with an extra set of navi­ga­tion links.

As long time user of a browser that have always revealed most relevant “link relations” as navigation in the browser-chrome – which means these links are always in view, I am used to navigate prepared sites more or less by “link rela­tions” alone.

Thus, it makes perfect sense to prepare my own sites with a good set of “link relations” for easy navi­ga­tion, and I still on occasions use a browser that can make them work as intended even if my browser pre­fer­ences have changed.

the outcome

It works on big and small screens.

I am quite happy with how this layout turns out on screens of all sizes. Always room for improve­ments, but the basic layout and the HTML template behind it are both pretty much done.

www.gunlaug.com advice upgrade advice upgrade navigation