Live data from Hacker News

Ask HN: Is it just me, or is CSS too damn hard?

news.ycombinator.com

291–300 of 358 posts

Re: Ask HN: Is it just me, or is CSS too damn hard?

#291
I really dislike CSS. I find of the 3 main web 'languages' it is the most difficult to do well. I really hate the 'C' in CSS. I've found that using scoped CSS cuts down on a LOT of the things in CSS that bug me the most. Like changing the style of a particular div and now all the p tags inside of it auto-magically changed as well!? So if you are using React, Vue, etc. I recommend finding some approach to scoping your CSS to your components so as to avoid as much of the cascade as possible.

As for layout, spend half a day learning about flexbox (https://css-tricks.com/snippets/css/a-guide-to-flexbox/). It's much simpler than CSS grid and it'll do 90% of what you need as far as layouts go. If you have a particular section of your page that needs to be laid out in a grid, then you could try out CSS grid in that limited section. I think it is a nightmare for overall page layout.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#292
post #282
post #243

Earlier quoted context omitted.

> I'm fascinated by the fact that so many of my fellow programmers - often the smartest ones - have so much trouble with CSS. I'm not sure exactly what the reason for that is I will demonstrate why. First, think of all the tools that you use that require a text interface. That may include a programming language (python, ruby, javascript, etc), a command line shell (bash, fish), a database client (mysql, psql), a conf…

Some of the names are unintuitive, sure. Though I don't think the ones you provided are in particular; I think your distaste for those is subjective. But it's really not hard to learn the names for concepts which themselves make sense (at the beginning, perhaps, but not for someone willing to put in a modicum of effort). Many of the worst parts of CSS, and even JavaScript for that matter, come from the need for backw…

> Some of the names are unintuitive, sure. Though I don't think the ones you provided are in particular; I think your distaste for those is subjective.

Relative and absolute... Is there a CSS book or tutorial that doesn't take a jab at these names when explaining positioning?

Re: Ask HN: Is it just me, or is CSS too damn hard?

#293

CSS is great, but its poorly taught. I've known so many developers of all skill levels who get stuck somewhere between "I can make it red but I have no idea how to apply all these random properties into the layout I want." They'd ask me for resources, and I couldn't find one I thought was very good at that. So I tried to write one. https://whatisjasongoldstein.github.io/buildcss/ What's nice about this is I wrote it…

I liked the no bootstrap section. People lack the foresight of shooting themselves in the leg. Currently working on a project where the front-end guys ended up using !important for literally everything due to lack of knowledge on how Bootstrap works.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#294
You don't need to have any creative sensibilities to understand CSS. It is a completely logical language, you just need to grasp the fundamental principles - as with any other language.

I have met many very competent developers who have struggled with "getting" CSS. They didn't get the fundamental logic because they lacked an understanding of the problem it was designed to solve. If someone says CSS is "a series of hacks" or "does not make sense" it is probably because they don't understand the premises for its design.

The design goals of CSS:

* A layout can adjust to any screen/viewport/canvas dimension across any platform - including the printed page.

* Text can be scaled independently of the viewport dimensions. Scaling font size up should not force the use to scroll sideways back and forth - the text should reflow to adjust to the new size.

* Anything can be overridden by the user: E.g the user can scale the font size up regardless of what the designer have specified.

* It should be rendered progressively: the layout of a box may depend on previous content, but not on things not loaded yet - although loading new content might force a "reflow" of previous rendered content.

* CSS applies styling and layout properties to elements in the HTML. So you can paint a border around a HTML element, but you cannot paint a box in pure CSS.

Whether or not you agree with these design goals, CSS makes a lot more sense when you understand them.

Developers sometimes compare CSS unfavorable to GUI toolkits like Windows Forms or to fixed-dimension layout formats like PDF. Those are indeed much simpler to use: You place a control or a line of text somewhere on a canvas, and it generally stays where you put it. But neither format gracefully handle scaling of text, non-standard screen sizes or resizing of the canvas. CSS solves a much more difficult problem than either Windows Forms or PDF attemps to.

So CSS is not about placing object with specific dimensions at specific coordinates. That does not work when all the assumptions behind the dimensions and coordinate may change dynamically. Instead CSS layout is typically defined in relative terms - relative to page width or font size or dimensions of the parent element.

After understanding the design constraints, it is a lot easier to understand the algorithm the browser uses to lay out elements. The is a handful of different algorithms depending on the display property of the current element. This property is the most important CSS property.

inline: Elements flows horizontally left to right as space allows. Line breaks happen when the edge of the container is reached, and the flow continues on the next line.

block: Elements flow top down, one after another. The width of the block is what is available in the container, the height is defined by the content.

table: Child elements are aligned both vertically and horizontally.

flex: Child elements are placed on a single axis either vertically or horizontally, which specified alignment, adjustments and spacing.

(there are more, these are just the most important.)

You will often combine these. Document-oriented layouts typically use inline and block flow. A classical GUI with some panels of fixed size and some panels expanding to the available width will probably use flex.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#295

Earlier quoted context omitted.

> What's the advantage? The same content reflows to different 2D spaces

Flow-like layout is just a sub-problem of 2D Layouting. Having it as the only way to do layouting (besides tables) has proven a nightmare to work with. That's why you got Flexbox (and now Grid).

Flexbox is a layout system for 1D content. CSS Grid is for 2D content, but it's designed in such a way that it can remain responsive to different container sizes, unlike . This actually makes it pretty complicated and unwieldy, because - once more for the people in the back - doing a responsive layout in explicitly 2D terms is a very weird thing to be doing and usually isn't what you actually want.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#296
post #189

Earlier quoted context omitted.

Good comment. CSS is actually pretty simple, as long as you start with the smallest elements and work up. It becomes a nightmare if you try and address everything individually. It’s not really a programming language, but a series of guidelines. I’ve seen this simplicity actually throw developers as they’re used to something much more complex and systematic. Preprocessors like SASS are great, but I wonder if they’re d…

Pixel perfect is not possible in HTML/CSS. Stop spreading this. But it is very possible to make websites look very good and inline with what was designed. But good luck making an input, button and select the same height. It's just not going to be pixel perfect. What is pixel perfect in your browser isn't in others. But what designers should now is it doesn't matter as long as it looks good for everyone.

> But good luck making an input, button and select the same height. It's just not going to be pixel perfect. What is pixel perfect in your browser isn't in others.

It's... actually incredibly easy to do that. You just disable the browser's default styles for those elements and then set their height explicitly.

There is a certain interpretation of "pixel perfect" which, I agree, isn't really feasible or worth trying to achieve, and that's when it comes to layout. You can hardcode the dimensions of "atomic" elements like buttons and inputs all you want, but if you start giving hard pixel widths to containers that should be adjusting their size according to their content and surroundings, you're going to get yourself into trouble real fast. I think designers these days have mostly started to grasp this, though.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#297
You can use JavaScript to extend CSS, to make it a higher-level language and _more_ declarative. CSS has live-updating variables in it which can be set and re-set from CSS, from HTML, and also in realtime from JavaScript. This means we can also include concepts from Reactive Programming and expose the streams of data directly to CSS in ways it can harness for styling purposes.

You can also extend selectors and at-rules in ways that allow you to define new, custom features, supported by JavaScript, and utilized from valid CSS stylesheets.

Given all this power and flexibility, you can go a long way toward turning CSS into the "styling language of your dreams". When you're extending CSS you also get to pick all the naming you work with as well.

Rather than trying to replace CSS, or abstract CSS away, it turns out the friendliest solution is to start with valid CSS and continue building on top it from there.

Check this out for more information about how to extend valid CSS with JavaScript: https://github.com/tomhodgins/caffeinated-style-sheets

Re: Ask HN: Is it just me, or is CSS too damn hard?

#298
I personally love CSS, I can do it in my sleep and enjoy it. JavaScript on the other had has always been a struggle for me, I can write code, but it hurts my brain and I'm not a natural logical thinker. I'd say CSS started clicking for me when I would play around with the Inspector with live previews. Once you learn how display (block, inline, etc.), positions (relative, absolute), margins and paddings actually work everything else is pretty simple.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#299
Sorry, but web UI in general is an industrial dumpster fire. I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter. The layout "math" should all be on a server.

That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of Tim Berners-Lee, a drunk standards committee, or whoever.

And it would mean we (developers & testers) are dealing with one engine instead of the myriad engines one is facing with a combinatorial explosion of browser brands and versions and OS settings. I've seen web UI "testing labs" with 20 PC's and Macs, and that wasn't enough.

The only people who like the current state of affairs are UI/UX specialists; it keeps their wallets fat. Bicycle science was turned into rocket science, and the rockets often crash and burn.

Re: Ask HN: Is it just me, or is CSS too damn hard?

#300

Earlier quoted context omitted.

> Some (unlucky) programmers entire job was turning PSDs into HTML and CSS. That was my entry into programming many years ago. But I wouldn't call it unlucky - early web devs like me (we didn't really call ourselves programmers back then) had front-row seats at the beginning of a revolution, and it certainly was entertaining to watch and be part of. > CSS has nothing to do with design CSS works the way it does becaus…

> CSS works the way it does because it was created to make the kind of designs that designers wanted possible Well, not originally. Later that became a thing, yes - but all the design that was already there at that point (circa CSS 2) remained, as did the overall approach with cascading styles. A styling language designed for HTML5 today from scratch, accommodating modern use cases, would likely look a lot different.

^this

I think the best illustration of this "fight" between CSS as a tool for styling "traditional" hypertekst documents, vs CSS as a tool for styling "web pages" is the fate of Adobe's CSS regions proposal - and Håkon Lie's opinion piece arguing against it:

https://alistapart.com/blog/post/css-regions-considered-harm...

That was when "design" lost. But now with grid and transitions, there's a "new" CSS - one that is oriented around UX for "web apps". But apps evolved from documents, mind - not from windowing toolkits like smalltalk morphs or Java swing etc.

Fwiw I really liked the idea of regions for laying out rich documents - like what you might want for epub.

I must admit I'm not that concerned about "web apps" - everyone seems to end up doing their o we n abstraction anyway, and the CSS that "falls out" isn't really sane anyway.

Post reply on HN