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.

The lower limit is set around 600, but mediaqueries are used to redefine as much as possible over several stages to let the layout shrink below the fixed lower limit for regular screens. This means it can continue to adapt to window-width as a 2-column until it has to be redefined as a 1-column for really narrow windows/​screens/​devices at/below 500.

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 500px 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.

The mobile browser I know best – Opera – does a reasonably good job at rendering my pages the way I ideally want to see them, on the devices I have checked on. Haven't tested in much detail in other mobile browsers myself, but reports indicate that things are appearing and working pretty much as intended across the board.

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.

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: 01.sep.2016

side notes.

responsive web design?

Yes, most definitely.

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 stylesheets between medium and small screens.

In reality these apparent differences 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. Nevertheless, 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 naturally accessed linearly.

It then becomes easy to style for responsiveness in graphic browsers across various window sizes, while splitting 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, anywhere. Plenty of such positioning 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‐positioned 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 positioned 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 intentional. 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 headline 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.

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 historically 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 validity though, and validity in itself has next to nothing to do with cross‐browser functionality 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 necessary simply to get access and reasonably OK rendering. My site work best with real dimensions though, as that's what it is designed for.

I am not playing around with “different content for different resolutions” – yet. The varied landscape in this field and lack of good and well‐supported solutions, makes “resolution negotiations” totally uninteresting to me at this time.

navigation and link relations

Not all visitors like that main navigation 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 appreciated, but it is nevertheless logical to have main navigation 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 software make use of “link relations” in many ways, including pre‐fetching and by providing users with an extra set of navigation 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 relations” alone.

Thus, it makes perfect sense to prepare my own sites with a good set of “link relations” for easy navigation, and I still use a browser that can make them work as intended.

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 improvements, but the basic layout and the HTML template behind it are both pretty much done.

www.gunlaug.com advice upgrade advice upgrade navigation