Comment by weitendorf | Hacker News Reader

Comment by weitendorf | Hacker News Reader

Guys, I found out about this technology called Cascading Style Sheets recently and I think it's the missing piece we've been looking for. It lets you declaratively specify layout in a composable, hierarchical system based on something called the Document Object Model in a way that minimizes both clientside and serverside processing, based on these things called "stylesheets".

The best part is, it's super easy to customize them, read others for inspiration or to see how they did something, or even ship multiple per site to deal with different user preferences. Through this "forms" api, and little-known browser features like url-fragments, target/attribute selector, and style combinators, plus "the checkbox hack" you can build extremely responsive UIs out of it by "cascading" UI updates through your site! When do you think they're going to add it to next.js?

I'm tentatively calling this new UI paradigm "no-framework" or "no package manager", not sure yet https://i.imgur.com/OEMPJA8.png

> Cascading Style Sheets recently and I think it's the missing piece we've been looking for. It lets you declaratively specify layout in a composable, hierarchical system based on something called the Document Object Model in a way that minimizes both clientside and serverside processing, based on these things called "stylesheets"

I tried that and it was an absolute nightmare. There was no way to tell where a given style is used from, or even if it's used at all, and if the DOM hierarchy changes then your styles all change randomly (with, again, no way to tell what changed or where or why). Also "minimizes clientside processing" is a myth, I don't know what the implementation is but it ends up being slower and heavier than normal. Who ever thought this was a good idea?

> There was no way to tell where a given style is used from, or even if it's used at all

It's pretty easy. Open the inspector, select an element and you will find all the styles that apply. If you didn't try to be fancy and use weird build tools, you will also get the name of the file and the line number (and maybe navigation to the line itself). In Firefox, there's even a live editor for the selected element and the CSS file.

> if the DOM hierarchy changes then your styles all change randomly

Also styles are semantics like:

- The default appearance of links should be: ...

- All links in the article section should also be: ...

- The links inside a blockquote should also be: ...

- If a link has a class 'popup' it should be: ...

- The link identified as 'login' should be: ...

There's a section on MDN about how to ensure those rules are applied in the wanted order[1].

This way, your styles shouldn't need updates that often unless you change the semantics of your DOM.

[1]: https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Casc...

> Open the inspector, select an element and you will find all the styles that apply.

That tells me which styles apply to an element. You also need the converse - find which elements a given style applies to - and there's no way to do that AFAIK. It's very hard to ever delete even completely unused styles, because there is no way to tell (in the general case) whether a given style is used at all.

> This way, your styles shouldn't need updates that often unless you change the semantics of your DOM.

In my experience the DOM doesn't have semantics, or to the extent that it does, they change all the time.

> You also need the converse - find which elements a given style applies to - and there's no way to do that AFAIK.

I've never needed to do this, because I pay attention to my DOM structure and from CSS selectors can figure where a style applies. But I've just checked and the search bar for Firefox Inspector supports css selectors.

> In my experience the DOM doesn't have semantics, or to the extent that it does, they change all the time.

The DOM semantics are those of a hyper linked documents|forms. Take a page and think about what each elements means and their relations to each order. They will form a hierarchy with some generic components replicated. The due to how CSS is applied, you go from generic to specific elements, using the semantic structure to do the targeting

As an example, the structure of HN's reply page is

  page
    header
      logo + Title
    body
      comment_box
        upvote_button + comment_metadata
        comment_text
      textbox // reply text
      button // reply

This and the structure of the other pages will give you an insight on how to target the relevant elements.

> As an example, the structure of HN's reply page

Is made up of table tags, which the CSS people will tell you is wrong/impossible/has different semantics.

> Is made up of table tags, which the CSS people will tell you is wrong/impossible/has different semantics

A table is a grid. Lot of UI toolkits have a grid container, and even CSS added it specifically as a layout engine.

> A table is a grid. Lot of UI toolkits have a grid container

Sure. As long as the end result is the same grid, it shouldn't matter. But in a CSS world you switch your table for grid-layout divs (or vice versa) and suddenly one corner case thing that is in one grid cell somewhere in your app gets its styling flipped.

> It's pretty easy. Open the inspector, select an element and you will find all the styles that apply.

Of course it's not easy, 80% of that list will be some garbage like global variables I would only need when I actually see them in a style value, not all the time.

The names are often unintuitive, and search is primitive anyway, so that's of little help. And the values are just as bad, with --vars() and !important needless verbosity in this aborted attempt of a programming language

Then there is this potentiality more useful "Computed" styles tab, but even for the most primitive property: Width, it often fails and is not able to click-to-find where the style is coming from

> Also styles are semantics like:

That's another myth. You style could just be. ReactComponentModel.ReactComponentSubmodel.hkjgsrtio.VeryImportantToIncludeHash.List.BipBop.Sub

What does that inspire in you when you read it?

Someone is using Tailwind (and the likes) and/or CSS-in-JS. Which I dump squarely in the weird tools.

What do you dump the other 99% of the poor designs and papercuts on? But at any rate, shifting blame doesn't help you make a hard system easy by citing a broken tool

You should talk the people behind the vanillajs framework, this sounds like it might work well over there.

http://vanilla-js.com/

Reply on news.ycombinator.com