4 ms·

> width looks up the tree while height looks down the tree. Why is this the case? Neither this post nor the linked https://geoffgraham.me/width-looks-outward-

> width looks up the tree while height looks down the tree. Why is this the case? Neither this post nor the linked https://geoffgraham.me/width-looks-outward-height-looks-inward/ 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.

lozenge 3y ago
It's a document format. The width is fixed by the browser window but the height is "as high as the document needs". 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.
- Dalewyn 3y ago
  At least with Japanese, the answer to "why it took so long" is "nobody really cared". 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.
deleted 3y ago
[deleted]
spacebuffer 3y ago
My guess would be that HTML and CSS originally were meant to deal with sites that resemble a paper document (i.e. a collection of A4 papers) so it tries to be consistent with that: - 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.
- magpi3 3y ago
  Yes, I have the same intuition. Sites scroll downward, the height of a website is never really fixed, but there does seem to be some assumption that the width of a website is fixed. At least when I approach it with this mental model in mind, it is logical.
- chrisjj 3y ago
  > - the maximum width of a paper document is simply the width of a piece of A4 Unsafe. Many A4 docs from spreadsheet to kids illustrated book are wider than A4.
codethief 3y ago
Is it really true to begin with? I mean, yes, naively setting height: 50% vs. setting width: 50% will do different things but that's not because height and width are doing anything differently fundamentally[0], as OP claims[1], but because the containing block's (and their containing block's etc.) default values for width/height differ: By default, block elements grow in height (fit their content) but take up a width of 100%, since that seems sensible for documents as the sibling comments point out. Now the issue is that if you set height: 100% somewhere down the tree, it refers to the height of the containing block. But if the latter wants to adapt to the height of its content, it's catch 22. The height: 100% won't have any effect. [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-inward/ https://geoffgraham.me/width-looks-outward-height-looks-inwa... where OP points to the YouTube video he got that line from.
MatthiasPortzel 3y ago
I think about it slightly differently; I’m sure I’ll get corrected if this is wrong. 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 */ } This means that I can create a root div element with height 100% and have it do what you’d expect. I skimmed over some stuff, let me know if you want a blog post.
emn13 3y ago
It's not true. It's also a dangerous rule of thumb. Percentage widths and heights refer to _containing_ blocks, not contents. However, if you size a box as some percentage of a block, and that block in turn has a size that depends on its contents, you can get a cyclical depedency. In that case, there _are_ rules on how that's resolved, but typically it's almost as if you hadn't written the percentage rule at all; i.e. this very rarely does what you want. And as it happens, if you're just in normal flow, then of course the height of any container depends on what's in it, so percentage heights with respect to such a container don't work. The exact cyclical-dependency-breaking-algorithm is more complex: https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contribution 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.

lozenge 3y ago

It's a document format. The width is fixed by the browser window but the height is "as high as the document needs". 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.

Dalewyn 3y ago
At least with Japanese, the answer to "why it took so long" is "nobody really cared". 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.

deleted 3y ago

[deleted]

spacebuffer 3y ago

My guess would be that HTML and CSS originally were meant to deal with sites that resemble a paper document (i.e. a collection of A4 papers) so it tries to be consistent with that: - 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.

magpi3 3y ago
Yes, I have the same intuition. Sites scroll downward, the height of a website is never really fixed, but there does seem to be some assumption that the width of a website is fixed. At least when I approach it with this mental model in mind, it is logical.
chrisjj 3y ago
> - the maximum width of a paper document is simply the width of a piece of A4 Unsafe. Many A4 docs from spreadsheet to kids illustrated book are wider than A4.

codethief 3y ago

Is it really true to begin with? I mean, yes, naively setting height: 50% vs. setting width: 50% will do different things but that's not because height and width are doing anything differently fundamentally[0], as OP claims[1], but because the containing block's (and their containing block's etc.) default values for width/height differ: By default, block elements grow in height (fit their content) but take up a width of 100%, since that seems sensible for documents as the sibling comments point out. Now the issue is that if you set height: 100% somewhere down the tree, it refers to the height of the containing block. But if the latter wants to adapt to the height of its content, it's catch 22. The height: 100% won't have any effect. [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-inward/ https://geoffgraham.me/width-looks-outward-height-looks-inwa... where OP points to the YouTube video he got that line from.

MatthiasPortzel 3y ago

I think about it slightly differently; I’m sure I’ll get corrected if this is wrong. 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 */ } This means that I can create a root div element with height 100% and have it do what you’d expect. I skimmed over some stuff, let me know if you want a blog post.

emn13 3y ago

It's not true. It's also a dangerous rule of thumb. Percentage widths and heights refer to _containing_ blocks, not contents. However, if you size a box as some percentage of a block, and that block in turn has a size that depends on its contents, you can get a cyclical depedency. In that case, there _are_ rules on how that's resolved, but typically it's almost as if you hadn't written the percentage rule at all; i.e. this very rarely does what you want. And as it happens, if you're just in normal flow, then of course the height of any container depends on what's in it, so percentage heights with respect to such a container don't work. The exact cyclical-dependency-breaking-algorithm is more complex: https://www.w3.org/TR/css-sizing-3/#cyclic-percentage-contribution 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.