3 ms·

> The worst part of CSS is its globalness. But global-ness is what you want from design directives. You want all your buttons to look the same, your links cons

> The worst part of CSS is its globalness. But global-ness is what you want from design directives. You want all your buttons to look the same, your links consistent. You want to define your base fonts once and then not have to worry about it for the rest of the build. You want to have your vertical rhythm (line spacing) repeated on most pages. You want most pages to have the same background and foreground colours. CSS syntax gives you all that for free. Giving multiple elements the same border definitions is easy: elem, another-elem, .some-class, #just-this-one { border: whatever; background: swoosh; } When I look at the hoops you have to leap through to get the same behaviour using any of the frameworks, my mind reels. Build steps, runtime libraries, repeated syntaxes in the mark-up... I accept that managing things like the shared border example can get fiddly. SASS made it easier; some flavour of react-plus-css-helper-library thing can make it easier, kinda, if you squint. But it's actually _very_ simple to write the basic core idea in plain CSS. Personally, I feel that the discipline required to manage larger CSS codebases isn't that different than the discipline required to write good JS or TS; we just have a habit of pretending we shouldn't need to do that and wishing someone else would (via a library, or changing the standards). I don't know why we're happy doing it in JS or TS, but not CSS.

wruza 2y ago
That’s as easy as fooModule.*(x), bar(x), Math.floor(x) { if (x === 42) return “oops”; return thisfunc(x); } Or as COMEFROM. The proper way for modularity is to import subtrees of declarations and have them applied explicitly. // elem.css elem { use border-bg from “./bbg.css”; } // html <div> import elem from “./elem.css” <elem/> // has it </div> <elem/> // doesn’t I don’t want aspect-oriented/comefrom globalness. It is an antipattern and dead tech in which you have to runtime-debug an element to learn its properties in each case, cause there’s no single place to treewalk your logic from.
- the_other 2y ago
  Your example is solving a different problem from mine. We can’t compare. I was arguing that global declarations are useful. Your example is intentionally differentiatiating similar elements, and placing the specialisation inline with the DOM declaration. So far these seem more like style preferences. I can’t infer the “anti-patterns” you’re concerned about, nor how your version solves them. Could you expand some? Personally, I much prefer keeping the layout and style code out of my JS/behavior code. It makes both easier to read.
  - wruza 2y ago
    A line of code somewhere affects an element. That’s aspect. A line of code affects an element if written locally. That’s lexical scoping. You can only runtime-check with aspect. You can statically infer with lexical scoping, cause all effects are specified in that scope. My second example is solving the same problem, adding a common border and background to an element declaration. My first example is solving the same problem too, adding a common behavior to a set of functions.
    - the_other 2y ago
      Ok, I see. I'm still not sold. Static analysis can't prove it looks right, so you need to runtime check it anyway. By that point, you may as well runtime debug. Lisp (and I think SmallTalk) give us a rich history of developing against the runtime. I don't see why we should avoid it in the browser. The dev tools are very good, and have been fairly good since the '00s. In my current team, we type check our CSS-in-JS (CSS-in-TS I suppose). It doesn't add much value. It can't tell you if the style rules are compatible with each other, if they'll conflict, if the cascade will force an effect you didn't intend the current snippet to produce. I am sure you're going to tell me that CSS is bad because it allows that kind of problem... but that's how visual design works! Every element contributes to the whole. Designers work from the outside in, and also from the inside out, rebalancing and refactoring as they go. CSS is a fairly good analog of that.
      - wruza 2y ago
        It can't tell you if the style rules are compatible with each other, if they'll conflict, if the cascade will force an effect you didn't intend the current snippet to produce. I am sure you're going to tell me that CSS is bad because it allows that kind of problem... Good, means I’m almost there! All true. but that's how visual design works! That’s how CSS works, not visual design. It mixes all together and you can’t even design a generic container because its customization will affect the inner content containing that type of a container. And all its custom margins will fight with its own margins-as-a-child. And you can’t properly outline it in-parent without reserving space in advance and dealing with shattered layout, or using half-baked “outline:”. This only worked for a non-recursive text. It was designed for text. I have worked as a designer many years ago btw. Corel draw, pagemaker, autocad, etc. I could place elements, group them, place two groups by distance between centers of their main content groups, stick them to arbitrarily angled guidelines. I wasn’t the autocad guy (more corel + vba) but I’ve seen how people work with it. CSS is like a $0.5 paper doll dress-up toy compared to these industrial CNCs. It’s not a pinnacle of design, it’s below mediocre at best. There are alternatives like constraints, alignments and so on that could be simply included into CSS next. But the stubborn sandcastle-model obsessed committee can’t add more than one practical thing per decade, because everyone will migrate asap. Their reasoning makes sense sometimes, but don’t try to put css on a pedestal, it’s a heavy tradeoff, not a win.

wruza 2y ago

That’s as easy as fooModule.*(x), bar(x), Math.floor(x) { if (x === 42) return “oops”; return thisfunc(x); } Or as COMEFROM. The proper way for modularity is to import subtrees of declarations and have them applied explicitly. // elem.css elem { use border-bg from “./bbg.css”; } // html <div> import elem from “./elem.css” <elem/> // has it </div> <elem/> // doesn’t I don’t want aspect-oriented/comefrom globalness. It is an antipattern and dead tech in which you have to runtime-debug an element to learn its properties in each case, cause there’s no single place to treewalk your logic from.

the_other 2y ago
Your example is solving a different problem from mine. We can’t compare. I was arguing that global declarations are useful. Your example is intentionally differentiatiating similar elements, and placing the specialisation inline with the DOM declaration. So far these seem more like style preferences. I can’t infer the “anti-patterns” you’re concerned about, nor how your version solves them. Could you expand some? Personally, I much prefer keeping the layout and style code out of my JS/behavior code. It makes both easier to read.
- wruza 2y ago
  A line of code somewhere affects an element. That’s aspect. A line of code affects an element if written locally. That’s lexical scoping. You can only runtime-check with aspect. You can statically infer with lexical scoping, cause all effects are specified in that scope. My second example is solving the same problem, adding a common border and background to an element declaration. My first example is solving the same problem too, adding a common behavior to a set of functions.
  - the_other 2y ago
    Ok, I see. I'm still not sold. Static analysis can't prove it looks right, so you need to runtime check it anyway. By that point, you may as well runtime debug. Lisp (and I think SmallTalk) give us a rich history of developing against the runtime. I don't see why we should avoid it in the browser. The dev tools are very good, and have been fairly good since the '00s. In my current team, we type check our CSS-in-JS (CSS-in-TS I suppose). It doesn't add much value. It can't tell you if the style rules are compatible with each other, if they'll conflict, if the cascade will force an effect you didn't intend the current snippet to produce. I am sure you're going to tell me that CSS is bad because it allows that kind of problem... but that's how visual design works! Every element contributes to the whole. Designers work from the outside in, and also from the inside out, rebalancing and refactoring as they go. CSS is a fairly good analog of that.
    - wruza 2y ago
      It can't tell you if the style rules are compatible with each other, if they'll conflict, if the cascade will force an effect you didn't intend the current snippet to produce. I am sure you're going to tell me that CSS is bad because it allows that kind of problem... Good, means I’m almost there! All true. but that's how visual design works! That’s how CSS works, not visual design. It mixes all together and you can’t even design a generic container because its customization will affect the inner content containing that type of a container. And all its custom margins will fight with its own margins-as-a-child. And you can’t properly outline it in-parent without reserving space in advance and dealing with shattered layout, or using half-baked “outline:”. This only worked for a non-recursive text. It was designed for text. I have worked as a designer many years ago btw. Corel draw, pagemaker, autocad, etc. I could place elements, group them, place two groups by distance between centers of their main content groups, stick them to arbitrarily angled guidelines. I wasn’t the autocad guy (more corel + vba) but I’ve seen how people work with it. CSS is like a $0.5 paper doll dress-up toy compared to these industrial CNCs. It’s not a pinnacle of design, it’s below mediocre at best. There are alternatives like constraints, alignments and so on that could be simply included into CSS next. But the stubborn sandcastle-model obsessed committee can’t add more than one practical thing per decade, because everyone will migrate asap. Their reasoning makes sense sometimes, but don’t try to put css on a pedestal, it’s a heavy tradeoff, not a win.