CSS Is Logical
geoffgraham.me
geoffgraham.me
And "Width Looks Outward, Height Looks Inward"
And - The key insight here is: height: 100% means “I am as tall as all the things inside of me”, not “as tall as all the things I am inside of.”
But this is wrong and 100% does mean as tall as the things I am inside of. And this is the same as how width works.
The spec even says "Percentages specify sizing of a box with respect to the box’s containing block."
Here's a quick example
https://jsfiddle.net/znqtue21/
There is a quirk where a box's size is a percentage of the parent block, but the parent block's size is calculated from its child (there would be a circular dependency), in which case there are special rules. But even these are the same for width and height. Usually you can just put an explicit height on the parent. https://drafts.csswg.org/css-sizing/#cyclic-percentage-contr...
This is the reason for the perceived difference between width and height. The rules are the same but the box's default width and height are different
I'm surprised how one can get something like this so wrong and, at the same time, claim that CSS is logical (and, supposedly, claim to understand that logic).
> width looks up the tree while height looks down the tree.
> that’s why height: 100% doesn’t do what people often expect and go the full height of the screen
That's why it's "not logical", even though both sets of rules (W/H look up; W looks up H looks down) can be written down. What's the logic behind the same thing (dimensions) looking at the opposite direction? What is the mental model of the interface world where this makes sense, so that you could use that logic instead of having to rely on remembering the rule that contradicts your intuitive "logic"?
You make something taller to fit the content.
So width is constrained by what is available but height determined by what is necesary for the content.
The CSS flow layout is designed to make text content readable by default on a variety on device dimensions.
CSS behaviour requires sustantial work to get one's head around. The result includes dramatic change to head shape.
#!important
#foobar {
width: 100% of container width;
height: 100% of contents height;
}It might be messy, but it is being processed by a machine that is fundamentally based on logic!
Programming is already “nonsensical” by your definition! Just ask a lay person! What we do as programmers is translate into machine instructions. Yes, “Text-Color” being used to declare font size is confusing, but so is a for loop to the untrained eye!
Is Brainfuck not logical?
Their line of thought would be "Type 'text-color' to change the font size." (in their language, obviously) and it would be perfectly logical both from human and computer perspectives.
テキストカラー: 20px;
vs
フォントサイズ: 20px;
Actual Japanese for text color would be "文書の色" (bunsho no iro) and font size would be "文字の大きさ" (moji no ookisa), and variants thereof.
So a Japanese dev who doesn't speak English would think: "文字の大きさを設定するために「text-color」と入力する。" and it would, again, make logical sense from both human and computer perspectives.
Logical and confusing are two different concepts and I’ll leave it to the reader to ponder why.
I cannot fathom how data-loss by default could ever be considered a logical answer to "hey guys we need need to start from the ground up to come up with a system for arranging elements because the old way was so busted".
It's actually very fiddly in CSS, whereas with something like Qt or Flutter or whatever it's completely trivial - just add a splitter and then two scrollable views. (And good luck if you want an actual movable splitter with CSS.)
Flexbox makes app-like layout possible, but still not easy.
I guess everything would be simpler if CSS defined "document" to exclude interactive interface ;)
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 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.
[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 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.
I just think it's more a question of the mental model that is in your head. Learning languages is the same. A language can have a syntactical/linguistic feature that seems very strange when you have the mental model of your own native language in mind, but the more practice the new model the more it begins to "make sense" until - voila - you get it.
Normal mode in VIM is an another example. The first time I experienced it, it seemed absolutely bizarre.
Literally by definition anything designed in a computer must follow logic.
Eh, that's not a particularly useful claim. Just because everything that runs on a computer can be expressed in formal logic doesn't mean the process would be logical in the colloquial sense of the term.
A claim that css is terrible, has a point.
Well, yes and no. It depends on context. You know, nuance.
Like I said, it can be technically logical, but that doesn't mean it is logical in the colloquial sense.
The point made in the article is to refuse a claim that CSS is not logical in the colloquial sense, it is not trying to refute that it is technically logical which is the point you are making.
I get what your saying here but basically the article and all responders are dodging the real issue here with this wordplay.
The OP article is actually saying CSS is not terrible. And people who disagree are saying yes in fact css is terrible. It's just a way to be not so on the nose about saying css is a shitty way to do things.
You missed my point which may be my fault as it's a bit obscure the way I said it. Let me rephrase it to be more clear:
I'm saying it's pointless to say or claim css is logical. He's using the term incorrectly. The real argument here is really about whether or not css is shitty or not shitty and using the term logical is not only dodging the point, but also awkwardly using the word logic.
:has() for example, is a gamechanger once you can confidently not care about IE11.
Before :is(), :has(), :where(), and before the forgiving selectors were added, things were not so much fun.
It's very much a black box people just fiddle with until it works. But if we had better tooling to explain why selector A matched and B doesn't (relevant in particular for stuff like `.outer .inner` - which `.outer`, exactly?); and why A has more specificity than B; and why and how a certain value was computed (e.g. so that a margin-top of some block is related to a highlightable _width_ of some specific containing block, for instance) - then I bet most people would figure out CSS pretty easily.
Another helpful thing would be if browsers had compiler-style warnings for CSS. We have (bad) CSS linters, but that's partially because it's hard to tell what kind of CSS is problematic "in general" for lots of the tricky stuff that only becomes apparent for a specific DOM. E.g., it seems like a browser should have no problem highlighting which percentage sizes are being semi-ignored due to cyclical dependency issues, but... they don't. Instead they simply pick some fallback which while technically deterministic isn't educationally helpful. There are usually pretty simple reasons why things "don't work" - but good luck finding those, because browsers won't tell you.
CSS is pretty simple, but not simple enough to be immediately intuitive in all cases without some inspection help - and we don't really have good CSS inspectors AFAIK.
Why is that logical?
This makes sense, CSS layout is computed with logical rules/programming.
I think the “illogical” reputation comes from people not knowing which rules apply. They cannot see how the current layout output was calculated by the given css properties.
This is due to CSS being backwards compatible and constantly adding new ways to do things. But you can choose to use the “good parts” of the language as Douglas Crockford would say (for JS).
Also many people assume CSS would be easy and brush off that it requires a bit of effort and practise to learn the language.
I created an interactive grid explainer here if anyone is interested, I think grid is one of the good parts.
Tailwind has become popular because like SQL, CSS is powerful and hard to do well; it takes skill.
Well constructed CSS is a thing of beauty. Tailwind...not so much.
Sure, CSS is hard and Tailwind makes it easier. God forbid people choose the tool with better DX.
When you're structuring an application around components—where a component is an encapsulated unit of layout, style, and behaviour—it doesn't make sense to start putting those three aspects in separate places. Under that model, you typically don't want stuff inside a component to be able to affect anything outside, which is where things like Tailwind, scoped styles, and various other recent styling tools start to make a lot more sense.
Now, you can argue whether or not that is a good way to build applications, but given it's how pretty much every desktop and mobile UI system works, I'm not inclined to say it's inherently wrong. It's just not a great match for the tools we have available to us on the web.
If it works, great, but I'm not going to base the architecture of my software around the desires of the 0.001% of users who even know that user style sheets exist.
The written Tailwind code might not be beautiful (still it tends to be simpler than well-constructed CSS), but it does not stop the resulting website from being beautiful.
Well-constructed CSS does not stop one from building non-beautiful websites with beautiful code.
Depending on the usage of the word "logical", _everything_ is logical, as the universe itself follows some set of rules.
“CSS be weird, but it not be illogical.”
Not just was. Also is.
"Cascading Style Sheets (CSS) is a simple mechanism for adding style (e.g., fonts, colors, spacing) to Web documents." https://www.w3.org/Style/CSS/
This is where most of the 'logic' breaks down for me. The specificity scoring is a system of weights that trips up a lot of new front end developers. It's not straightforward. Different selectors have different weights you need to know about. There are 'hacks' you need to know about when you find yourself needing to override particularly heavy selectors. https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity
And conveniently the author doesn't mention !important.
I think nowadays I find myself using CSS variables and calc() more often to establish some system of logic in my CSS. I can have --spacing: 120% variable at the root of the tree, and all its descendants can consume that and use calc() to multiply that by a unit value to have consistently scaled spacing. The author doesn't mention this, but it's great!
Yeah, it's a bit implicit. Or you have to learn the rules by heart.
I also saw people struggle with two elements aligned to bottom with different line heights. Turned out they did not know that there is a default line height. And of course the "correct" line height to use is either "1" or "1.15" (not the browser default).
Many times I’ve heard someone claim “my native tongue is logical because this or that” and it’s fun when I demolish their logic with examples as to where that “logic” breaks down, most commonly with examples from many other languages, the takeaway being: human languages are not logical, you’re just rationalizing your years-long understanding of them as “logical”.
It's not even understanding, it's more habitualization.
Often, people do confuse "logical" with "easy". For me, "logical" means "there are rather strict rules that you can and have to learn and apply". In this sense, I would say Russian and German are much more logical languages than English (and I know quite some people who learned one of these languages as second language who agree with my judgment), but learning (bad) English is likely easier than learning Russian or German (of course assuming that you don't already know a related language).