calculating available space
…
or extracting width of “auto”.
Tracking computations for a fluid layout on various window sizes, can sometimes be a bit daunting. Calculations range from rather complicated to near impossible when auto-width and auto-/fixed-margins are mixed with max-width on some containers and not others in an intentionally imbalanced responsive 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 calculations, but at least it works.
newspaper test #1
Never mind the daft examples. Throwing newspapers to see where they land, is as good a test as any for the job at hand.
1
-8
title-attr in images reveal margin values
Left- and right-side margins are arranged in sets of steps, using microtuning
class
es that can be assigned to any element. As both positive and negative margin values are included in these stepped
arrangements, elements can be pulled out over the edges of the page itself on narrow windows using these class
es.
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 (cellphone) 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 class
es, and I can of course break the system of
negative-margin restrictions at will by assigning microtuning class
es 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 “leftover” spaces outside that container.
Using constants within calc()
are easy, so some incalculable 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 grandparent, minus width
of parent, minus defined horizontal margin
and padding
on parent. In my calculation 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 challenges 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