The continuing tragedy of CSS
paulrobertlloyd.com
paulrobertlloyd.com
I do this with TypeScript on my current contract, I limit its use to almost "JavaScript with Types", only using features (other than types) that have made it into core JS.
I understand the anxiety over the ever increasing pressure to have knowledge of all these APIs and features, but you don't need to. Being a good developer is having a wide but shallow (even only knowing the existence of something) understanding of the platforms. Enough to start. No "real" developers code without constantly referring to docs, or Googling (or using chatGPT) to help.
Personally there are a few new things coming I am super excited about. To call out one, the new "popup" element will apparently have its own stacking context, elevated to the top compositing layer, no mater how nested within other stacking contexts the node is. That's going to be the best things since sliced bread, lots of code I can simplify, bugs that will be easier to close. Other people won't have a need, and so don't need to even touch it.
(this does not concern many people though - this is still somewhat important, a complex spec reduces potential implementations)
Plus, whatever you can find under the "Reference" section: https://www.typescriptlang.org/docs/
type Option = “foo” | “bar"There is an example in the "Objects vs Enums" section of the Enum docs, at the bottom of the page: https://www.typescriptlang.org/docs/handbook/enums.html#obje...
Just glancing it looks like it would simplify tooltips. Does it have wider implications than that?
You know how, uh, ad blockers used to be called "popup blockers"?
There's an order, a z-indexing that creates a syntax and a hierarchy in everything you build. Sometimes you have to jump it with absolute positioning. Which already exists for this exact purpose.
CSS itself has suffered from this same line of thinking, like, "what if something has to override a class and override a style, should we call it !important? Yeah!"
Google's involvement in the internet ecosystem exactly aligns with their profit motive: Putting relevant ads in front of individuals based upon data they've gleaned from relatively "un-sexy" sources like search, analytics, libraries, font hosting, email, chat, etc.
I'm not opposed to companies making a profit. I try, however, to keep in mind conflicts of interest when choosing my sources of information. Everything anyone at Google says about the web is suspect because that is a conflict of interest. Google, as an organization, exists to turn web traffic into profit and should always be considered accordingly.
Yeah, you get corporate fingers in the cookie jar, but at least you can still recognize the cookies (i.e. webpages).
This is particularly pertinent with what is going on with Reddit. Imagine if subreddits were actually just portable HTML+CSS+JS websites built on a common framework produced by Reddit Inc, instead of bits of data in their proprietary databases.
You dont remember IE6 do you?
IE6 was stagnant and non-standard-compliant. The horror for developers, as far as I understand, came from the fact there was another, much more rapidly evolving, web browser, and they had to maintain compatibility between the two.
Now, as time went on, IE became very stagnate and upset folks by not adding more and more. So maybe it depends what time we are talking about here?
I remember reading Mozillazine back in the day, breathlessly anticipating the shiny new version.
Some years later I stopped waiting, and gave up.
They were rewriting not just a browser, but also an Outlook competitor and a WYSIWYG webpage editor - and while doing that, they decided it would be cool to create a universal GUI runtime for all of them, powered by the browser engine itself!
In a way, it was an amazing effort (without which we wouldn't have Firefox and Thunderbird), but it was definitely more than most people expected of them.
And IE6 becoming stagnant was a result of MS's deliberate attempt to bake IE6 into the OS itself, which made it a ridiculously complex piece of software to change safely.
Again, not because MS lost interest in the web, but because MS thought they could use their ownership of the desktop OS to own the web, rather than by innovating through a web browser.
And frankly, if it wasn't for the EU they may even have succeeded. You can already see how they would have done that with some of their actions today, where opening a link from a Windows search will open the link in Edge irrespective of what your default browser is, etc. If it wasn't for the EU antitrust ruling forcing them to separate IE from Windows I suspect their actions to push IE6 would have been even more aggressive.
As a web user, I'm definitely not grateful for this.
Google tries the same with web and Chrome as it's de facto standard browser.
It should be one HTML standard not one browser's interpretation of it.
Can see why they didn't invest in web when they didn't want linking to work in apps on the iPad, except in specific cases:
They used to be very proud of their JS performance and so on.
But then in recent years they seemed to coasting.
Hopefully now they are back on to it, maybe the threat of being forced to allow alternative browser engines has them to focus.
Who knew completion might actually be good for innovation and capitalism….
Autocompletion, perhaps? I suspect you meant "competition".
Do they support new things as quickly as Chrome? No. But some of their most important investments have been in supporting less, not more: a decade ago, that meant killing flash to preserve security and performance; nowadays it’s about killing adtech to preserve privacy.
FTFY
or maybe they invested in the stuff they thought was worth investing in instead of what Google wanted - like better accessibility features support or more advanced color profiles which Google and FF still haven't implemented even though they said years ago oh it's coming "this" year (perhaps using JavaScript this, hence the confusion)
i made htmx.org and hyperscript.org, and I've been using CSS on and off for two decades now
still spend an inordinate amount of time making things look/work right in a way I never did when I used the old apple UI layout system (springs/struts)
¯\_(ツ)_/¯
I think there's a general anxiety some devs have about how much CSS has been developed in the past few years, and I think that partially comes from not being able to keep track of all the changes anymore. Like it wasn't uncommon a few years ago to have a few CSS experts on your team that felt comfortable with every single thing in the CSS spec, but now that's becoming a little less common as the spec and implementation in browsers evolve and grow. But I think that doesn't mean there's a "tragedy" of CSS. I think it means CSS is becoming more complex, but to me it's generally been in the right direction.
+ CSS Colors[1] - very nice to have, but do we need all of them? Given the chance, I mostly stick to oklab() and oklch() nowadays; I don't see myself reaching for color('a98-rgb' ...) anytime in the near future.
+ CSS Houdini[2] - giving us devs the power to extend the CSS engine in interesting and innovative ways is very exciting ... but a lot of the functionality requires JS help (why-oh-why use JS classes as part of the definition process?) which is going to be problematic for environments that ignore or suppress JS
+ CSS Animation[3] - I like this functionality (the granularity of control is very welcome!), but we also have CSS transition[4] and I've never understood the need to have two animation systems when a single system could have covered all situations (I expect there's a really good explanation somewhere but I've never gone looking for it).
[1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value
[2] - https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini
[3] - https://developer.mozilla.org/en-US/docs/Web/CSS/animation
[4] - https://developer.mozilla.org/en-US/docs/Web/CSS/transition
The clue to them is in the names.
CSS Animation works well for complex multi-step animations. Things where having to think about keyframes and iteration loops and stop/starts isn't an excessive burden for something that'll be used in a few key areas to create something visually interesting.
CSS Transitions meanwhile, is for changes from one state to another (normal <-> hover , checked <-> unchecked). Much more common, simpler visual flourishes that are more about giving hints to the user than visual eye candy.
You mean two-fold. Hyperbole doesn't work when you're flat out lying about the numbers with the evidence for that lie in the same sentence.
And how many of those 18 are commonly used? Because it's not "all of them", not everything on the web needs all of them (a web page doesn't need physical dimensions, an app doesn't need pixels, you don't use every unit for everythi9ng).
Complaining about "what it can do" when you don't use what it can do doesn't make a whole lot of sense. Learn what you need to use, ignore the parts you don't need. Learn those through trivia and incidental "oh huh I didn't know that" moments.
CSS growth is in my view good, but it does sound like having more diverse people and organisations influencing it would be good for the community.
The author also has a footnote mentioning that there are actually 36 relative length units in CSS now, so it's actually a 12-fold increase in relative unit types.
Lastly, I don't think the author is even complaining about the number of units. He obviously has reservations about it, but the main point is to illustrate the growing complexity of CSS over time.
> These raw numbers tell an underlying story; websites now appear in a number of different shapes, sizes and dimensions, and CSS needs to account for that.
The more complex these languages are, the more SEO content gets generated ad nauseum.
Yet it is impossible to learn CSS from searching Google.
https://www.w3.org/TR/css-2022/
Note it is a common structure for standard documents to be written like
"Dates are formatted like the ISO 8601 standard (which nobody has ever read because nobody thinks it is worth 166 swiss francs) except that instead of a four digit year it is a six digit year"
which is absolutely mind bending for people to understand. Maybe with LLMs we can merge a standards documents and 50 amendments into a single coherent document, a prospect I was thinking of attacking with knowledge graphs a few years ago.
I think the way forwards here is to make everything modular. Then people can fork a browser and easily replace a single component. The Servo project has made a very good start on this.
Where problems arise is when people expect to challenge behemoths right from launch. Like demanding your burgers be adopted by all mcdonalds consumers when you haven't done anything to actually compete with them.
And yet, Microsoft ditched its own engine and went with Chrome's. So did Brave and others.
> Where problems arise is when people expect to challenge behemoths right from launch. Like demanding your burgers be adopted by all mcdonalds consumers when you haven't done anything to actually compete with them.
So they should start small and slowly build up the artificial complexity that accumulated over decades in incubent browsers until it reaches feature parity? By then, the other browsers will have another 10+ years of more complexity than you.
I don't quite get what's your point here. Could you give examples?
>So they should start small and slowly build up the artificial complexity that accumulated over decades in incubent browsers until it reaches feature parity?
No, they should find a new angle. What are they building a browser engine for? To go back to the burger example, you cannot compete with McDonalds by trying to do everything they do. Everyone understands this about general products, you can't compete with Apple by making an iPhone clone. You can't compete with Marvel by making funny light hearted hero movies. Yet, when it comes to browser engines people short circuit.
Do you know about Steam? The video game launcher/store. This store is so successful that it's spawned many competitors who struggle to compete. Why is this? Because they do not want to change the status quo too much, they just want their company to be where Steam is. So they spend so much time and money trying to add features Steam has had for years now, all while people refuse to budge because "why use a steam clone that's worse?" Sound familiar?
This is the current problem with browser engines. Everyone just wants to be Chrome, to have Chrome's userbase, but they don't want to actually think about a product. They don't want to find a niche, or make people rethink what a browser should be/do.
Therefore, it's not a problem that people keep failing to be Chrome. I say good riddance. We don't need a Chrome alternative; we need something else entirely.
What you're proposing is basically telling someone willing to build a better web browser to compete with Chrome that they should actually build, say, a music player instead and change the game completely. Even a less extreme example: a browser with a completely different UI still would need to support HTML/CSS and have a super complex engine so we're back to square one. I don't see how that makes sense.
We need more energy and money to be spent into moving this distributed codebase to use newer features so engines can drop support for old stuff and be less complex. Who's going to drop features from their browser only to see people say "use browser X, that one still works with all your existing pages" and then lose their userbase.
If this was easy as ever, as you say, people would have done it already. In reality, it's a multi-billion dollar problem and the incentives don't align.
https://awesomekling.github.io/Ladybird-a-new-cross-platform...
I hate CSS frameworks as much as coders hate CSS. Web architecture is fairly organized when you have HTML, CSS, and Javascript files. I appreciate the modular nature of React, but otherwise, frameworks like Tailwind basically entirely muddy that separation. I can no longer know whether the style of an element needs to be changed in the html or css file. And the html become much harder to read. That's just not better.
I know at some scale, with a very static design system, that Tailwind can speed up deployment. But half-decent semantic HTML with some custom helper classes can make Tailwind entirely unnecessary for most tasks.
I wake up every day happy I'm never using Bootstrap again. Say yes to CSS. lol
True but it never happens. Where is CSS going? Tailwind. Ninjas like you that want to tinker with CSS can work on tailwind...or bootstrap...or something else.
CSS has gotten a lot more powerful and more complex with that added power.
What has struck me most really learning BEM, CSS pre/post-processing, and Web Components is that writing well maintainable and reusable styles is really difficult and different from stock OOP. Not to mention you can make something that looks great and is completely inaccessible.
I tend to lean toward a more simple and brutalist web design, but I am happy that I have the option to do something more complex with CSS if needed.
CSS is becoming more complicated with new features. But these features are much better than rolling your own solutions to styling with JS. It also makes the web more performant and accessible.
I’ve also found the CSS implementers to be very responsive to user input. As an example, check out their survey for designing nested CSS: https://developer.chrome.com/blog/help-css-nesting/
Literally the only reason I can see for this to exist is because iOS Safari obstructs the browser UI with its stupid toolbar. So we're building new additions to the language purely because Apple builds user-hostile features for their mobile web browser. Lovely.
</rant>
(I assume you are talking about the notch, because Safari doesn't have a toolbar that obstructs the page)
Except for a version from 2 years ago that never even made it out of beta ;)
But that has been the default behaviour in any mobile browser since forever. I don't know why he would blame Apple for this.
(Though I don't know how it used to interact with vh)
Can't believe showing user either controls or address bar at the bottom is consider "user-hostile".
It’s true that some temporary browser elements will display on top of the viewport, but these are things like alerts where it makes sense.
To have a permanent fixture that takes up space and then have the viewport lie to devs about the actual dimensions is really frustrating.
And why is it user-hostile?
You can do this in CSS with a dimension called "vh" and "vw" (viewport height and viewport width). If you're using JS, you can use "window.innerHeight" and a few other methods.
The problem is that in virtually every browser, this screen space is respected as the space that belongs to the developer. It would be extremely inconvenient if the "vh" value didn't take into account the browsers own UI. Because then you'd need to adjust your style value to account for that height. Well, iOS Safari does exactly that, and it's been a major source of frustration for web developers for years.
It's hostile to users because it makes developing for the mobile web fairly difficult, and thus degrades the experience. I honestly don't know why they do it, but my more cynical side says that they don't mind sacrificing UX on the mobile web because it competes with their app store.
This behaviour is hostile to developers, not users. A more cynical commenter might suggest that you're the one engaging in user-hostile behaviour with hovering elements and overlays.
Scumbag SV giants need to get snipped no matter how many relative units we have.
CSS can be as complicated as you need it to be. If you have complex requirements, per-media failovers, accessibility switches and the like, it's going to be complicated. If you have one fixed screen, you can go basic.
What's your alternative? Magic?
Welcome to the future. You don't have to like it and you're free to go back to tables. They still work (view the source of this page).
Even if web tech is sometimes messy, these days it can be used to build almost anything you can think of, which is good, as it should cater to a very broad set of needs. I'm fine with there being 26 size units, even if I only use 2.
I think the true tragedy of CSS is that most developers suck at it. They only know it superficially or feel they don't need to learn it deeply because they're using a CSS framework or some crude CSS-in-JS hack. Others might be genuinely interested in learning it, but can't find the time for it, and stick to what they know.
As a result, many spectacular improvements in CSS largely go unused. Even something that can be used for 5 years now (CSS grid) is rarely used today and you'll be hard-pressed to find a developer that deeply understands its possibilities.
Step 1: Establish an implicit narrative that additional language features are mandatory.
Step 2: Identify a gigantic, corporate boogeyman who somehow seeks to use these additional features to control your life.
That strikes me as fallacious. Let's change some words around:
"Aspects of embedded programming not involving C coding, such as maintaining complex make files or boot scripts, are seen as ignorable by employers, so few will get the opportunity."
CSS was indeed, very difficult to make lines go from the top to the content bottom. Or 15 to 20 other various quirks that only worked in IE or only in Firefox or what have you.
I can only guess that Chrome programmers hated that website so much they decided to use it as a way to champion new CSS features. Thus instead of having 0.89 ways (a.k.a. almost there + hack) to accomplish something in CSS, there are 15 ways to do it now.
Is that good? Maybe
Also I HAD to know if he was still around and YES he is. And his main product is STILL for Dreamweaver! That's wonderful I was so worried about that for some reason.
http://www.decloak.com/dev/csstables/CSS_Tables_16.aspx
His extremists update has HN posts from 2019!!!!!!
But for users:
> a handful of folks that can correctly use most of them
That doesn't really matter. For most developers a simple guide is enough, the ones with special needs have to know. They don't have to know all either, but different folks with different subsets.
Everybody else just has to know "there is more" and read up if they encounter something special.
One way out is to rethink each of these separate problems individually. Element styling is typically about configuring attributes, while layout is more closely related with programming (even if it’s a non-Turing complete environment like constraints). There’s no reason why the same language should try to do both.
But not js.
Support programmatic control of content generation, styling, composition, animation, UI events, backend connections, and object-based component reuse with standard libraries that implement each feature across multiple platforms.
Basically the visual/UI part of iPhone/Android dev but in a browser, perhaps with some standard backend APIs.
The amount of duplication in modern CRUD development is just insane. Every project reinvents the same wheels. CSS is part of that because it's so disconnected from the content and the UI that it has to be customised for each project and can't be reused - except as a reset file, which shouldn't even be needed.
I define my font sizes in em and rem. It bothers me exactly 0% that someone else is able to define his fonts in millimeters or pica’s.
Is there a modern replacement for the old ACID tests? It seems like you now just have to assume things will work, or look up / test for support in each browser individually.
It's pretty useful.
Is there a browser-native way of doing mixins now?
The issues is that mixins applied via a pre-processor don't need to take into account the complexities of the cascade. Designing a mixin system that works as part of the cascade is hard, and so no one has yet proposed a system that everyone is happy with.
This is the same reason we can't use var() within media queries to define breakpoints. Custom properties are part of the cascade and so are attached to a dom element, media queries have no dom element attached to them. (The proposed custom environment variables with env() will solve this one)
Geez, what a humblebrag. "Look how I am such an authority that every major UI/UX conference in the world invites me, I hope I don't regret accepting them, I am such weak-willed".
But then, I still remember when it was considered disrespectful to the user and generally ill-advised to ship vector graphics unless absolutely necessary, because it'd offload too much processing on the client and harm performance. Now people do 3D transforms of DIVs and apply blur and such with CSS on every page load because pre-calculating it would be more work (or practically impossible). And they think nothing of doing this, maybe dozens of times on a single page.
each way has it's own tradeoffs and edge cases which you may not realise until late.
none of this helped by the hostility of the web as a platform and the emergent complexities of css.