
Ask HN: Is it just me, or is CSS too damn hard? - napsterbr
Hey HN,<p>I&#x27;m a seasoned backend developer and systems administrator, with over 10 years of full-time programming experience. I&#x27;ve worked with anything from Assembly, C, Rust all the way to Python, Erlang, Elixir, PHP, Haskell, Lisp, Clojure.<p>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&#x27;t center my divs properly. I can&#x27;t say &quot;hey, CSS, this is the parent div, and all child divs must obey its size&quot;. I can&#x27;t do anything basic on CSS without turning for help.<p>Incidentally, but very likely related, I always failed to have any glimpse into how design works. I have no idea which colors &quot;go&quot; with which ones, and pretty much all fonts look like the same for me.<p>I&#x27;d like to know the experience from fellow programmers. Is CSS an &quot;art&quot; 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 &quot;click&quot; for you?
======
_bxg1
1) CSS is for implementing designs; being able to use it doesn't require
design sense for things like colors

2) 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, though I did write an article hoping to address it in
some capacity: [https://css-tricks.com/css-is-awesome/](https://css-
tricks.com/css-is-awesome/)

I think part of the problem is that many programmers, who like things to be
orderly, see CSS as arbitrary and chaotic. Here's the biggest point that I
think has to click: CSS isn't a programming language, it's a _constraint_
language. The browser has lots of default, complex behaviors that drive
layout, and whereas in a traditional programming language you tend to "build
up" from nothing, CSS is more about paring down and guiding that automatic
engine with as few statements as necessary. You tell the browser exactly what
your layout requires, and the browser figures out how to flesh that out into
various contexts and situations.

Personally I think CSS is beautiful: it's stateless and declarative, and it
allows you to talk about huge swaths of entities in very general terms, gently
paring down their avenues of expansion until the possibility space aligns with
what your application requires. It's incredibly elegant once you get the hang
of it; I sometimes find myself wishing I could use a similar paradigm for
talking about objects in other contexts.

~~~
Animats
CSS is not a real constraint language. If it really were a constraint
language, it would be better. There's no constraint solver. Just a bunch of
rules applied sequentially.

I'd like to have a real constraint system, like the one in Autodesk Inventor
sketch mode. You select two things and apply a constraint - parallel, tangent,
horizontal, collinear, etc - and the constraint system enforces those
constraints. The layout GUI tells you if you've created a conflict. CSS solves
an easier problem, and not very well. It's such a mess that no one can attach
a decent GUI to it.

Amusingly, tables came back. But they're called "layout tables" now, to avoid
embarrassment. Trying to do 2D layout with 1D constructs (the "float" and
"clear" era) was just silly.

~~~
_bxg1
> Amusingly, tables came back. But they're called "layout tables" now, to
> avoid embarrassment.

I'm not really sure what you're talking about. Tables were bad because they
were too rigid and weren't designed for layout purposes; they do still get
used when you want to display an actual table. Maybe you meant CSS Grid?

> Trying to do 2D layout with 1D constructs (the "float" and "clear" era) was
> just silly.

The float era was certainly a dark time, and I'm glad I came into the field on
the tail end of it. It was a hold-over from CSS' document-focused origins.
Today we have flex-box, which quite elegantly serves 90% of people's layout
needs, and CSS Grid which fills in the rest. For the record, flex-box is a 1D
construct for doing 2D layouts, and it does the job fantastically.

Your Autodesk comparison belies a fundamental misunderstanding about the
nature of the DOM - it is, to its great advantage, a 1D space which flows into
a 2D shape. In fact, this was the great flaw with using tables for layout in
the first place. By making the content fundamentally 2D, all it could do to
respond to different screen sizes and different browser window resizes is
stretch. But you don't actually want your layout to be totally percentage-
based. You want your content to wrap and flow to make the best use of the
available space that it can, with no assumptions about screen size or ratio.
The web is 1D because _text_ is 1D. As text flows in lines, within containers
which may be different shapes and sizes, so does the entire document model.
This is profoundly powerful. Modern CSS gives you the tools to make select
aspects of your layout work differently - yes, even in 2D ways - but they're
best used to shape and guide that fundamental flow instead of replacing it.

~~~
zeroname
> Your Autodesk comparison belies a fundamental misunderstanding about the
> nature of the DOM - it is, to its great advantage, a 1D space which flows
> into a 2D shape.

What's the advantage? The screen is 2D space. Layouting is a 2D problem.
Images are two-dimensional. It's simpler to start from 2D and make 1D content
fit that space than the other way around.

> The web is 1D because text is 1D.

That made sense in the very early days of the web, now it's just a historical
crutch. I fully understand _why_ things are the way they are, but that's
orthogonal.

~~~
shaki-dora
Humans can only focus on a single thing at a time. As your focus goes through
any content, it necessarily follows a 1D path. HTML, eint Text, is also one-
dimensional.

CSS, as said before, transfers this 1D information into the 2D representation
on a scree, or a printout. Or it leaves it allone, or rearranges the 1D
stream, for a different 1D representation to a screen reader.

This has nothing to do with being a “historical artifact”. It’s a fundamental
idea of communication theory. But maybe it helps you to see its value if I
just mention that thinking a bit about such theory will make it far easier to
you to create designs on the vastly different devices, from smart watches to
Times Square screens connected too the internet now.

~~~
nnq
> As your focus goes through any content, it necessarily follows a 1D path

No. Not at all. Almost never. Your brain is a chiefly parallel processing
device, no matter how much you delude yourself that "you read text in the
order it was written" and other such nonsense...

It's widely known that this is not even how people _read text_. Even when you
listen to music, and nothing is more 1D than sound, your brain chops it up and
rearranges in multiple concurrent variants trying to "do the shazam thing" of
identifying what else it may be even a bit similar to even if you don't
realize it...

"Following a 1D path" through content is what you do when you either want (1)
to reliably communicate at _the lowest imaginable common denominator with
people with unknown and presumed low skill and intelligence_ (eg. "talk to a
customer" or "talk to the bank teller") or with _people so mentally different
from you that they are close to being a different species_ (eg. "talk to an
accountant or lawyer" or "send a binary encoded message to maybe be received
and decoded by an alien civilization"), or (2) you actually want to force a
particular interpretation of the sequence and causality of things to people
(eg. "explaining history to people" or "telling an educational story" or
"manipulating people" or... "selling stuff to people").

 _All the other communication_ , and more like the only part of interpersonal
communication that _I_ find interesting is _non sequential_ , it's about
working with information that can be rearranged in multiple equally valid
sequences and interpretable in multiple possible causality graphs. Think maps
and painting. Or a textual description of a stack of maps etc.. Or computer
code _as it actually gets executed on an even slightly parallel machine_ (not
"as it stays written code in a text file", that's also a "lowest common
denominator representation" bc human and computer brains are so different).

------
notjustanymike
I work as a frontend architect and UX lead (yes, it's tiring), and you're
encountering a common problem.

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.

~~~
mattmanser
A layout engine and design are two entirely different concepts.

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.

~~~
perilunar
> 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.

~~~
int_19h
> 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.

~~~
perilunar
It would probably be written in JS, maybe something like JSSS [1]. I remember
playing with it when it came out and thinking it was very cool. Pity it never
went anywhere.

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](https://en.wikipedia.org/wiki/JavaScript_Style_Sheets)

~~~
mattmanser
Extremely doubtful, given that many of the modern ones have been written in
XML (e.g. xaml, android) and iOS went old skool with a drag/drop GUI.

No-one went pure code (because it's a massive PITA).

------
nightlight
> 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?

If you're coming from an application development background, you will hate CSS
layouting. It's the most ass-backwards way of structuring a UI that you will
ever encounter. A lot of web people who never used stuff like Qt, Swing,
Winforms (etc) just don't realize this. They think there's some sense in CSS.
There isn't, it's a bunch of historical accidents.

HTML wasn't designed to be dynamic, it was designed for documents. CSS wasn't
originally meant to do layouting. The end result is an incredible amount of
technical debt. CSS performance is a complete disaster. It's _unfixable_. If
you need to do a non-trivial amount of dynamic content, you need to use Canvas
or even WebGL and re-implement a lot of stuff yourself, but then people will
complain that it's not "semantic", that it's poor design and that it goes
against what HTML is meant for. It's a complete joke.

The thing is, you don't have much of a choice. The web platform is what it is.
If you want to work in the web frontend, you'll have to deal with it.
Alternatively, don't work there. There's other opportunities.

~~~
mcv
I'm glad to read I'm not the only one struggling with it. It's not as bad as
with the OP; I can get stuff done in CSS. But any non-trivial layout always
requires a lot of trial and error: does this need to float? Does inline-block
work better? Now there's flex layout on top of that. Do I need relative or
absolute positioning for this thing? Do I need padding or margin here? And why
does my margin not do anything?

Every time I think I finally understand it, I run into a situation where it
doesn't do what I expect. And then there's hacks with negative margins and
that sort of stuff, where it feels like CSS needs to be wrangled into doing
something it doesn't want.

~~~
xemdetia
The worst part for me is that it's one of the few places I end up having to
hack my hacks because I find out that Firefox does something wildly different
from Chrome so the fix I just made to Firefox made it better but broke
something else. It feels just as annoying and opaque now as when I was doing
CSS hacks for Netscape navigator vs IE. The other thing that frustrated me
about CSS and continues to this day is the lack of permanence of a working
layout. That is one of the things that really separates the backend from the
front end mindset for me, the back end can be done forever but the front end
will have to change to fix something unknown in the future

------
ctidd
I'd recommend spending some dedicated time learning about layout, not leaning
on a framework.

CSS layout is largely about the relationship between elements. Instead of
looking at it as "I want this element on the right," try to see the
relationships between elements. What's the group of elements, and what causes
them to be where they are? (Generally, complex layouts are nothing more than
nested groups of elements.)

Once you recognize the patterns, CSS layout becomes straightforward. Not easy,
but straightforward. It becomes a matter of defining and expressing the
relationship between elements, and the constraints that define their layout.
Flexbox is really the thing to focus on here. Don't worry about the words if
you mix them up -- justify vs align, etc. Just the idea of a spacial
relationship between things with rules that define the constraints.

Often times, the relationship winds up being expressed as "I want this group
to consist of items with space between them on the current row they wind up on
opposite sides of viewport, and when they wrap, I want everything aligned to
the left."

Also, really understanding CSS is not about tricks, but if there's one thing
that can help you gain an appreciation, it's learning how to write layouts
that can handle arbitrary number of elements without any templating logic to
add special case classes, e.g. for the first and last column in a grid. To
this end, using equal but opposite positive and negative margins (negative on
a container, positive on its children) can provide space between elements and
allow for arbitrary numbers of elements within a layout where you don't care
which is first or last in a given row. Let the elements flow into the layout.

I think there's a pretty definitive set of exercises any developer could work
through to learn about the different types of constraints we need to express,
and from there, it's generally a matter of recognizing the pattern in a
higher-fidelity format.

~~~
spinningslate
That's _really_ interesting. I'm also firmly in the space of finding CSS
layout inscrutable (CSS _styling_ is fine). I'd concluded that the issue is
precisely the _lack_ of peer-to-peer relationship constructs. Everything
seemed based on 2 constructs:

1\. Flowing 1D content (text) into a 2D space

2\. Hierarchical relationships, i.e. positioning children with respect to
parents.

I haven't looked deeply into flexbox or grid. My initial skim suggests they're
both still fundamentally hierarchical. I'll take another look now given your
comments.

I'll freely admit I haven't invested a lot of time trying to get to grips with
the more recent constructs (flex/grid). I would say my initial forays were
difficult and frustrating. CSS layout seems (seemed?) the antithesis of the
maxim "make the simple things easy and the hard things possible".

As a counterpoint: back in the midst of time, there was a cross-platform UI
toolkit called Galaxy. It only had 2 layout constructs: springs and struts.
Springs defined a proportional layout between components (so would
stretch/compress), struts defined a static relationship. It was remarkably
simple to define layouts using just those two concepts.

The web is clearly a more complicated space than conventional, thick client
apps that only ran on the desktop. Responsiveness is a much bigger challenge
now. Nevetheless, it seems to me that the key construct lacking in CSS is the
ability to specify peer to peer relationships among elements - without needing
to create a whole cruft of container components.

You've incentivised me to give flex/grid another look. I remain healthily
sceptical, but thanks for the prompt.

~~~
e12e
I'd say grid is much more of a "new" concept for CSS than flexbox.

And while I'd always understand learning the basics - to get stuff done most
everyone landed on hard coded (sort of) grids before "CSS grids" came out.

Beyond that, I still recommend looking in the (reborn) CSS zen garden:

[http://www.csszengarden.com/](http://www.csszengarden.com/)

------
foxfired
I remember when I first told my colleagues that I followed every single CSS
course on Lynda, they laughed. They thought why would you spend all this time
on a non programming language?

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.

~~~
flukus
> Build every part of the application then suddenly "Oh Right! CSS!" Slap
> bootstrap or other popular framework then don't think about it.

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.

------
elviejo
CSS is almost a failure as technology. None of it's promises has been
realized.

The idea with CSS was that we would be able to separate content from
presentation. Remember CSS Zen garden? Yet that has never been the case and
div tags were always needed to be able to display something simple.

Another promise was that content would be displayed easily on different
mediums, desktop, mobile even print.. yet it's impossible to get decent
rendering in every medium.

For the first years of CSS it was always easier to get a decent layout with
tables than with it.

Finally all the CSS preprocessor, like saas and compass show how incomplete
the technology really is.

~~~
themacguffinman
It's only a failure when viewed through the lens of application development.

The web platform wasn't initially designed for applications, it was designed
for documents.

If you're crafting a document, you can separate style from content pretty
neatly with CSS.

~~~
Mikhail_Edoshin
What if my style requires a triple outline around a header?

------
jvvw
The fundamental problem, I think, is that alignment is a key concept in design
which isn't reflected well in CSS. The concepts of normal flow and the box
model are almost at odds with wanting to align lots of different parts of a
page. CSS Grid and Flexbox do help with this certainly but don't completely
solve the problem.

Even disregarding mobile and tablets, I think it's also sometimes surprisingly
quite hard sometimes to specify how fundamentally you want a page to look in
differently-sized browsers - how things like spacing and guttering and so on
should work particularly when your content is dynamic.

Plus, there is the fact that it is hard to shield parts of your page from
being inadvertently affected by CSS that you don't want to affect it. Again,
there are ways to minimise this, but if you're not the only person working on
your codebase, good luck!

And if you want to learn a bit about design, The Non-Designer's Design Book by
Robin Williams is a good starting point. It is a quick and engaging read and
will certainly make you start to appreciate things like the differences
between fonts.

------
dsherry
I actually prefer coding CSS from scratch. Color schemes and making things
look nice IS hard, for my previous and current projects I had to get feedback
from friends, family, end users, graphic designers, etc. UX is hard, it's a
different field than programming, but there is a method, research, and science
behind it.

Here's a good resource for UX: [https://goodui.org](https://goodui.org)

And here is one for color theory: [https://uxplanet.org/color-theory-brief-
guide-for-designers-...](https://uxplanet.org/color-theory-brief-guide-for-
designers-76e11c57eaa)

~~~
devmunchies
I also really enjoy building CSS UIs from scratch, but editing existing
stylesheets is a pain point. Band-aid after band-aid.

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.

~~~
monkpit
Why not styled components? It’s what immediately jumped to my mind while
reading your comment, until you said otherwise :)

~~~
arvinsim
Styled components, CSS-in-JS and CSS modules largely solve the same problem. I
think it's just a matter of preference.

------
d0m
I hate css, but one of my colleague (who's really good at it) told me once
that people have problems with css because they don't study and take it
seriously. I.e. I spend so much time reading on new languages and design
architectures, but besides some articles here and there I don't study css or
take it seriously at all. So yeah, there you have it.

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!

------
nroviw
CSS is not as difficult as many people think.

I believe part of the reason why developers have trouble with CSS is that they
don’t ever try to write it from scratch. A lot of web development
tutorials/courses/bootcamps often go in depth on JS and maybe HTML but always
just slap in CSS frameworks to make things look nice as an afterthought.

I remember the first project I worked on as a web developer was to update the
styles of an existing web app with very complex UI. It was hard as hell. But I
was lucky to have worked with a senior developer who was a CSS wizard. He
taught me that CSS is not magic although it is magical. If you don't give up,
you can bring any designs to life.

Not knowing any better, I spent months playing, tweaking, learning how to
style different components from scratch. I mastered selectors and the cascade,
block model and floats, display and position types, a few tricks like using
negative margin, constructing triangles from borders. I never stopped honing
my skills. Before long I started learning about responsive design,
transitions, animations, performance, and design systems.

CSS became a playground for me to experiment. It opened up a whole new world
to express my imaginations. My advice for anyone aspiring to master CSS is to
find some design inspiration that you like and just build it. You'll learn so
much along the way if you don't give up. At some point, things will fall into
place and you will realize just how wonderful CSS really is.

~~~
mattmanser
No, as someone who's struggled, and seen other programmers struggle, with CSS
way before bootstrap was released I can assure you this isn't true.

------
lazyjones
The whole set of web technologies is a mess. We‘re still in the stone age of
web UI design, similar to the 80‘s era of home computing when everybody built
their own UI with basic drawing primitives. It’s going to take a while till
decent, cross-platform/device UI libraries make progress and designers
discover the value of reusable components that just work and are familiar to
users.

Until then, we‘re stuck with terrible websites with, at most, one messy
version full of ads for desktop computers, with much too small
links/navigation elements for tablets (hi, HN!) and one clunky mobile version
that looks horrible on most devices, particularly tablets.

~~~
api
The sad thing is that by the 1990s we'd figured out how to do good UI design
for desktops, but then we promptly forgot every single bit of that knowledge
when the web came along.

~~~
the_pwner224
But the web wasn't supposed to be a UI platform - it was supposed to be a
medium for delivering text with some images and media occasionally
interspersed. Hyper _text_ markup language.

Java applets could use Swing to get a normal-ish desktop UI and still be close
to the web. But we keep trying to cram a UI framework into HTML/CSS.

The standards are slowly mutating and eventually they may provide a good UI
framework.

JavaFX and Qt are both modern UI frameworks. Both provide a drag-n-drop
interface to design applications using standard widgets such as lists and
tabbed panes etc. You can modify the styling with CSS (at least in JavaFX, I
don't have much experience with Qt). But the final layout spec is done in FXML
or the Qt XML format - the XML has <TabbedPane>s and <HBox/VBox/GridBox> and
<Button>, with CSS used to style these elements and dictate their visual
properties. Instead of divs and spans hacked with css/JS into becoming
scrolling lists and tabbed panes or horizontal container boxes.

I know the basics of HTML/CSS and it took me half an hour to figure out how to
put 3 images side by side. Because divs can't represent that naturally - I had
to use weird css and put 3 divs inside the outer div. In JavaFX you would put
an HBox and drag three Images into it and it just works, because a HBox
represents a UI concept instead of a document markup concept.

~~~
prewett
I must be missing something, because isn't 3 images side by side just:

<div><img ...><img ...><img ...></div>

? But you're right, the web isn't a UI platform. It's designed for to produce
things that are like Microsoft Word documents. Web-apps are like using
MSWord's scripting and text layout to produce a MSWord-app. Yeah, one can do
it, but it's like cutting a steak with a spoon.

~~~
the_pwner224
You are somewhat correct. I just tested with the tiny HN logo (upper left of
this page), and a div with 3 imgs makes them appear side-by-side. The issue I
had previously was that the three images were quite wide, and while I wanted
them to still go next to each other (with a horizontal scrollbar in the
browser), the browser moved images into a new row if they would overflow past
the right edge.

I haven't used JavaFX in a while but I'd bet there's a checkbox you can toggle
in the builder GUI to control how an HBox overflows.

The solution for HTML/CSS was to give the outer div "white-space: nowrap" and
the three inner divs (with images inside them) "display: inline-block".

~~~
scottmf
Aren’t imgs inline-block by default?

------
adrianhel
The tipping point for me was memorizing "A complete guide to flexbox" from the
site "CSS Tricks" by using flash cards (Anki).

The problems with CSS are:

\- A lot of features have been abused before there were good layout features
in CSS. *

\- Errors are silent and you can repeat rules. __

\- Selector specificty is a major fail in the language IMHO. __*

\- Everything is global. __*

* An example: floating an image is an excellent way of wrapping text around an image. Inline blocks are excellent for inserting layout in the middle of text. Neither are ideal for creating a layout. Flex and grid has now fixed that however.

 __What helps is to internalize the core concepts and to never "slap on
another rule" when things just don't work. Start from scratch and update your
mental model.

 __* CSS-in-JS bypasses the issue of global selectors. And when CSS is
localized, specificity becommes a none-issue. Check out styled-components for
either React or Vue. When IE11 dies and Edge turns Chromium, shadow DOM will
probably become the standard way to solve this.

~~~
adrianhel
Multiple asterix are stripped it seems.

~~~
TeMPOraL
Asterisks are used for emphasis here:

    
    
      *like this*
      =>
    

_like this_

Footnotes we do usually do with a different mark here; some use square
brackets [0], others use superscript chars¹, and I've also seen daggers†
around.

------
kearneyandy
It clicked a bit more for me understanding the box model better. More recently
flexbox makes things a lot more clear/easier and handles a lot of those
problems by default. I have no idea how design works, that seems a bit more
art.

EDIT resources

I personally love [https://cvan.io/flexboxin5/](https://cvan.io/flexboxin5/)
for testing and [https://flexboxfroggy.com/](https://flexboxfroggy.com/) for
learning flexbox

------
coffeefirst
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/](https://whatisjasongoldstein.github.io/buildcss/)

What's nice about this is I wrote it for real people, tested it on them,
applied their feedback... etc. It's a little old now (this was before
widespread Flexbox support) but it's specifically aimed at the sorts of
problems you described.

~~~
wieghant
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.

------
weliketocode
It sounds like you just haven't put in the effort/time. I very much doubt that
CSS is "too hard" for you.

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.

~~~
ummonk
I would put regex shell and vim all in the same bucket as being esoteric and
hard to learn since they don’t replicate any of the normal syntax and patterns
you are used to. Actually, they are arguably even weirder than CSS.

------
Skunkleton
My frustrations w/ CSS stemmed from not having respect for the complexity of
the problem that CSS solved. I went into it w/ the same attitude of "hey, just
center this thing", and didn't really get anywhere. These days I have accepted
that CSS is a tool for pros, which I am not.

~~~
exodust
> _hey, just center this thing_

Step 1: On your container div...

display:flex; justify-content:center; align-items:center;

Step 2: There is no step 2.

~~~
bsamuels
this won't work on bootstrap elements

~~~
exodust
Another reason to avoid bootstrap if possible. I wouldn't touch that thing
with a 10 foot div.

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.

------
Arnt
Speaking as someone who has no problem with either CSS, SQL,
C++/java/perl/python/assembly or Jan Tschichold, the problem with CSS doesn't
seem art-like, but rather SQL-like. People expect CSS/SQL to be like those
other languages that also have indentation and (){}[], but they are based on
other concepts.

C++ and Python may be different from each other, but they're both imperative
block-structured languages with a strong emphasis on time and happens-before.

SQL is set logic expressed as ABNF. If you want to write good SQL you have to
let go of assignments that happen-before other assignments. Instead there are
sets, unions and other concepts from logic.

Debugging javascript is a little different from debugging C++. Debugging SQL
is fundamentally different.

CSS is like that. It's Jan Tschichold's design rules expressed using ABNF and
has nothing to do with von Neumann machines. You might achieve Zen by reading
one of Tschichold's books, and ignoring all of the syntax and tricks and
howtos for a while.

------
hobofan
I held the same belief for a long time, but now I think that CSS isn't
particularly in general, but can be very hard if a few core concepts are
missing.

The main thing that personally made it really hard for me is that I totally
forgot about the first thing you learn in CSS: _Cascading_ - Coming from saner
languages, the concept that what is written at the bottom of the file has more
meaning than what's at the top of the file, or even worse that the file that
is included later in the HTML has more meaning (without much scoping, and
sometimes unintuitive specificity of selectors), seemed bonkers to me (and
still does to some degree). Once I internalized that, that solved 50% of my
CSS problems.

Apart from my anecdotal stupidity, one of the best resources I found was
"Learn CSS Layout the pedantic way"[0].

[0] [http://book.mixu.net/css/](http://book.mixu.net/css/)

------
Klonoar
>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.

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_

~~~
Doctor_Fegg
Can I be really predictable and give a "very different response"? Worked in
magazines for years, still do a lot of print cartography, and I find CSS a
completely different mindset to Illustrator or InDesign or Quark or whatever.

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.

~~~
davidivadavid
Same for me. As someone who's done a lot of layouts in InDesign, it seems to
me that CSS is only starting to offer decent tools to reproduce that mental
model (e.g. CSS grid). But somehow doing incredibly basic things such as
positioning or aligning elements can still take inordinate amounts of time.

------
jayshua
I was in your boat about five or six years ago. Programming was fine, CSS was
kinda-not-really ok, and design was just non-existent. Over time though, it
really is something you can learn.

I started by cloning designs in CSS that I liked. Same way I write programs
just to learn. Pick a design and try to reproduce it. (Here's a good simple
one that could probably be finished in a single sitting. [1]) Eventually I was
able to clone an entire website while only referencing the internet for CSS
details, not core concepts. It'll take time just like learning any language,
but the theory behind CSS does make sense if you can peel back the layers of
features built on top of it. (Like Git, the core model is beautiful - the CLI
not so much.) Reading about the "cascade" part of "cascading style sheets"
would be a good place to start if you get the basic syntax already. Then study
the selector operators. All of them, there aren't that many.

Then read books on design. Info about CSS the language is readily available
online. Info about design, not as much. Design for Hackers [2] is targeted at
programmers and explains not just the _what_ but also the _why_ certain
designs work. The way our brains interpret color and how that causes certain
colors to work well together. How people process information and how to
leverage that to make designs that "make sense." Visual Grammar [3] is a
design reference book I refer to. It's like a SQL reference book - won't teach
you the language (of design) but explains the options you have and when they
could be useful. Things like "these types of alignments will produce this type
of result."

Just remember that it takes time to learn a skill. And design is definitely
that - a skill that can be learned.

[1] [https://assets.awwwards.com/awards/images/2016/04/uxpin-
teas...](https://assets.awwwards.com/awards/images/2016/04/uxpin-
teaser-2016-web-bundle-1.jpg) [2] [https://www.amazon.com/Design-Hackers-
Reverse-Engineering-Be...](https://www.amazon.com/Design-Hackers-Reverse-
Engineering-Beauty/dp/1119998956) [3]
[https://www.barnesandnoble.com/p/visual-grammar-christian-
le...](https://www.barnesandnoble.com/p/visual-grammar-christian-
leborg/1101639288/2694163951767)

~~~
maroonblazer
I'll toss another design resource into the mix that I don't think gets
mentioned enough: John McWade's "Before & After" magazine and videos. His
focus isn't exclusively web but the principles he applies also apply to the
Web. He does a fantastic job of training one to develop the eye of a designer.
E.g. noticing certain patterns that aren't immediately apparent and then
working with those to bring out a certain aesthetic.

I can't recommend him highly enough.

[https://www.youtube.com/watch?v=gQ3NJGJY_F4](https://www.youtube.com/watch?v=gQ3NJGJY_F4)

------
saagarjha
I've written a small but non-trivial amount of CSS for my website recently,
and my general perspective has been that CSS has quite a few non-obvious
corner cases (margin collapsing, the exact semantics of how things will wrap
or overflow) and I really haven't quite understood why certain solutions work
and when some don't (when they seem to do the same thing?), and I'm not sure
if it's because the model is just too complex or these are idioms that I
should memorize.

------
fsloth
CSS is not an art thing. It's just a configuration language with a accidental
hierarchical features attached. CSS has as much to do with design as a tube of
paint has with painting.

As a technology, like all things related to how browsers work really, CSS is
not really a well designed part of a wholesome and complete architecture, but
an accidental feature on top of a pile of an accidental agglomeration of
features.

CSS is not art. It's just accidental complexity. It's totally understandable
to me if it seems weird.

But if you need to learn it - maybe train yourself by small examples? Maybe
you are trying to understand the layout of a complete and complex page? What
if you implemented simple HTML pages by hand of increasing complexity and
figure how CSS affects those? People are different learners but this sort of
thing helps me along often.

And the font thing - typography has a long history. Since the chances are
fairly good that your designer counterparts are font afficionados it never
hurts politically to familiarize oneself at least with the history of the
craft and to identify serif fonts from sans serif ones.

[https://en.m.wikipedia.org/wiki/Serif](https://en.m.wikipedia.org/wiki/Serif)

[https://en.m.wikipedia.org/wiki/Sans-
serif](https://en.m.wikipedia.org/wiki/Sans-serif)

[https://en.m.wikipedia.org/wiki/Typography](https://en.m.wikipedia.org/wiki/Typography)

------
rafiki6
You're experience is so common that there are sites like "[https://css-
tricks.com/"](https://css-tricks.com/"). I feel the problem here is that when
they were making the standards, they for whatever reason separated the content
from the layout and styling. I think XAML is actually an incredible example of
well implemented layout and styling. I can do the layout graphically, and I
can adjust the layout intuitively using XAML for those things that can't be
done graphically. I can dive further into it and apply styling also through
XAML. From a developer experience perspective, XAML is what a developer is
looking for. HTML+CSS has it's roots in authoring pages of content, not
applications and it clearly shows. They've attempted to evolve both to become
application development languages and they're just not meant for that. The WWW
really needs something akin to XAML+C#, maybe in this case a hybrid
layout/styling language combined with TypeScript (IMO). All languages have
their merits and their shortcomings, but for a web application developer,
thank your lucky stars that CSS Frameworks exist.

------
ddebernardy
FWIW my father struggled with CSS for countless years before retiring. The
reasons were he never got his head around the DOM or the CSS box model and the
fact that it all assumed you were using CSS to style a _document_ (or more
specifically, a DOM tree). He would instead want to place this/that
here/there, oblivious to the fact that he was building a web _page_ that
scrolls, rather than a more familiar VB app _screen_ that does not.

Understanding the DOM, the CSS box model (and more recently, flexbox), and the
above-mentioned nuance if you're coming from the app world, is more relevant
than ever in our mobile-first time and age. Until you wrap your head around
the notion that no, you're not styling an app screen that is fixed-sized, but
are rather styling a document, you'll find CSS hard. (And yes, the real WTF is
why are we using this type of tech to build UIs instead of native controls,
but that's another debate.)

Once you do grok that, you also need to learn to accept some quirkiness and
imperfection (it _is_ a lousy language, after all, and browser engines don't
render everything the same way), and you'll find that CSS is not that hard.

~~~
onion2k
_The reasons were he never got his head around the DOM or the CSS box model
and the fact that it all assumed you were using CSS to style a document (or
more specifically, a DOM tree)._

This seems to be true of many devs who find CSS hard - there seems to be an
assumption that you can take any HTML structure and use CSS to magically make
it look like any design. The author of the question even lists a huge number
of languages they've used over 10 years but misses out HTML as one of them.
The simple fact is you can't _just_ use CSS. To implement specific layouts you
also need the right DOM structure.

------
c-smile
CSS is simple.

It uses two basic constructs: rule and its selector.

Selector is SQL's SELECT/WHERE statement essentially that says:

When the element conforms this condition it has these set of properties. Any
element may have multiple rules applied with matching selectors in particular
order (so called CSS specificity).

And there are 20-30 basic CSS properties defining different aspects of layout
and rendering.

Yes, there are 200+ other properties (and counting) in the full set. But
that's for Jedii and merely 10-20 of us who are in business of creating layout
engines.

It used to be more of us but the ones from MS are lost for the Republic - all
their events were bubbled up onto the Dark Side.

------
joe8756438
CSS is not hard. Design is hard. Putting a technical barrier between yourself
and a decent design makes designing a little harder. But CSS is just obscuring
a really tough problem. One thing that makes CSS seem tough is its
incompatibility with the design process. A "simple" design change can mean
many many lines of CSS or CSS that is simply incompatible with existing
CSS/HTML structure. The best CSS writers I've known all have backgrounds in
design/art. It's a long term play, but I'd say invest in learning to design.
Forget about CSS for a while.

------
eswat
How many hours have you spent writing CSS versus the programming languages you
mention?

I don't think there's any art to writing CSS or having an easier time with it.
It's just putting in the hours to know what works and the energy to understand
the foundations (box model, cascading, etc. which are concepts you only need
to commit to memory once).

Maybe CSS clicks better with some people, but the others can offset it with
time. When I started writing CSS 15+ years ago I never thought I'd be able to
do anything useful with JavaScript. But then you put in the hours…

------
Falkon1313
What you discover about CSS is that it's an accretive thing. You start out
perhaps with a (comparatively) simple basis, whatever came with whatever app
or framework your site is based on, or if you're lucky and starting from
scratch, what you yourself wrote and understand.

Then over the years, you and other developers and designers on the team add to
the CSS. You can't go back and change anything, because changing something to
look right on this page may make it look wrong on another page. You can easily
see the structure of selectors on the page you're looking at, but not the set
of all possible selector structures on every possible potential page on the
site to know how it will cascade everywhere. So you just add on, gradually
getting more and more specific with the selectors up to the point where you
have to start using !importants.

Meanwhile, over the years, the 'best practices' change, and the CSS that you
and your coworkers write changes to adapt. So you end up with things
originally sized in pixels, later multiplied by a floating point scaling,
overridden with em measurements, overridden by whatever the current fad in
measurements is. Change any of that and it breaks random things throughout the
site due to cascading, inheritance, and document structure/selector
specificity.

Due to the way it accretes over time, you end up with massive amounts of CSS,
most of which is overridden but can't be removed without breaking random
things. You can't reconcile it or do it the right way without a full rewrite.

And in the end, it still always takes a few hours to figure out how to center
something without breaking the alignment of other things, or whatever you're
trying to do. Because it will be different than it was last time. It's not
like just calling element.align(vertical=center, horizontal=center); as it
would be in a programming language. It's a series of hacks built upon hacks to
do the most basic things.

------
bbx
I’m currently writing my second ebook on CSS, and you are exactly the type of
person I want to help.

The first thing you need to understand is how a page behaves when it’s
_unstyled_. I mean when you haven’t implemented your own CSS. It turns out
that there is no such thing as an unstyled page because the browser comes with
its own default CSS.

At that point you have to get a feel of how each type of element (block,
inline, table, list…) is rendered. Turns out that you’ll that if you
understand block and inline elements, you’re halfway there (that’s actually
what my second chapter will cover).

When I started writing CSS, I wrote it by hand in Notepad++, line by line,
with no autocomplete. I think you need to go through that process to
understand each property first, and learn what it does.

Send me an email and I’ll send you a draft of my book. If I can solve your
problems, it’ll mean I’m on the right path.

------
a13n
> 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.

Use Flexbox. It makes layout so much more straightforward.

This is an awesome resource for learning Flexbox that you can use as a
reference until you don't need to anymore: [https://css-
tricks.com/snippets/css/a-guide-to-flexbox/](https://css-
tricks.com/snippets/css/a-guide-to-flexbox/)

> I have no idea which colors "go" with which ones, and pretty much all fonts
> look like the same for me.

This isn't about learning CSS, this is about learning design, which is a
completely different game.

------
woogiewonka
As a designer who often hands over designs to developers, I find it all too
frequent scenarios where developers struggle interpreting design into code. I
have NEVER seen a developer who can implement a design exactly per spec in
CSS.

This is not to say that developers are incompetent with CSS, in fact, it
probably says more about CSS than it does about the developer. The fact that
CSS has gotten so convoluted is counter to its original goal.

Perhaps I have just work with companies who don't have an A-class developer
team? I don't know. But it's not unusual for developers to straight up tell me
"I'm not a CSS guy". Like... really? Who is then?

~~~
dragonwolf
As both a designer and primarily a developer I can tell you there hasn't been
a design I couldn't implement exactly as per spec over several years.

The issue has been more a case of it would be better not to and the design
being incomplete (being most frequently static mocks) it hasn't fully captured
the interaction, all scenarios or device widths. Designers need to really
understand the medium they are working with and meet devs halfway.

Good design is function over form and working within constraints. All too
often in the industry the designs are created as though they are for print.
This is in large part also due to the fact designers tooling itself was
designed for print and we are just now beginning to have better tools for
designing interfaces but there is a long long way to go.

------
beaconstudios
as someone who is intimately familiar with CSS and doesn't have a problem
using it - it's still poorly designed. I think the problem you have with it
(and the one I have with it) is that it is in no way systemic. It's like PHP -
it's evolved over time not by iterating on the foundations, but by tacking new
features on. Flexbox/grid have solved a lot of the layout issues that required
messing around with display:inline-block/margin:auto/float/clear for so long
(by basically pretending none of it ever existed), but other issues are still
around. The fact that box-sizing:border-box is not the default is basically
down to netscape winning the browser wars. Shadows overlap even when they
logically shouldn't. It's not nightmare-level but it is hard to mentally model
at first.

I don't think it helps that most of the CSS I've seen in the wild is vastly
over-complicated.

------
temporallobe
I’ve been working with CSS for about 20 years now and it still baffles me at
times. I understand selectors just fine and I’ve memorized most rules, but
placement and spacing are still unintuitive in my opinion, not to mention all
tbe browser-specific rules and overrides. Oh yeah and there are plenty of
young devs who don’t understand that SCSS generates CSS and don’t understand
actual CSS. It also doesn’t help that so many libraries and frameworks
encapsulate all the CSS heavy-lifting for you, never forcing you to actually
have to learn CSS, which is in fact hard.

------
whooaaaa
You really want to develop a mental model of a CSS engine, so you can “run”
code in your head.

This will allow you to read code and have a high chance of predicting what it
will look like before running it.

Your probably not developing this mental model for some reason.

You should try to explain why you are seeing a visual result, and keep a
notebook of how CSS primitives work together. For example, why are there 10
ways to vertically align, and why do they all work?

Once you collect enough primitives, you can use them together to design a
layout.

You could try developing your own css layout engine which would force you to
understand the rules.

------
whytaka
I am a designer turned developer. But long before entering development, I made
websites with HTML and CSS from scratch.

I have no idea why people find CSS difficult. There is the odd case which even
I find cumbersome, but for most of UI development, I find creating layouts
with it very natural.

If you have specific questions, I can probably help.

~~~
whalesalad
Same exact experience. I have a few theories as to why some struggle. One, I
think of myself as having really great spatial awareness and reasoning
abilities. I can think of a div in 2D space and imagine all of the forces
acting on it to push it around. I’m a very visual person and tend to do well
with stuff like this. Contrast this to complicated recursive algorithms and I
can’t do it without actually drawing it with shapes and physical things. So I
think of this as the proverbial right brained or left brained... some are able
to visualize things better in their mind and I think those people tend to grok
css better.

Two, I think all of the modern tooling and libraries have stunted folks
abilities to learn the fundamentals. There’s also been a paradigm shift in
that, at one point, there was a much more distinctive line in the sand between
frontend and backend where it was more typical to build a website that was
either static or used a CMS and you spent 90% of your time living in
HTML/CSS... so you could master it better. Nowadays if you find the latest
tutorial or join a boot camp or whathaveyou you’re gonna a be messing with
components and css-in-js, express servers, graphql etc... so it’s a lot harder
for a newb to hone that skill.

If you wanna know and be good at CSS you need to go back to basics and
actually _learn it_. Text editor, style.css, index.html and a browser window.

------
oliwarner
I guess I'm alone in liking CSS.

Yes, it definitely takes _years_ of experience implementing annoying designs
to appreciate... But the macro-positioning stuff comes pretty easy once you
understand the box model and can visualise the positioning.

I don't think it's an art. It just takes real experience.

------
WestCoastJustin
It's not just you. I'd recommend using a CSS framework. Have you checked out
Bootstrap [0]? I was very much the same way (focused on backend). CSS is just
a means to an end for me, in that I just wanted something that doesn't look
like total garbage, so I used Bootstrap for the frontend bits. Allows you to
quickly get up and running using the examples without learning too much CSS
[1]. Just find something that looks like what you want and then copy/paste.
Much much easier.

They 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/](https://getbootstrap.com/)

[1]
[https://getbootstrap.com/docs/4.2/examples/](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.

~~~
aphextron
Don't use bootstrap for anything beyond personal project prototypes. It ends
up being a complete nightmare for maintenance. Coupling of DOM with
presentation and state is the number one thing we should be avoiding in modern
JS apps.

~~~
WestCoastJustin
Interesting, I'll have to read about that. This has totally not been my
experience.

~~~
aphextron
It works great... for a while. Then you end up wanting to tweak something here
and there, start adding classes to things, and you realize you want to do
something that requires changes to the DOM within a component and you're
screwed. Or you ignore the fact that _the right way_ would be modifying the
DOM, use some hacky CSS to kludge it, and you start getting browser
inconsistencies. Either way you end up stuck with 100k of dependencies to
style a popover and a dropdown that could have just been defined in a design
system from the get-go and done with minimal CSS in a React/Vue type
architecture scoped to the individual component.

~~~
WestCoastJustin
Ah, that does make sense. Thanks for adding the examples -- I can totally see
this happening. Guess I just haven't been bitten by that _yet_. Although, I do
remember running some mass regex through the codebase to update class names
when bootstrap changes something. Or, changing templates to use some new
formatting. This can be nerve wracking.

------
albertkawmi
I think there is a spectrum Of skills with programming at one extreme and
visual design at the other. Even within “front end” you tend to have JS
experts and CSS/design/UX experts. Some people can do both.

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](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...

~~~
XCabbage
I don't see get why anyone thinks that CSS skills and design/UX skills somehow
go together. It seems to me that the skills needed to write CSS have more in
common with those needed for programming than for UI design.

------
jwarren
I can only assume that you're trying to run before you can walk. Remember that
you're just defining a set of layout rules. You're not giving the browser
specific instructions to follow. It seems that there's the temptation to
assume that CSS is easy and simple, because it's for the web and isn't a
proper programming language.

That is clearly not true. CSS describes a complex set of interactions which
evolved over many years. You'll have to refer to MDN, experiment in your
browser dev tools, etc.

Start in small and isolated chunks. Open a codepen with just a couple of divs
and work out how their layout interacts.

I firmly believe that you can write beautiful CSS. Your list of languages
shows that you are clearly interested in learning, and in expressing your
needs in varied ways.

As an aside, I would recommend having a design on paper/on screen to implement
before starting to write your CSS. Until you become relatively fluent with it,
I think CSS relatively counter-productive as a design tool. Thinking about the
target result as a separate step from implementing that result is going to be
a much better approach.

------
magicmouse
CSS is utter crap. In the history of computers, one programmed in a single
language at a time. You had punch cards, then a text file in a terminal, then
a text file in a PC written in a language like FORTRAN, COBOL, PL/1, Java,
etc. And it was fine. Then they invent a bizarre 3 language sandwich where you
switch back and forth between 3 completely incompatible languages (CSS, HTML,
JS), which don't even agree on how comments are entered. It is one of the
worst designed languages ever, surpassing the previous abomination RPG. I
can't wait to deep six the whole HTML stack, as it is a huge time waster. We
need a single, well-designed language that can all the general purpose coding
we need (and generate websites). Maybe the output will be JS because that is
what browsers support today, but seriously let's not put lipstick on a pig and
call it pretty. That CSS can draw but not compute, and JS can compute but not
draw, and HTML can't do IF, what kind of nutty design is this? Chaotic rapid
growth was the cause, but the cure is to dump it entirely.

------
matty22
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/](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.

------
hjek
These made CSS click for me:

\- [https://flexboxfroggy.com/](https://flexboxfroggy.com/)

\- [http://cssgridgarden.com/](http://cssgridgarden.com/)

~~~
DesertVarnish
That was fantastic. Attempts to teach programming through gamification tend to
have issues, but the instant visual feedback and clear goals helped me
understand CSS much better.

------
mattlondon
I have done a lot of backend and front-end coding over the years I've found
CSS is complex just due to the sheer depth of detail, but not hard once you
get the hang of the basics.

The key areas that will probably help you the most are flexbox and grids.
These are modern things that will make your life in CSS 10x easier and more
productive. With flexbox and grid it becomes trivial to do "hard" things like
centering div's, full-height divs, footers etc etc. Use flexbox for laying
things out in one dimension (e.g. "I want these related <things> to appear in
a row/column") and use grid for doing two dimensional layouts (e.g. "I want a
bar across the top and bottom and then two columns in the middle"). Mix and
match flexbox and grid (e.g. use flexbox inside of a grid area) and you've got
90% of the CSS done in my experience.

This guide for flexbox is awesome and spells it all out: [https://css-
tricks.com/snippets/css/a-guide-to-flexbox/](https://css-
tricks.com/snippets/css/a-guide-to-flexbox/) (although their site's visual
design is the worst type of hideous garbage IMO, but I can forgive them that
for the content)

The last 10% is fiddling around with colours and margins and font sizes etc.
I'm no designer and rely on the UX and Visual Designer to tell me what
colours/fonts/margins/etc to use, but regardless there is actually something
very very satisfying about nailing the CSS and seeing something ugly transform
into something really nice right before your eyes.

Also a final top tip is to get familiar with your dev tools in your browser of
choice. Doing "real time" edits in the browser (in CSS but also DOM & JS too)
then updating the code in your IDE is something I do frequently.

------
svrtknst
Whenever this subject crops up, I'm inclined to just answer "Yeah, it's just
you", at the risk of that coming off as too harsh.

I really like CSS and it's where I got my start, and used it for a long time,
often to make up for not knowing JavaScript.

I don't think CSS is an art thing. I think CSS is pretty simple, but requires
an understanding of how CSS works and how browser layouts wotk.

Without that, you're going to have a hard time, but I can't really think of a
language where that isn't true, either.

Sometimes I feel like this is the result of people undervaluing CSS, because
they "just want to make a colored box" or whatever, but fail to view it as its
own language, with its own ecosystem and considerations, placing undue
expectations on its simplicity.

If I were to "just make a program" in C, without any knowledge or
consideration for how Windows works, how stacks, heaps, memory, and pointers
work, and how C works, then I'm gonna have a bad time, and the same goes for
CSS, imo.

------
amoitnga
Being able to produce nice, competent design requires a very different skill
set from the one developer has. It's not our job to know what are
complementary colors, what is hierarchy etc. But when handed sketch/photoshop
design it's part of my job to implement it.

It's not a coincidence that you brought up positioning.

> I can't center my divs properly.

I remember having a similar feeling. What made it click for me was searching
for some articles like "how to master css".

Btw, just did that search and this is the article I remember I went over
[https://designshack.net/articles/css/5-steps-to-
drastically-...](https://designshack.net/articles/css/5-steps-to-drastically-
improve-your-css-knowledge-in-24-hours/), which is the first result.

Understanding how to position things I think was the biggest aha moment:
floats, box model, the difference between positions such as fixed, static,
absolute etc...

I think if you go over resources mentioned in that article you'll be good
enough.

It feels like there is this idea that CSS is very simple, not a real thing, so
we don't dedicate the time to learn it. You wouldn't expect to be good with
React after one day, would you? It takes time to learn js, having that base
it's easy to pick up React in a few days. And then you read articles on best
practices, staying up to date with new versions etc.

CSS requires much less, but still some time and effort. Treat it as
technology, give few days, don't skip steps, just sit down and learn it.

You can't solve `x + 5 = 10` when you don't know what `2 + 2 = ?`

So don't try "hey, CSS, this is the parent div, and all child divs must obey
its size" until you know what is the difference between absolute and relative
position.

------
ivanhoe
I don't think CSS has anything to do with art, you usually have the design
done already, you just need to put it together in a way that browsers can
read, so it's just good ol' programming. Thing is that it's very easy to do a
little things and tweaks in css, copy & paste snippets, so people jump to
conclusions about css being easy - but then you discover that to really master
css it requires a lot of lateral thinking and being able to look at the design
and "see the matrix" behind it. It's like trying to figure out haskell and you
come from C, you need some time for your brain to rewire how you think of
problems. IMHO emphasis should be especially at a lot of learning by doing it,
because experience is everything with css. So just give yourself some time,
work on it and you'll figure it out...

------
zoomablemind
My feeling about CSS is similar to asm/Assembler. It gives you ultimate
handles, but it's very much low-level down to pixels. Same about peculiarities
of the underlying platforms and browsers.

While I see great uses for asm directly within parts of an application
constructed with higher-level languages, yet building a whole system using asm
is unnecessary. Compiler does this job.

With CSS from scratch or not, you need to move, store, add, clear, and jump on
your own. And let's not think of how many losely coupled variables a real-life
web-design presents to deal with. There's no compiler for this, only a
debugger (Firebug, etc.) CSS frameworks simplify some aspects of this, but
fundamentally it's still low-level.

That's what makes this CSS chase a somewhat futile exercise in a long run.
Assembler is at least is more concise to memorize.

~~~
kevintb
This is a great way of putting it.

------
Androider
It's easy-peasy once you get the general algorithm down:

1\. Is there a Stack Overflow CSS snippet you can use as-is that solves your
problem? Score!

2\. No? Fiddle with random bits until it looks OK in your browser of choice
(Chrome). Display: block and position: absolute are great time savers, slap
that on most things.

3\. Ship it! Onto the next feature!

Pro-tip: Pixels totally work and you should just stick to that everywhere. The
browsers and device manufacturers have kindly taken the necessary steps to
make it Just Work no matter what the medium.

In case you think I'm being sarcastic, only half. Nobody cares about your
beautifully cascading, resolution independent em's and semantically
beautifully structure. The whole thing will be run through an uglifier anyway
and probably you should just have used JS for your runtime generated layout
anyway if you have any kind of dynamic behavior.

------
open-source-ux
Yes, it is horrible. It's got a little bit better (think flexbox and CSS grid)
but it still feels clumsy, unintuitive, unpredictable, inelegant, frustrating.
You learn to live with all it's painful shortcomings, but you'll never learn
to like or love it.

Interesting aside: what would the creators of CSS do differently today?

Bert Bos:

\- Feels there was too little detail in the first CSS spec (but Håkon Wium Lie
thinks there wasn't enough)

\- Wishes there were more ways to display link behaviour e.g.
expanding/collapsing text

\- He wanted to create CSS syntax that was readable for people who were not
programmers

\- He preferred a full stop (period) to mark the end of a group of statements.
Curly brackets (braces) to group statements was Tim Berner-Lee's idea.

\- Grids should have been a fundamental part of the CSS spec from the
beginning

\- Prefers the idea of CSS for documents and a separate language for UI
elements

\- Thinks the cascade could have been made easier

Håkon Wium Lie:

\- Feels there was too much detail in the first spec: the more you added to
the spec, the harder it became to implement

\- Thinks that margin collapsing was too complicated for v1 and could have
been dropped

\- Also thinks first-letter and first-sentence pseudo-elements should have
been left out of v1

\- Hypercard was based on the idea of cards rather than documents - he wished
a CSS card element had been defined

\- He didn't want border radius originally, but designers insisted and he now
likes it

\- The v1 spec was written without any test documents - he considers that a
major mistake

\- They both approached CSS in a document frame of mind and wonders if they
should have considered the idea of web apps more

Source:
[https://www.youtube.com/watch?v=PQTpsxf7rQQ](https://www.youtube.com/watch?v=PQTpsxf7rQQ)

~~~
antod
Interesting comments from those guys.

I taught myself CSS by reading the CSS 1 spec back in the late 90s (mainly
aimed at IE 4 - Netscape 4.6 sucked bad) before there were any books on it. I
think the CSS 2 spec was also out by then too, but the browsers didn't support
it yet (that took a surprising long time).

I found learning CSS 1 from the spec pretty easy as it wasn't a large spec and
was fairly easy to read. The CSS 2 spec was a lot larger (5-10 times?), and a
lot more complex with all the new stuff. Learning that took some help from the
old Eric Meyer book from O'Reilly with the pair of trout (?) on the front.

The Eric Meyer book helped a lot with understanding fundamentals like how flow
worked etc and properly grokking inline vs block etc. There wasn't really any
of the tooling (eg Firebug and successors) to help back then.

Of course, I wasn't reading the specs to implement a rendering engine - just
to use it.

I stopped doing any CSS about 8 yrs ago just as CSS 3 was starting to happen
and never really learnt that. It seems way more powerful/complex/useful these
days.

One tip that really helped back then was to try and do what you wanted with
the very minimum of selectors/declarations to avoid conflicts, ambiguities and
debugging difficulty. So creating lots of scratch empty test pages to explore
one specific technique before including it with all your other CSS/HTML.

------
tmm84
I understand this feeling of CSS being some kind of black magic or something
that just doesn't play by the rules. At almost every single place I work it
feels like I am the only one who has a real grasp on CSS and makes stuff
happen.

My personal advice is to take a website you are familar with and try and
duplicate it with pure css and html. When you get good at simply writing it
from scratch then you'll be able to understand it easily. You'll start to
notice the red flag stuff, the useless UI libraries (useful is relative) and
stuff that you could get done on your own easily.

My most important tool is the element inspector for any browser that isn't
displaying as I expect it to.

------
h1d
CSS isn't hard. It's design is broken on a few things which makes it look more
complicated than it should.

I've done web for 20 years and I still Google around when it comes to aligning
things vertically centered and I sometimes fall back to using tables for
layout because it's still the most stable way to keep stuff at where it should
be.

And of course the way you need to declare in a very redundant way for
selectors on multiple elements is annoying but we have at least sass and my
preference is using stylus (combined with pug) which removes a lot of those
unnecessary declarations go away with the ability to define variables in 1
file and use it all over.

------
rntz
> 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.

This is not related. There is no magic or natural connection between grokking
CSS and having a sense for color theory or typography. They are connected by
circumstance only, in that they're all useful for web design, and in that CSS
can control colors and typography in the web browser. CSS is not any more an
"art" thing than Javascript or C, although it is a thing with which one can
make art (as are Javascript and C).

------
acjohnson55
In reference to a sibling comment
([https://news.ycombinator.com/item?id=19021837](https://news.ycombinator.com/item?id=19021837)):

> 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.

Yes! I went looking for this comment before adding it myself. Although I chose
not to reply, since that's only part of what I want to discuss.

Once I realized that CSS is exactly what would make sense for laying out a
textbook, it clicked for me. Until a few years ago, web design implementation
was hacking this model to realize application and widget layouts.

Nowadays, flexbox and grid are basically universal, and we can use them as we
please to do proper 2-D layout, and then use classic CSS for textual flow.
It's a wonderful time.

But to go beyond that mismatch of expectations, the other historical problem
with CSS is how to organize it in a reasonable way. Typically, you need a
number of rules to apply to related elements in order to achieve some specific
effect, but these get all jumbled with other effects that need to reference
overlapping sets of elements. Combine this with the fact that CSS offers a
crap-ton of features that you rarely need, especially in the selector spec.
Preprocessors and methodologies like SMACSS and especially BEM helped give us
ways to tame the madness. The BEM website
([https://en.bem.info/](https://en.bem.info/)) is a great resource for this.

This is all front-end dev skills that most of us learned by thousands of
articles and hard knocks. I wish I could point you to a bible for this, but I
don't know of one.

When it comes to design, that's its own skillset, which really may have little
to do with CSS. Many of the designers I've worked with don't know how to
implement their designs in CSS (although that's not always the case). The
principles of good design ultimately come from the goals of the product, mixed
with usability concerns and, of course, fashion.

------
squirrelicus
I'm also a seasoned back end developer. It took me 3 years to become a
beginner at CSS, and two more to feel like I could finally style an arbitrary
front end at an intermediate skill level. This is in comparison to 1 year to
master javascript and another year to "get" React top to bottom. CSS was even
harder to learn than ansible or clustered mongodb at scale.

I suspect it's a neurological difference. I've seen masters of CSS struggle
with basic operational computing concepts that feel obvious to back end
developers.

------
wbkang
> I can't center my divs properly.

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.

~~~
ken
> This is actually pretty simple, once you understand how "block" elements
> work.

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.

------
androidgirl
CSS positioning woes are brutal- until you have the knowledge from previous
struggles.

Full disclosure, I am artistic, but imo css is a different skillset.

You'll have knowledge on when to use flex, floats, or the new css grid, be
able to center <pictures> behind text, and all the other traditionally tricky
things.

Honestly, just practice, don't give up!For layout specifically, Flexbox can
solve almost any problem. Once I "got" flexbox I was having an easier time.
And CSS-Grid can solve almost everything else!

------
ummonk
I have a lot of aesthetic sense, and a strong eye for good layout and design.
I still struggle every time I need to use CSS. I know enough to eventually
make it do what I want with a lot of experimentation and googling, but not
without a great deal of difficulty. I’ve known CSS whizzes who can make it do
what they want easily, but they’re extremely rare.

I think it is just a really poorly designed framework. Other layout toolkits
for native programming are typically far easier to learn and use.

------
roryokane
When I was struggling with CSS at my first job (2011), the thing that made it
click for me was learning the significance of the `display` property and its
possible values. After I learned that each `display` value causes the element
to be rendered in a certain way, and that some CSS properties were only useful
for certain `display` values, it became much easier to predict how the layout
would look and to organize the CSS properties in my head.

For example, it cleared up a lot of questions when I learned that `display:
block` elements naturally expand to the greatest width they can while matching
the height of their contents.

Also, the Mac app CSSEdit (now folded into Espresso;
[https://espressoapp.com/](https://espressoapp.com/)) helped me learn the
various CSS properties thanks to its GUI interface that listed properties by
category, such as Text, Decoration, and Layout. It had icons for each possible
value of each property that made it easy to remember what values each property
supported. A useful feature of the app was letting me load an arbitrary web
page and edit its styles with its GUI editor – I could see which properties
were more often useful and how switching the between the possible values would
change the look.

------
TylerH
The main things you should learn to become decent at CSS are:

\- the box model

\- how cascading, specificity, and inheritance work

\- googling CSS problems with the site:stackoverflow.com filter

Bit tongue-in-cheek with that last one, but the rest will give you a solid
understanding of why certain things work the way they do when your code
doesn't look the way you expect.

> I can't do anything basic on CSS without turning for help

The thing is, if you are working with a whole website (even simple looking
websites can have a lot of HTML and CSS), then there are often no "simple"
problems, at least with layout, because every element can and often does
affect every other element.

Sometimes you just need a good old analogy or picture to demonstrate some
things: [https://stackoverflow.com/questions/33132586/why-isnt-my-
mar...](https://stackoverflow.com/questions/33132586/why-isnt-my-margin-
working-with-position-fixed/33132765#33132765) (disclaimer - I wrote that
answer). In a lot of ways, your elements and their CSS are like rocks in a
river... the water/document flows around them in certain ways, which affects
stuff around them or downstream. Removing one or adjusting it can change how
the water/document flows, and thus can affect other rocks/elements, etc.

------
mch82
I arrived at CSS and HTML from a background in print layout with Adobe
PageMaker and InDesign in the 1990s. Professional layout programs like
InDesign attempt to separate content from layout and styling. The first step
in creating a print document is to set up a grid of empty containers. The
second step is to fill those containers with placeholder text (often Loren
ipsum). Step three is to develop a style sheet to style the text so that
styles can be updated in one place and applied consistently throughout a
document. The last step is to flow content, written as plain text in an
external copy editing tool, into those containers.

Coming from that background, HTML (the document structure) and CSS (the style
sheet) are relatively intuitive. I can see how they were influenced by tools
like InDesign. However, browser quirks are very frustrating. I try to avoid
situations where I need to deal with them, or if I do I try to find CSS
written by others that guides the way.

I think it’s probably unfortunate that screen layout techniques, where screens
are variable size and interactive, were so heavily influenced by print layout,
where pages are of fixed size. On the other hand, maybe HTML + CSS was too
influenced by Microsoft Word style desktop publishing where layout and content
are in a single document and not influenced enough by InDesign style
publishing were layout, content, and structure are each distinct. But
relatively few people are ever exposed to professional print layout tools like
InDesign.

Having recently gotten into parametric CAD and constraint based design, I’m
hoping to see more of that approach make its way into both print and screen
design.

------
dakom
Yes CSS is too damn hard.

Too hard to learn? No. Too hard to use? No. Too hard to do elegantly? No.

It's too hard because it doesn't need to be nearly as hard as it is. Advanced
layout can be done using techniques like pivot, relative anchoring and
alignment, and lots of other approaches that CSS lacks.

It's too hard because what is there is broken. Even the new stuff (try to
select a row in an auto-adjusting grid. You can't yet, and the powers that be
will eventually fix that... which is ridiculous for a modern release)

It's too hard because it's neither how designers think, nor how programmers
think, nor how users think. So you need to write it in some weird hodgepodge
that accounts for none of those and all of those.

It's also too hard because due to the difficulty it takes a lot of time to get
good at, and so we as non-CSS gurus don't invest the time we need to digest
it... because why would we when it shouldn't require that sort of investment?

At the end of the day it's almost like going to your neighbor's house but some
committee forces you to walk in zigzags and on your hands. It'll get you
there, and you will become so good in the process you could work in a circus,
but it's an unnecessary pain when you just want to drop off a cup of milk.

------
olingern
I was like this 5 years ago. It's trite and no one wants to hear it, but the
basics go a long, long way.

All of that stuff you hear about in front-end interviews ( like the box-model
and relative vs absolute positioning ) comes in handy.

I do admit that pre-flexbox CSS did require some wizardry and hacks here and
there. I think "modern CSS" is quite enjoyable and we're able to enjoy a time
where we no longer need CSS frameworks to do all the "hard work"

~~~
vittore
I remember times of supporting x-platform css for IE5/5.5/6 and FF1. IMO
everything that people complaining right now is nothing with the Wild West
that was back then.

~~~
olingern
Indeed, I think times and CSS has gotten much better. MDN's documentation is
great, and browsers are finally _starting_ to standardize.

------
sgc
People have mentioned flex and grid a few times. I would add using box-sizing:
border-box; solves a lot of problems stemming css' default of measuring from
the inside of elements that need to fit together from their outsides. See
[https://css-tricks.com/almanac/properties/b/box-sizing/](https://css-
tricks.com/almanac/properties/b/box-sizing/)

------
err4nt
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](https://github.com/tomhodgins/caffeinated-style-sheets)

------
Brajeshwar
CSS is best served along with HTML. I believe that one should understand the
intricacies of HTML — the hierarchies in which one writes and the ability to
think far ahead on how they will be treated on a page, container(s) or re-
purposed by a templating engine.

HTML and CSS for that matter are very easy to start off. After a while, many
begin to believe they are done; when actually, they are just starting off. It
is one of those whom many would choose to ignore or use other tools to just
“get it done”. A good designer, who can code, can do magic if s/he can go deep
into HTML and CSS.

For instance, when developing interface designs for a complex or a big enough
system, I advise my team to think of each and every block as something that is
liquid enough to be thrown inside a container of varying possibilities. Test
with few default container sizes but leave enough room that this can be just
thrown in anywhere and will adapt to that containing block. This has become
easier in React and other frameworks that encourage design thinking in modular
blocks of designs.

Pre-processors, post-processors do help but one needs to be clear of the
underlying philosophies and methodologies of CSS to appreciate these helper
tools. Mastering these tool can then help work faster, smarter.

CSS is learned through practice, knowing the quarks and being able to make it
work for 80%+ of the use cases. Break-up into smaller chunks of simpler
blocks, have a styleguide-ish setup for yourself (if you don’t have one for
your team), use development tools as guard rails. Finally, have a good post
development workflow to get the final juice — task automation that removes un-
used CSS, et al.

Imagine being able to get a column’s background color to extend equally all
the way down the page in a 3-Column Faux Layout in 2003 (sometime around
2002-2004). ;-)

------
feluso
I picked up CSS last year because I always felt bad I never really put my time
into it while I had to use it so often, I'm not a designer by any means but I
like to experiment things out, but what I got from what I learned is that CSS
works in its own way, it's not that much about "I want this div in this
position" but more like "Everything in your page must flow a certain way" and
from the experience I've had with certain inhouse "frameworks" it seems like
other people dont get it either.

I think that in that sense CSS still irks me a bit, I still do a lot of things
that just feeeel like a hack, but from what I search and google around it
seems like that's the only way to do it? but I also think it's kinda fun, I
like reading the MDN web docs from time to time and they do seem to explain
things very thoroughly, I've had a lot of moments where things started to
click after reading it.

------
askmike
> 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 just want to point out this is completely unrelated: the best people I
know when it comes to designing interfaces (both UI and UX) don't know much
CSS. That's very much a creative field.

I can do CSS without many problems (nothing too fancy but slicing any
interface or basic flexbox grids for layout and such). CSS isn't complex, just
very foreign. Understanding the "rules" (cascading, priority) isn't hard, but
knowing how to use it (how to target the element you want, what css to use to
get the positioning/styling you actually want) takes a lot of practice. Though
when it comes to creating a beautiful page I'm of no use.

------
DougBTX
Sure, CSS is hard, just look at the specs which define the height and width of
elements: [https://www.w3.org/TR/css-position-3/#size-and-position-
deta...](https://www.w3.org/TR/css-position-3/#size-and-position-details)

There's a lot of complexity there.

------
Jach
Your frontend experience sounds like you've only dealt with web apps. Try
making more web sites. That is, collections of pages that have enough content
on them to scroll. Don't use any framework, don't even use JS if you can help
it -- maybe something like PHP is ok to avoid some repetition (i.e. just use
it for require_once of shared html). Then you'll understand the environment
CSS was forged in. Ctrl+F the comments here for "box model" for the main "make
it click" piece. (Edit: you might even want to try designing without CSS, to
see what that's like. It's actually not that bad, and may well remind you of
how things are typically done in frameworks these days -- a regression IMO,
but a reminder that separation of design from markup isn't truly necessary.)

------
bellerose
CSS isn’t bad after writing it a lot and googling the same tricks to do what
typically works. My best advice is to stick to some framework for most UI
(material or bootstrap) with using custom css seldom. Colors are definitely an
art form and matter a lot.

------
alan_n
Those are two different problems, imo, one is you don't know the language, and
the other is design. I'm an artist and I've always understood design (not to
say I was great at it, it still took experience, but I can see a site and I
can understand why it does/doesn't work visually), so I can't speak much about
how to learn it, except to first try to copy/observe from designs you think
are good and go from their.

As for css. I actually like designing UIs from scratch so it's not like I hate
it when I'm doing it, but it's bad. It's like 80% works as intended, but then
there's 20% that is just weird quirks and there's no way around them but to
memorize them. For example, I just ran into a particularly annoying one again
recently (you can't do overflow-x: hidden with overflow-y:visible). This stuff
is not going to change. At best they might add some new property to fix it.
And the workarounds are often dirty.

I would suggest, A) keep a list of problems you run into and their solutions
if they're particularly weird, even better, make fiddles of the solutions, and
B) comment your css with why you did what when it's out of the ordinary.
Sometimes you'll need to create extra wrapper divs, etc, and when you come
back to a project after some time you'll have no idea why they're there or why
you placed some weird css property, C) master flexboxes and grids and know
their limits, that will get you 90% there usually.

Also using something like scss or less, or currently I'm trying styled
components (css-in-js <\- though it doesn't feel like it), really helps.

As for how related learning css and learning design are, I'd say, you do not
need to know design to know how to use css, but you need to know css to be
able to implement a design. You can get by without knowing design (there's
plenty of css frameworks), but frameworks won't save you when you need to
tweak them with css. Also you can practice design without knowing css (e.g.
using photoshop or figma or something), although note many times nice designs
are nightmares to implement in css, which is why I think learning css is more
important.

------
exodust
> Is CSS an "art" thing?

No, but it helps to enjoy and respect visual layout challenges. Without
appreciation of design, particularly web UI, you won't have much to aim for
except MVP.

With programming, you are not usually switching back and forth between code
and some visual layout element. CSS on the other hand, is an endless game of
tweak, refresh, repeat. It's not for everyone.

BTW, Flexbox is now widely supported, and is much nicer to work with than
trying to float DIVs, which nobody ever liked or found easy. Flexbox provides
a nice way to center your elements horizontally and/or vertically, not to
mention very nice control of spacing and item-level responsive sizing with
flex-shrink.

------
alexbecker
It sounds like layout is your primary problem (as it is most people's). You
should view (the layout-specific parts of CSS) as a layout description
language, which is a class of languages you've never worked with before, and
so something that requires significantly more time investment than just
learning a new syntax (e.g. JavaScript). My guess is you haven't put in that
amount of focused study, so naturally it doesn't click for you.

This is not to say CSS doesn't deserve any blame--it's a _bad_ layout
description language, as evidenced in part by the fact that the recent
grid+flexbox additions are much better (where supported) than old-school CSS.

------
talkingtab
For me (maybe) its the size thing. I've never read anything about "content
driven size" so maybe I just don't understand it, but I'm often confused about
why some box (div) is the size it is. When I use dev tools to try to
understand, nothing seems to help. I can see how the rules cascade, I see how
the flexbox and grid things work, I can grasp the DOM and selectors - but then
why is everything so small or so large...

The suggestion of building a page from scratch is good and helpful
<BeginHumor>And the next time a CSS friend wants to learn JavaScript I will
suggest they start by learning i386 assembly language :-) </EndHumor>

------
abecode
My wife is a technical designer for jeans and recently started learning web
development because we moved and there wasn't much denim industry. She turned
out to be good at CSS and I think it's similar to making jeans. From looking
at the overall shape and style you can't easily construct a pair of jeans.
People with artistic style can sketch a pair of jeans but to actually go from
that to the specs that go to the factory (what a technical designer for denim
does) is a different set of skills. Art is definitely a part of it but it's
also a lot of tricks of the trade and processes, and this seems analogous to
CSS.

~~~
tabtab
Half the problem is that we got spoiled from WYSIWYG tools of yesteryear.
Drag-drop-boom!-Done! But it turned into rocket science when dealing with web
browser "auto-flow" and "responsive" design. Something that took 20 minutes in
WYSIWYG now takes 4 weeks UNTIL you get proficient[1], and then the new
different "in" layout framework comes along and you have to start at square 0
yet again. (Okay, maybe square 0.5 since some experience may transfer.)

It often seems like it would be easier to make 3 WYSIWYG designs for small,
medium, and large screens. The device and/or server would pick the best fit of
the 3. In other words, WYSIWYG x 3 < autoflow design time.

Reinventing 3 wheels is easier than reinventing one rocket.

Footnote 1: Often people fudge them to work most of the time, but glitches
often show up over time as new browser or OS brands/versions come out and
expose one's accidental fudging-based version lockin.

------
mxuribe
You are not alone! Beyond the bugs and inconsistency that web browsers
implemented, I've always felt that css was unnecessarily over-complicated.
During development on projects, it seems to be the thing that used to create
the most hair-pulling frustration. But nowadays, i have learned to let go of
some things, including any OCD feelings about css. Either i construct the most
basic views, and hand it over to someone else who is willing to put up with
css (and who is better at picking colors)...or simply construct the basic
views - and stick to the bare/default view without any colors or complex css
applied at all.

------
azangru
As anything, CSS requires practice. Imagine writing Haskell after having
experience only with Python or C — you will probably expect it to be different
— and difficult. You will probably want to read a book or two about Haskell,
going from the first principles to real-world programs. Starting directly with
real-world problems in Haskell will probably leave you frustrated and
confused.

Perhaps you were never interested in CSS, and never gave it much thought; but
it too has its own basic principles, after learning which it will be easy to
say, like you want: "hey, CSS, this is the parent div, and all child divs must
obey its size".

------
LarryMade2
CSS is pretty simple and like a programming language you can overwork it to
high complexity. And most people who aren't used to how to optimize it, just
make a usable kludge of CSS.

When I first was going through CSS to learn it I thought it was the worst
thing in the world - manly because many people had copied CSS without knowing
what how to really achieve - or inheriting disparate css blocks which add to
the confusion.

Once understood and starting from scratch, you can make it a lot more logical
and flexible without much of a mess. My big tip - learn to break down style
parts into separate classes and then combine the classes as needed!

------
simonhamp
First of all, CSS is t like any programming language. It’s a cascade of
properties that is tightly coupled to the tree-like nature of HTML. You don’t
‘understand’ CSS on it’s own; it must be in tandem with suitable HTML.

Secondly, the visual aspects of design (colours, fonts, layout) have got
nothing to do with your grasp of CSS. I am not a designer and really struggle
to make pages look good without a professional’s help. But give me a beautiful
design and I’ll code it up in lovely CSS for you no problem.

P.S. check out Tailwind CSS
[https://tailwindcss.com/](https://tailwindcss.com/)

~~~
nepeckman
Seconding the recommendation for Tailwind. I know functional css is
controversial, but Tailwind isn't dogmatic about it. Sensible defaults for
colors, fonts, padding, etc. And unlike Bootstrap, when you use Tailwind,
you're actually learning css instead of a framework. I feel like my css is a
little better since I started using Tailwind.

------
bobbydreamer
CSS is hard. I like Colors but I find it really hard coding hand picking
Colors and designing this game exactly the way I want. Sometimes the design
will look like not the way I imagined and since I had put too much time, I
have no choice other than accept it. Bootstrap 4 & mdbootstrap are great help
but eventually prior pains of learning css helped to change or modify
bootstraps. Now just looking for tools that would reduce the size of css files
which I am using and remove the css content which I am not using. That kind of
app will improve load time.

------
madiathomas
First learn design, then learn the tools(CSS). Preferably using a book that
has nothing to do with web design. Problem with most developers is that we
only learn the tool and forget to learn design. To understand how to properly
mix colours, you need to study colour theory. To understand how to use the
right fonts, spacing etc, you need to study typography. Also learn about image
types. I don't understand why most web design books want to dive straight into
CSS before design.

After that, you need hours and hours of practice in order to be good at it. We
learn by doing.

------
wtmt
> I have no idea which colors "go" with which ones, and pretty much all fonts
> look like the same for me.

Can't help on the fonts thing here, but for colors, there are a couple of
things to consider. You can use color wheels of different kinds to find
matching colors and harmonious color palettes to create/use in a color scheme.
There are many online sites that provide this for free. While deciding on
colors, you should also consider accessibility from the color blindness point
of view and the contrast point of view.

~~~
alanbernstein
I can relate to OP's lack of appreciation for fonts and color palettes - not
100%, but I get it. Color wheel tools are useful, and their results do look
notably better to me, but using those may not improve your understanding of
the color relationships much. But then, maybe you don't need to understand.

------
fulltrottle
Read the full CSS spec:

[https://www.w3.org/TR/CSS22/](https://www.w3.org/TR/CSS22/)

[https://www.w3.org/TR/CSS22/sample.html](https://www.w3.org/TR/CSS22/sample.html)

And the W3C flexbox and grid specs

Recently I read the full CSS spec front-to-back in detail, and I can say that
it was so totally worth it. Tutorials don't cover a lot about CSS. Once you
read it you'll know things about CSS that most devs think is a mystery

~~~
audience_mem
Some might consider this radical, but if one considers how long CSS will be
around, and intends to live in the web development world, it certainly would
pay off. There's nothing like the feeling of _true understanding_.

Not the kind of reading material most people would turn to, admittedly. I've
recently found this:

[http://book.mixu.net/css/](http://book.mixu.net/css/)

It feels like a good balance between quotes straight from the spec, and
explanation from the author.

------
kowdermeister
I feel similar but with the functional languages you mentioned. But I know
they are not special or dark art, just tools I haven't spent enough time to
master because I lacked motivation.

As others mentioned the complexity of CSS makes it very powerful, thus
complex. Don't underestimate it as some low level icing.

I would start here with CSS:

[https://www.youtube.com/watch?v=I9XRrlOOazo&list=PL4cUxeGkcC...](https://www.youtube.com/watch?v=I9XRrlOOazo&list=PL4cUxeGkcC9gQeDH6xYhmO-
db2mhoTSrT)

------
jorgesborges
There's so much value to learning CSS and all it takes is time and practice.
It's not an art but I think competent programmers are justifiably irritated
when their skills don't apply to what is ostensibly just another language or
syntax. They'll walk away when they realize it takes time to do things which
ought to be simple like making a layout with some columns. But it's actually
really fun after a while. And you're like a wizard to everyone that was just
too lazy to learn it.

------
miguelmota
CSS is not hard, but it's certainly unusual compared to programming in any
other language because you're dealing with the DOM. HTML was originally
designed to display simple text documents, not fully fledged single page
responsive and progressive web apps. My single piece of advice is to master
the top CSS properties, relative/absolute/fixed positioning, and grids &
flexbox for layout. CSS has come a long way and it's 10x easier to layout
content compared to just 10 years ago.

------
tobyhinloopen
Experience. Reading what features there are and trying them out.

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

------
sebringj
It might be a visual/spatial disconnect because you mention you cannot intuit
color contrast or distinguish fonts or failed at how design works. CSS then
would have no meaning to you. Imagine asking a deaf person to describe music
in notes. If it has no true meaning to you, it is nearly impossible to grasp.
If this is the case, I would rely on a UI toolkit that has theme support so
you can easily change between them and not care about these types of things.

------
companyhen
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.

------
arkh
Here is a crazy trick with CSS: read the specifications and take notes.

The cascading and the different display contexts should be enough to get you
through most pitfalls.

------
towb
So back in the day you had to know a lot of weird tricks. The goal was usually
to make it look the same in every browser so you had to know the differences
between them and what caused them. I think that's why I don't find it very
hard today, even though I don't do much CSS it usually works. With the changes
to CSS since then, that old knowledge might be a lot harder to find for
newcomers.

------
mattferderer
I suggest trying a CSS framework that handles most use cases for you. Just
like we use frameworks with every other language, CSS/Sass/Less/JS frameworks
can help here so you aren't constantly reinventing the wheel.

The ones you can customize with something like Sass or JS are my favorite when
I don't want a basic template looking website. Tailwind, Foundation &
Bootstrap are popular choices.

------
vuild
If anyone sees this, I'm a little late but understand your frustrations, it
seems a lot of people in this thread feel the same.

I'd be more than happy to teach a group some basics/ simple rules to make your
life easier, just let me know how.

I make stuff like this to teach myself [https://vuild.com/game-
watch/](https://vuild.com/game-watch/) (resize)

------
nicoburns
The problem with CSS is that there is some (completely unintuitive when you're
learning) tricks to make it all work. But there only say 5-10 important ones,
so once you've learnt them it gets a lot easier.

I'd recommend [http://learnlayout.com](http://learnlayout.com) for learning
some of these tricks.

------
microcolonel
If you ever get the chance, read the code which runs your CSS, it should give
you a better idea of what's going on.

------
scns
One guy once wrote here on HN that he does not have an intuitive feel for CSS
even after 20 years working with it. Seems we just have to memorize all the
rules.

I think the book "Learn CSS the pedantic way" is a great resource:

[http://book.mixu.net/css/](http://book.mixu.net/css/)

------
ASalazarMX
> I have no idea which colors "go" with which ones, and pretty much all fonts
> look like the same for me.

Before going into web development, I wondered why some people were so picky
about fonts when they all looked similar. I'm a little ashamed to admit that
after 5 years, they still look somewhat similar.

------
Antonio123123
Think this way: You html is a tree of tags. You have to layout this tree.

Each tag is a box that can contain other boxes. Learn about the box model to
understand the properties of a box.

How do you display the boxes inside another box? Learn about the display
property.

How do you position the box inside another one? Learn about the position
property.

------
eweise
I can't understand CSS either. For Elm you can bypass that headache with this
library;

[https://package.elm-lang.org/packages/mdgriffith/elm-
ui/late...](https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/)

~~~
nickcox
I'm quite interested in this library. Have you used it? What did you like and
not like about it?

~~~
berryg
I am using Elm-UI. I haven't written any CSS or any raw HTML in my project.
The elm-ui layout model works very well. The `explain` attribute is a life
saver in more complex layouts. There is much to love and very little to hate.
I have been struggling a bit with `width fill` on rows and wrapping of blocks
of text. But, these inconveniences are almost insignificant compared to the
complexity of CSS. Elm-ui is well worth trying out.

------
bayesian_horse
The underlying problem is somewhat hard.

------
sumo89
The thing is CSS is there's a lot of gotcha's to remember but I think people
mostly struggle with it because they underestimate the HTML. You need to think
through the box model for how to structure the elements before you start
trying to move them around relative to each other.

------
tabtab
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.

~~~
goto11
> 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.

OK...so if you search for something on google you need to know the coordinates
for every pixel in the rendering of the text you are looking for?

~~~
tabtab
Who is "you" in your scenario? It would be similar to printer formatting
languages. The printer driver translates a document into lines, vectors, and
polygons, and sends those to the printer as page coordinates, except the page
length is not limited to paper's limit. (We'd probably have to add event
triggers on designated polygons to handle UI interaction.)

The equivalent of the "printer driver" is the rendering engine on the server
that takes your document or data and formats it using whatever
formatting/layout engine YOU choose. The "input document" could be HTML even.
We don't have to toss away HTML to use it. The difference is it doesn't _have
to_ be HTML.

In some ways it would be closer to working with PDF documents, except it
wouldn't be based on "paper" conventions. The width would typically be
dictated (or requested) by a particular device (client), and the length would
be whatever the renderer decides is needed, typically based on the content
being rendered.

Office workers love PDF because it's WYSIWYG. Browsers don't butcher their
original vision. But, keep in mind the layout engine does _not_ have to be
WYSIWYG. The key point is your shop decides, NOT a standards committee. Layout
engine FREEDOM! Hallelujah!

~~~
goto11
My question was, how would Google index pages and make them searchable in this
system?

~~~
tabtab
My main focus is on "productivity" applications and CRUD, not so much
documents. One doesn't typically index applications in a Google-esque way. I
don't propose we throw out all the Web, but rather create (or extend?)
standards for the things HTML/DOM/CSS do poorly. My apologies for not making
the scope clearer. (Maybe that's why I got a "-1" score.)

And, there may still be a markup language with text as text and other semantic
info. The new standard may be able to use existing HTML tags, but add
supplement attributes to control precise placement, and other features
HTML/CSS lacks.

By the way, Google can index PDF documents reasonably well, depending on how
the PDF was created. This is evidence that precise control over layout doesn't
necessarily prevent indexing and summarizing of text and content.

I will also point out that many graphic designers are frustrated with CSS also
because they envision a concept, but have a hard time getting web pages to do
what precisely what they envision. It's why Flash was popular with them: the
proverbial paint strokes wind up exactly where you put the brush down on the
canvas. The artists may still want their work to adjust to the end-user screen
size, but they want to control precisely HOW it adjusts: they want to write
the size adjustment formulas themselves (or select among multiple API's), not
rely on browser programmers and their variation on the CSS engine, which often
differ across browser brands and versions.

~~~
goto11
Can't you already do everything you propose with the HTML canvas element then?

But I can't see why you would want to render something as mundane as a CRUD UI
through such a complex and slow scheme. For perhaps a game or some truly
unconventional UI, it makes sense to use SVG or canvas to render it. But then
you also want the rendering logic on the client (in JavaScript) because it
would be _far_ too slow to round-trip to the server for each mouse movement.

Btw. Google can index PDF files only because the PDF format contain text in
the form of character strings, not as drawings or bitmaps, as you suggest.

~~~
tabtab
I haven't seen a good realistic example of the canvas element doing what I
expect. Didn't you even admit "canvas" is overly complex and slow, or did I
interpret that wrong? I'm not sure what you mean about JavaScript either.
Perhaps an example?

As far as character strings, I don't propose rendering text via vectors. But
PDF's do control text position far better than HTML/CSS can or does. I realize
there's a lot of details to define and work out, but HN is probably not the
place to iron all that out.

~~~
goto11
No I don't think canvas itself is overly complex and slow. Canvas is fine when
you need to go beyond what is possible with HTML and CSS.

I'm saying your proposal to perform rendering on the server and just stream
pixels to the client is going to be overly complex and slow. Just imagine how
you would implement a hover effect using this scheme. Or screen resizing. Or
scrolling...

> But PDF's do control text position far better than HTML/CSS can or does.

You can place text precisely using absolute positioning in CSS. It is just
rarely a desirable approach since the layout will not adapt to screen size.

~~~
tabtab
It would generally be vectors sent, not pixels. If the kit or standard came
with decent and common GUI/CRUD widgets and related attributes, then one would
not typically need to re-implement hover indicators etc. on the client. (There
might be a "hoverbordercolor=blue" attribute, for example to override the
default hover color. And normally you wouldn't mess with the default.)

It shouldn't be slow and bandwidth intensive if you stick with typical and
common stuff for productivity applications. If one values eye-candy and fancy
animation above productivity and reliability, then they can use the existing
standards. I don't propose replacing everything, just supplementing and/or
extending for work-oriented stuff.

And CSS's existing absolute positioning is _not_ absolute in my experience. I
get different results in diff browser brands/versions/OS-settings. Screen size
adapting was covered in another sub-thread. People are so used to thinking in
terms of HTML/CSS that I have a hard time explaining what I have in mind. I
may need to make a more thorough write-up.

~~~
goto11
You can already send vector graphics to the browser in the form of SVG.

~~~
tabtab
I've yet to see it used effective to give us desktop-like GUI's. My experience
is SVG lacks common GUI widgets, and text positioning is still inconsistent
across browser brand/versions/OS-settings. Downloading tons of JavaScript to
emulate typical GUI's gets right back to fat-client problems created by
current browser "standards". Maybe someday these weak points will be solved,
but so far it doesn't seem ready. SVG is meant to draw pictures, not manage
GUI's.

~~~
tabtab
(There is no "reply" under your comments, so I had to put the reply on the
prior level.)

Goto11, you are correct that I was ambiguous. I was mostly talking about
positioning and sizing itself when I said, "browser should be a dumb x,y,z
coordinate polygon plotter." I should have said, "browser should use absolute
x,y,z coordinates for sizing and positioning objects....". By "dumb" I meant
the layout & sizing engine is "dumb", not every UI object. No more client-side
auto-flow nor auto-size. Good catch. I'll hire you to debug the wording of my
Next Great Write-up :-)

------
anotheryou
most has been said, but I want to add that the pragmatism of the language
makes needed effort unpredictable.

many solutions seem to be born out of the fashion of that time. an animated
dropshadow is easy, styling a checkbox, it's label and making it work for rich
devices is damn hard.

(for the latter you need to figure out the way to associate a label with a
checkbox, hide the default checkbox, draw your own to style that, somehow get
the state from the hidden original checkbox and than build a very weird
wrapper, that invisibly enlarges the clickable/touchable area without bursting
your layout or covering another touch zone)

I think medium did a whole blog post on how to get aesthetical authority over
a text undergone.

------
jwr
CSS is crazy.

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.

------
mellow-lake-day
The Bootstrap CSS framework is the easy button of CSS

It makes writing CSS enjoyable and fun

[https://www.youtube.com/watch?v=wesUO81YX0U](https://www.youtube.com/watch?v=wesUO81YX0U)

~~~
Grumbledour
No, really, it isn't. It just teaches you to fill up your html with a lot of
useless classes while teaching you nothing about css, unless you want to
change how it looks, in which case you have to basically rewrite everything.

It may be a good substitute for a first draft, but your website will be much
leaner and cleaner without it.

Also, I can never get over the fact, that the bootstrap devs seem incapable of
delivering UI elements like dropdowns without additional javascript or can't
even include a no-js fallback. That doesn't really create confidence in their
abilities as web developers.

------
inoda
A hilarious rap about how neglected CSS can be:
[https://www.youtube.com/watch?v=0yXJ4t6Ax1U](https://www.youtube.com/watch?v=0yXJ4t6Ax1U)

------
nope4666
I am in very similar boat, years of experience as back-end dev but struggling
with "simple" css for layout.

what helped me is understanding flexbox and realizing you can use negative
margins.

------
iamgopal
Flexbox almost do what you told it to. Try it. Previous generations were
giving days of nightmare, but current flexbox + many utility libraries have
reduced headache a ton.

------
k4ch0w
I have limited experience by building my own apps for learning purposes.
Getting CSS working in multiple browsers exactly the same is always a pain
point.

------
misiti3780
Is it a true statement that if you are starting to learn css in 2019, you
should spend most of your effort with flexbox and scss (they are the future)?

------
panic
It's not just you. Treating the web like a native UI framework, where you can
set pixel positions directly to get the perfect layout, isn't going to work.
The trick to using CSS effectively is to give up on achieving whatever design
goal you have. Instead, you should settle for what CSS actually lets you do.
Don't try to align text to the pixel; change your design so it doesn't require
precise alignment. Ideally your designers should also work in CSS so they can
understand why nothing looks exactly like the images they produce.

~~~
tabtab
Everything is "easy" once you learn it. Rockets and brain surgery are second
nature to experienced rocket scientists/engineers and surgeons.

As I mentioned elsewhere, something that used to be quick and simple in
WYSIWYG tools now have a giant learning curve and/or require lots of fiddling
time to get working. It's hard to believe we _must_ go from bicycle science to
rocket science to make everyday software. We are not trying to make Mona-
Lisa's, just get-er-done software that's relatively easy to use for end users.
This alleged must-ness bothers me. It makes one feel there's a Grand Invention
_missing_ that will bring back the grand simplicity and speed of WYSIWYG
tools.

It's as if we finally got flying cars in the 1990's (WYSIWYG tools), and then
they are all _yanked away_ from us and we are back to 2D roads.

 _Who shot the Jetsons?_

------
jlengrand
Might only partly related, but I have had the same exact problem for years
until I start using web components.

Having to handle the CSS only for small bits at a time, in a contained
environment made it much more logical and understandable to me. Most likely
because it is more obvious to understand where to put specific CSS to achieve
a certain behavior. I guess that small components tend to fit better with how
my brain is wired as a mainly back-end developer.

I know react and others are also using the same strategies lately, but most of
my experience is with WC.

~~~
jlengrand
God I love downvotes without any explanations. I can't learn anything from it
:S

------
mrtejas99
Well, CSS is an obligation. You have to use it for front-end whether you like
it or not. Even for me it kinda always problematic to use

------
atoav
CSS is not hard. But there are certain things that are (needlessly) hard to
solve with CSS. But it certainly got better with CSS3

------
pandeya
My personal favourite for this topic

[https://internetingishard.com](https://internetingishard.com)

HTH

------
devendramistri
That's the case with me too.. I write JAVA/Python at rocket speed, and css
slower then snail.

------
lsadam0
To me, the fundamental issue isn't that CSS is hard, it's that CSS is just not
interesting.

------
threatofrain
CSS doesn't seem to be experiencing the same revival or energy that JS is
still experiencing.

~~~
mattlondon
I'd disagree. There is a lot of new stuff to CSS making our lives HUGELY
easier.

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.

------
ilitirit
The "hardest" part of CSS to me is accounting for minor browser differences.

------
andrewstuart
I like CSS - it took some time to learn but in the end it's incredibly
powerful.

------
austincheney
As somebody who has been writing CSS for 13 years and watched numerous people
fail here is the deal.

You have to confront the challenges head on and solve for them directly.
Unlike JavaScript there is no magic framework abstraction hide from your fears
shortcut. You have to embrace this reality both cognitively and emotionally.
This is the reality, accept it. If you cannot get past this barrier give up
and do something else with your life.

That said CSS isn’t too hard but it takes some very real practice up front to
wrap your mind around it. The browser tools are much better than they used to
be.

First you have to understand that CSS describes markup and markup is a tree
structure. A solid understanding of the DOM is helpful but not required. Most
CSS properties cascade down to descendant DOM nodes but some do not,
particularly anything addressing the box model.

Second you have to embrace the box model. Don’t use the box-sizing property to
redefine reality. Embrace the box model and understand it deeply. It isn’t
hard but needs to be seared into your brain so that you are thinking about it
visually instead of as code properties. Once you have mastered comfort with
the box model you can use box-sizing if you want, but you probably won’t.

Third, understand dimensions. For learning I recommend not using pixels. Set
the body to font-size: 10px and use em units for everything else. This
simplifies things by setting 1em to 10px for initial definitions and forces
you to consider how the cascading works when 1em becomes some multiplicative
value. You are already an experienced developer so the math won’t be hard. You
just need to wrap your mind around why the value changes how to correct for it
in the code.

Fourth, learn float. Float Changes an element into something like
display:inline-block and allows content to flow around it. Specify clear:both
on another element to stop the flowing/wrapping behavior. You can create
columns by creating a parent element filled with floating children. Add a
final child element with display:block and clear:both to limit the floating
behavior to the parent.

Fifth, understand position. Default is position static. Avoid value absolute
unless you deliberately want to impose layering and completely remove the
element from the flow control of the page. The properties top, right, bottom,
and left refer back to the last positioned ancestor node.

Finally, play with pseudo classes to be familiar with what’s available.

Practice those things and build up your confidence. It gets easy but it takes
some effort. It is a different skill than programming logic. After I had first
started learning there was something called the CSS Zen Garden that made for
some practice. Here was my attempt:
[http://mailmarkup.org/zen/](http://mailmarkup.org/zen/)

Browsers evolve in how they render text, but when I made that Zen Garden thing
all the text columns were in complete vertical alignment cross browser.

------
thepapanoob
css is just as hard as you make it! if you follow basic rules: make every
component contained in a box wich they cant break out of!

make it lean and use the css operators like > first-child etc.

------
yyx
Don't compare CSS with JS. Compare it with LaTeX.

------
pmoriarty
Are there any replacements for CSS on the horizon?

------
msie
web apps are 2d, web docs are 1d. There should be something else to style web
apps instead of css.

------
joeld42
It's not just you. CSS is bad.

------
goto11
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.

------
sgentle
Yes, CSS is a hot mess for a few reasons that all basically boil down to
historical baggage.

CSS was designed for an era where the web was made of documents, probably
closer to the environment of a modern ebook than a modern web app. In an
ebook, you might want to set your fonts and spacings and so on, maybe even
throw in a table or two, but the idea of "I want this box to appear exactly
here"... well, you don't even know where _here_ is! The paper size might be
different, or the user might have custom fonts, or who knows what. The goal
wasn't fine-grained control over visual design, but consistency across an
organisation's published material.

Of course, "fine-grained control over visual design" is exactly what everyone
wanted, even in the early days, so CSS grew in features and scope until today
we have this decades-tall stratified monument to the art of pleasing
everybody: a fully-featured typesetting, layout, visual design, animation and
user interface language. But, however rich its top layers, the whole thing
rests on a base of document publishing, and that can't be changed because You
Can't Break The Web.

HTML has this problem also, which is why so many sites look like <body><div
id="container"></div><script src="app.js">. In truth, the whole modern web is
built on hacks that pretend apps are documents. A lot of that hackery (React,
Vue, etc) is incredibly clever and sophisticated, but it's hacks all the same,
and it only exists because the web is an app platform that wasn't built for
apps. This hits CSS hardest because developers solve developer problems, and
design isn't a developer problem. Unlike the DOM, the CSSOM isn't yet swaddled
in enough layers of JS to fit in app world. That said, check out the various
"CSS-in-JS" projects for some valiant attempts in progress.

I would say if you really want to really _get_ CSS, you should start by using
it as it was intended, typesetting simple documents with only CSS1 features
(check it out, [https://www.w3.org/TR/CSS1/](https://www.w3.org/TR/CSS1/) is
so simple it makes your heart sing). Then work your way up through CSS2's
additions, especially the positioning stuff ([https://www.w3.org/TR/2008/REC-
CSS2-20080411/changes.html#q1](https://www.w3.org/TR/2008/REC-
CSS2-20080411/changes.html#q1)). Only once that feels coherent should you
drink deep from the firehose:
[https://www.w3.org/TR/css-2018/#css](https://www.w3.org/TR/css-2018/#css)

Or you could do what the rest of us do and pretend CSS makes sense while only
using carefully-memorised avoid-the-dragons patterns, copy-pasting stuff from
css-tricks, and fiddling with the result in the web inspector until it works.
And, meanwhile, pray for Houdini:
[https://houdini.glitch.me/](https://houdini.glitch.me/)

------
barbecue_sauce
I think of CSS as just using Photoshop but with descriptive rules.

------
pmarreck
CSS is declarative. Code is procedural/imperative.

~~~
dragonwriter
Except logic, (pure) functional, and some other kinds of code, which is
declarative.

------
andrewmcwatters
As far as small projects go, it's useful to take what you've learned from
larger projects like Bootstrap, and use a subset of that knowledge.

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.

------
jstewartmobile
> _Is CSS an "art" thing?_

Certainly![0]

> _Is it common for other developers to have issues with it?_

Boy howdy it is! Like eight years of discussion[1] on vertically centering
text in a div. It's all siegeworks-engineering[2] anyway, so no surprise that
we ended up here.

I think at one point in time, poor Doug Crockford suggested actual versioning
for things like javascript and CSS. The children shivered as though they had
been visited by a ghost! And after brushing the chill aside, returned to our
great undertaking of cramming as many _different_ languages into a .js file as
humanly possible.

[0] [https://www.widewalls.ch/andy-warhol-piss-
paintings/](https://www.widewalls.ch/andy-warhol-piss-paintings/)

[1] [https://stackoverflow.com/questions/2939914/how-do-i-
vertica...](https://stackoverflow.com/questions/2939914/how-do-i-vertically-
align-text-in-a-div)

[2] [http://2ality.com/2011/03/javascript-how-it-all-
began.html](http://2ality.com/2011/03/javascript-how-it-all-began.html)

------
droithomme
I always end up having problems using css to do layout, like you mention that
it's often a pain to center things. I prefer tables for a lot of things that
I'm not "supposed" to use table for because the css methods don't work the
same in various browsers, or at all in older ones.

css for markup works fine for me.

A humorous experience for me is when I look up some css concept I can't
remember the details and find sites and blogs by css gurus about it, but their
site is a total mess, unreadible, with for example letters as large as the
screen, all readible text in a div that is off screen, etc, and turns out
their blog only renders properly at all when viewed in Chrome. Seems there's
lots of css experts that advocate for weird features which only work in one
browser.

~~~
eyelidlessness
I won't fault you for finding tables intuitive for layout, but please stop
using the actual table elements to do it. You can use normal divs with table
styling for exactly the same outcome: [https://caniuse.com/#feat=css-
table](https://caniuse.com/#feat=css-table)

Semantically it does make a difference, and can impact people using
accessibility technologies.

------
shmooth
CSS is the worst.

Git and CSS are the two hardest things anyone will ever try to learn in
computers.

To the extent I've had some success with CSS, I've used bootstrap, and went
back and did some CSS 101 stuff because none of it is intuitive -- actually
learning how they did CSS helps a lot b/c trying to figure it out will never
work -- it's all back-asswards at best.

and that's before you get to browser differences.

------
prevedmedved
It's not just you.

------
idevice
The same content in html5 is much faster

------
gammateam
HA! It used to be a lot worse

Current CSS is a culmination of polyfills, which is why nothing works as
expected

I wouldn't call CSS hard, once you accept that there is no expertise of making
CSS work right without many iterations.

------
aphextron
The thing with CSS is it's not a programming language. Progamming skills and
CSS skills are almost completely orthogonal. It is simply a domain of
practical knowledge that takes years and years of dealing with all the
idiosyncracies, cross browser issues, and silly warts of historical legacy
that come with it to master. That being said, it is without a doubt the most
powerful and simplest layout tool in existence. Things like QT can come close,
but really nothing else is as as simple and easy to use while still being
extremely performant and highly customizable. There's very very good reasons
why practically all software nowadays has gone to HTML/CSS based UIs.

~~~
jolmg
> There's very very good reasons why practically all software nowadays has
> gone to HTML/CSS based UIs.

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.

~~~
zapzupnz
> and there's no choice

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.

~~~
aphextron
>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...](https://github.com/amraboelela/myos.examples/blob/master/CoreGraphics/Gradients/gradients.m)

~~~
zapzupnz
Then I guess my dream system marries the two concepts, somehow. I don't think
we should accept CSS just because it's what we have; far too many people find
it confusing and dislikable.

At this point, I'm starting to look into things that "transpile" to CSS.

~~~
alexis_read
IMHO I think that one of the main problems with CSS is that it doesn't have an
explicit model of text. If you have that, then a constraint-based designer can
take you through wizards to ask to to consider eg. When there's more text than
space. Springs, struts etc. Can take care of layout. Controversially I think
we should replace/remove div tags as they don't make all their behavior
explicit vs flexbox/ cssgrid etc. Every object should have explicit layout
behaviors defined. Then you can compose them or create new objects for
undefined cases.

