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 consequence, 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
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
or any detail anywhere on site that rely on existing specificity
balance. Specificity balance failure is like sending data into
a wormhole, wondering 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
selector specificity calculator”, as extension to
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
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
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
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.
text-shadow for first headline (
h1) at least three
times, added the stupid
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
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.
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
CSS coding than at knitting, which explains the
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.
last rev: 30.nov.2017