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.
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.
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.
I'm not putting CSS on a pedestal, but the last 25 years of web adoption would suggest CSS helped. You can do quite a lot with it. There are new features being added all the time: some of them even look useful (I wouldn't know.. I've been supporting devices from 2016 for the past four years so I'm out of date).
Could those CAD packages auto flow live text around the objects? Could you dynamically add new objects to your presentation in response to data and user interaction, and have them lay out perfectly according to your rules?
The paddings issue can be fiddly, but a little discipline can help. You've got two different width-calculation schemes to choose from. Flex & grid remove the need for most margin-wrangling and layout hacks. You can create relationships between objects and parents, and rotate/scale/translate groups of objects in 3D. You can flow text around irregular shapes. You have LOTS of control over fonts these days (I can't keep up with all the new font rules).
It may not be the pinnacle, but it's quite a reasonable compromise that's very easy to get into (admittedly hard to master, but so is most coding).
> That’s how CSS works, not visual design.
Visual design definitely, often employs a set of top-down ideas/rules, modified by sub-rules and ad-hoc exceptions.
> 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.
If the paddings of your generic container don't suit some uses of that container, then maybe it's not as generic as you thought.
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.