Live data from Hacker News

In defense of functional CSS

mikecr.it

171–180 of 246 posts

Re: In defense of functional CSS

#171
Awful idea. Just awful. The reason for splitting content (+hooks in form of CSS classes) and presentation is to make problem space smaller. If you say that HTML is now concerned with presentation too, you are basically going back to inline styles. And yes, I would prefer style "font-size: 10px" to class "fs10" anytime. At least I don't need to learn new classes with every single codebase I come across. There is a reason developers get emotional when someone tries to defend ideas like this - it's not because we don't understand, it's because we do, and we've been there. The location of the CSS is a solved problem, just let it be.

Re: In defense of functional CSS

#172
post #153

Earlier quoted context omitted.

Yeah, I really don't get it. As for this part: > when you get into a situation where one of the buttons needs to have slightly more margin-top than the others, then it's easy to fix You can have this with semantic classnames. In fact, that's exactly what the "cascading"[1] part of "cascading style sheets" was intended to solve. [1]: http://cssspecificity.com/

Cascading is bad and creates more problems than it solves.

It breaks encapsulation, leaks styles, you have to fight specificity and it makes it hard to change markup and many more.

Re: In defense of functional CSS

#173
post #166
post #153

Earlier quoted context omitted.

Cascading is bad and creates more problems than it solves.

I see the downvotes already coming. Cascading is bad, it makes it hard or impossible to restructure things and move markup around. And then you have to fight specificity. An example from my work where someone put a bunch of tags under `.new-style` like `.new-style h1` and applies to every container which needs those new styles. Now if I add my component to that container, it completely breaks encapsulation because `.…

In other words, improperly used cascading is bad? (didn't downvote you FWIW)

Re: In defense of functional CSS

#174

Earlier quoted context omitted.

I never said it has anything to do with the pipe operator, and I did not mean to imply that it is a direct equivalent to the pipe operator. But just as the pipe operator allows you to compose multiple pure functions, the idea with atomic CSS classes is that you are able to compose "pure" classes. The quotes are important here. Obviously, they are not 100% comparable. CSS is not a programming language.

It's a weak analogy. In programming, `f . g . h` is not the same as `h . f . g`. In CSS, ` ` is the same as ` `. In programming, the order in which you define functions is not important — it's the order in which you use them which is important. In CSS, it is the exact opposite. To further drive the point home: assuming the names of these classes aren't lying, what colour is the text of this element? foo It depends on…

I understood what you meant. Whether or not I'm supportive of the terminology used for "Functional CSS" is a different story.

Re: In defense of functional CSS

#175
post #134

Earlier quoted context omitted.

I'm not sure why that was suggested. Our team has migrated to utility css (Tailwind) and we never do this. The basic approaches are either to create a component or template for the button and put the utility class there or use Tailwind's `@apply` utility to create a `.button` class with the utilities applied to that class. I had some reservations at first but in practice it's been pretty much universally agreed to be…

First line of the first example you get in "what is Tailwind": Just accept the fact your HTML contains your styling and go with: There was a time when people thought CSS could be used to style some logical HTML: So the day you want to change the color of your card-wrapper from white to green you can change a line in some CSS and not have to go around all your HTML or end with a with a green background. CSS frameworks…

> CSS frameworks feel like a "let's get all the shit CSS was meant to help remove and just put it in divs".

You just made me realize this is why I always have a hard time every time I try a CSS frameworks.

It always goes the same way. I'm first amaze by all what they offer, how simple and quick a great UI can be made. Then when I try to use it, there's always something wrong and I hate how it goes and I always stop and goes back to the logical ways to do it entirely in CSS.

I guess I should try some CSS preprocessor, they must support heritage of CSS class I guess.

Re: In defense of functional CSS

#176
More fundamentally speaking, I'm wondering what the intrinsic value of CSS is when you compare the work involved in building a UI in web-land and native-land.

I remember once looking up on the proposed alternatives to CSS. One was basically a lisp, or at least the syntax, as far as I recall it. Think of what you could do with that!

However the problem now is that the problem CSS intended to solve can only be considered in terms of CSS itself. I'm curious what other approaches could be taken if we worked entirely from a clean slate. Would it involve changing the DOM? Would it require a separate language? Who knows...

CSS works great for websites but not so much for full-blown apps, where you're programming with a totally different mindset than what the web originally anticipated.

Re: In defense of functional CSS

#177
post #83
post #53

Earlier quoted context omitted.

Even if you only have one client - do you really want to manually hunt down all profile-card instances and update the styling anytime you need to change the styling? And if you had a bug related to profile-card styling, are you going to find all cards to update the styling? Are you sure you didn't forget some? This approach seems to be based on the idea that design is completely immutable after the initial conception…

It's unclear to me the problem you are addressing. Searching for places to make amendments is an important consideration when naming something. I would have thought that class names like "profile-card" would be easier to search for than "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light". Especially if you have some page elements which may look the same now but are functionally different and could look…

I was commenting on the original proposal, even in the single-client context. So, we're talking about the same problem - I just obviously wasn't very clear about it :)

So, yes, semantic names matter, and functional names are a bad idea in the long run, because they shatter maintainability.

Re: In defense of functional CSS

#178

As a frontend developer of 15-20 years now I've been pretty dumbfounded and unconvinced by any arguments for this style of css, I think it's especially hard for frontend developers of such duration because this is effectively the first ever style of css you write, and then you were force fed xhtml, semantic web and then later responsive became the "Told you so!" of the methodology. Despite my scepticism of extremes o…

I'm a frontend developer of about 15 years as well and I think functional css makes a lot of sense. My biggest argument for it is not having to name every thing. You know how many times I've had to think of a name for a random container that exists simply to align some crap? Then if you need another wrapper or something for that for some reason? It eliminates the name game (whenever you want it to).

> My biggest argument for it is not having to name every thing.

This x 100. As a guy who is the only American on a team with a bunch of non-native speakers, taking away naming responsibility is a big win.

Re: In defense of functional CSS

#179
I don’t get why people are still defending this method of CSS. When - or, perhaps I should say 'if' - your webapp has to scale you will realize the enormous amount of problems you’ve created for yourself using this method of CSS.

Re: In defense of functional CSS

#180
post #172
post #153

Earlier quoted context omitted.

Cascading is bad and creates more problems than it solves.

It breaks encapsulation, leaks styles, you have to fight specificity and it makes it hard to change markup and many more.

You’re 100% correct on the cascade being bad and causing incidental breakage. The people downvoting have clearly not run into these problems yet or it would be obvious to them that your reply is in no way wrong, lol
Post reply on HN