I don't recall it vividly but it was a good experience It makes sense if you're using hiccup / even more so with SSR, where it's handy to have not .html / .css / .js files at all It probably also fostered composable bits in a more intuitive way than css'.

Thank you 🙂 I've been wondering if it's worth the effort. It seems like yet another opportunity to "opt out" of the more general programming world (here; standard CSS stylesheets), for better and worse. You can footgun yourself into incidental complexity that no stack overflow post can help you with.

Yeah, that's part of what I'm thinking. Another part is NIH syndrome taking over and coming up with/accreting needlessly complex abstractions instead of researching css and finding existing solutions.

I've experienced my share of legacy homebrewed solutions for whatever problems. Sometimes, it's a real pain in the butt. And general disdain for frontend development and in particular css is sure to inspire confidence in reinventing the wheel among some 😅

(Not to say that there isn't room for good abstractions)

I know what you mean. CSS has gotten a lot better over the years. At this point I am mostly trying to teach myself how to look at CSS as a very real part of my code base warranting proper structure etc. But many years of treating CSS as a second class citizen make that difficult. 😅

For my part, I detest the "cascading" part of CSS, along with whatever else causes html elements to be hit by multiple, competing styles (I guess, poorly chosen selectors, really). I yearn for whatever strategy can make styles straightforward.

I have not researched this properly; there's probably plenty of strategies/frameworks.

Actually figuring out how to get stuff to look/act in a particular way in CSS is kind of interesting, I think. A rewarding puzzle. I just wish I had more experience in, or a better feel for, what actually works well, design-wise 🙂 For now, I'm more of a translator of designers' screenshots into CSS/HTML.

I recommend taking a look at https://cube.fyi/ and this presentation by Andy Bell: https://www.youtube.com/watch?v=5uhIiI9Ld5M Both have given me a new perspective on CSS and design for the web.

TL;DR: It's all about embracing the cascade.

Thank you! I'll give it a whirl 🙂

@U0AQ3HP9U I don't see how you get to the conclusion that implementors have to be both designer and developer. Let's for the sake of argument say that the two roles are separate people. As you say, the designers have no idea how to write CSS, and the developers cannot do design. However, the designers can come up with a nice design and your developers can translate that nice design to CSS. To me this only suggests that designers and developers need to collaborate; which is no different from how it works with any other approach to styling the web. What am I missing? 🙂

What I'm talking about is stuff like determining ratios for fonts and layout (and other aspects of responsive/fluid layout) seeming, to me, like something that you can only really design interactively and iteratively, like a developer does by actually coding things and reviewing the results. Otherwise, won't it be guesswork as to how it looks when the viewport is fluidly resized? Or double-the-work - "programming" fluid design by creating static images, or through some other mocking method, before having to do it all over in code. But here, the design is the fluidity, achieved and reviewable (only?) through code. Maybe this is more of a general concern that puts my lack of knowledge about how UX'ers generally work into the bright light of day 🙂

Good point about the design process being interactive and iterative. I have talked to some of the designers / UX'ers in my company about what Andy Bell proposes and they don't seem intimidated by thinking about design as something fluid based on screen size. They do say that it is unfamiliar and probably not something they will be able to find time for learning any time soon. That said, given that designers mostly hand out static wireframes or high-fidelity designs I always try to communicate that pixel-perfect is not what I do. 😄

The last bit of what you said is what frustrates me a bit about the communication with our UX'ers, too. There's an impedance mismatch between what they deliver and the final product, they're different beasts altogether. And, maybe especially so when you try to make good fluidity decisions that are so beyond what static wireframes can achieve. So, as a developer interpreting the UX, you kind of automatically assume a bit of a design role, yourself. And it just seems to me that you're doing more so with Andy's process.

Ah well, part of the job