20 ms·

The continuing tragedy of CSS

113 points by headalgorithm 3y ago

PaulHoule 3y ago
... isn't it thanks to AMP that we have so many "readers" that unlock paywalled news sites?
- Freebytes 3y ago
  Being able to bypass paywalls does not justify AMP. AMP is a threat to decentralization of the web.
  - PaulHoule 3y ago
    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.
centmot 3y ago
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.
- PaulHoule 3y ago
  The CSS specification refers to roughly 50 documents describing CSS https://www.w3.org/TR/css-2022/ 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.
- nicoburns 3y ago
  > 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.
- waboremo 3y 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.
  - gtirloni 3y ago
    > 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?
    - waboremo 3y ago
      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.
- samwillis 3y ago
  Andreas Kling would beg to differ, it's absolutely possible for a small team to build a completely new browser from scratch. https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ https://awesomekling.github.io/Ladybird-a-new-cross-platform...
lagniappe 3y ago
I have a suspicion that on a long enough timeline, eventually CSS will subsume the interactivity of JS for the frontend.
- PaulHoule 3y ago
  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?
- douglee650 3y ago
  This is probably the right answer … for ex. why does css need trig? Well, if you want to transform and animate things, math is very useful.
- bamfly 3y ago
  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.
gherkinnn 3y ago
I don’t follow. Don’t like trigonometry functions, don’t use them. Scumbag SV giants need to get snipped no matter how many relative units we have.
samwillis 3y ago
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.
- jraph 3y ago
  Unless you write a browser engine. You can choose what to implement, but you are highly encouraged to implement what people use in the wild. (this does not concern many people though - this is still somewhat important, a complex spec reduces potential implementations)
- sebzim4500 3y ago
  What other features does TypeScript have? Genuinely curious, I haven't used TS much so I'm probably missing a bunch.
  - nayuki 3y ago
    Enum, namespace, type-oriented programming (e.g. https://type-level-typescript.com/ https://type-level-typescript.com/ ), easy de-sugaring down to earlier versions of ECMAScript (e.g. converting async-await to switch statements). Plus, whatever you can find under the "Reference" section: https://www.typescriptlang.org/docs/ https://www.typescriptlang.org/docs/
taeric 3y ago
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.
- jozzy-james 3y ago
  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.
  - taeric 3y ago
    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. :(
- johannes1234321 3y ago
  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.
recursivedoubts 3y ago
i'm a reasonably smart guy 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) ¯\_(ツ)_/¯
kazinator 3y ago
> 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."
azangru 3y ago
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?
- DHPersonal 3y ago
  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.
  - kitsunesoba 3y ago
    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.
  - LukeBMM 3y ago
    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.
- 3y ago
FigurativeVoid 3y ago
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.
kazinator 3y ago
The proliferation of units strongly suggests that programmers should instead be able to define the ones they need.
Julesman 3y ago
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
- datavirtue 3y ago
  "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.
TheRealPomax 3y ago
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.
- samwillis 3y ago
  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.
- czx4f4bd 3y ago
  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. [0] https://www.w3.org/TR/REC-CSS1/#length-units https://www.w3.org/TR/REC-CSS1/#length-units
B1FF_PSUVM 3y ago
One of the mysteries of life I cannot begin to fathom is how "style sheets" have come to include "page layout".
- tabtab 3y ago
  They have everything else in there, might as well add the kitchen sink. CSS is Swiss Army Rocket Surgery.
- esarbe 3y ago
  Because then you don't have to switch to a different technology if you want to have the same content for print. It's pretty useful.
pupppet 3y ago
Just curious, if you could throw out CSS and start from scratch, what would you do? What's the alternative?
- pavlov 3y ago
  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.
- giantrobot 3y ago
  You could go back to JavaScript style sheets[0]. I'm joking please don't do this it's stupid. [0] https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets
- TheOtherHobbes 3y ago
  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.
  - icedchai 3y ago
    This sounds like Java w/more modern UI.
  - goto11 3y ago
RadiozRadioz 3y ago
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.
- willio58 3y ago
  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.
- rikroots 3y ago
  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). [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value https://developer.mozilla.org/en-US/docs/Web/CSS/color_value [2] - https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini [3] - https://developer.mozilla.org/en-US/docs/Web/CSS/animation https://developer.mozilla.org/en-US/docs/Web/CSS/animation [4] - https://developer.mozilla.org/en-US/docs/Web/CSS/transition https://developer.mozilla.org/en-US/docs/Web/CSS/transition
wwweston 3y ago
> 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?
- samwillis 3y ago
  No, unfortunately. 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)
bob1029 3y ago
This reads exactly like most pieces on why C# & Microsoft bad. 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.
danielvaughn 3y ago
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. </rant>
- SebastianKra 3y ago
  I've seen much hate for the iPhone notch, but "user-hostile" is a first. (I assume you are talking about the notch, because Safari doesn't have a toolbar that obstructs the page)
  - deleted 3y ago
    [deleted]
  - imauser 3y ago
    I think he meant the bottom address/controls bar.
    - SebastianKra 3y ago
      Yep, but that doesn't obstruct the page. Except for a version from 2 years ago that never even made it out of beta ;)
      - imauser 3y ago
        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.
        3y ago
leokennis 3y ago
There are probably 200 ways to manipulate text on Unix. Does this limit anyone in using the tried and trusted awk, sed, cut, grep etc.? 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.
JakeAl 3y ago
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.
coding123 3y ago
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. http://www.decloak.com/dev/csstables/CSS_Tables_16.aspx http://www.decloak.com/dev/csstables/CSS_Tables_16.aspx His extremists update has HN posts from 2019!!!!!!
tabtab 3y ago
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.)
jack_the_dev 3y ago
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 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/ https://developer.chrome.com/blog/help-css-nesting/
dahwolf 3y ago
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.
- whatarethembits 3y ago
  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.
pauljonas 3y ago
It seems we need a CSS: The Good Parts guide here.
alchador 3y ago
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.
tails4e 3y ago
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?
oliwarner 3y ago
This is poor analysis. 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?
- oliwarner 3y ago
  I'll add that adding features has actually made it far less complicated. I'll take grid and flex over double-margin-float hacks any day. 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).
iainmerrick 3y ago
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.
- lucumo 3y ago
  I generally look at https://caniuse.com/ 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.
5350-uiop-1130 3y ago
having many ways to do the same thing is stressful. 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.
Ireallyapart 3y ago
[dead]
pomatius 3y ago
"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".

113 points by headalgorithm 3y ago

PaulHoule 3y ago

... isn't it thanks to AMP that we have so many "readers" that unlock paywalled news sites?

Freebytes 3y ago
Being able to bypass paywalls does not justify AMP. AMP is a threat to decentralization of the web.
- PaulHoule 3y ago
  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.

centmot 3y ago

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.

PaulHoule 3y ago
The CSS specification refers to roughly 50 documents describing CSS https://www.w3.org/TR/css-2022/ 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.
nicoburns 3y ago
> 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.
waboremo 3y 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.
- gtirloni 3y ago
  > 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?
  - waboremo 3y ago
    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.
samwillis 3y ago
Andreas Kling would beg to differ, it's absolutely possible for a small team to build a completely new browser from scratch. https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ https://awesomekling.github.io/Ladybird-a-new-cross-platform...

lagniappe 3y ago

I have a suspicion that on a long enough timeline, eventually CSS will subsume the interactivity of JS for the frontend.

PaulHoule 3y ago
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?
douglee650 3y ago
This is probably the right answer … for ex. why does css need trig? Well, if you want to transform and animate things, math is very useful.
bamfly 3y ago
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.

gherkinnn 3y ago

I don’t follow. Don’t like trigonometry functions, don’t use them. Scumbag SV giants need to get snipped no matter how many relative units we have.

samwillis 3y ago

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.

jraph 3y ago
Unless you write a browser engine. You can choose what to implement, but you are highly encouraged to implement what people use in the wild. (this does not concern many people though - this is still somewhat important, a complex spec reduces potential implementations)
sebzim4500 3y ago
What other features does TypeScript have? Genuinely curious, I haven't used TS much so I'm probably missing a bunch.
- nayuki 3y ago
  Enum, namespace, type-oriented programming (e.g. https://type-level-typescript.com/ https://type-level-typescript.com/ ), easy de-sugaring down to earlier versions of ECMAScript (e.g. converting async-await to switch statements). Plus, whatever you can find under the "Reference" section: https://www.typescriptlang.org/docs/ https://www.typescriptlang.org/docs/

taeric 3y ago

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.

jozzy-james 3y ago
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.
- taeric 3y ago
  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. :(
johannes1234321 3y ago
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.

recursivedoubts 3y ago

i'm a reasonably smart guy 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) ¯\_(ツ)_/¯

kazinator 3y ago

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

azangru 3y ago

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?

DHPersonal 3y ago
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.
- kitsunesoba 3y ago
  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.
- LukeBMM 3y ago
  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.
3y ago

FigurativeVoid 3y ago

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.

kazinator 3y ago

The proliferation of units strongly suggests that programmers should instead be able to define the ones they need.

Julesman 3y ago

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

datavirtue 3y ago
"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.

TheRealPomax 3y ago

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.

samwillis 3y ago
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.
czx4f4bd 3y ago
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. [0] https://www.w3.org/TR/REC-CSS1/#length-units https://www.w3.org/TR/REC-CSS1/#length-units

B1FF_PSUVM 3y ago

One of the mysteries of life I cannot begin to fathom is how "style sheets" have come to include "page layout".

tabtab 3y ago
They have everything else in there, might as well add the kitchen sink. CSS is Swiss Army Rocket Surgery.
esarbe 3y ago
Because then you don't have to switch to a different technology if you want to have the same content for print. It's pretty useful.

pupppet 3y ago

Just curious, if you could throw out CSS and start from scratch, what would you do? What's the alternative?

pavlov 3y ago
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.
giantrobot 3y ago
You could go back to JavaScript style sheets[0]. I'm joking please don't do this it's stupid. [0] https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets https://en.m.wikipedia.org/wiki/JavaScript_Style_Sheets
TheOtherHobbes 3y ago
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.
- icedchai 3y ago
  This sounds like Java w/more modern UI.
- goto11 3y ago

RadiozRadioz 3y ago

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.

willio58 3y ago
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.
rikroots 3y ago
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). [1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value https://developer.mozilla.org/en-US/docs/Web/CSS/color_value [2] - https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini https://developer.mozilla.org/en-US/docs/Web/Guide/Houdini [3] - https://developer.mozilla.org/en-US/docs/Web/CSS/animation https://developer.mozilla.org/en-US/docs/Web/CSS/animation [4] - https://developer.mozilla.org/en-US/docs/Web/CSS/transition https://developer.mozilla.org/en-US/docs/Web/CSS/transition

wwweston 3y ago

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

samwillis 3y ago
No, unfortunately. 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)

bob1029 3y ago

This reads exactly like most pieces on why C# & Microsoft bad. 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.

danielvaughn 3y ago

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

SebastianKra 3y ago
I've seen much hate for the iPhone notch, but "user-hostile" is a first. (I assume you are talking about the notch, because Safari doesn't have a toolbar that obstructs the page)
- deleted 3y ago
  [deleted]
- imauser 3y ago
  I think he meant the bottom address/controls bar.
  - SebastianKra 3y ago
    Yep, but that doesn't obstruct the page. Except for a version from 2 years ago that never even made it out of beta ;)
    - imauser 3y ago
      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.
      - 3y ago

leokennis 3y ago

There are probably 200 ways to manipulate text on Unix. Does this limit anyone in using the tried and trusted awk, sed, cut, grep etc.? 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.

JakeAl 3y ago

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.

coding123 3y ago

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. http://www.decloak.com/dev/csstables/CSS_Tables_16.aspx http://www.decloak.com/dev/csstables/CSS_Tables_16.aspx His extremists update has HN posts from 2019!!!!!!

tabtab 3y ago

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

jack_the_dev 3y ago

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 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/ https://developer.chrome.com/blog/help-css-nesting/

dahwolf 3y ago

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.

whatarethembits 3y ago
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.

pauljonas 3y ago

It seems we need a CSS: The Good Parts guide here.

alchador 3y ago

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.

tails4e 3y ago

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?

oliwarner 3y ago

This is poor analysis. 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?

oliwarner 3y ago
I'll add that adding features has actually made it far less complicated. I'll take grid and flex over double-margin-float hacks any day. 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).

iainmerrick 3y ago

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.

lucumo 3y ago
I generally look at https://caniuse.com/ 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.

5350-uiop-1130 3y ago

having many ways to do the same thing is stressful. 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.

Ireallyapart 3y ago

[dead]

pomatius 3y ago

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