CSS Is Logical

https://geoffgraham.me/css-is-logical/

by DeathArrow • 2 years ago

86 97 2 years ago

geoffgraham.me

n3storm• 2 years ago

nice and terse

dartos• 2 years ago

Is “has rules and features” the same as “is logical?”

phoe-krk• 2 years ago

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-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• 2 years 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.

Dalewyn4• 2 years 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.

spacebuffer• 2 years 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.

magpi33• 2 years 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.

chrisjj12• 2 years 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.

codethief3• 2 years 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-inwa... where OP points to the YouTube video he got that line from.

MatthiasPortzel• 2 years 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.

emn132• 2 years 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-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.

degun• 2 years ago

CSS gets the impression of being illogical, because it’s a bit more complex than it looks. At first, it looks so simple that you think you know all there is to know about it by the first week or so. You think that you can infer what a said instruction will do, just by its nam. But to actually get a hold of it, you have to learn all the concepts that are listed in the article, otherwise you can get easily frustrated.

dsego2• 2 years ago

Doesn't help that there is a lack of internal consistency between properties and that things just got bolted on over time.

yCombLinks2• 2 years ago

Or that the "right way" to do things have changed several times over the years, and you have to figure out if that's the "old right way" or not, because they both are still available.

emn132• 2 years ago

Is it really complex? I think the real reason it gets this reputation isn't because of any complexity or lack of logic, but rather more simply because it's so opaque. Browser devtools are much worse for CSS than JS; there's no way to ask for an explanation of _why_ a certain value was computed. You can't step through a computation and figure out that well, DUH, there's a cyclical dependency here so of course that won't work, or, DUH, it's using the wrong containing block etc etc etc. Even stuff like selectors are pretty opaque; like you can't easily visualize why a certain selector matches or worse _doesn't_ match, and even trivial concepts like specificity aren't really surfaced in a very helpful way.

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.

J_Shelby_J• 2 years ago

Debug or a flowchart for computed properties would be amazing for learning.

CharlieDigital2• 2 years ago

CSS is like SQL for DOM elements.

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.

xcdzvyn• 2 years ago

Wow, CSS elitism is a new one.

Sure, CSS is hard and Tailwind makes it easier. God forbid people choose the tool with better DX.

CharlieDigital2• 2 years ago

A tool versus a toy.

deergomoo2• 2 years ago

That's a fairly reductive take on Tailwind. The motivation isn't because CSS is hard, it's because it doesn't match how web applications are commonly built today (which makes sense; the web is still primarily a document platform we've bolted software onto).

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.

xigoi3• 2 years ago

Soparation of data and style allows users to easily customize how your app looks, just like with documents. Using Tailwind is user-hostile.

tauchunfall2• 2 years ago

It looks like putting a list of utility CSS classes into one line is an intimidating thing of simplicity.

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.

bemusedthrow75• 2 years ago

It's worth observing that some of the things he points at are new-ish in terms of stable support.

: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.

janpot• 2 years ago

It's not illogical, but it's not adapted to half the applications it's being used on. That's what's illogical about it. "Document flow", "writing mode", the language used in this post indicates what CSS is meant for, formatting documents on screens. Yet half of us try to beat it into submission building highly interactive applications.

safety1st• 2 years ago

I think this was true for a long time, but now that we have flex, grid, nesting and a wide range of relative units to name a few modern features... the syntax for some of these can be a bit obtuse, but I don't really feel like the language is missing anything I need to lay out an application that adapts to any screen it's presented on.

chrisjj12• 2 years ago

Agreed. Yet still the CSS spec holds to "a simple mechanism for adding style (e.g., fonts, colors, spacing) to Web documents."

dumbo-octopus• 2 years ago

Even with flex we still don't have a good way to center a list of div's. In fact the intuitive way, `justify-content: center;`, has a hidden foot gun that to this day breaks countless sites on mobile: content overflowing to the left of the parent container is entirely lost, whereas content overflowing to the right is scroll-accessible. And there's no easy fix for this! (Please Cunningham's Law, please...)

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".

skydhash• 2 years ago

What about constraints based layout, so it’s not needed to have all these divs nested inside each other?

IshKebab• 2 years ago

Mm yeah you can definitely do it now, but consider the trivial task of putting two independently scrollable pages side by side.

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.

chrisjj12• 2 years ago

what CSS is meant for, formatting documents on screens. Yet half of us try to beat it into submission building highly interactive applications.

I guess everything would be simpler if CSS defined "document" to exclude interactive interface ;)

eviks4• 2 years ago

Listing a set of rules doesn't not "logical" make.

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"?

Dalewyn4• 2 years ago

You make something wider to fill the viewport.

You make something taller to fit the content.

alpinisme• 2 years ago

That’s a mnemonic not a descriptive rule. People make things taller for style and layout reasons too.

chrisjj12• 2 years ago

I can't see what is logical about that.

bazoom42• 2 years ago

It is logical for laying out text because if a text is larger than what fits on a screen, you want lines to be no wider than the viewport width and instead have the text expand vertically.

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.

chrisjj12• 2 years ago

Good points. And they highlight that the word "logical" needs disambiguation here.

CSS behaviour requires sustantial work to get one's head around. The result includes dramatic change to head shape.

#!important

Flimm• 2 years ago

I wish percentages in CSS were more explicit:

  #foobar {
    width: 100% of container width;
    height: 100% of contents height;
  }

eviks4• 2 years ago

Same idea I had when commenting - this just needs some good old explicit reference (can be optional)!

err4nt• 2 years ago

This exists, you can specify containers and then use 100cqw container query length percentage units https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_contain...

williamcotton6• 2 years ago

How the hell would anything coherent be drawn to a computer screen if the underlying description wasn’t logical?

It might be messy, but it is being processed by a machine that is fundamentally based on logic!

yCombLinks2• 2 years ago

So if CSS had a property named Text-Color that set the font size it would be logical, because it's all based on logic? CSS isn't a mathematical construct based on first principals. It's a spec that was created to layout print-media style webpages in the mid 90s.

eviks4• 2 years ago

Riddle me this: why does this blog list a long set of rules as a justification instead of a single one "because a machine can process it to draw something coherent"? Could that be due to the fact that your definition is irrelevant for this conversation?

wildrhythms• 2 years ago

Selectors are evaluated by a specificity score.

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!

dsego2• 2 years ago

What's more logical than writing `.myClass.myClass.myClass` to overpower a more specific selector. Add in a `div.myClass.myClass.myClass` for good measure.

tauchunfall2• 2 years ago

It's not straightforward.

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).

slmjkdbtl• 2 years ago

Everything is logical, some things have more rules and some things have less

vertnerd• 2 years ago

This is a wonderful article. Now I know to strike "really and truly learn CSS" from my list of things to do in retirement, so I can focus on things that I can actually accomplish.

upghost• 2 years ago

Tangential, but this is the first time I've seen the valediction "Handwritten by". Fascinating statement in the age of AI. Think I'm gonna steal that.

xigoi3• 2 years ago

How things change… The word used to mean “not written on a computer”, now it means “not written by a computer”.

chrisjj12• 2 years ago

The applied style when two selectors match is the one that appears lowest in the Cascade when they share the same origin.

Why is that logical?

xigoi3• 2 years ago

So that you can override styles.

chrisjj12• 2 years ago

PS Now I wonder if this article is intentionally "ironic".

n_plus_1_acc• 2 years ago

How is it logical that when giving padding-top as a percentage, it's evaluated as a percentage of width?

chrisjj12• 2 years ago

Well said.

AltruisticGapHN• 2 years ago

Of course it’s not illogical. That doesn’t mean it’s intuitive. IMHO a bunch of properties should be renamed in more intuitive groups like all the flex stuff should begin with `flex-`

corethree3• 2 years ago

Logical is orthogonal to terrible.

Literally by definition anything designed in a computer must follow logic.

Ygg2• 2 years ago

Says you. I renamed my TRUE to be FALSE 10% of the time :P

PrimeMcFly2• 2 years ago

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.

loloquwowndueo• 2 years ago

“I understand the rules” is not the same as “is logical”.

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”.

codethief3• 2 years ago

your years-long understanding

It's not even understanding, it's more habitualization.

aleph_minus_one2• 2 years ago

Many times I’ve heard someone claim “my native tongue is logical because this or that”

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).

CmdrKrool• 2 years ago

CSS is 'logical' in the same way that a pseudorandom number generator is 'predictable'.

imjonse• 2 years ago

So there must be another reason for why it is confusing programmers more than any other computer language...

aleph_minus_one2• 2 years ago

I think a central reason is that CSS was originally intended for laying out text instead of laying out web applications. So what many programmers do/did with it was something that CSS was not originally intended and thus not optimized for, i.e. a lot of people use(d) (out of necessity) CSS in a very "hacky" way.

chrisjj12• 2 years ago

I think a central reason is that CSS was originally intended for laying out text instead of laying out web applications.

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/

chrisjj12• 2 years ago

Such confusion is entirely the fault of insufficiently logical programmers P;

jgwil22• 2 years ago

Seems like a largely semantic debate about the definition of "logical" is taking place in the comments here. CSS is logical in that it follows a set of rules, but that is the case for every computer program by definition, so it's not informative or useful. People claiming that CSS is not logical probably mean that it's poorly designed and not easily understood by humans, which is probably a question of taste more than anything objectively measurable, though I happen to agree.

magpi33• 2 years ago

probably a question of taste

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.

jgwil22• 2 years ago

I think a good way to think about good design is the Einstein quote on mathematical models, that they should be "...as simple as possible, but no simpler." Normal mode in vi/vim is necessary for that program's goal of keeping your fingers on the center of the keyboard as much as possible: forgoing the use of arrow keys means that navigation and editing have to be separate modes. It's more complex, but only because it has to be. CSS on the other hand seems to introduce a whole lot of accidental, unnecessary complexity.

jkcxn2• 2 years ago

He says "width looks up the tree while height looks down the tree."

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...

magpi33• 2 years ago

But what about if the "parent" is the body tag?

https://jsfiddle.net/6fmu2z8s/

jkcxn2• 2 years ago

It's no different except now you've set parent's height to 100% of its parent, which is the html tag. But the html tag is height: auto so there is a circular dependency. if you put html { height: 100% }, or set parent's height to an explicit height then its fine

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

pcthrowaway• 2 years ago

Interestingly, the body's box there is only expanding to fit its content, but the body's background-color is applied to the entire document

codethief3• 2 years ago

Exactly, this was pointed out in some other comments further down the thread, too.

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).

Towaway692• 2 years ago

One of the weirdest things - for me - about css is that !important means important ... not not important! /s ;)

chrisjj12• 2 years ago

Agreed. The spec needs changing to !!important. Much more logical! P;

Towaway692• 2 years ago

Bang on I would say! ;)

spcebar2• 2 years ago

Well, the ! character is pronounced 'bang', so you can read it as, `BANG!!! IMPORTANT!!!`

g4zj• 2 years ago

Logical and intuitive are two different things.

Depending on the usage of the word "logical", _everything_ is logical, as the universe itself follows some set of rules.

ClumsyPilot• 2 years ago

And computer is a logic machine made of logic gates

graypegg• 2 years ago

    “CSS be weird, but it not be illogical.”

Off topic, is that the English subjunctive mood, but the whole phrase is written in it? I don’t think I’ve seen much content written like that! I have to agree that CSS be weird, but one’s use of the confusing subjunctive mood best be left aside.

emadda• 2 years ago

Another interesting rule: when margin/padding is a percentage, it is always a percentage of the width, never the height.

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.

https://cssprinciples.com/3/grid

CSS Is Logical

Related Stories