another destructive design…

…in the box, with bugs and all

Although no single page can destroy, or even disturb, the overall site design, any page can affect how certain bits and pieces across the site appear and function.

Most pages have affected something beyond themselves when they are released, as I not only write articles and notes, but also often find reasons to try out new ways to combine elements and styles for serving content the way I want.

In essense: I design while writing, and may also write about it while designing.

Not always easy to say what comes first or last or in what order when I produce articles – especially web design related ones. Often you get “two for the price of one” on this web site, as two (or more) somewhat related subjects often co-exist on a page.

On this page for instance, where I decided to try out some large-text effects in the side-notes, played around with necessary “bug killing” to make that work as intended across browser-land, and then decided to write about it all (and more).

And, while playing with all that as kind of “a side-show”, I wrote this long-planned article about “buggy web design and creativity”, as seen from my point of view.

This “mixed approach” of mine in turn often pushes parts of my design up against, or over, the edge of what is possible with existing styling, making it necessary to go through and fine-tune or rearrange details here and there in main stylesheets so the site-wide design can handle more, over time much more, than it originally was created for.

As a conse­quence, the site-wide CSS evolves into something more efficient, robust and versatile with each turn – almost with every page, and my arsenal of design techniques grows.
It is amazing how many ways a piece of CSS code can be used, reused and abused, and what can be made to co-exist on a page. And making all the differently styled content carrying elements live inside what is a pretty minimal HTML template, is part of the challenge. No “divitis”6 allowed here.

This is the fun part of coding web designs, but while being the most creative it is also the least organized part – around my place anyway.

With each upgrade and improvement, designer bugs2 may sneak in and wreak havoc on my site-wide design. Usually no big deal if flawed code becomes immediately apparent on the page I am working on, but that is not always the case.

Now and then one of these “home-grown” bugs pass unnoticed on to other pages and/or other parts of the site, as main stylesheets do cover the entire site.

In such cases it may take a while before my CSS designer bugs are discovered, and then it is of course not of much help that they almost always can be fixed in no time once they are found.

how to spread destruction

Insertion of unbalanced CSS selectors are usually what cause problems and spread destruction in a web design project. I see examples of this literally every time I look at code behind a web site with problems, and often it is so obvious even on a seemingly well working web site that future failures can be predicted.

We must try to get those selector chains4 balanced just right for the task at hand, in competition with other selector chains targeting element combinations in the same area or under similar conditions. Not taking care of this at every turn, will tend to throw even the simplest web site designs out of whack sooner or later.

Making changes to a single selector chain, will make a set of property/value pairs target more or less specific, and also affect its specificity. In addition to desired effects across site, changes in selector chains may have adverse effects on design in pages launched before the change was introduced, or any detail any­where on site that rely on existing spe­cif­icity balance. Spe­cif­icity balance failure is like sending data into a worm­hole, wonder­ing where they all went.

Introduction of entirely new selectors for serving new sets of property/value pairs, may in the same way have unforeseen and adverse effects. If targeting isn't narrow and specific enough, new styles may affect much more than intended.

Checking back and forth between existing and new/modified styles, and tuning all selector chains for just the right target-width and as low specificity as possible, can be time consuming. It is however important that we tune the balance for site-wide styles as best we can at all stages, as we otherwise risk running out of specificity much too early.

Has anyone come up with an “automatic CSS selector specificity calculator”, as extension to HTML/CSS editors? Sure would like to have one.

The absolute easiest way to spread destruction in web design, is by adding in hacks and fixes for imaginary or real browser bugs here and there and everywhere – especially when “done for good measure” and in ignorance. Flawed and failing bug fixes are common causes for failures in visual web design.

Of course: only newbees add code they are not in perfect control of, and we see most such mistakes made by newbees. Not uncommon that we see some on sites built by more seasoned designers/​coders also. Especially easy to enter hacks when deadline is near and the latest “great idea” won't work as intended across browser-land.

Afterwards – if not documented well – it can be difficult to remember what one did and where one did it. Or maybe someone else in a team entered all the “clever code”, and never told anyone about it? Whatever, trying to add new solutions into a nest of old hacks and weak code, can result in all sort of “funny things”.

Not quite so much fun to sit for hours trying to find out why some simple, new, code doesn't work as intended. Not to mention searching for those damned hacks and flaws, and trying to figure out what they actually were supposed to do in what browser…

how to avoid destruction

The easiest way to avoid adverse effects caused by future changes, is to freeze stylesheets – disallow future changes – once the initial design is in place. Then the entire design becomes static, and nothing can ever fail – providing every thinkable use of the design is covered initially.

In my view, “freezing” CSS, or anything else, is unthinkable for any but the simplest ten page “Hi, I am here” sites. Such sites are either launched and forgotten about, or they don't last long.

Really large web sites also often use a “frozen code” strategy, but they also usually document everything behind the scene so well that it works just fine for them. Combined with planned and well-prepared design, front- and back-end updates every few years, they can keep their sites current and fresh on all levels for ages.

A more practical approach for small to medium size sites, is to section up the site, use partly separate stylesheets, and have key pages in each section to check for adverse effects when additional and/or changes to site-wide or section-wide design styling are introduced. This method will catch around 99% of all designer bugs2 within minutes on prepared sites, and should work well for most active sites.

On sites like mine, which is a web developer's public playground in addition to more or less frequent serving of somewhat meaningful content, CSS upgrades and changes are introduced so often that not even the method with “sections and key pages” can catch more than maybe 80% of my many designer bugs.

I can live with an 80% immediate bug catch, as most of my bugs are not noticed by anyone but myself anyway. Fact is, I have no choice the way I choose to work.

after all these years

Should think that after more than a decade5 of designing with CSS, that I mastered it to perfection by now. But, luckily, I can still come up with new ways to destroy “perfect solutions”, giving me no choice but to discard and/or improve on things.

As more browsers arrive with improved support for CSS3 fragments, more of my ideas can be put to the test on site. The only limitation on real-world production, is slow switching from old to new browser versions amongst end-users – not much I can do about that.

After three years the original HTML template behind this site holds up just fine though, which tells me I must have done something right back in January 2011.

Thus, whether I use the old XHTML1.0 template, or the relative new and “funky” HTML5 template – a straight copy of the old template using new elements, does not matter much. I can still mess things up big time anytime, without even trying.

the creative phase

Trying to be perfectly organized and systematic when creativity starts to take over, is for me totally impossible. Knowing where the coffee cup is, is about as much attention I give to where I am and what is going on around me and in the rest of the world. Can be hard on those around me at times.

Once the creative phase is over – after hours, days or weeks – I try to reorganize myself and collect as many pieces as I can find, and hope I haven't lost track of too much important stuff from behind the creative layers while I were “in the mood”.

At this stage code gets cleaned up, browser support is checked, and update notes are written. And, needless to say: not everything I have done on the lower layers in a web design comes clear to me right away.

Sometimes it takes weeks to get everything cleaned up after a day or two of “intense creativity”, and to update my update notes to the degree necessary so I later can refresh my memory on what I have been doing.

In the mean time my designs may look a little “rough around the edges”, as polishing details isn't always part of the creative process. It depends on what I felt creative about at the time, which varies greatly.

creativity can be hard on a design

This site has literally been at the edge of falling apart several times because I pushed something in it a bit too hard. Somehow I have always managed to pull it back onto safer ground, without resorting to redesign.

While writing this page I have managed to change site-wide page section alignment four or five times – no big deal.
Also modified font-size, width and text-shadow for first headline (h1) at least three times, added the stupid EOF (with HEAD element check) at the page bottom, and changed outer background three or four times.
Fun … and through all this I haven't lost a single CSS selector or property/value pair, so the design is intact. Practice makes perfect…

Apart from playing around with details – like above, I do not want to redesign or redefine this site. I only want to make the most out of the design and template that has been carrying content from the day it was launched.

Some like to play in “a sandbox” – a section totally separated from everything that holds up their actual site and its design. Easier to create things in total isolation too, which I guess is why many use sites like codepen, jsfiddle, etc, for experiments.

I work in a sandbox too now and then, but I often find it more rewarding to be creative where I have to take an existing design into account. It is something about being able to pull off things directly on a “living site”, where my ideas and “creative fragments” are supposed to end up some day anyway.

I don't feel like playing it safe in web design, and the world sure isn't coming to an end just because a web design fails in one or more browsers for a few days or weeks, or longer.

nice hobby

Web development, and all it brings with it, makes for a nice hobby. I often place coding and programming in the same class as the knitting my wife has as a hobby – a form of handiwork. Only that this semi-retired technocrat is slightly better at HTML/CSS coding than at knitting, which explains the choice.

It is the many small challenges that makes it so interesting, and I can find as many such challenges as I may ever want to deal with in life, right here on the world wide web. Spread the playing field a little, and there are more interesting challenges than I have time for.

I don't have to make a cent in order to keep on doing what I do here. But of course I do, and it sure doesn't hurt in the long run.

In addition to designing and coding I like to write, and will continue to write as long as I have something of value to write about. Maybe some of my articles are a little long-stretched, but it was far worse in my younger days so I won't make excuses for anything I serve on this site.

sincerely  georg; sign

Hageland 25.mar.2014
last rev: 30.nov.2017 advice upgrade advice upgrade navigation