basic tools

makes debugging easy.

That something works does not mean it works optimally, and I do not belong to the group of folks that fall down on the “if it works, don't fix it” mantra and leave it at that.

If it works, let's fix it” is more my style, especially when it comes to web design. Leaving things alone just because they are already working more or less as intended, will restrict my develop­ment as web designer.

As I prefer to work out the more complex design details on a private site like this rather than on client sites, this is also where I need debugging tools. So, I built the ones I use the most into the design itself.

Every single page on this site has thereby become part of a “service center for visual design”, where I can intermix and test out design ideas within the restrictions of the overall layout of a working site. This is better than having to prepare a clean slate every time I come up with an idea, and then later figure out how to make it work as part of a real design.

To test out the small stuff we do of course have services like jsFiddle, although I do prefer my local environment for everything.

open to the public.

As no damage can be done, there is no lock-and-key on my on-site service center. So, in theory at least, any visitor can perform these tests on my designs. That regular visitors would have no need for or interest in this, is another matter entirely.

Despite being “open to the public”, all test-stages are made as unobtrusive as possible. The idea is that regular visitors should not notice anything unusual as they go about reading, or scanning through, whatever they may happen to find interesting in my articles and posts.

One way to keep test-functionality out of the way for regular visitors, is to utilize the fact that the main container elements – html and body – are not totally overlapping each other, and that page-head elements are styled to occupy their own visual spaces.
This deviates slightly from how most web-sites are designed today, but I like to get away with as few container-elements as possible without having to compromise on what can be done in visual design. One way to do that is to make the most out of the more mandatory elements.

By having on-screen access to the html, head and body elements separately and overlayed in a certain manner, I can run :active on one element and not the others. Simple selector-chains like the one below sort out the rest for conditional styling of page-elements under test…

html:active head:active+body:not(:active) #base:target>…

… with a :target condition added to keep certain parts of the test from being triggered by accident by regular visitors.

Several such conditions and variants are built into dedicated test-pages on site, as not every test has to be available everywhere. Some tests are also only available in specific browsers, as they don't make sense in others – think testing of older IE versions.

The overlayed raster-image is achieved by absolute position a full-size generated content element using ::before

head:active+body:not(:active)::before {
content: ""; background: transparent url("raster.png"); 
position: absolute; top: 0; left: 0; 
height: 100%; width: 100%; padding-bottom: 4px;
background-position: 50% 0; opacity: .3; z-index: 50;

… that is layered above all page elements using a high z-index.

The overlayed raster lines up with the raster on body, so if one raster doesn't provide enough line-up infor­mation I can apply both.

The html and head are acces­sible below the body – at bottom of the page. This is where I usually press the mouse-button to turn these elements :active, whereafter I scroll up the page to see/extract the line-up and other infor­mation while holding the left mouse-button down. Once I let go of the mouse-button the overlayed infor­mation disappears and the page returns to normal.

All devices that can activate and scroll simultaneously, can access these function­alities. As such test-function­alities don't have to be acces­sible beyond my own devices, they do not have to work on all devices on the market.

lining up?

Hardly anything lines up in my designs anyway, so why should I bother to compare element line-up with a perfect raster? Well, visual design is all about ballancing the visual parts of elements, colors and shapes to each other, and without a raster and some outlines any lineup becomes more of a guesswork – especially in unruly “over the edge” layouts like mine.

For predictable and stable rendering, what matters is how the actual elements line up with each other on various screens. With all the margins, paddings, invisible borders and transparent images everywhere, how the individual elements actually line up becomes obscured.

The raster in the background and on some of the elements, along with element-outlines and the “on/off” overlayed raster, makes it a whole lot easier to see behind the purely visual and discover potential problems and causes.

When I combine this system with the tools found in various browsers, or made available in most of them through add-ons, pretty much every detail in my design can be revealed – live.

I suspect most web design coders to use such methods when things don't look quite right. The only difference is that I have turned my debugging methods into a system, and included the most useful parts in the site's permanent stylesheets.

All of this makes even more sense since I recycle most of the special styling for, and from, the regular look/feel of the design. Nothing goes to waste on this site.

sincerely  georg; sign

Hageland 05.sep.2016
last rev: 12.sep.2016 advice upgrade advice upgrade navigation