krsdcbl

disagree. Colocation seems great when authoring, but it comes at a big cost of downstream tech debt

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

I'll second that, this is extremely annoying and exhausting.

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"

Given the premise, one could also say we nerds are forever happy.

We've been running our services on Hetzner for 10 years, never experienced any significant outages.

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

Enforcement will be the issue here.

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

this is the way. Modern CSS brings most of the capabilities to the table that SASS & LESS used to provide, and in part even much more functionality that could never be adequately solved with preprocessors (runtime calc(), light-dark() and layers come to mind)

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

Hot take: CSS is actually type safe, just doesn't get compiled & fails gracefully ;P

Being from Germany our history classes in school went into great depth about the countries past - and I can't help but feel increasingly scared and left utterly speechless by all the parallels I'm seeing unfolding in the US ...

when technological advancements that actually would allow for BETTER privacy and security, and MORE local-only features are misappropriated for constructing bogus and dishonest justifications to rather erode the least-effort user-minded safeguards that already had been present, it's become plain obvious that the claim to create a product that serves the user has always been a lie. It's about capturing data and influence, and always has been

supposedly idealistically opposed parties doing something that is in the sense of the argument doesn't prove the argument. Walz might very well have been just as wrong

almost everything you have in your home is built for humans, so adopting this form factor is the likeliest to fit everywhere and be able to operate everything

Honestly with those numbers, I'm pretty surprised it's even an independent company. Wouldn't such a community of 3-4k people in a very remote location be a prime example where providing internet could just be a gov/municipal service, subsided by an extraordinary tax if needed?

nitpick on your nitpick on the nitpick: a "metacommentary" would be if you'd be commenting on your own text. That's even less important, but I thought you might appreciate such asides

They strangely work quite well together

This makes me anxious about net neutrality. Easy to see a future were those bots even get prioritised by your host's ISP, and human users get increasingly pushed to use conversational bots and search engines as the core interface to any web content

I'm quite surprised by the impression in the first place, since "dancing events" as a way to meet others and connect seems more ubiquitous than ever to me.

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.

think of an artist posting to Instagram to eventually have successful gallery shows

I didn't feel that way, since she specifically points it out and also explains (quite correctly) why this matter is to be treated differently for a newspaper than for any other business

Hits the nail on the head. I was surprised they even removed the ability to customize the taskbar location - but it still employs the same registry entries, so you can relocate it by messing with obscure manual modifications.

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

This is one of my main topics when integrating design systems for UI concerns, and imho this site does well at demonstrating a central problem and misunderstanding:

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.

Maybe it's just me, or I might be missing a relevant implication - but I'm having a hard time understanding why so many people have become alarmist about the fact, that things that they publish on the web, can and will be scraped?

"Bad UX" can't be generalized that easily for a simple visual effect, that's highly dependent on the integration.

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

I would argue that while it _feels_ wasteful to us humans, as we perceive it as a "big recomputation of the rendered graphics", technically it's not.

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

one could argue aswell that having at least generally satisfying, but at the same time omnipresent "expert assistance" might rather end up empowering you.

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.

Same here. Specially back when Atom was a thing, Notepad++ would always be my "side editor" for any kind of heavy lifting (or even heavy-ish - looking back I really ask myself why I didn't just use it for everything ^^)

I'm familiar with the feeling of "old, not keeping up", but rest assured, there's also other very important factors at play here:

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

Fully agree with you!

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

isn't this exactly what CSS is meant to solve originally?

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

this is exactly the point, using it for ALL the styles was always a horrible idea -- and never it's intention (i think)

op is not talking about style atts, but referring to nesting inline `<style> @scope { ... }</style>` to declare vanilla css in the scope & context of specific DOM nodes