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 development 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 information I can apply both.

The html and head are accessible 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 information while holding the left mouse-button down. Once I let go of the mouse-button the overlayed information disappears and the page returns to normal.

All devices that can activate and scroll simultaneously, can access these functionalities. As such test-functionalities don't have to be accessible 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

side notes.

testing - testing

very local service center.

Here follows a compact description of the basic test-package that is open to the public. Should give anyone with interest in such matters an idea of how it works and gets used. The following only works on screens wider than 643.

1: raster overlay

A raster image can be laid over the entire page-body by clicking and holding the mouse-button on the html element in the head area – title element at bottom of page. As long as I hold the mouse-button and thereby keep the head element :active, I can scroll up and down the page and see through this raster on the element line-up behind it. When the head element is no longer :active the overlay gets deactivated and the page becomes accessible.

In this html :active state with the raster overlay, any ID anchor for in-page linking to headlines and other elements are revealed. That's the function I use the most, as I tend to forget whether I put those anchors there or not.

2: line-up check

On all pages I also have a more detailed line-up check available, with the added bonus of some filter() functions being applied to images.

In this state the page content looks more diffuse because opacity is lowered on all elements to let the introduced background raster on body shine through. Headlines and images get their own background rasters so I can see how they line up in the page. In all other ways the page looks and behaves normal.

The raster overlay works here too, but now with two variants:
1) click and hold on the html element, and all elements in the page get a dotted outline in various colors.
2) click and hold on the head element (accessed via the page-title at bottom of html element), and some elements in the page get a solid black outline for better visual separation.
There's a screenshot (#1) of the 2) test-variant in the Addendum on this page.

3: in-depth check

On a few dedicated pages I have added some elements at the start of body, for more thorough manipulation of page-elements. I use these manipulations mainly to test progress in browsers, which is why I have them only on a few pages.
These few dedicated test-pages do look and behave normal in every way, until I :target an ID on body only these pages have.

Access to this in-depth check is intentionally made a little obscure, as it isn't supposed to get in the way and throw off the unsuspecting visitor.
A link can be found in upper left corner – above the “home” link – on every page on site. This almost hidden link either links to the browser evaluation page that has a set of in-depth tests built in, or it :target the in-page ID that opens up for such tests in a few more pages.
The present page has a partial in-depth check built in.

Once the link has been followed, there's another “lock” to open for full access to these tests. Clicking once more in the upper left page-corner position, opens up a number of input: check-box on top of side column. These check-boxes in combination controls a few filter, transform and other tests, primarily for images. Which and how many tests that are available varies, as I infrequently replace and/or upgrade them.
There's a screenshot (#2) revealing ::before and ::after pseudo elements, in the Addendum on this page. And that's it for the publicly available stuff.

is all this necessary?

Nope, not at all. However, being able to shave off a few minutes of testing time and lower the strain on my eyes every time I see a potential design problem, makes these built-in test procedures well worth the time it took to code them, and justifies the slight increase in stylesheet size.

As time goes by and browser support for CSS standards increases, I simply modify and/or replace one or more of the existing tests with new ones, as I already have done several times since this site went on-line back in 2011.

just an idea

Whether it is a separate stylesheet that gets linked in during building and testing of web sites, or a more permanent solution like the one I have made here, creating an environment for whole-page testing is in my opinion a good idea. There is no “one size fits all” solution available, so we can all build our own that suit our projects and work methods.

I have chosen to only use CSS and not mix in javascript, but that is just a matter of personal preferences and lack of need. I won't even start to think about what can be done if one wants to cover all bases.