Is There Too Much CSS Now?

• caniuse

  387 5,500 9.5 JavaScript

  Raw browser/feature support data from caniuse.com

  Good point.

  For example, :has() has nearly 83% global support already [1]. Once Firefox enables it by default (it’s behind a flag currently) and more upgrade to the latest versions of macOS and iOS, we’ll soon exceed 90%.

  [1]: https://caniuse.com/?search=%3Ahas

• stylelint

  44 10,808 9.6 JavaScript

  A mighty CSS linter that helps you avoid errors and enforce conventions.

  

  you'll never see any error messages or warnings in devtools / IDEs when you try.

  I’ve seem dev tools highlight code that either doesn’t make sense or doesn’t have any affect.

  I wonder if something like Stylelint [1] would catch this.

  [1]: https://stylelint.io

• SurveyJS

  surveyjs.io

  sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• Cassius

  5 90 0.0 Racket

  A CSS specification and reasoning engine

  

  1. CSS should've been split into app-y styles and doc-y styles a looong time ago; meaning that when you need JavaScript to make use of a feature anyway, there's no point in using CSS and it's better to set styles, layout using JavaScript rather than bloat CSS. The Houdini API was on the right track years ago.

  2. The CSS WG at W3C must deliver formal specification rather than the prose they're writing up now. For an idea how a (partial) formal spec for CSS rendering looks like, see eg. [1], [2] (with limitations).

  The one way complexity that both W3C and WHATWG have delivered over the past 15 years with complete lack of mental discipline due to financial dependency/job security will be a major source of confusion for generations to cone, and will not be looked at favorably.

  [1]: https://github.com/uwplse/cassius

  [2]: https://github.com/lmeyerov/sc

• sc

  2 4 10.0

  superconductor (by lmeyerov)

  1. CSS should've been split into app-y styles and doc-y styles a looong time ago; meaning that when you need JavaScript to make use of a feature anyway, there's no point in using CSS and it's better to set styles, layout using JavaScript rather than bloat CSS. The Houdini API was on the right track years ago.

  2. The CSS WG at W3C must deliver formal specification rather than the prose they're writing up now. For an idea how a (partial) formal spec for CSS rendering looks like, see eg. [1], [2] (with limitations).

  The one way complexity that both W3C and WHATWG have delivered over the past 15 years with complete lack of mental discipline due to financial dependency/job security will be a major source of confusion for generations to cone, and will not be looked at favorably.

  [1]: https://github.com/uwplse/cassius

  [2]: https://github.com/lmeyerov/sc

Suggest a related project