As someone who actually likes a lot of the languages that developers like to hate (bash, JS, css), I like this take on CSS. That being said, I think the problem with some of these things isn’t that they behave according to specifications but that the specifications don’t default to sensible defaults (“defaults matter”): the default overflow behavior is basically what no one wants; same with padding being outside the border (fixed by border-box); and with the way margins of child elements collapse into the margins of parent elements.
I think it would be less surprising if you had to opt-into text overflowing the border-box: the current behavior is like the behavior of floats, which always ended up being something you spent a lot of time working around.
If I say `width: 32px`, I want the width to be 32px, cropped, because that's what I asked for. This is really a question of what the default value of the `overflow` property should be.
Ok, I would disagree that cropping is the best default. The overflow effect is typically unintended (eg. the new design was never tested with the German translation), but at least you can read the text if it happens. Silently hiding content would be way worse for the user IMHO.
You might deliberately want to crop text to get some particular visual effect, but I cant see why you would want it to be the default for all text.
The issue is you are putting a bigger box inside a smaller box. There is no perfect way to solve this, but css defaults to respecting the specified sizes by letting the inner box overflow the edge of the outer box. Seems reasonable to me, and you can get scaling or scrolling or cropping instead if you specify so.
Collapsing margins was a sane default in the original use case of CSS - text documents with sections and headers. But it is not intuitive when working with GUI components.
Even when I'm writing HTML documents, collapsing margins doesn't make sense. I'm sure there's some historical reason here, but it's been a surprising default as long as people have been writing CSS. `thing+other-thing { margin: 0; }` (or `thing > other-thing:first-child { margin: 0; }`) is a lot more explicit and less likely to be surprising. (And, yes, I've been writing HTML+CSS since CSS was first released)
Part of the reasoning here is that I’ve fixed a lot of style issues where someone allowed the content of an element to overflow its boundaries. While this might be ok in some contexts, it creates a lot of weird edge-cases in any moderately complicated page and the cause of the issue is invisible. With cropping, you can see the problem much more easily because the content is just cropped or otherwise cut out.
No. It is unreadable even with descent preparation. Compare WPF grids with CSS grids or flex. People struggle with the latter after months, while the former you can understand at first shot. The design is extremely bad.
IIRC (it has been years since I've worked with it) Windows Presentation Foundation does not entirely cover the same problem set? I mean to say, that I believe the solution space of CSS - the problems which can be solved with it - is much, much larger than that of WPF. I'm open to being updated, but can't everything that WPF does be done with CSS media queries + absolute positioning?
> I didn't make any claim about how many platforms it runs on, though.
We should probably define terms. You mentioned that HTML + CSS make a terrible design tool. I suppose that's true in the same way that C++ is a terrible design tool. Most designers don't touch CSS, and use Photoshop or Figma or similar and hand it over to a frontend engineer to actually implement it. You might be using the term design tool differently from how i understand it though.
LaTeX wasn't half bad (for its time). Most of its sins are the strange way that transforms gets done and functions are applied. One could imagine a latex-ey css that punted crazier function calls to js.
I'm sure someone will tell me a bunch of downsides. But I recently did something small on the web, css seems much easier then it remember. I really liked the flex box stuff and the vw and vh size. Idk when they got introduced, I guess it's been a while for me lol
I appreciate the simple way CSS is written, but I find myself struggling with it quite a lot even after many years of actively using it. I think there may be something in the way it's been designed that is preventing me from having the moment where it all clicks. I want to be able to think, "ohh that's how that works, now the rest is falling into place", but instead I'm hacking and slashing and failing forward until something looks the way I want. Every time. I don't know for sure if that's me not being smart enough or if there's some design flaw that's preventing a clear mental model. If anyone has any good resources for that I'd love to see it.
This started improving for me recently when I spent more time really learning flexbox and flexgrid. They are part of CSS so no installs needed. It’s a different way of thinking but I’m finally good enough with flexbox that I can tell when I need it and make productive use of it. Knowing these patterns makes a difference for me, since now I can assemble the blocks better than before when I’d just try mostly random css without any guiding principles.
Flexbox froggy helped a lot with some practical experience that translated fairly well to my regular work.
There are other games like this that I haven’t gotten to yet, including one for flexgrid. Once I clear all the levels in flexbox froggy I’m going to try the flexgrid game.
Then after that I’m going to spend time with bootstrap and tailwind since the last time I really used them was back in my more junior days when I barely knew anything at all about css.
My advice is to just learn a framework and let other people deal with the details. This article makes it seem like CSS is as easy to work with as pencil and eraser. But a lot of the complexity is arbitrary due to either history or fashion
The optimist in me hopes that one day the web is built on HTML, vanilla JS and CSS only (or languages comparable), but it's so good that no frameworks are needed. Until then, you may be right.
That is my favorite stack. :) I call it pure JS but I like vanilla JS too.
CSS is super powerful and I love how much you can do with it. I’m still scratching the surface, too. I’ve been using it for years for common things as a full-stack dev but it’s only really the last six months that I’ve really begun to stretch myself with it.
The power it has for animations is impressive too, for example. I spent a lot of time on just that and flexbox and flexgrid and it made me go from hating CSS to really liking it.
> I’ve been using it for years for common things as a full-stack dev but it’s only really the last six months that I’ve really begun to stretch myself with it.
It's incomplete, it's not good for testing layouts, etc ... but it was useful to me when I didn't know what the defaults did.
(I should perhaps rewrite it now to be more complete and less cruft-filled - this was written when I knew less about JS and CSS than I do now).
[1] No special reason - there are too many, and most of them seem bloated for what I need. I'm sure react solves real problems, but I find it's shorter to solve my problems using whatever I've already written and understood than learning a whole new framework.
Hey, this is really cool! Part of the struggle is definitely getting a feedback loop set up so that people can see what the css actually does. Especially when you’re trying to build a product at the same time. This is neat because it could let me see the benefit of some styling in isolation pretty easily.
Enjoy the rewrite! I love that feeling of rewriting something with new knowledge and finding all kinds of gains while doing so.
Learning the order of padding/border/margin and how they interact with each other and width/height was the tipping point for me. There used to be a good article on mdn for it, but their introductory page now looks like a bad replacement to me: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_box_mod...
If nothing else, the image at the top is more confusing than it needs to be, the old one was much better. It didn't used to refer to edges, but the margin/border/etc itself, which is what you're actually dealing with in CSS.
If the reason for that makes sense to you, I think that makes you well above average among frontend devs. All the new stuff like flex and grid is still built on the box model after all.
My aha moment in CSS was learning the rules of specificity, when one rule overrides another. I had always assumed on some level that later rules override earlier ones, which is true, but only part of the story.
I'm really confused about what's meant to be good about Tailwind.
I recently ran create-next-app with Tailwind, and the default example output page has several divs with 600+ characters of tailwind class names. Each! Without word wrap most of the page's style information is way off the right side of the screen, and with word wrap the page source is mostly class names. Is this how tailwind pages are meant to look?
Also, with tailwind the page's style information is all in class names - which are plaintext, with no syntax highlighting or code hints or linter errors. Do people using tailwind maintain styles that way, or is there a quasi-mandatory plugin or something?
The only obvious benefit I see for tailwind is that style rules are tied directly to the markup they modify. But if I use any SFC framework like vue or svelte, I can have scoped CSS with the style rules right next to the markup, and I also get legible style rules, code hints, CSS variables, and everything else. What is it that tailwind makes better?
Hmm. Thanks for the link; I can see where that argument comes from.
But doesn't that entire line of thinking disappear if one just uses scoped CSS inside components? Everything in that link assumes that all CSS rules are global, and it runs through BEM and then tailwind as a way to avoid putting component-specific rules in the global CSS file.
But if you just use a frontend framework with SFCs, you can treat each component as a module with its own local style rules. If there's no global CSS file to edit, don't BEM and Tailwind become irrelevant, since the problem they solve no longer exists?
Yeah, actually! I'm using it at my current internship. I like it because the syntax is shorter and is sometimes reworded to be clearer, but there's still some flaws in Tailwind. To use the shorter stuff, like mt-8, you have to first know that mt stands for margin-top, which means it's not replacing knowing CSS to some degree first. Writing my styling inline is also not amazing. Working with their documentation is a breeze though.
I don't get this exactly:
> Or you know, how about we just make the box bigger so it fits the text, we could just get rid of the explicit width and height and everything will just work.
Doesn't the out of the box styling give you just that:
<div>{arbitraryContent}</div>
Except that CSS explicitly avoids having a solver, so you can't refer to that size anywhere, and if you want to do anything besides the trivial "flow the content until it ends", you can't.
So yeah, if you want to have any elaborate design, you can't just let the box be sized by its content.
Btw is there an update of the "CSS is Awesome" mug/t-shirt motive [1], possibly representative of the CSS issues we have today ;? Asking for upcoming gift season ...
The problem with css is that it's a horrible design language, terrible from a developer perspective, and abysmal from a performance perspective both on the network-side, server and client side. In-fact it would be difficult to come up with a standard for transmitting information, layout and style specifications over the Internet in a worse and less efficient way.
Most web-pages size is 1MB or more while the text is usually 1-2Kb. That means we have roughly 1000x spent on styling/layout in relation to content. I wrote a post about this back in 2006, still true. https://gregraiz.com/graiz/2006/09/25/ten-reasons-why-css-su...
I’m not sure I agree or at least understand how a page could be sending 1000x more styling data than the raw HTML without a heavy un-optimized framework or heavy JS injection.
That post feels... very 2006, and it may be worth revisiting CSS with fresher eyes, because almost none of that seems to true to me any more.
Cross-browser compatibility is very rarely an issue that I actually run into any more; flexbox and CSS grid have solved a lot of your concerns about layout options; there aren't a lot of areas of duplicate functionality (especially in rounded corners); CSS is declarative (I just didn't get this point at all - parsing CSS is rarely the bottleneck in modern browsers); and CSS is a lot easier to use than it used to be.
I think the most important point is that the comparisons with things like Word or PDFs miss the most important thing that CSS/web design needs to do, which is work for any browser size on any device in a huge variety of contexts. A PDF is, as you say, design-centric in that I draw a design on a screen and that design, exactly, is reproduced in the file and therefore on someone else's screen.
But the tradeoff made there is that the PDF file they open will be the exact size and shape that I've chosen. With websites that's just not possible. You might be on mobile, you might be on a desktop with an extra-large screen, you might be on desktop but with the browser window snapped to the side so you can view something else on the other side of the screen, or you might just be using a particularly unusual monitor with odd proportions. The promise of CSS is that my design will still fit your browser window well, even as you resize it.
This means that rather than say where I want my image to be, I need to say how I want it to fit on a generalised screen. Or rather than define N columns, I need to define a grid with automatic columns of a certain width. This, it turns out, is very hard to encode in existing PDF-/print-oriented software where all sizes can be hardcoded.
I'm very unconvinced by your idea that there is 1000× more CSS to can content. In my experience, the single largest contributor to web bloat is tracking scripts, followed by other forms of JS, followed by images. CSS is very rarely so big an issue unless you're pulling in an entire CSS framework.
i mean it kind of depends on what of the new stuff you actually want to use.
as a general example aspect-ratio is a neat property but was only introduced in safari 15. there's still a bunch of people using versions of safari older than that. :has came out around the same time.
I was hoping this would be an article about how fucking cool the cascade is. When you're using a JS framework it doesn't necessarily come up as much anymore, but look at how much you can do with just vanilla CSS because the cascade is so well-designed.
> CSS makes the common things that nearly everyone wants to do unnecessarily hard.
I'd like a list of those, along with a solution for each item in that list.[1]
A CSS cheat-sheet, if you will.
[1] I remember it common things being unnecessarily arcane, but since flexbox and grid, I can't think of any problems I might have. Although, take my words with a barrel of salt, because I am in no way an experienced CSS user.
What's the argument here? That CSS doesn't suck because there's a self-serving snake oil industry publishing explainer articles about CSS which is at the same also pushing for ever more CSS complexity as the browser cartel is pulling up the ladder such that no browser can be coded from scratch, ever again? At best, CSS could have served as an experiment for collecting requirements for the "real" successor and replacement language.
CSS does, in fact, suck big time. The yardstick never was arbitrary complexity. Do you really believe Gen Z+ has nothing better to do than to pick up the boomer shit that is CSS?
CSS proponents are well advised to conduct a language review, return to CSS "levels" and/or device profiles or other means to break it down into manageable chunks that can actually serve as a basis for implementors.
Or provide a formal semantics rather than a disorganized set of tenths of "modules" not really deserving of that term that are compiled into a pointless "snapshot" every two years or so.
Or layer CSS functionality on top of primitive layouting/plugin capabilities such that newer parts of CSS can be provided as reference implementation in JavaScript on top (ie what the dormant Houdini API was attempting to do).
Basically, anything to organize a project of the size of CSS when the criticism has been loud and clear for many years now. But W3C, Inc. does nothing of the sort, hinging on the CSS WG as literally the last bit of influence it has over the web, and apparently in financial dependency on Google as the sponsor to have an interest in weak standardization bodies - the only other sponsor being from China since last year?
