CSS Is Logical(geoffgraham.me)
geoffgraham.me
CSS Is Logical
https://geoffgraham.me/css-is-logical/
108 comments
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).
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).
But what about if the "parent" is the body tag?
https://jsfiddle.net/6fmu2z8s/
https://jsfiddle.net/6fmu2z8s/
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
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
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
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"?
> 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"?
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.
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.
I wish percentages in CSS were more explicit:
#foobar {
width: 100% of container width;
height: 100% of contents height;
}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...
Same idea I had when commenting - this just needs some good old explicit reference (can be optional)!
[deleted]
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
CSS behaviour requires sustantial work to get one's head around. The result includes dramatic change to head shape.
#!important
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!
It might be messy, but it is being processed by a machine that is fundamentally based on logic!
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.
Yes, it would still be logical. You translate from English “Text-Color” to font size. To a computer there is no meaning in what the words ever meant. There is just the logic of the parsing and execution. For example, it’s “font-size: 20px”, which is not English and already requires translation. That is would be “Text-Color: red” and that results in a font size of 20 pixels in a consistent manner is still logical!
It’s rather nonsensical though, you would have to admit. CSS isn’t a spec just for computers to parse, unless you consider it a write-only language written by savants.
The divide here is that I’m thinking in terms of a computer.
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?
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?
I think a more apt argument to make is that "text-color" means absolutely pig latin to those who don't speak English.
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.
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.
Very good point! I guess for English natives the insight would be in Japanese, "text color" is テキストカラー (tekisuto karā), and "font size" is フォントサイズ (fonto saizu).
テキストカラー: 20px;
vs
フォントサイズ: 20px;
テキストカラー: 20px;
vs
フォントサイズ: 20px;
That's just literally transcribing English to Japanese using katakana, to be fair.
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.
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.
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?
Because a computer can take more than one instruction, right down to the CPU. Is ASM not logical?
This doesn't address my question
The author is missing a key understanding of how computers operate and any thesis that the human language is illogical to the computer system misses the point.
Logical and confusing are two different concepts and I’ll leave it to the reader to ponder why.
Logical and confusing are two different concepts and I’ll leave it to the reader to ponder why.
corethree(2)
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.
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.
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".
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".
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.
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.
Agreed. Yet still the CSS spec holds to "a simple mechanism for adding style (e.g., fonts, colors, spacing) to Web documents."
What about constraints based layout, so it’s not needed to have all these divs nested inside each other?
> 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 ;)
I guess everything would be simpler if CSS defined "document" to exclude interactive interface ;)
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
[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.
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
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 */
}
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.
- 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.
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.
> - 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.
Unsafe. Many A4 docs from spreadsheet to kids illustrated book are wider than A4.
[deleted]
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.
> 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.
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.
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.
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-`
Logical is orthogonal to terrible.
Literally by definition anything designed in a computer must follow logic.
Literally by definition anything designed in a computer must follow logic.
Says you. I renamed my TRUE to be FALSE 10% of the time :P
> 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.
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.
Right. So that's my point. Css is logical. The point made by the article has no point.
A claim that css is terrible, has a point.
A claim that css is terrible, has a point.
> Right. So that's my point. Css is logical.
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.
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 disagree. The colloquial understanding for logic is technical. OP is using the term incorrectly and in a strange way. I understand that most of us can still 'understand' his point but that does not mean he's using the term colloquially or correctly. Think about it.
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.
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.
How is it logical that when giving padding-top as a percentage, it's evaluated as a percentage of width?
Well said.
CSS is 'logical' in the same way that a pseudorandom number generator is 'predictable'.
Is “has rules and features” the same as “is logical?”
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.
: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.
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.
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.
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.
Debug or a flowchart for computed properties would be amazing for learning.
Doesn't help that there is a lack of internal consistency between properties and that things just got bolted on over time.
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.
The main example I'd give of that is laying out elements. Best practice, at one point, was putting two inline-block divs next to each other, then it changed to 'everything flexbox,' then it changed to 'everything grid.' In my experience, really, you wouldn't lose a job for using any of the three of those, as long as you're being conscious of the limitations of each method, and, in specific cases, each is the right tool for a certain job. Best practices change in lots of languages, and paradigms shift. CSS is flexible, and has always felt a little more like art than science. I get why a lot of people don't working with it, I enjoy writing it though.
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
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 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.
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.
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.
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.
Soparation of data and style allows users to easily customize how your app looks, just like with documents. Using Tailwind is user-hostile.
I'm sorry but that's just not a realistic concern for a developer to have.
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.
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.
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.
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.
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.
Sure, CSS is hard and Tailwind makes it easier. God forbid people choose the tool with better DX.
A tool versus a toy.
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.
Depending on the usage of the word "logical", _everything_ is logical, as the universe itself follows some set of rules.
And computer is a logic machine made of logic gates
“CSS be weird, but it not be illogical.”
So there must be another reason for why it is confusing programmers more than any other computer language...
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.
> 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/
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/
Such confusion is entirely the fault of insufficiently logical programmers P;
>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!
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!
>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).
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).
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.
PS Now I wonder if this article is intentionally "ironic".
Everything is logical, some things have more rules and some things have less
“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”.
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”.
> 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).
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).
> your years-long understanding
It's not even understanding, it's more habitualization.
It's not even understanding, it's more habitualization.
nice and terse
One of the weirdest things - for me - about css is that !important means important ... not not important! /s ;)
[deleted]
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...