All the additions to CSS, JS, HTML, and even the continued growth of frameworks and abstractions, are a choice. You have a choice to limit yourself and your team to a subset of the available tools, and it's a good idea to do so. The web as a platform is a lot of different things to a lot of different people, it needs to expand and grow in order to cater to all. Restricting the tools for your project makes it easier to maintain, and easier to onboard new contributors.
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.
How do you express option/enum types without enums? And if you do that, isn't it more of an unsupported way of doing things than using the native enum type?
The problem is you had a glimpse into ecosystem when it was normal. Now it is increasingly abnormal and new developers will be flooded with all this unnecessary clutter, so the chance they will get lost in the forest of bullshit will become higher and higher. Which will lead to even worse performing tools, pages etc.
> 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.
Just glancing it looks like it would simplify tooltips. Does it have wider implications than that?
Downdown/context menus that are attached to a node inside an "overflow: scroll" element. The common solution is to use a React "portal" or Vue "teleport" to move the element to the root of the body, but this has its own problems around accessibility and can often result in bugs during page transitions.
You don't need vue or react. Just get the x/y coords of the child relative to the parent and attach the dropdown element in an absolute position to those. A little measurement of the window and the elements is all that's necessary. People reach for these stupid frameworks with a million lines of code to do these incredibly trivial things you can do in 4 lines of Javascript.
Tooltips and fixed dropdowns pinned to the position of page elements are already fairly trivial to do... so are modals... so are dialog boxes... so are every other thing that needs to "Pop Up" on your webpage. I predict a very fast death spiral for this tag, in which 99% of the uses will be obnoxious.
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!"
On a large complex single page webapp, it can be very non-trivial to have a popup/modal over everything else in the page. That’s why things like React Portals[0] exist, as well as many, many libraries that provide similar functionality. z-index is not an absolute number and depends on your stacking context.
[0] https://react.dev/reference/react-dom/createPortal
How is what that's doing any different from figuring out element A's desired position in the coordinate space of the body, or in the local coordinate space of element B, and then appending it to one or the other in an absolute positioned wrapper? I've written very large single page webapps that have dropdown menus with sub-menus that are almost entirely CSS with just small amounts of vanilla JS to adjust their screen positions. Sometimes a really lightweight library is useful, but requiring the whole React framework seems like total overkill. On the other hand, adding a new HTML tag for the purpose of popup modals seems unnecessary.
I don't understand these attacks on Google and Chrome. Yes, Blink in general and Chrome in particular are dominant. Yes, Google has a shitload of money. But at least it invests its money in the web platform, which, if you are a web developer, you ought to be grateful for. Apple, in comparison, also has a shitload of money; but until a couple of years ago, didn't seem overeager to invest in web. As for shrunken browser xhoice, isn't it easier for developers to target a few platforms than a host of diverging ones? When you are not in control of the client platform isn't it a relief to have as little variability - and hence as much predictability - as possible? Isn't this the closest thing to being in control?
Google has contributed many good things to the web, but they should always be scrutinized and challenged to prevent them taking over the platform to serve only their purposes. This is the same complaint leveled at Apple.
Exactly. Apple's lack of contribution to the internet ecosystem exactly aligns with their profit motive: Selling hardware.
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.
Yes, there's a very real conflict of interest between their line of business and the level of control they have over the web, and they've not proven themselves willing to abstain from inappropriately leveraging that control.
The IE6 situation happened because Microsoft lost interest in the web. Plus, Microsoft was developing its browser in disregard of web standards. With Google, at least for now, we have a company that is heavily invested in web, AND, what the article strangely complains about, is heavily involved in web standards, to the point where it becomes a driver for some of them.
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.
This is a bit inaccurate, oddly. At least, for my memory, IE6 was genuinely better than Netscape at the time. They did make some odd choices, such as border-box, but by and large Netscape was stagnating hard. That said, I remember the fieldset and legend styling was much better in IE than it was in Firefox. And, amusingly, I have grown to prefer border-box for sizing.
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?
Yes, there was a dark period (early 2000's) where IE 6 was basically the only usable browser. Netscape was far behind, and also incredibly unstable (crashing hourly.) Firefox wasn't out yet. Chrome was years and years away.
They did a Big Rewrite which was somewhat bogged down by feature creep.
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.
Part of the problem is that when Google really wants a feature for themselves, they'll plow through and implement it in Chrome regardless of any concerns raised or input offered by Mozilla and Apple, creating "nonstandard standards" much like those created by IE.
IE6 becoming standards non compliant was deliberate. Not because MS lost interest in the web.
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.
There's a growing number of people who are adults years into their careers who have only known a world with a dominant Chrome. Stuff like this is cyclical because new generations come, and no one tells them about this stuff. Or if someone does, they don't take it seriously.
Blink was forked from Apple’s WebKit, 8 years after WebKit forked off of KHTML; Apple’s invested plenty in the web.
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.
>but until a couple of years ago, didn't seem overeager to invest in web.
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)
Exactly -- in a Web 2.0 world where everything is siloed into proprietary, closed platforms like Reddit, Facebook, Twitter, etc., Google AMP looks like an angel.
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.
What you call investing in the web I call making the web worse by making browsers very complicated (which is good for Google because it makes it so that only the largest corporations can afford to compete with Google, e.g., in offering a fully-functional browser).
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 didn't find there to be much substance in this article. I would have preferred more examples of ways in which there are "too much CSS", and the ways in which it is a "continuing tradgedy", instead of a retrospective about the wider state of the web. The measurement units section was interesting, the introduction had me primed to expect more of that, but I was left generally wanting.
My three examples of "CSS bloat" - by which I mean "interesting but do we really need them?" are:
+ 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).
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.
Fully agree. Seems like the author pointed out one thing - that there are increasing numbers of units usable in CSS, doesn't really talk about why that's bad, and then wraps it up.
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.
Come on, man. "There were three units (and 5 more that that I personally never used and didn't realize were critical for proper print.css stylesheets because I never printed anything). Today there are 18! A six-fold increase"
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.
The post doesn't say "There were three units". That's a quote you made up. The post says "the original CSS specification included 3 relative units". That is factually true. The original CSS spec lists only em, ex, and px as supported relative units, which are distinct from the five absolute units you accused them of leaving out.[0] Accusing someone of lying while lying about what they said is a bad look.
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.
I don't think the OP is necessarily arguing against the growth of CSS per se, I think they are arguing that CSS development is being pushed forward by an increasingly small group of people and companies.
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 more complex the languages for building web pages become, the more complex browsers become, the harder it is for someone to build or continue to build a Chrome alternative, the harder it becomes to challenge Google.
The more complex these languages are, the more SEO content gets generated ad nauseum.
Yet it is impossible to learn CSS from searching Google.
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.
It's never been easier to build web pages. Never been easier to build a browser.
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.
> It's never been easier to build web pages. Never been easier to build a browser.
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?
Yes they did. Because they do not care about a good browser engine product. They care about selling services on top of that. So whether it's Chromium or something else entirely, they don't care. They went with what had the most external developers working on it because again, they do not care about the engine.
>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.
The only issue I see is that people don't want something else entirely, they want their web pages. CSS/HTML features are deprecated but browsers continue to support them forever and make their engines more complex because... people won't adapt (for good and bad reasons).
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.
> The more complex the languages for building web pages become, the more complex browsers become, the harder it is for someone to build or continue to build a Chrome alternative
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.
I'm pretty good at CSS. Getting good at it is not a straight line with perfect logic, like say Python. Browser issues, different ways of doing the same thing, cascading in general. I get the issues. But a) we have no serious alternative at this point, and b) the answer isn't frameworks.
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
"But half-decent semantic HTML with some custom helper classes can make Tailwind entirely unnecessary for most tasks."
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.
I work on part of a pretty CSS heavy team as part of a large application.
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.
Found this article click-baity with its title. It doesn’t deliver on the premise of CSS becoming worse. And it doesn’t either with its claim that it’s led by out of touch dictators.
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 been writing CSS since 2009 and though it's always been a love/hate relationship, I didn't feel this way until last week. Not sure how new this is, but "dynamic viewports" are now a thing in CSS. The "dynamic viewport" is the area not obstructed by the browser UI.
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.
Having controls at the bottom isn't user hostile, it's the fact that it obstructs the space allotted for developers. This makes it much harder to develop mobile sites - in my experience a very large minority of sites fuck it up, and it makes the mobile browser feel like a worse experience.
Like, you drag a window over your browser, and the viewport values change? I'd not have expected that, and I don't think I've ever noticed that behavior. How does it account for all of those sorts of things (browser-provided login prompts, or browser settings windows, or certificate-info pop-downs, or non-browser windows being dragged on top of part of the browser window) not necessarily resulting in a viewable area describable as a rectangle?
Sorry I should have been more specific. The viewport is merely the window of the browser itself where the website is rendered. The calculations given to devs reflects that area, and it does change if the user resizes their browser. But it doesn’t change if something is displayed on top.
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.
It's just... vexing to have "viewport" units in the spec, but then the user agents are just drawing stuff on top of the "viewport" but not changing its reported size, so now we need additional "real viewport size" units...
It does before user scroll down the page a little. That's what he called dynamic viewport being added to spec. It was to address issue of incorrect viewport height (100vh) when the toolbar is visible. So units such as svh, lvh, and dvh are added.
You often need to base your styles on the height of the viewport, for example if you need to pin an element to the bottom of the screen, or if you need an overlay to fill up the entire screen.
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.
The more realistic explanation is that the toolbar takes up space and every pixel has value on smaller screens. Moving the toolbar out of the way when the user is not likely to be using tools makes sense when understanding the web from the perspective of someone reading articles.
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.
(1) the browser is an application platform so devs are users as well, (2) making it harder to develop good UX by not following the spec _does_ make the experience worse for end users, and (3) "hovering elements and overlays" were just a couple of examples - there are tons of reasons why devs need to reliably know where the boundary of the fucking screen is.
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.
I consider the web's growth in capabilities a positive because it's the only independent computing platform we have, despite Google's large influence on it.
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.
I think that’s largely because there’s no job out there titled “CSS developer”. CSS is expected to be one thing among 14 others that a developer is expected to know.
I'd like to see vector-driven challenges to web standards. For one, we could bring back WYSIWYG under vectors by having grids with "stretch zones" that allow for larger devices. Constraint and flow-based layouts often grow highly convoluted for those of us who need to be generalists (full stack devs). Not every project should have to hire a CSS Sheldon Cooper to get Hello World in the right spot. (SVG and Canvas lack most the Input elements.)
> Yet when aspects of frontend development not involving JavaScript are seen as ignorable by employers, few will get this opportunity.
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."
I fear that, basically, decloak's little hot sauce and menu website might be the cause of this. His basic premise seemed like he was arguing that tables can easily describe the UI's we seek.
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.
Ok, 36 relative units does feel excessive. Reading each of the names, I can understand why many were added. Still, that is a lot and I can't imagine there are more than a handful of folks that can correctly use most of them. I'd also wager that the odd interactions that you are certain to get with them has to be a nightmare on large teams.
For implementors it is probably a lot (while it's trivial math usually once resolution etc. is known)
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.
outside of Q, I think I've used most all of these in one way or another for various reasons. Most can be done with calc() and whatever the nearest root value is - but some of them are handy, even if they don't appear so.
Again, going on the name, I can see easy justifications for most of them. I, sadly, can also imagine the rabbit hole that is justifying any particular one for a document. :(
The fundamental problem with CSS is that it conflates element content styling, layout directives, and compositing configuration into an unholy mess.
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.
Have a single common bytecode language for all web dev, including scripting, content definition, and UI.
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.
Like Java applets or Silverligt? The problem with those formats is they are black boxes - you can't link or search or anything which makes the web accessible and interconnected. They are more like apps than the web.
HTML is not an alternative to CSS. The HTML still has to be presented in some way. HTML without any CSS just means it uses the default browser-supplied style sheet.
I mean throwing out HTML and HTML attributes altogether and starting from scratch. It's time to evolve out of PostScript, Portable Document Format (PDF), SGML, HyperText Markup Language (HTML) + CSS + JavaScript, markdown, and move to a fuller open document standard that brings all the amazing features of the old formats without all the baggage and mistakes. Just get rid of the crappy stuff and focus on the good stuff.
I'm reasonably happy with current CSS for the most part, but...
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.
I generally look at https://caniuse.com/ . If support in the major browsers was green for a few years, I assume it's okay to use without further thought.
I've been watching the videos of the ladybird browser development, and how it improves it's css compatability. I'm eqal parts impressed and aghast. The standards seem overly complex, and very hard to be compliant. It amazes me how so much code is executed to implement css, and how slow it can be requiring great feats of SW engineering to make it peformant while still correct. It's no wonder there are so few independnt browser engines. Surely something a lot simpler and saner could replace it?
> developers no longer needing to understand pre-processors or other tools. Sass served the community well, but as CSS slowly morphs into a (more evident) programming language, its days seem numbered.
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)
I still prefer good old fashioned plain HTML. If you want an app, write an app. Keep the web HTML and accessible to author by anyone rather than require one become a programmer of someone's proprietary scripting language.
"Hopefully, I won’t regret saying yes to speaking at UX London. I certainly haven’t regretted saying yes to speaking at CSS Day eight years ago, not least because Peter-Paul and Krijn kindly offer me a badge for each subsequent edition"
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".
I wish people used CSS for semantic tagging, to take over some of the role that JSON-LD and all the other half-baked standards for adding metadata and annotations to HTML. Why do we have the Rube Goldberg machine called ARIA when we could use CSS attributes to express the same information quite naturally?
I've not investigated it to prove my hypothesis, but I've long suspected that CSS doesn't get enough of the blame for the modern Web being so bloated and resource-hungry.
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.
POST TL;DR: CSS Day 2023 highlighted the increasing complexity and breadth of CSS, with more units and modules than ever before. While the growth presents opportunities for specialization, there's a concern that CSS and open standards are being controlled by a narrowing group of implementers, particularly Google. Despite this, CSS and HTML continue to evolve, making web development more accessible and the web more functional. The web's progress has been influenced by both European collaboration and American innovation, leading to its constant evolution. The conference underscored the need for the CSS community to grow and thrive to counterbalance the dominance of Silicon Valley giants and ensure user-centric development.
What I am seeing is that AMP-like technology lets you incorporate readers into social platforms or document classifiers to make very interesting applications. Granted you used to be able to make things like Stumbleupon with <iframe>s but note you were always free to write AMP consumers but I've only seen people really try it recently. If you quit hating on it you might realize it's a way to reverse ten years of enshittification of news sites.
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.