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/

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.

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.

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.

And when you have to implement a email design someone gave you who think it’s more important to have it look a certain way then to implement it reliable.

I like my emails like I like my actual mail; text and maybe the odd image.

Those are JS related, I don't think anyone is asking for renderers to allow that. But proper CSS support would be nice.

I don't understand why HTML payloads can't just be loaded in a (streamlined) browser pane?

https://templates.mailchimp.com/resources/email-client-css-s...

Javascript should stay firmly blocked though.

I'd even go as far to say the text on most webpages isn't even linear. It's either a tree (like this comment page) or a fragmented collection of text chunks.

The webpage that strictly consists of one linear stream of text is very much the exception. And it also happens to be the exception that CSS never had problems with.

What you seem to be saying is that paragraphs are 1D (which get wrapped and flowed in layout), therefore entire webpages are 1D (no) and therefore the web is 1D (definitely not).

Or maybe you could say that most viewport representations, scrolling vertically, are 1D. In which case CSS should be the tool that converts the tree or graph of content into this semi-1D viewing representation.

I agree that this mismatch is where CSS finds a lot of problems.

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.

The same content reflows to different 2D spaces

An individual flexbox container is one dimensional. To get a 2D layout, you nest rows and columns.

> ...doing a responsive layout in explicitly 2D terms is a very weird thing to be doing and usually isn't what you actually want.

I have no idea how you would come to that conclusion. To me, a "responsive" layout is one that adapts to the viewport size. The viewport is 2D. This is a 2D layouting problem.

A subset of that problem is concerned with fitting content of a fixed viewport width to a variable height, i.e. your classic web site. That's what you may call "1D content". Once you're trying to get a layout that adapts to both viewport width and height (i.e. an ordinary application), CSS can get quite ugly.

Precisely. More often than not, accomplishing this requires more than just squishing and stretching. Panes have to wrap around at certain points and the layout has to shift. You can do this with a bunch of special cases, but the better way is to let the rules of flow work for you. For example, you can have a flex child "grow to fill available space but have minimum size", so that if less than that minimum size is available it wraps around to the next line. You want to talk about your layout in terms of a series of sections, not a fixed grid. This was impossible with <table>; CSS Grid provides tools for special-casing these things, but it's still way more obtuse than letting them occur naturally.

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.

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

That's why the 2D layout is important because it can help assist or guide the creation of this path. For many pages there is no fixed "proper" path through the content even though the DOM is necessarily in some order.

I'm not sure exactly what you are referring to, but there have been some misunderstandings regarding tables. Before CSS, <table>-tags were there only way to control the layout, but since CSS 2, it have been possible to achieve the same kind of layout which display:table in CSS without having to abuse <table>-tags. But there is nothing wrong with using <table> when they are semantically appropriate.

Recently CSS have gotten display:grid which is way more powerful than table layout ever was.

Float and clear was never intended for general layout. They were invented by Netscape back in the day to allow text to float around images. Float/clear-hacks became a necessary evil in the dark age before IE supported display:table.

You cant really blame CSS for IE not supporting critical parts of the spec, since this was part a deliberate strategy by MS to "kill the web". Luckily this strategy failed and MS changed their minds.

As an historical aside: that's not quite true to my recollection.

p-elements had width, height (and possibly other attributes, margin, border?). And empty <p>, hr, br(?), were used for rudimentary layout? Then there was color, bgcolor attributes; and font tags. Not sure when <center> came out?

This https://www.w3.org/Style/CSS20/history.html is probably much better than my recollection. I started making webpages/email-circulars about 1994-95.

However, these (below) suggest that HTML3 spec at least had layout attributes like align, wrap, clear on p; and had width for hr (it was a Netscape extension on HTML2 too, apparently).

Also since HTML2 textarea had cols and rows attributes. There was also default styling on blockquote and lists that have indents. \&nbsp; was used for horizontal "alignment" (tabs); code and pre too. I'm going to say there was some layout "tools" prior to CSS.

Quite interesting to read the specs now, at the time I was just groping around in the dark by myself, learning by reading source of live sites. Would have probably been much easier if I'd known a spec existed!

https://www.w3.org/People/Raggett/book4/ch02.html -- MSIE promise to include CSS Nov '95.

http://marc.merlins.org/htmlearn/html-ref.html#P -- HTML3 spec, I think?, dated 1995. Go up one level to find HTML2 spec.

Further aside: spacer GIFs I never came across until about MSIE4, avoided them myself, too much of a purist. In the Mosaic vs Netscape Navigator days I don't think anyone had started to attempt pixel-matched designs across different UA??

A very good point. My guess is that we could let designers do a lot more and developers do a lot less, if it wasn't for that impedance mismatch.

> I'd like to have a real constraint system, like the one in Autodesk Inventor sketch mode

Here you go: https://gss.github.io/

> GSS reimagines CSS layout & replaces the browser’s layout engine with one that harnesses the Cassowary Constraint Solver

[1]: http://overconstrained.io/

[2]: https://constraints.cs.washington.edu/cassowary/

With that, we could have Dreamweaver type layout working again.

That project seems to be more about the math than making layout easier. That's a problem with many academic projects. One thing I've liked about Autodesk products is that they often have complex math inside, completely hidden from the user. You see that in the CAD world, where the physical universe has to be modeled.

In theory, yes.

And the theory certainly can work beautifully as intended in practice.

However, developers and designer tend to have huge problems with autolayout. Specifying what you want visually as a set of linear constraints is challenging. It is very easy to get very surprising outcomes, easy to overconstrain and underconstrain.

It's a very big sledgehammer aimed at some very delicate eggshells. Not just when it comes to understandability, but also when it comes to runtime performance.

> The browser has lots of default, complex behaviors that drive layout, and […] CSS is more about […] guiding that automatic engine

I think for most people who struggle with layout, what they really need to learn is what process the browser uses to lay out content, so that they can then turn their mind to how to guide it. Instead, I've seen hardly any CSS tutorials / documentation that start with a description of the layout algorithm and what hooks it provides via CSS; they all start from the meaning of individual CSS declarations, which are never the full picture.

I think there's really room for teaching layout from the other end (the following is the browser's algorithm, and here's what can influence it), for people who think procedurally.

That, and experience. Very rarely do you actually encounter genuinely new layouts in CSS, so with experience you just end up building in your head your own little 'component library' and pattern match designs to that.

CSS is actually pretty simple, as long as you start with the smallest elements and work up. It becomes a nightmare if you try and address everything individually. It’s not really a programming language, but a series of guidelines.

I’ve seen this simplicity actually throw developers as they’re used to something much more complex and systematic.

Preprocessors like SASS are great, but I wonder if they’re designed to complicate CSS a bit so developers feel at home.

Pixel perfect design is totally possible, as long as the designer is aware of the constraints and opportunities of the medium they’re working in.

But it is very possible to make websites look very good and inline with what was designed.

But good luck making an input, button and select the same height. It's just not going to be pixel perfect.

What is pixel perfect in your browser isn't in others.

But what designers should now is it doesn't matter as long as it looks good for everyone.

It absolutely is possible—we used to do it all the time back in the table layout days—but it is not desirable. They are inherently fragile (often users can break them just by changing the default text size), and they do not adapt to different screen sizes very well.

Designers coming from print often get caught out when designing for the web as they tend to think of a webpage as a fixed layout, rather than a flexible system of components.

It's also important to understand where the design and development budget should be effectively spent. For example, unless there's a real business or usability reason for doing so, there's little point in trying to custom-style form elements like selects as doing so is difficult and time consuming and system defaults look better and provide a more consistent experience.

We demand pixel-perfect accuracy at work between design and code – but the developers must approve the designs first to confirm that it's achievable.

I guess it comes down to what we define as 'pixel perfect'.

When the customer hears "pixel perfect" they don't think "different on different browsers and on different OSs and on different devices", they think "the same everywhere".

During the pitch meeting we'd point at the big TV in the meeting room, their laptop and smartphones and (maybe) watch, and explain that while we could make their site look great on everything, it wouldn't look the same.

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

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

Sure you can. Just see how Bootstrap does it.

It is true that for a long time, input controls were rendered using the native platform controls, so there were are a lot of differences and limited styling capabilities. But these days all browsers (as far as I am aware) use the browser rendering engine for input controls, and they are fully stylable.

1) Nested selectors

2) Imports

3) Variables

#3 is now solved/being solved natively, but I couldn't live without #1 and I'm not really sure why it hasn't been added natively yet

(If you are old enough, you may have come across one of those WordPress templates in which they crammed PHP $variables inside inlined CSS. #goodolddays)

People have developed some techniques to mitigate these issues, but many are unintuitive and don't follow naturally from "make this thing look this way".

With the key difference being that there's no rigid structure to it at all, much less a strict-subset hierarchy. It's really more like structural object types, which can be easily composed, than OOP classes. It's set theory, rather than taxonomy.

> Without some sort of build system, static analysis is difficult so it's hard to say if a definition is being used or not

This can be easily solved with good project organization. At my day job I maintain a codebase with a couple hundred SCSS files, which are on average a couple hundred lines each. We've organized things well enough that the cascade is a non-issue, and "leftover" styles from an element that's been removed are a rare occurrence. All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles.

> don't follow naturally from "make this thing look this way"

This is precisely the problem; programmers come from a background where they think in terms of "make it do this thing", and they try to translate that to "make this thing look this way". That's how you create supremely fragile CSS which is impossible to safely make changes to. Instead you should be thinking in terms of, "make it behave this way in the general case, relative to what's around it".

"All you have to do is closely mirror your UI components, pages, fragments, whatever, with the relevant CSS files. Then if you add or remove something in the markup, you add or remove it in the corresponding styles."

Super simple. It is what it is and powerful etc, but simple? I have given up. I just use the minimum web tech to get by.

It is arbitrary and chaotic. It breaks the principle of least astonishment.

You have a shitload of display sizes to support on the other hand and strange behaving browsers which aren't truly standardized on the other. That makes adjusting your CSS to all of these a pain in the ass even if you like fiddling around with styling (as I basically do).

I don't want to adjust my margins, paddings and fonts and then restart from scratch because f Apple decided they will do everything in Safari completely different from the rest of the browsers just to show how special they are.

I'm also sick of building selenium grids with a mac mini in them just to also test this piece of ... "ingenuity" ;-)

So nowadays I just go with a framework with sane defaults and no-hassle usability and when I need something special I ask people who don't do anything but CSS the whole day.

Without more standardization it's not a domain you'll be great at when you don't specialize in it - which means you got to invest a lot of time to master it.

I will demonstrate why.

First, think of all the tools that you use that require a text interface. That may include a programming language (python, ruby, javascript, etc), a command line shell (bash, fish), a database client (mysql, psql), a configuration script language (systemd, nginx), etc. In all these the text based interface is the language used to speak with the underlying engine. Now, these languages must be designed and there are good designs and there are bad ones. If the language sucks, people can generally just choose to go with a competing alternative that has a somewhat more accommodating syntax. But CSS is a monopoly. We're stuck with it. For many of us it's a really shitty language that is guaranteed to live on, no matter what, just because, well browser technology.

Ok, enough ranting, on with my demonstration.

For this I'll take CSS positioning as a case. Let's say we decided to design a domain language to express how items on a web document must be placed. We could start from the perspective that when repositioning an element it should always be relative to some point of reference. That starting point could be the element's default position, or it could be the viewport, or it could be an ancestor element. From there we could devise some simple rules to express this.

To move an element you must first declare where you're starting from. For example moving with respect to its "default" position in the normal flow of the page would be declared as such (could be made optional too):

    position-reference: default

    position-reference: viewport

    position-reference: parent  /* immediate parent     */
    position-reference: div     /* first div ancestor   */
    position-reference: root    /* the document         */
    position-reference: <some-syntax-to-navigate-ancestry>

    position-maintain-gap: true
    

    position-scrolling: off

Now, contrast that with how these concepts are actually expressed in CSS. Instead of the different patterns being simply given as combinations of the above simple options, as I've demonstrated, they're rather given as ready-to-eat dish with labels such as "relative", "absolute", "fixed", "sticky". The whole thing is then sprinkled with ifs and buts. This "simplification" doesn't always have the intended effect though, and many many people are just confused when first trying to understand positioning.

CSS is a badly specified mix of a unidirectional constraint system, a typographical system, a compositor and a declarative transition/animation system.

While there is by now a CSS: The Ok Parts, there are no good parts because they hang off the bad parts.

Many of the worst parts of CSS, and even JavaScript for that matter, come from the need for backwards-compatibility. There are literally websites from the 90s that still render and function perfectly fine in a modern browser. That's an amazing property of the web, and I'd say it's worth the tradeoff of living with a few questionable decisions of the past. Plus, we continue to rapidly build new features on top of those backward-compatible ones, so it's not like we're truly held back by them. Modern CSS and JavaScript are barely recognizable from the 90s versions, but they still contain those as a subset.

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

Javascript is logical (sort of...), and a lot like learning math. It's fairly easy to validate your output. It works well with the logical side of your brain.

Learning CSS is a lot like learning English. There's the basic grammar, but also tons of edge cases, dialects, and straight up absurd rules (Buffalo buffalo..). It's a language primarily improved through experience and memory.

CSS has undergone LOT of development last few years, so things like div centering can now be solving by margin (oldest), flex (newer), and grid (newest), but only in certain browser. It's a language you must constantly keep up with.

Design is just colors and fonts right? (At least, that's what my CEO says). It's important to realize that good design is as hard as good code, and you really benefit from a similar education. That being said, cheat by using a color wheel or Coolors.co

Fonts all look the same until you learn how to look at them. Wine all tasted the same to me until someone taught me what to look for. Without knowledge about why fonts are a certain way you'll never be able to pick one, but it's totally possible to pick that knowledge up. Find a beginner book on fonts and you'll be on your way in no time.

CSS has nothing to do with design. It is the tool used to implement the design and there are loads of other layout tools out there that don't have CSS's infuriating quirks. On the flip side, they usually have steep learning curves because they are strict.

For a long time, until less than a decade ago, designers knew nothing about CSS. They'd do a design in pictures and their design would be implemented by a programmer.

Some (unlucky) programmers entire job was turning PSDs into HTML and CSS.

That was my entry into programming many years ago. But I wouldn't call it unlucky - early web devs like me (we didn't really call ourselves programmers back then) had front-row seats at the beginning of a revolution, and it certainly was entertaining to watch and be part of.

> CSS has nothing to do with design

CSS works the way it does because it was created to make the kind of designs that designers wanted possible. It has everything to do with graphic design. All the web designers I knew back in the early days knew some HTML and CSS and we'd often discuss possibilities and limitations of browsers and standards, and how to work around issues. They didn't just lob PSDs over the partition to the devs - there was an active dialogue and they knew their stuff.

You were one of the lucky ones. I worked with designers who would've done fine designing a printed flyer, but couldn't comprehend the idea of a scrolling website with dynamically-populated content (of varying lengths) being viewed at different sizes on different devices/browsers.

Their solutions were along the line of "Force the browser to be XxY resolution and limit the number of words that can be entered in this area."

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.

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

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

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

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

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

If we were going to start from scratch though, we wouldn't do HTML5, we'd use some other format. JSON maybe?

1. https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

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

I find this false. PSD-to-code was very common back then. There even still some designers today that only work via images/PSD.

What a bizarre statement. That's like saying words have nothing to do with stories, or paint has nothing to do with art.

[1]: https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buff...

Nearest English silliness I can remember hearing is: police police police police.

Policing OTOH seems to be a fairly widespread verb form with a clearly understood meaning (i.e. what the police conceptually is supposed to be doing). Unless you have close experience with buffalo, you probably can't infer buffaloing means "intimidating".

EDIT: Also as mentioned elsewhere, not everyone outside the US knows there are places actually called Buffalo or makes that leap when hearing the word "buffalo". So "Buffalo buffalo" is more likely to be read as "buffalo(n) buffalo(v)" (which already sounds weird if you don't already know what "to buffalo sb" means) which breaks down as soon as you add more buffalo to the sentence.

Buffalo the city was probably better known 150 years ago, when it was an economic powerhouse as one of the end points of what’s still the second most famous canal in the Western Hemisphere. Afterward it continued to be a significant industrial center until the decline of manufacturing turned the Great Lakes region into part of the “Rust Belt” in the past 50 years. Most Americans probably know of it these days because it still hosts an American football team.

Anyway, the point isn’t that that’s a common sentence. It’s that it’s a grammatical one.

Police police police police is grammatically correct, but of little meaning : (the) police police(v) police (of) police (ie overseers of the police).

Yeah, I'd sum it up by saying CSS makes hard things barely possible and simple things hard.

The example OP gave of centering divs illustrates this point, and there are unnecessary weaknesses in laying out a page when, for example, sizes aren't known in advance. Overall, there's a divide between intuitive expression and output, wherein the browser ends up saying things like, "I won't do this (e.g. center) unless you also do that (e.g. tell me how big it is)." Really? Why?

In all, it's never been an efficient solution to the problem it seeks to solve. When the Great War on Table-based Layouts broke out, it was even less suitable, which made it even more painful that you were persona non grata for resisting. So, rather than demand a better standard and uniform browser support, we just hacked and kludged and shimmed around it. So, the need to support the legacy has made it even more impractical to fix, hence the attempted do-over with flexbox.

CSS has been the bane of front-end development for many a dev. Amazing that we largely just suffer through it, and its tyranny has reigned for so long.

Of course the cutting edge will temporarily see one rendering engine a few months behind another. But that’s unavoidable unless you prefer a monoculture, which is liable to move slower than slowest of today’s major rendering engines.

It’s perfectly normal today to create CSS (and JS) in one browser and find it working flawlessly in another. 10 years ago, you would have called everyone over to your screen to have them witness this miracle.

I don't think CSS is any less logical... but some might not be use to _declarative_ languages like CSS is?

With CSS, you can't avoid hacks. If you try to design anything non-trivial, you will have to employ tricky non-semantic tricks, run into edge cases, and have to settle on ugly, non-optimal solutions.

I don't think it's a declarative vs imperative thing. It's more that CSS was designed to be easy to use and relatively terse for a specific, outdated use case (20+ years ago when a website page was thought as a 1 dimensional flow of text and pictures).

Nowadays our requirements encompass pretty much the full spectrum of 2D space design, yet we still use a language that builds on high level primitives designed for a narrow usecase.

New features like Flexbox and CSS Grid help with the layout part, but it's not enough.

Here's the thing though — most websites are still just a '1 dimensional flow of text and pictures'. They try to disguise it with multiple columns of guff, but it's still just text and images. Sometimes a video.

Sure there are web 'apps' now too, but most websites are not apps (thankfully).

The thing is, web apps are also just a more complex version of the same '1 dimensional flow of text and pictures,' just maybe with Canvas and a lot of javascript. There's no real difference between a web app and a document, as far as HTML/JS/CSS is concerned. The dirty secret of the whole "the web used to be documents but now it's applications" meme is that the applications are still documents.

Just... use the constructs you're familiar with? It's not like you can "accidentally" use an ES6 class or something.

You can know about for..in without knowing about hasOwnProp.

You can forget to enable strict mode.

The list goes on. Static analysis is universally a good thing.

I don't think it is caused by this aspect of CSS.

The problem could come from the fact that it mixes 2 purposes: style AND layout to apply it globally with rules that get harder to understand the bigger the project.

No, it really isn't.

Some languages are, JS definitely isn't. It's mostly illogical / broken / mental.

Even if it were an argument I'm not even sure it would be an argument worth having because it's likely entirely orthogonal given the context of the original statement (i.e. contrasting JS with CSS and HTML -- where whatever esoteric programming language you're thinking of is not an option to begin with).

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.

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.

I spent most of my frontend career in that world (and dabbling in Qt, SDL etc. for kicks), and now shifting to the web a couple years ago, it boggles my mind how horrible CSS feels compared to what I used to do with minimal scripting and a bunch of button clicking.

The design of CSS makes a whole lot more sense when you understand what problem it is designed to solve.

> CSS wasn't originally meant to do layouting

This is not correct. The first version (1.0) did not support advanced layouts but it was definitely in the cards. DSSSL was an inspiration and supported layout.

My point is just that CSS is designed like it is because it tries to solve some particular problems. If you expect it to work like a GUI toolkit (or DTP program) you will be confused because they do not try to solve the same problem.

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.

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.

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/

This 1000x. I was at a university that used Bootstrap in their Web Design class(!). And, predictably, it didn't work all that well. I spent some time tutoring one of the students and was amazed at the content they didn't cover. Not even modern things like Flexbox, but basic stuff like sibling/child selectors and the cascade.

No one takes CSS seriously. For most, CSS comes as an after thought. Build every part of the application then suddenly "Oh Right! CSS!" Slap bootstrap or other popular framework then don't think about it.

Yes, CSS is not a programming language like others but it is just as complex. It requires studying, practice and long exposure to become versed in it.

Note: you can google your way into using a couple jquery functions, but you can't become a competent JavaScript developer like that. The same goes for CSS.

It depends on the problem your trying to solve, if you just want something that looks decent (because you're a programmer and you don't notice things like colors, alignment and spacing) then something like bootstrap is a good go-to.

I still think learning CSS properly is worth it, using bootstrap without knowing CSS is like using an ORM without knowing SQL, but less dangerous.

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.

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.

I've been a frontend dev close to 5 years now, and recently I read the entire CSS spec front-to-back in scrutinizing detail for a project.

If the goal was really to decouple presentation and content then CSS has failed spectacularly. Having element selectors, attribute selectors, child and sibling selectors, very tightly couples the content with the layout. It also has the ability to affect content by inserting text nodes for example using the 'content' rule.

I'd say one big gotcha that trips up most people is not understanding when a style is valid or not. Certain styles are only valid for certain display types (see the CSS spec). Also look at the non-normative references on W3C for the default style sheet to see what default rules get applied to elements

To really fully keep content and presentation decoupled you have to stay away from those things and use something like css modules or similarly have a one-class-per-component rule.

Worth noting that the real separation of content from presentation is JSON-data + a CSS/HTML hybrid front-end, often implemented as an off-the-shelf display framework (Bootstrap etc).

Disagree. CSS media queries allow you to identify different media, just like uname(2) allows you to identify the platform you‘re running on. Handling all the aspect ratios, resolutions, capabilities, bugs, idiosyncracies of the current device or modus operandi is not at all trivial, especially if you don’t want to design for each situation from scratch.

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.

Here's a good resource for UX: https://goodui.org

And here is one for color theory: https://uxplanet.org/color-theory-brief-guide-for-designers-...

I think keeping UI components tiny and coupling the stylesheets with the component is the best way I've seen (not necessarily styled components, just styles in the same folder as the component.)

As the component is removed, its easy to nuke the stylesheet with surgically removing related styles and not breaking something else.

I feel the same. I fiddled with css on personal projects just fine, but in my job, diving into years of accumulated, imbricated classes is a nightmare and even though I try, 80% of the time I end up passing the problem to the design team.

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!

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.

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.

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.

Naturally also Web based ones since early 2000's.

Share the feeling, everything is so much easier in native toolkits.

There is some hope though thanks to Web Components and Houdini.

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

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

This is (still) a problem with OSes. Mobile improved the situation a bit but not really that much. I am now reluctant to install mobile apps since virtually every mobile app is a potential vector for who knows who to spy on me. Mobile apps are isolated enough that they're unlikely to trash the device but they still have huge security isolation problems.

TL;DR: endpoint OSes suck so the web won in spite of being a crappy UI platform.

I find it very unlikely that browser vendors will agree to have the same implementation across their own products, vested interests and all.

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.

That page was a godsend. It's one of my most accessed bookmarks :)

Shadow DOM and WebComponents to the rescue!

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

EDIT resources

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

So I tried to write one.

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.

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.

Step 1: On your container div...

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

Step 2: There is no step 2.

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.

.d-flex.align-items-center etc

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.

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/

Yeah, you're not a designer.

Note I'm not insulting you. :)

CSS is very much like magazine or print layout IMO. If you're not used to that, it won't gel well. If you think of layout from a design perspective and _not_ a programming perspective, it's really not that bad. The warts more come down to differing implementations across browsers, which has become far less of an issue in recent years.

I expect you'll get a very different response from the crowd here, though, so consider it my two cents. I've done much backend work (like yourself) but started in frontend, so I feel adept enough to work with CSS well when I need to. shrug

It just feels like a weird outlier to me - not freeform enough to fulfil the "design" role, not programmatic enough to fulfil the "developer" role.

Designing a catalog is similar to designing a SaaS tool.

Designing a magazine is similar to designing a marketing website.

Working with AdobeIndesign taught me the following things, that translated into web development:

(1) Importance of style guides (things like BEM, SMACSS, etc): If you don't lay these out upfront, your catalog becomes incredibly inconsistent and hard to manage (too many components everywhere).

(2) How to organize your SCSS files - it's actually almost the same way you do it in Adobe Indesign. There's a `base` folder for global layout styling (fonts), `components` folder for things like buttons, tables, etc.

(3) How to layout a webpage. In Indesign, you start with the header/footer usually in your masterpage layout. Then you design each page from top to bottom generally (for a catalog at least). The viewport is more or less the size of a single page. You can only fit so much content there.

(4) Font-types - Open indesign, dig through all 100+ font types and see what the differences are. Some can handle fractional fonts, others have support for narrow styling (Arial).

(5) Design combinations - Take a look at a Grainger or McMastercarr catalog. There's many tricks for cramming a lot of information on one page. Minimal font sizes, horizontal lines in tables, use of white-space eye relief, consistent styling, etc.

(6) Constraints - If you saddle-stitch or 3 punch bind your catalog, your margins differ. If you make brochures, it's like designing for mobile devices

(7) UX Interaction - There's many ways of looking at a page, and where you want to draw a user's attention first.

UX tools are still playing catchup to what Indesign has offered for years.

I would say CSS is different mindset in that there are more rules. And you have to usually handcode it yourself. It's "design" in the sense of knowing what colors to use, size of content, etc. "Development" in the sense of knowing how to use master-page layouts / component designs upfront.

I 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... [2] https://www.amazon.com/Design-Hackers-Reverse-Engineering-Be... [3] https://www.barnesandnoble.com/p/visual-grammar-christian-le...

I can't recommend him highly enough.

https://www.youtube.com/watch?v=gQ3NJGJY_F4

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/Sans-serif

https://en.m.wikipedia.org/wiki/Typography

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.

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.

Not only that but you are building a page that displays on all kinds of screen sizes so you just have no idea how much space there is between here and there. Thats 90% of what makes CSS hard because depending on what screen you are on, you can't just put something here because here doesn't exist for everyone.

I think CSS is designed fairly well its just that its solving a very complex problem of how do you make one page display on all kinds of devices without having to define layouts for them all.

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.

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…

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.

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.

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/

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

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?

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.

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

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.

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.

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.

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.

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/

[1] https://getbootstrap.com/docs/4.2/examples/

EDIT: downvotes? Why not mention why you don't like bootstrap and share with the larger thread? At least, then it is useful to everyone else.

When you consider UX, accessibility, progressive enhancement, cross browser and cross device support - there’s plenty to know. And unlike programming, it doesn’t all flow logically. Some stuff is subjective, other stuff requires specific knowledge of browser quirks etc.

The only site that helped me gain some _understanding_ of CSS (as opposed to knowledge, tricks and hacks) was this one http://learnlayout.com

It’s a bit dated now - Flexbox is mentioned at the end and CSS Grid is entirely absent - but still important if you’re supporting older browsers.

But CSS has never “clicked” for me. For a start the whole idea of cascade is based on inheritance and I generally prefer composition. I like designing UIs and it’s quite a satisfying challenge to match a wireframe to the pixel. But overall, I’d rather be writing application code.

If users could just read JSON everything would be a lot easier...

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.

- https://flexboxfroggy.com/

- http://cssgridgarden.com/

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

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

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.

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

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.

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.

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

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.

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.

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.

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

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

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.

This is actually pretty simple, once you understand how "block" elements work. Block elements will always try to fill up the "available width" i.e., they stretch side ways. The sum of margin + its width must match the total width.

Inline elements will fill up its parent block like text.

So, a simple example - suppose you set a div's width to 100px, and margin to auto, then you will a 100px wide box centered.

I see people get confused when they try to have a block that has an unspecified width and hope CSS just figures out.

I disagree -- in this and every case where someone has told me that something is simple once you understand the fundamentals. Understanding how a tool works is completely different from understanding how to use it to accomplish a particular goal. One's a deconstructive process, and the other is a constructive process.

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!

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

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

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

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.

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.

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"

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

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

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.

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.

There's a lot of complexity there.

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.

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.

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.

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>

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.

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

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!

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/