Live data from Hacker News

The Debate Around “Do We Even Need CSS Anymore?”

css-tricks.com

21–30 of 67 posts

Re: The Debate Around “Do We Even Need CSS Anymore?”

#21
post #7

The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your code…

> If a user doesn't like something about how your page is presented, they can fix it using userstyles

I'm actually curious what percentage of people could do so in under an hour.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#22
post #7

The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your code…

> If a user doesn't like something about how your page is presented, they can fix it using userstyles I'm actually curious what percentage of people could do so in under an hour.

Or on mobile.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#23
post #7

The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your code…

> If a user doesn't like something about how your page is presented, they can fix it using userstyles I'm actually curious what percentage of people could do so in under an hour.

Not a huge amount of people will make custom styles, but they can be shared on sites like userscripts.org, for people who wouldn't bother making them or don't know css to use. Knowledge of basic HTML and CSS is more widespread than you might think.

If you're using inline styles, you're likely to end up with a lot of elements that don't have classes or ids to target for styling, so userstylers will have to use complex selectors using :nth-of-type and such, which is harder, more fragile, and not even always possible. And every line of the userstylesheet will need !important annotations, which makes composing multiple userstylesheet on the same page more likely to break.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#24
post #7

The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your code…

> If a user doesn't like something about how your page is presented, they can fix it using userstyles I'm actually curious what percentage of people could do so in under an hour.

I believe there are extensions for this, and places where users submit their own stylesheets and rules. A few experts can do the work of many.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#25
post #19

>What is the alternative to CSS then? The alternative is inline styles. ... The idea is you apply styles to elements through JavaScript. But if you have a non-trivial app with thousands of elements across hundreds of pages, people will inevitably want to "tame", "organize", "consolidate", etc those inline styles into some coherent taxonomy to enforce consistency. Wherever and however the programmers decide to store t…

There's still some key differences between what this new JSON declared and Javascript distributed stylesheets would work. Mainly is that there is no more CSS Selector madness. You no longer need to have concepts such as selector specificity, nor the entire syntax around grabbing the correct selectors.

Also you could then be able to logically follow the flow using traditional debugging methods rather than this mess which we have for debugging CSS currently.

Lastly this removes the need for a lot of the additional syntax introduced into CSS for animations/transitions (though I have no idea what the performance would be inbetween these two methods).

To be fair I haven't actually implemented this form of styling yet but it's something that interests me and I'd be interested in any potential downfalls before I commit to it on a project.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#26
post #14
post #7

The separation of concerns argument is dogmatic here. Just because it used to be that you should keep presentation in your CSS and behavior in your javascript, doesn't mean that's a universal truth. It's a good abstraction to separate presentation from behavior, but that doesn't mean one has to be done in one language and the other in a different one. Separating the concerns just by partitioning them within your code…

> One is that your page should work without javascript Universal rendering would send straight HTML with inline styles to the browser. And plenty of web applications need JS to function properly.

True. Doesn't address the userstylesheet problem though.

Also, sending prerendered pages with inline styles causes a bandwidth problem. Your prerendered page is probably dynamic and uncacheable, but your stylesheet isnt. By using inline styles, you send tons of repetitive uncacheable styles over the network where you could have just used a stylesheet.

If you need the power that a full general purpose programming language gives you for some of your stylesheet, go ahead and use inline styles where needed, that's why they exist. But there's no reason that you should then decide that all of your styles ought to be inline.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#27
In human history we always went through development loops. And I can tell you this: I was there when there was not much CSS, and certainly no preprocessors. CSS was the Next Big Thing on the table (not even 10 years ago, and div was the next big thing instead of table). There are reasons for CSS. Now that it's everywhere young people think it sucks. Because old code always sucks. But often it's not the technology that sucks. It's just that code bloats when it gets older. Now when we take CSS away we'll do that for 5 years and then we'll miss it, so we reintroduce it, maybe using another name, or a competing technology from back then that didn't make it. Both will happen, I'm quite sure of it. Just for you, dear reader, if you want to be the cool guy that knows the technology before the other kids know it, start doing CSS now and wait 5-10 years. The last thing I remember we've seen such a loop was SQL. Now they are slowly reintroducing it. So if you stayed with MySQL and Postgres over the last 5-10 years, you'll probably earn a lot of money now. Good luck.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#28
It makes a lot of sense to programstically generate css because all of what the author said is true: global namespace, difficulty to trace specificity, modularity, etc. I am not convinced inline styles are the way forward. You can just as easily write (manually or programmatically)your styles using css/sass/less and optimize and serve them.

You can just do it server side. You can create global classes for objects and elements and include the However you want. You can optimize on your own server FOR THE CLIENT, and serve the best result.

It is dogmatic, but I don't like inline styling. I think it should really be limited to values that are expected to regularly fluctuate during a session. This would be your height or width resizing on an animation or something where the x or y moves. These usecases make sense because you directly apply animation to an element.

Can you imagine what the dom would look like with html, javascript, css, sass, markdown and haml/ruby all on a page? I hope there is a way to demonstrate your page to Search Engines, because eventualu they may stop believing the alternate robots files if they just cant tell what is going on. Also, writing your own tags and attributes, I like it think it's helpful, but DOMs don't make sense anymore.

Re: The Debate Around “Do We Even Need CSS Anymore?”

#29
I'd propose the following distinction, especially for React users:

If your components will only ever be used by you or a small, internal team of programmers, then inline styles can work.

If, however, your components are meant to be re-usable, public and accessible then CSS is still a must.

To pick on one project react-datagrid is a super useful, public component for displaying data, but they use inline styles, which makes integrating the component into any other design a nightmare. You have to fork their codebase to update a style because you can't over-ride it and there's no way they'd pull in a PR for your preferred style.

Post reply on HN