Every once in a while, styling a Web Application can be oh so frustrating quite interesting because stuff that appears easy does actually not comply with any of your suggestions. And there are some fields that ambush me more often than I’d like to admit, and with each application there appears some unique quirk that makes a universal solution hard.
Right now, I’m thinking about a CSS-only nested layout of several areas on your available screen that need to make good use of the available space, but still be somewhat dynamic in order to be maintainable.
Web Apps are especially delicate in layout things because if you ask most customers, a fully responsive layout is never the goal (as in, way too expensive for their use case), but no matter how often you make them assure you that there is only a small set of target resolutions, there will be one day where something changed and well-yeah-these-ones-too-of-course.
It is also commonly encountered that “looking good” is “not that important”, but as progress goes, everyone still knows that that was a pure lie.
Of course, this is a manifestation of Feature Creep, but one that is hard to argue about. And we do not want to argue with customers anyway, we want to solve their problems with as little friction as possible.
So by now, one would have thought that CSS would have evolved quite enough in order to at least place dynamic content somewhat predictable. There are flexbox and grid displays and these are useful as hell, but still.
And while, for some reason or another, the width of dynamic nested content can usually be accounted for in some pure CSS solution that one can find in under a day’s work; getting the height quite right is a problem that is officially harder than all multi-order corrections I ever encountered in my studies of quantum field theory. Only solvable in some oversimplified use-cases.
The limits of “height: 100%;” are reached in cases where content is dominated by its content instead of their container; as in nested <svg> elements that love to disagree about the meaning of “100%”. Dynamic SVG content is especially more cumbersome because you neither want distorted nor cut-off content, and you can try to get along with viewBox and preserveAspectRatio, but even then.
Maybe it won’t budge, and maybe that’s the point where I find it acceptable to read the actual DOM elements even from within a React component, an approach that is usually as dangerous as it is intrusive,
but is it a code smell if it is rather concise and reliantly does the job?
const useHeightAwareRef = () => {
const [height, setHeight] = useState({
initialized: false,
value: null,
});
const ref = useRef(null);
useEffect(() => {
if (!ref.current || height.initialized) {
return;
}
const adjustHeight = () => {
const rect = ref.current?.getBoundingClientRect();
setHeight({
value: rect?.height ?? null,
initialized: true
});
};
adjustHeight();
window.addEventListener("resize", adjustHeight);
return () => {
window.removeEventListener("resize", adjustHeight);
};
}, [height.initialized]);
return {
height: height.initialized ? height.value : null,
ref
};
};
// then use this like:
const SomeNestedContent = () => {
const {height, ref} = useHeightAwareRef();
return (
<div ref={ref}>
{
height &&
<svg height={height} width={"100%"}>
{ /* ... Dragons be here ... */ }
</svg>
}
</div>
);
};I find this worthfile to have in your toolbox. If you manage your super-dynamic* content in some other super-responsive** fashion in a way that is super-arguable*** to your customer, sure, go by it. But remember, at some point each, possibly,
- (*) your customer might have data outside the mutually agreed use cases,
- (**) your customer might have screens outside the mutually agreed ones,
- (***) your customer might have less patience / time than originally intended,
so maybe move the idea of “there must be one super-elegant pure-CSS solution in the year of 2025” back into your dreams and shoehorn that <svg> & friends into where they belong :´)
Schneide Blog 