Why is this the case?
Neither this post nor the linked https://geoffgraham.me/width-looks-outward-height-looks-inwa... explain the rationale for this concept. In this particular case, the difference between the behavior of width and height rules seems arbitrary, rather than logical.
As for vertical writing, it wasn't a priority to the Western authors of web browsers at the time, then backwards compatibility meant we couldn't introduce it.
Edit: OK, I just set the writing-mode CSS property on a webpage (MDN) and it works- height is fixed and width is as long as needed to fit the content. But this was implemented in 2016. I don't know enough about the history of computing in Asia to say why it took so long to implement.
Vertical writing is only commonly seen in books and very formal documents these days, and word processing software to make them have long supported it. Most writing, by hand or by computer, is done horizontally.
The exact cyclical-dependency-breaking-algorithm is more complex: https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contri...
You should only use percentage sizes with respect to containers that have a definite, non-content-dependent size. As it so happens that's the _default_ for width, but not for height, but you could easily have the reverse situation if you're shrinking width to fit and sizing height explicitly.
So the problems people encounter are really simple and the need for the CSS exception here pretty intuitive. I'm pretty sure people get caught out by this largely because there's no good feedback loop here; it's not like the browser devtools warn you when you've made a cyclical dependency: it just doesn't quite do what you want and worst of all: sometimes that still sort of looks "ok" so you don't notice what's wrong right away. There may be some good reason why devtools can't warn you about this, but that's the real problem here, not CSS illogicality.
So the rule of thumb: don't rely on cyclical dependencies; i.e. don't define width or height with respect to a container that itself has a width or respectively height that depends on its content.
[0]: MDN says the following about setting a percentage for height/width:
> <percentage>: Defines the height/width as a percentage of the containing block's height/width.
[1]: See also https://geoffgraham.me/width-looks-outward-height-looks-inwa... where OP points to the YouTube video he got that line from.
The first realization is that the height of the parent, by default, expands to fit the content. And so the default behavior that people expect, (just taking the computed height of the parent), isn’t possible; it’s circular reasoning. It’s these situations, where the parent doesn’t have a defined height, that the percentage height does nothing.
Percentage width and height are both calculated by going up the tree, to find the first parent with a defined width and height. Block displayed elements by default have a defined width. They default to “width: 100%” basically. And by default, the root html tag is block displayed. This is why width seems to work out of the box, but height doesn’t.
I start my websites with
html, body {
width: 100%;
height: 100%;
/* adjust padding and margin as appropriate */
}
- the maximum width of a paper document is simply the width of a piece of A4 => so an element can have a well defined width, that being a percentage of the width of the document
- the maximum height of a paper document though.. doesn't exist as you can always add more papers, similarly css can't define the height as a certain percent of the document, so it chose to look at it's own child elements.
Unsafe. Many A4 docs from spreadsheet to kids illustrated book are wider than A4.