Ask HN: Is it just me, or is CSS too damn hard?
I'm a seasoned backend developer and systems administrator, with over 10 years of full-time programming experience. I've worked with anything from Assembly, C, Rust all the way to Python, Erlang, Elixir, PHP, Haskell, Lisp, Clojure.
When it comes to frontend, I have used React, Vue.js, ReasonML, Clojurescript and Elm extensively, and I know my way around web technologies in general. However, ever since I first started programming, I was NEVER able to get the gist behind CSS. I can't center my divs properly. I can't say "hey, CSS, this is the parent div, and all child divs must obey its size". I can't do anything basic on CSS without turning for help.
Incidentally, but very likely related, I always failed to have any glimpse into how design works. I have no idea which colors "go" with which ones, and pretty much all fonts look like the same for me.
I'd like to know the experience from fellow programmers. Is CSS an "art" thing? Is it common for other developers to have issues with it, or is it just me? Is there any material out there that made CSS "click" for you?
357 comments
[ 5.3 ms ] story [ 224 ms ] threadThey have a pretty nice grid system that allows you all types of formatting options (desktop/mobile). All types of text formatting options too. Honestly, I think you're way better off learning something like Bootstrap unless you want to do this professionally.
[0] https://getbootstrap.com/
[1] https://getbootstrap.com/docs/4.2/examples/
EDIT: downvotes? Why not mention why you don't like bootstrap and share with the larger thread? At least, then it is useful to everyone else.
Step 1: On your container div...
display:flex; justify-content:center; align-items:center;
Step 2: There is no step 2.
.d-flex.align-items-center etc
Each to their own, but it's better to make your own templates, unless your primary role is something other than frontend dev and you want the equivalent of store-bought pasta sauce instead of making your own pasta sauce.
EDIT resources
I personally love https://cvan.io/flexboxin5/ for testing and https://flexboxfroggy.com/ for learning flexbox
Yeah, you're not a designer.
Note I'm not insulting you. :)
CSS is very much like magazine or print layout IMO. If you're not used to that, it won't gel well. If you think of layout from a design perspective and _not_ a programming perspective, it's really not that bad. The warts more come down to differing implementations across browsers, which has become far less of an issue in recent years.
I expect you'll get a very different response from the crowd here, though, so consider it my two cents. I've done much backend work (like yourself) but started in frontend, so I feel adept enough to work with CSS well when I need to. shrug
It just feels like a weird outlier to me - not freeform enough to fulfil the "design" role, not programmatic enough to fulfil the "developer" role.
Designing a catalog is similar to designing a SaaS tool.
Designing a magazine is similar to designing a marketing website.
Working with AdobeIndesign taught me the following things, that translated into web development:
(1) Importance of style guides (things like BEM, SMACSS, etc): If you don't lay these out upfront, your catalog becomes incredibly inconsistent and hard to manage (too many components everywhere).
(2) How to organize your SCSS files - it's actually almost the same way you do it in Adobe Indesign. There's a `base` folder for global layout styling (fonts), `components` folder for things like buttons, tables, etc.
(3) How to layout a webpage. In Indesign, you start with the header/footer usually in your masterpage layout. Then you design each page from top to bottom generally (for a catalog at least). The viewport is more or less the size of a single page. You can only fit so much content there.
(4) Font-types - Open indesign, dig through all 100+ font types and see what the differences are. Some can handle fractional fonts, others have support for narrow styling (Arial).
(5) Design combinations - Take a look at a Grainger or McMastercarr catalog. There's many tricks for cramming a lot of information on one page. Minimal font sizes, horizontal lines in tables, use of white-space eye relief, consistent styling, etc.
(6) Constraints - If you saddle-stitch or 3 punch bind your catalog, your margins differ. If you make brochures, it's like designing for mobile devices
(7) UX Interaction - There's many ways of looking at a page, and where you want to draw a user's attention first.
UX tools are still playing catchup to what Indesign has offered for years.
I would say CSS is different mindset in that there are more rules. And you have to usually handcode it yourself. It's "design" in the sense of knowing what colors to use, size of content, etc. "Development" in the sense of knowing how to use master-page layouts / component designs upfront.
I've had similar experiences with regex, shell, & vim. If you're not doing it all the time, it's easy to just brush it off to the side or google whatever you need to do.
No reason to be an expert in something you're only going to use once in a while.
For virtually everything else in production, you should be using themed Bootstrap or CSS framework x, y, or z that fits to your corporate identity. Usually so you can have a front-end engineer make decisions about symbols and have those changes flow out to the rest of your webpages and web apps without relying much on engineering to hand tune everything all over again. This is sort of ideal CSS usage, though it's probably debatable by folks here.
CSS is development more than it is design. It just helps you accomplish design.
Maybe one of the points glanced over CSS discussions is that the traditional visual formatting model was designed for documents, and not web page and web app layouts for today's world. That's better addressed by flexbox and CSS grids. For instance, the entire concept of floats isn't for aligning things, it's for text to flow around "floated" boxes like images. Most hacks like clear fixes were designed to help utilize floats for page layout versus document composition.
I also think it's getting better. One major problem with css was getting it to work across all browsers, but now if you're lucky enough to only have to support modern versions it's so much easier than it used to be!
One being that practically all software nowadays are webapps and there's no choice. For those that aren't webapps and whose GUI toolkit use CSS or something like CSS, it's probably to try to pull people that already have experience with webapps.
And this is the thing that many web developers miss. As they've begun to creep into the mobile and desktop space, intent on replacing native experiences with a continual barrage of non-native, bespoke apps, each with their own design, they've mistaken widespread availability with quality and utility — that HTML/CSS UIs are widely available is all to do with ubiquity and lessening an otherwise not-at-all steep learning curve, not technical merit.
Give me springs and struts, Autolayout, or PowerApp's style declarative positioning any day.
Positioning is one thing, but CSS really shines in it's graphical abilities. Autolayout is fantastic, but have you tried writing the custom CoreGraphics code that is required to do anything outside of standard UIKit visuals? Not fun [0]. Being able to just type `background: linear-gradient(orange, green)` is a godsend compared to that stuff.
[0] https://github.com/amraboelela/myos.examples/blob/master/Cor...
At this point, I'm starting to look into things that "transpile" to CSS.
Here's a good resource for UX: https://goodui.org
And here is one for color theory: https://uxplanet.org/color-theory-brief-guide-for-designers-...
I think keeping UI components tiny and coupling the stylesheets with the component is the best way I've seen (not necessarily styled components, just styles in the same folder as the component.)
As the component is removed, its easy to nuke the stylesheet with surgically removing related styles and not breaking something else.
I feel the same. I fiddled with css on personal projects just fine, but in my job, diving into years of accumulated, imbricated classes is a nightmare and even though I try, 80% of the time I end up passing the problem to the design team.
Javascript is logical (sort of...), and a lot like learning math. It's fairly easy to validate your output. It works well with the logical side of your brain.
Learning CSS is a lot like learning English. There's the basic grammar, but also tons of edge cases, dialects, and straight up absurd rules (Buffalo buffalo..). It's a language primarily improved through experience and memory.
CSS has undergone LOT of development last few years, so things like div centering can now be solving by margin (oldest), flex (newer), and grid (newest), but only in certain browser. It's a language you must constantly keep up with.
Design is just colors and fonts right? (At least, that's what my CEO says). It's important to realize that good design is as hard as good code, and you really benefit from a similar education. That being said, cheat by using a color wheel or Coolors.co
Fonts all look the same until you learn how to look at them. Wine all tasted the same to me until someone taught me what to look for. Without knowledge about why fonts are a certain way you'll never be able to pick one, but it's totally possible to pick that knowledge up. Find a beginner book on fonts and you'll be on your way in no time.
CSS has nothing to do with design. It is the tool used to implement the design and there are loads of other layout tools out there that don't have CSS's infuriating quirks. On the flip side, they usually have steep learning curves because they are strict.
For a long time, until less than a decade ago, designers knew nothing about CSS. They'd do a design in pictures and their design would be implemented by a programmer.
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 because it was created to make the kind of designs that designers wanted possible. It has everything to do with graphic design. All the web designers I knew back in the early days knew some HTML and CSS and we'd often discuss possibilities and limitations of browsers and standards, and how to work around issues. They didn't just lob PSDs over the partition to the devs - there was an active dialogue and they knew their stuff.
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.
If we were going to start from scratch though, we wouldn't do HTML5, we'd use some other format. JSON maybe?
1. https://en.wikipedia.org/wiki/JavaScript_Style_Sheets
No-one went pure code (because it's a massive PITA).
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.
You were one of the lucky ones. I worked with designers who would've done fine designing a printed flyer, but couldn't comprehend the idea of a scrolling website with dynamically-populated content (of varying lengths) being viewed at different sizes on different devices/browsers.
Their solutions were along the line of "Force the browser to be XxY resolution and limit the number of words that can be entered in this area."
I find this false. PSD-to-code was very common back then. There even still some designers today that only work via images/PSD.
What a bizarre statement. That's like saying words have nothing to do with stories, or paint has nothing to do with art.
I don't think CSS is any less logical... but some might not be use to _declarative_ languages like CSS is?
With CSS, you can't avoid hacks. If you try to design anything non-trivial, you will have to employ tricky non-semantic tricks, run into edge cases, and have to settle on ugly, non-optimal solutions.
I don't think it's a declarative vs imperative thing. It's more that CSS was designed to be easy to use and relatively terse for a specific, outdated use case (20+ years ago when a website page was thought as a 1 dimensional flow of text and pictures).
Nowadays our requirements encompass pretty much the full spectrum of 2D space design, yet we still use a language that builds on high level primitives designed for a narrow usecase.
New features like Flexbox and CSS Grid help with the layout part, but it's not enough.
Here's the thing though — most websites are still just a '1 dimensional flow of text and pictures'. They try to disguise it with multiple columns of guff, but it's still just text and images. Sometimes a video.
Sure there are web 'apps' now too, but most websites are not apps (thankfully).
The thing is, web apps are also just a more complex version of the same '1 dimensional flow of text and pictures,' just maybe with Canvas and a lot of javascript. There's no real difference between a web app and a document, as far as HTML/JS/CSS is concerned. The dirty secret of the whole "the web used to be documents but now it's applications" meme is that the applications are still documents.
Just... use the constructs you're familiar with? It's not like you can "accidentally" use an ES6 class or something.
You can know about for..in without knowing about hasOwnProp.
You can forget to enable strict mode.
The list goes on. Static analysis is universally a good thing.
I don't think it is caused by this aspect of CSS.
The problem could come from the fact that it mixes 2 purposes: style AND layout to apply it globally with rules that get harder to understand the bigger the project.
Yeah, I'd sum it up by saying CSS makes hard things barely possible and simple things hard.
The example OP gave of centering divs illustrates this point, and there are unnecessary weaknesses in laying out a page when, for example, sizes aren't known in advance. Overall, there's a divide between intuitive expression and output, wherein the browser ends up saying things like, "I won't do this (e.g. center) unless you also do that (e.g. tell me how big it is)." Really? Why?
In all, it's never been an efficient solution to the problem it seeks to solve. When the Great War on Table-based Layouts broke out, it was even less suitable, which made it even more painful that you were persona non grata for resisting. So, rather than demand a better standard and uniform browser support, we just hacked and kludged and shimmed around it. So, the need to support the legacy has made it even more impractical to fix, hence the attempted do-over with flexbox.
CSS has been the bane of front-end development for many a dev. Amazing that we largely just suffer through it, and its tyranny has reigned for so long.
[1]: https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buff...
Nearest English silliness I can remember hearing is: police police police police.
Police police police police is grammatically correct, but of little meaning : (the) police police(v) police (of) police (ie overseers of the police).
Policing OTOH seems to be a fairly widespread verb form with a clearly understood meaning (i.e. what the police conceptually is supposed to be doing). Unless you have close experience with buffalo, you probably can't infer buffaloing means "intimidating".
EDIT: Also as mentioned elsewhere, not everyone outside the US knows there are places actually called Buffalo or makes that leap when hearing the word "buffalo". So "Buffalo buffalo" is more likely to be read as "buffalo(n) buffalo(v)" (which already sounds weird if you don't already know what "to buffalo sb" means) which breaks down as soon as you add more buffalo to the sentence.
Buffalo the city was probably better known 150 years ago, when it was an economic powerhouse as one of the end points of what’s still the second most famous canal in the Western Hemisphere. Afterward it continued to be a significant industrial center until the decline of manufacturing turned the Great Lakes region into part of the “Rust Belt” in the past 50 years. Most Americans probably know of it these days because it still hosts an American football team.
Anyway, the point isn’t that that’s a common sentence. It’s that it’s a grammatical one.
Of course the cutting edge will temporarily see one rendering engine a few months behind another. But that’s unavoidable unless you prefer a monoculture, which is liable to move slower than slowest of today’s major rendering engines.
It’s perfectly normal today to create CSS (and JS) in one browser and find it working flawlessly in another. 10 years ago, you would have called everyone over to your screen to have them witness this miracle.
No, it really isn't.
Some languages are, JS definitely isn't. It's mostly illogical / broken / mental.
Even if it were an argument I'm not even sure it would be an argument worth having because it's likely entirely orthogonal given the context of the original statement (i.e. contrasting JS with CSS and HTML -- where whatever esoteric programming language you're thinking of is not an option to begin with).
When you consider UX, accessibility, progressive enhancement, cross browser and cross device support - there’s plenty to know. And unlike programming, it doesn’t all flow logically. Some stuff is subjective, other stuff requires specific knowledge of browser quirks etc.
The only site that helped me gain some _understanding_ of CSS (as opposed to knowledge, tricks and hacks) was this one http://learnlayout.com
It’s a bit dated now - Flexbox is mentioned at the end and CSS Grid is entirely absent - but still important if you’re supporting older browsers.
But CSS has never “clicked” for me. For a start the whole idea of cascade is based on inheritance and I generally prefer composition. I like designing UIs and it’s quite a satisfying challenge to match a wireframe to the pixel. But overall, I’d rather be writing application code.
If users could just read JSON everything would be a lot easier...
This is actually pretty simple, once you understand how "block" elements work. Block elements will always try to fill up the "available width" i.e., they stretch side ways. The sum of margin + its width must match the total width.
Inline elements will fill up its parent block like text.
So, a simple example - suppose you set a div's width to 100px, and margin to auto, then you will a 100px wide box centered.
I see people get confused when they try to have a block that has an unspecified width and hope CSS just figures out.
I disagree -- in this and every case where someone has told me that something is simple once you understand the fundamentals. Understanding how a tool works is completely different from understanding how to use it to accomplish a particular goal. One's a deconstructive process, and the other is a constructive process.
To keep my sanity, I try to avoid touching it as much as I can (I use Semantic-UI which gets me most elements with little effort), and when I have to, I try to stick to the more recent, reasonable parts. Flexbox for example is understandable and predictable.
No one takes CSS seriously. For most, CSS comes as an after thought. Build every part of the application then suddenly "Oh Right! CSS!" Slap bootstrap or other popular framework then don't think about it.
Yes, CSS is not a programming language like others but it is just as complex. It requires studying, practice and long exposure to become versed in it.
Note: you can google your way into using a couple jquery functions, but you can't become a competent JavaScript developer like that. The same goes for CSS.
It depends on the problem your trying to solve, if you just want something that looks decent (because you're a programmer and you don't notice things like colors, alignment and spacing) then something like bootstrap is a good go-to.
I still think learning CSS properly is worth it, using bootstrap without knowing CSS is like using an ORM without knowing SQL, but less dangerous.
Classic example is CSS grids that is only recently starting to become ubiquitous in commonly used browsers, and the new units of measurement that go along with it like 'fr'. CSs does not feel stagnant to me, but is evolving I think... Perhaps not at the breakneck speed that JS libraries are, but then the core of ECMAScript is not going as fast as JS libraries either.
CSS can be fun. Its easy to learn but hard to master.
Be careful; if people recognize you know anything more than basic CSS, you’ll become the CSS helpdesk