Old dogs, new CSS tricks

Original Article ↗ Hacker News Discussion ↗

New CSS capabilities like container queries, subgrid, native nesting, and view transitions are prompting both excitement and skepticism among web developers. Many welcome the power to build more flexible, component‑driven layouts without heavy JavaScript or preprocessors, but others worry CSS is becoming harder to read and maintain in team settings, especially given uneven browser support and long‑lived devices stuck on older Safari or iOS versions. The debate centers on how quickly to adopt these features, how to balance progressive enhancement with wide compatibility, and whether utility‑first frameworks like Tailwind are a cure or a symptom of deeper CSS complexity.

New CSS Features & Their Value

  • Container queries: widely praised as a long‑requested shift from viewport‑based media queries to container‑based layout; seen as enabling truly reusable components. Some argue they’re less useful until elements can query their own size, and current wrappers “dirty” markup.
  • :has() is viewed as a game‑changer (effective parent selector, replaces JS workarounds). :is() is seen as mild sugar; :where() divides opinions because of specificity complexity.
  • Subgrid: considered very useful for aligned, card‑style layouts; some thought grid already sufficed, others showed concrete cases where subgrid beats hacks like display: contents, which also has accessibility issues.
  • Native nesting: broadly liked as a quality‑of‑life feature, though some note compatibility nuances (the & syntax vs newer “no‑&” form).
  • Logical properties: appreciated for enabling RTL support if teams stay disciplined.
  • Anchor positioning, scroll-linked animations, view transitions: seen as promising for micro‑interactions and reducing JS, but currently niche and/or Chrome‑only; expected to be overused in “marketing” sites.

CSS Complexity and Developer Experience

  • Some feel modern CSS is becoming too complex, resembling compiler output rather than hand‑crafted code. Layers and scoping are called unintuitive or “gibberish.”
  • Others report the opposite: the new features simplify their CSS and could eventually obviate Sass, BEM, and many frameworks.
  • Concern raised about “too many ways” to do similar things, impacting readability and team onboarding.

Browser Support & Backwards Compatibility

  • A major blocker is old browsers and especially old iOS/Safari versions, iPads, TVs, and set‑top boxes that don’t auto‑update.
  • Debate over how aggressively to drop old browsers: some argue not supporting them nudges users toward safer, updated software; others highlight users who simply cannot upgrade.
  • Progressive enhancement with @supports and fallback styles is encouraged, but teams note the maintenance and testing cost of dual paths.

Adoption Barriers & Team Practices

  • Many projects use frameworks (Bootstrap, Tailwind, MUI) or large legacy stylesheets; they won’t be rewritten just to use new features.
  • Long‑time devs, burned by the IE era, still instinctively avoid features newer than 2–3 years.
  • Team dynamics matter: using new CSS often requires educating colleagues and aligning on conventions.

Tooling, Frameworks & Alternatives

  • Utility CSS (e.g., Tailwind‑style) is praised for eliminating cascade conflicts but criticized for avoiding CSS rather than improving it.
  • Persistent complaint: massive, append‑only CSS files with !important everywhere; “well‑written CSS” is rare.
  • Calls for better tooling: compilers with warnings, dead‑code detection, stronger scoping, and richer editor support. Some note existing solutions (CSS Modules, styled components, PostCSS/Lightning CSS, IDE support) but acknowledge they’re not universal.

Learning & Keeping Up

  • Suggested resources: MDN, web.dev, caniuse.com, the Interop project, and the State of CSS surveys.
  • Some readers wish the article and similar posts included more live demos and links to docs for each feature.