161–170 of 173 posts
Earlier quoted context omitted.
> I can only imagine where we'd be now if DSSSL had won over CSS Or if Brendan Eich had prevailed when he wanted to embed Scheme in Netscape instead of Javascript.
He embedded Scheme in JavaScript instead but nobody noticed. As Lou Reed once said, “JavaScript is Lisp in drag”.
This is a somewhat superficial history that only briefly touches on origins, and doesn't discuss the fundamental idea behind CSS, from which everything else is, directly or otherwise, a consequence. Two decades ago I was overjoyed to discover that Scheme was finally going to have a useful application beyond illustrating SICP and writing koans to amuse myself, because DSSSL was on the cusp of evolving into the last do…
Can we just start over on the entire web stack? 1. create a serious styling and scripting framework, basically React as a language since people seem to like it 2. implement an interpreter in WASM. Ship the interpreter with the website unless the browser says not to 3. over time, build the interpreter into the browser
Earlier quoted context omitted.
Typically you have a design system that keeps things consistent. So you would have maybe 5-6 different padding sizes, eg padding-s, padding-xl or whatever. That's why you don't just do style='padding: 1rem;'. Instead you assign a predefined padding class that's defined by your design system. As for me using .centered, it was just a quick example, and you took it in bad faith and now are nitpicking minor details. Site…
> Typically you have a design system that keeps things consistent. So you would have maybe 5-6 different padding sizes, eg padding-s, padding-xl or whatever. That's why you don't just do style='padding: 1rem;'. Well, I'm not saying you should do style='padding: 1rem;', I'm saying that padding-s has all the downsides of mixing styles into your markup, with none of the clarity of just using inline CSS. The solution isn…
I don't think it does, it's semantic with respect to your design system, not your content. The use of utility classes is to avoid the proliferation of "header-foo", "header-foo-large-padding", "button-foo", "button-foo-large-padding" or even worse usage of overly specific selectors, relying on element position, eg .main-content > header-foo { padding: 1rem } etc . Instead, you can just "header-foo.p3", "button-foo.p3".
> 1. Cool it. Nobody is attacking you, you don't need to attack me.
Sorry, not a native speaker, it didn't sound like an attack in my mind. With argument in bad faith I meant fixating on the simplified .centered example instead of discussing the general idea of design systems and utility classes.
I guess cause I got flagged I need to "cool it".
> I've encountered this antipattern in production code, so regardless of whether you were actually proposing it as a serious idea, some people do take this idea seriously, so it needs to be addressed. The problems I pointed out aren't theoretical: I've dealt with them in practice.
I don't understand this argument. A lot of major css libs and frameworks use utility classes. I'm sure they deal with production code and practice all the time. I know I do. This comment I take as very dismissive.
I've found that since using utility/functional CSS in the form of Tailwind that I actually enjoy making UI's now. Coupled with componentization in the form of a JS framework like Vue, I don't need to stress over CSS anymore. No more LESS or SASS, no more .header-container, .header-parent-inner crap. https://adamwathan.me/css-utility-classes-and-separation-of-... I'm sure some puritan naysayer will disagree but whatev…
This article would have much less of a problem with CSS if they actually used the cascade. All those instances of double underscore in class names should be two separate classes: ".author-bio__name" becomes ".author-bio .name". Then you can style the generic .name while also having control over specifically author names. The end of the article comes to the same kind of conclusion (use multiple classes), while also us…
Earlier quoted context omitted.
He embedded Scheme in JavaScript instead but nobody noticed. As Lou Reed once said, “JavaScript is Lisp in drag”.
Except it isn't. JS has lexical closures, but that's not the only feature that makes Scheme what it is. JS got one thing right and about a dozen other things very badly wrong. https://blog.kevinchisholm.com/javascript/javascript-wat/
Earlier quoted context omitted.
I often use grids when flex would do just to take advantage of the grid gap features. Once the more general gap feature lands in most browsers I’ll probably start using flex more again.
It's not really 1 vs the other IMO. I use flexbox within grid quite often, for example. They're two different tools with some overlap... Grid is absurdly more powerful for full-page layout than flexbox (which is amazing for individual columns or rows). Especially once we start getting subgrid. The common comparison is 1 dimensional (flex) vs 2 dimensional (grid) layout.
Earlier quoted context omitted.
There's the experimental :has pseudo-class which appears to be doing what you want [1]. Personally, I'm against adding any more complexity to CSS, though; and :has fundamentally changes the locality/algorithmics and complexity of CSS selector matching. I think if the goal of CSS was to bring good-enough styling to the masses, it has utterly failed to so, yet has left a legacy of overcomplicated and badly specified ad…
> a legacy of overcomplicated and badly specified ad-hoc styling rules that don't compose to a reasonable whole Agreed. For instance instead of creating the flexbox display, it would have been much nicer to version it out into CSS4 with center aligns, vertical aligns, and a few other things fixed rather than continuing to add new concept layers and increasing the complexity.
Earlier quoted context omitted.
> Typically you have a design system that keeps things consistent. So you would have maybe 5-6 different padding sizes, eg padding-s, padding-xl or whatever. That's why you don't just do style='padding: 1rem;'. Well, I'm not saying you should do style='padding: 1rem;', I'm saying that padding-s has all the downsides of mixing styles into your markup, with none of the clarity of just using inline CSS. The solution isn…
> I'm saying that padding-s has all the downsides of mixing styles into your markup, with none of the clarity of just using inline CSS. I don't think it does, it's semantic with respect to your design system, not your content. The use of utility classes is to avoid the proliferation of "header-foo", "header-foo-large-padding", "button-foo", "button-foo-large-padding" or even worse usage of overly specific selectors,…
> I don't think it does, it's semantic with respect to your design system, not your content. The use of utility classes is to avoid the proliferation of "header-foo", "header-foo-large-padding", "button-foo", "button-foo-large-padding" or even worse usage of overly specific selectors, relying on element position, eg .main-content > header-foo { padding: 1rem } etc . Instead, you can just "header-foo.p3", "button-foo.p3".
How is the proliferation of "padding-s", "padding-left-s", "padding-top-left-bottom" any better?
The solution here is don't do either of these things. Strictly stick to semantics. "primary-button", "secondary-button", "post-header", "comment-header", etc.
> I don't understand this argument. A lot of major css libs and frameworks use utility classes. I'm sure they deal with production code and practice all the time. I know I do. This comment I take as very dismissive.
Just because a lot of people do something doesn't mean it's a good thing to do.
Earlier quoted context omitted.
He embedded Scheme in JavaScript instead but nobody noticed. As Lou Reed once said, “JavaScript is Lisp in drag”.
Except it isn't. JS has lexical closures, but that's not the only feature that makes Scheme what it is. JS got one thing right and about a dozen other things very badly wrong. https://blog.kevinchisholm.com/javascript/javascript-wat/
CSS is amazing. It's hilarious to watch the twisted ways people will work around it, or spend time making libraries to find solutions to problems that don't exist; without ever even trying to get comfortable with it. Its an amazing and simple piece of technology. Kind of a shame. Id love a real history and critical discussion on the "tools" we have now for web dev.
I'd rather it be a programming language, which Netscape tried to do with Javascript Style Sheets in the late 90s. Was way more flexible, but was never accepted as a standard and of course, was not supported by IE.
the corruption of the net is proportional to the corruption of the tools. a shame really.