krsdcbl
there could be better ways to ease the burdon of naming things, while preserving cascade and the actual full features of CSS
Tailwind is a mirage, a shortcut to not having to do the important stuff by stacking wrappers on top of wrappers and redundancy
And the "fragile" part is exactly the same thing with tailwind, it all remains low specificity class names
It feels like the slightest occurrence of a less-than-ubiquitous pattern or any word not regularly used by the majority of the population instantly spawns a sleuth of newfound linguists who'll pitch in to explain how this certain marker ought to be proof of AI origin.
This does nothing for the conservation, except helping the claim that AI will erode and dumb down our language become a self-fulfilling prophecy when people start feeling pressured to use the most dumbed down, simplistic and rhetorically bland way of expressing themselves to avoid any "suspicion"
That might be datacenter dependant of course, since our root servers and cloud services are all hosted in Europe, but I really never understood why Hetzner is said to be less reliable
If I order physical goods from a foreign nation it's gonna have to somehow get into my hands, and can be withheld until i pay tariffs
If a irish subsidiary invoices me subscription prices for intangible services, there's no way in the current legal world to enforce a tax on my end
I'm still a fan of LESS, but quite specifically because it _does not_ try to force another languages syntax into my preprocessed stylesheets, rather keeps everything as css-like as possible. This makes it much easier to transition things to vanilla-only when possible, absolutely dreading "mostly js"-types of SASS frameworks
It may not look much like typical social dances performed with a partner, but I'm definitely thinking of clubbings, raves and festivals as happenings were "dancing connects people" - and it's one of the primary ways almost anyone I know has been socializing, at least throughout their 20s and 30s.
Yet half the menus will just ignore it. The start menu will pop up at the correct location, but then glitch to bottom left as soon as you start typing/searching
What's beyond is that even if we were to accept all the dumbing down and reduction of the UI as a sacrifice to make the OS more touch/hybrid friendly - it'd be really bad design, since keeping the taskbar on top makes it quite ergonomic to access on touch ultrabooks.
I'm picking this specific example, since it really questions the "trust us it's how it's best" excuse, and makes it much rather feel like 11 was simply rushed into production
The author talking about "4 colors", when really he means 4 "color roles" or "theming swatches".
First of all, 4 don't cut it.
You'll need accents for all of them, to fade sidenotes, visual hierarchy and disabled elements; to differentiate states of interactive; for borders, separators, and other parts of the chrome, and visual distinction of illustrative elements like icons; to give just a few samples ..
But the shortcomings of building a design system on 3 swatches for "text, bg, button" will become obvious much sooner, since defining which of the text/bg colors works for the button text depends on the button color itself, etc.
What most frameworks, complex and simplistic alike, get wrong imho, is that you need TWO "layers" of color definition, not to cram your palette definition into semantic concerns of the ui to be decorated. Those are separate concerns!
Or better said: the purpose of design tokens is not to be an abstraction for css properties of distinctive components.
- One Layer is your brand definition, or the color palettes that will serve to define the GUIs design. These are your design tokens
- The other layer is a semantic abstraction of the requirements in the design context. These are your "text, bg, button text, button bg, ..."
The library of design tokens need to acommodate ANY context the brand design could be applied to, and thus provide a wide range of shades for whatever amount of base colors want to use in the brand design.
These will then be mapped to the second layer of "roles", and populate whatever distinct use cases in the design.
TLDR: there is no "text, bg, highlight" color. There are "primary, secondary, accent, neutral, ..." color palettes, and "copy text, copy bg, button text, button icon, button bg, hovered button, .." swatches to be populated with them.
A good integration would:
- consider how heavily to use the effect to not overload the ui
- query for feature support to avoid adding all additional decorations if blur isn't available
- query for display & video features to avoid rendering the effect on devices that likely don't have a capable gpu
- query for user preferences and serve solid colors with good contrasts to users who might struggle with the busier background
- limit the extent of the effects and shadows depending on available space
- tweak the blurring and opacities to ensure good readability in the specific UI, regarding how complex or contrasted the background under blurred areas will be
- ensure blurs and shadows scale adaptively with the typography to ensure consistent visuals
UX is by definition the design of how a user experiences the complete app and interaction, it's not made or broken by individual stylistic choices
the redrawing of anything that changes in your ui requires gpu computation anyway, and some simple blur is quite efficient to add. Likely less expensive than any kind of animations of dom objects thar aren't optimized as gpu layers.
additionally, seeing how nowadays the most simple sites tend to load 1+ mb of JS and trackers galore, all eating at your cpu ressources, Id put that bit of blur for aesthetics very far down on the "wasteful" list
Feeling confident to be able to shrug off blockers, that might otherwise turn exploration into a painful egg hunt for trivial unknowns, can easily mean the difference between learning and abandoning.
Simply put, stuff gets much more much quicker compared to 5, 10, 15 years ago.
Not being quite able to keep up with any and all frameworks popping up and being overloaded with the size and speed of current web ecosystem is a struggle for younger peers aswell, and the days of "you even COULD check out every other new framework" are long, long gone
The API being unauthd is clearly a core design choice, and finding out any customer or service data is openly accessible with consecutive numbers through that API is not a zero day or something.
There is no "responsible disclosure" to be made here, going to the company and explaining what's the issue with all of this amounts to "handing out free consulting" if anything
Write a class & map it to the relevant component or DOM node in a template, so you only have a single source of truth to maintain the styles of that component.
Writing the explicit style declarations directly to the DOM nodes themselves is precisely what _prevents_ portability and reusability.
The perf issue of "zombie css" is seldomly an issue in my experience: if it really impacts your load time or perf, you can still easily serve subsetted stylesheets at build or request time
If the perf impact is negligible, you might in turn profit from serving all the css at first, since it will be cached and accelerate subsequent request or rehydration
Removing unused CSS is mainly a concern for _inline_ styles, since the bloat of the initial HTML might impact FCP and repaints/reprocessing once additional stylesheet are loaded.
... which ironically also means that adding truckloads of utility classes to every DOM node might introduce quite some initial load & paint performance implications aswell, depending on your app.
It might even be interesting to benchmark if a stylesheet with a bunch of "zombie css" really has more perf impact than serving a minmaxed css file, but requiring dozens of classes on every other DOM node to be processed for painting
it's not a file size game in the end, the amount of selector statements & DOM nodes they might apply to has much larger paint perf impact than a few kb of unused gzipped text