calculating available space

… or extracting width of “auto”.

Tracking computations for a fluid layout on various window sizes, can some­times be a bit daunting. Calc­ula­tions range from rather compli­cated to near impossible when auto-width and auto-/​fixed-margins are mixed with max-width on some con­tain­ers and not others in an intent­ion­ally imbal­anced res­pon­sive layout.

Here I am dealing with the effects of margin:auto on both sides of this fluid but max-width restricted page, and margin:auto on left side only of this max-width restricted content area.        
So, how wide are those “auto” spaces actually?

CSS cannot extract those numbers directly, so the only way to figure them out is by observing. Media queries keep track of window width, and the widt of those “auto” spaces can be estimated by observing them along the entire fluid-width range. It's a long way round for what should be simple calc­ula­tions, but at least it works.

Outlines makes it easier to keep track of actual as well as visual containers – they are not always the same in my layouts. To turn on/off outlines, check/uncheck the checkbox over at the top-right corner of the side column.

Layout of major containers is as follows:
outline color Outer:
RED body div main
Inner:
GREEN body div main>article
Content areas:
YELLOW body div main>article>section
body div main>article+aside
body div main+footer>aside>section

news­paper test #1

Never mind the daft examples. Throwing news­papers to see where they land, is as good a test as any for the job at hand.

  1

  0

-1

-2

-3

-4

-5

-6

-7

-8
title-attr in images reveal margin values

Left- and right-side margins are arranged in sets of steps, using micro­tuning classes that can be assigned to any element. As both positive and negative margin values are included in these stepped arrange­ments, elements can be pulled out over the edges of the page itself on narrow windows using these classes.

present solution…

To make sure images stay completely within even the narrowest window, also if I happen to assign a large negative margin to an img-element because it looks right on wide windows, negative margins are restricted to that of the largest step there is space for inside any window/​screen width.

All major browsers handle the present image line-up method fine, with restrictions and all. Limits are handled by sets of tightly stepped media queries, so support in major browsers is pretty much guaranteed.

Full-width window is from about 1500 upwards, with default (100%) zoom. Any window width above 642, with default zoom, gets two column layout/​design. Any window width below 643, with default zoom, gets one column layout/​design.

For two column layout, left-side negative margins within the system are restricted in (this) main content area, and right-side negative margins in side-note area. For content area in footer negative margin restrictions are defined for both sides.
For one column (cell­phone) layout restrictions are of course introduced on both sides in all content areas, since there is hardly any space left outside content areas for negative margins to pull elements into on those small screens.

No such restrictions are applied to non-image elements using the same classes, and I can of course break the system of negative-margin restric­tions at will by assigning micro­tuning classes that are not within this “restricted” system.

wishful thinking

As calc() cannot be used to calculate values based on anything outside an element's immediate parent-container – apart from window size, it can not be used to solve the problem with “left­over” spaces outside that container.

Using constants within calc() are easy, so some incalc­ul­able problems can be solved by swapping constants as layout changes.

Cascading calc() down the selector chain hasn't been introduced in CSS yet, and may never be. Being able to perform such calculations would provide us with a powerful design tool though.
Thought experiment based on my markup…

*.myclass {margin-left: calc((width(section) + 6.5%) - width(main));}

That is: space (auto-margin) at left of parent, equals width of great grand­parent, minus width of parent, minus defined horizontal margin and padding on parent. In my calc­ula­tion this is inverted to get a negative margin-left on an the .myclass element that will make it overlap all that unused gutter-space, without having a defined gutter width.

finishing off

One more test/demo page completed, and task at hand solved. CSS only, no scripts involved – as it should be with static designs. So far so good.

Nevertheless, I am far from happy with progress in how design chal­lenges can be solved with HTML and CSS alone, neither in standards nor in support across browser-land.
Sure would like to do more with calc() than what is possible now. Not to mention being able to play with attr() in calc().

sincerely 

Hageland 14.nov.2017

last rev: 14.nov.2017