Hacker News new | past | comments | ask | show | jobs | submit login
Things I wish I’d known about CSS (cssfordesigners.com)
878 points by harshamv22 73 days ago | hide | past | favorite | 330 comments



It always helped me to do an absolute basic concepts course on a new technology I learn.

Like, sure I can play around in Photoshop or Eclipse or CSS or JavaScript and find most things.

But a good 101 course is worth so much saved time.

Most of the stuff in that article was mentioned in a CSS box model course I did 10 years ago.

People were always baffled how I learned all this. Well, I read the docs!

They always assume every one learned like them, by trying stuff out all of the time, until they got something working. Then they iterate from project to project, until they sorted out the bad ideas and kept the good ones. With that approach, learning CSS would probably have taken me 10 times as long.

Sure this doesn't teach you everything or makes you a pro in a week, but I always have the feeling people just cobble around for too long and should instead take at least a few days for a more structured learning approach.

What I didn't learn about CSS in a basic course and what cost me multiple weeks to fix, was `pointer-events: none`. Keep this in mind when your clicks stop working after you pulled some new CSS ;)


> I always have the feeling people just cobble around for too long and should instead take at least a few days for a more structured learning approach.

There are two kinds of documentation: there's a list of all the individual things you can do, and there's a "The fundamental abstraction is this". The second is rare, and rarely done correctly, and much more important.

A lot of people assume that X is like Y, but with Z, and they know Y, so they just need to learn about Z. A lot of time that isn't true, the fundamentals are different. The natural way do perform W in Y might be profoundly wrong in X. Examples:

* git is like subversion, but distributed.

* C++ is like C, but with classes.

* C++ is like Java, but you have to remember to delete stuff.

I love git. I love C++. I think these things are the bee's knees. They're so simple and elegant. But I totally understand how people think they're arcane eldritch horrors when you're holding the sword by the pointy end.


Exactly. Another fundamental abstraction they should have mentioned in the article is [the surprising way z-index actually works](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positio...), especially being aware of the existence of [stacking contexts](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positio...).


> there's a "The fundamental abstraction is this"

In most cases, I'd settle for "what problem this is trying to solve" (although this is obvious for CSS, it isn't nearly as obvious for things like React and Vue).


The problem here is that really understanding "what problem this is trying to solve" often requires a passing familiarity with cognitive science.

How many people here could explain the link between Working Memory and React.js?


New to JS world. Would love to know a brief explanation.


Can’t agree more. The first kind of doc is useful from time to time to check the correct argument of a function. The second one is about the big picture and the overall architecture. And sadly this is what is missing with every codebase I’ve worked on. In my project on the contrary, this is something I try to document.


If someone needs to read documentation for a few days in order to figure out which end of the sword to hold, perhaps the sword was just poorly designed and unintuitive.


So you want a dull sword with handles on both ends just so that nobody can possibly cut themselves? Professional tools are meant to be efficient for those trained in using them and if that means they are slightly harder to learn that's OK.


Cobbler here, currently cobbling a frontend (am a backend dev by trade).

The issue for me is the format these courses and resources take. CSS is the most jam packed with non-intuitive technology I've met. How many dozens of pages or segments of video would I have to go through in a course to learn what the author in OP summarised in two or three sentences? Any time I've considered the structured approach for something like CSS, the material drones on and on with technically correct explanations and example code, but somehow against the odds, almost nothing of substance.

Worse yet are the top google result reference resources. Look no further than the top result for "css grid" if you're in the mood to claw your brain from its stem, and flush it down the toilet.

Link: https://css-tricks.com/snippets/css/complete-guide-grid/

Behold, 8 zillion words and symbols across 7 trillion seemingly randomly organised boxes full of both all of the information, and simultaneously none of the information, about css grids.

Which brings me to where I am now, cobbling. It's more effective for me to cobble, than to spend an entire day figuring out css grids "the right way". If the going gets tough I'll just use some grid tool, or look up some sandbox examples, and be on my way.

If there was more material like the OP, and someone organised it well, well, I'd actually get around to learning it rather than cobbling. It's the best bit of writing I've ever seen on CSS. This is shocking. Not that there is anything wrong with the writing, but it's very, very simple. What on earth have all of the other CSS wizards with basic writing skills been doing? Confusing the issue, that's what.

Which leads me to a sort of meta frustration with learning CSS. I know it's not hard, I know that if someone just wrote about it even half decently it would take only a moment to digest each concept, but watching learner-disconnected authors create resources I can tell have lost sight of what it's like to learn, turns me off.


I had the same perspective on these frontend technologies as a backend/ops guy, and it all finally clicked when it came to me that I just couldn't find a justification for why CSS was the way it was.

This was solved trivially by just reading the history of CSS. It was shocking to finally have made clear all of the quirks and weird aspects of CSS that always made it difficult for me to connect the dots and feel myself lost in a messy tangled up language.

By far the best source I went through was found here: https://news.ycombinator.com/item?id=22215931 - it's a long read, but extremely enlightening!

https://www.w3.org/Style/CSS20/history.html was also useful.


This is a great comment. I expect it only applies to some folks depending on how they learn, but it resonates a lot with me.

I find it very difficult to learn the whats and hows of a new thing without the whys. I tend to construct mental frameworks of things, revising the inaccurate bits as I go, until theory starts meeting practice. (I always did poorly with math "teachers" whose method was, "doesn't matter, just do it." But it did take a while to realize that they were failing, not me.)

So when I encounter complicated, new things with a history, I usually try to start with at least a bit of the history.


This is so true. Though I'd been writing CSS long enough to remember Netscape 4.0 quirks, it wasn't until I learned some troff a couple years back that I had my moment of CSS enlightenment. The fundamental features are the same! CSS (and HTML) were (originally) made for pages of technical/academic writing, not creating user interfaces.


Couldn't agree more. I had less issues learning multiple programming languages,some challenging concepts around them and yet when it comes to CSS, most resources aren't very useful. You do something and it doesn't work. You check documentation and it show exactly the same thing that does work. 5 hours later it turns out it was some overriding property+ browser incompatibility+ weird undocumented exception. Very few books do deliver on their promise either. I don't know,maybe it's just me but the whole ecosystem is a bit weird.


" but the whole ecosystem is a bit weird."

It absolutely is.

The web was meant for static documents and some link magic.

Now allmost every complex programm can run in the browser with web technologies. And in the time between you had lots of powerful organisations with their own agenda, as well as millions of single developers with a agenda and a loud voice. How could a sane, clear spec be made, under these circumstances?

Besides, it would be very hard, to make a clean spec that satisfies the needs of the whole population. So by now I say, all in all, it works pretty good.


How could a sane, clear spec be made, under these circumstances?

Serious answer: By respecting and supporting the organisation that had for a long time codified realistic web standards reasonably well. When the Web was younger, you could (and many of us did) learn all you needed to know about things like HTML and CSS by reading the documentation produced by the W3C. In many cases, the official recommendations themselves (the documents that were informally called "web standards") were very readable and short enough for normal developers to go through the whole thing.


My experience with the W3C was very complicated written specs, with sometimes no connection to reality(implementation in the browsers). And they moved too slow.

And no. I don't think you can expect the whole world to wait for some spec commitee.


It wasn't that way in the earlier days. The W3C certainly made some questionable decisions later on that contributed to its slide into irrelevance, but it was Google flagrantly ignoring standardisation, absurdities like "living standards", and the way all of the other major browser developers were asleep at the wheel for years that really sealed the W3C's fate. And now, sadly, a new generation of web developers is about to learn the hard way why browser monopolies are a bad idea. :-(


> the whole ecosystem is a bit weird

The whole ecosystem reminds me of why I did not study synthetic biology or medicine. I prefer the systems I work with not to have evolved but to have been designed by some intelligence with a limited memory for random details.


> Behold, 8 zillion words and symbols across 7 trillion seemingly randomly organised boxes full of both all of the information, and simultaneously none of the information, about css grids.

It's interesting, because that's my go to resource for CSS Grid. I find it super handy when I forget something. Although, I'm not learning grid, I'm using it.


> Although, I'm not learning grid, I'm using it.

Precisely. What CSS-Tricks calls a guide is actually almost entirely a reference. It makes a tolerable reference if you already know what you’re looking for. It’s a poor reference if you don’t know what you’re looking for because it’s insufficiently structured and takes waaaaay too much scrolling to explore. (It used to be more manageable—it used to be more a guide. It has been allowed to grow far beyond a healthy point.) And it’s atrocious as a guide.


Reference books aren’t the same as textbooks.

And, typically, there are several levels of textbook. e.g. high school, then freshman physics, undergrad electrodynamics, then Jackson, then specialist references.

My point is you go over the subject completely several times, at increasing levels of sophistication.


Yes, web technology is overloaded, because of the history, backwards compatible stuff etc. pp.


Check out Tachyons or another atomic CSS system. It makes CSS so much easier to use (especially in single-page apps written in JavaScript). https://tachyons.io/ "Create fast loading, highly readable, and 100% responsive interfaces with as little css as possible."

See also: https://css-tricks.com/lets-define-exactly-atomic-css/ "Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function."

Or from: https://acss.io/ "CSS is a critical piece of the frontend toolkit, but it's hard to manage, especially in large projects. Styles are written in a global scope, which is narrowed through complex selectors. Specificity issues, redundancy, bloat, and maintenance can become a nightmare. And modular, component-based projects only add to the complexity. Atomic CSS enables you to style directly in your components, avoiding the headache of managing stylesheets. Most approaches to styling inside components rely on inline styles, which are limiting. Atomic CSS, like inline styles, offers single-purpose units of style, but applied via classes. This allows for the use of handy things such as media queries, contextual styling and pseudo-classes. The lower specificity of classes also allows for easier overrides. And the short, predictable classnames are highly reusable and compress well."

Mostly though, Atomic CSS is a state of mind or design pattern. So you can do it from scratch without support from something like Tachyons etc. -- but it helps.

You might even find it fits right in with your "cobbling" style of development. As an example, if you want to make some text red, you add the style "red" to it. If you want a border all around something, add a "ba" class. If you develop using HyperScript (like from Mithril) to define your UIs, code might look like this: h("div.red.ba", "This is red and has a border")

I refer to the Tachyons style sheet as essentially a menu of options: https://github.com/tachyons-css/tachyons/blob/master/css/tac...

In the rare case something is missing I do an inline style or add something to a single supplemental stylesheet written in a similar way.

There is also a verbose version of Tachyons without the abbreviations, so "ba" would be "border-all" (though I prefer the abbreviations): https://github.com/tachyons-css/tachyons-verbose/blob/master...


Your evaluation is problematic.

I am a front-end dev by trade and I could really easily say similar things about the tech stack you work with daily.

If you want a good reference and a learning guide start with this: https://developer.mozilla.org/en-US/docs/Web/CSS it is what us professional use.

For us professionals that use CSS in our jobs, that have put the same amount of hours into front end technology as you have done for back-end, CSS is a perfectly cromulent technology. It is easy to work with, it is intuitive, it is easy to find a good reference (go to MDN not random blog posts from people that are admittedly not masters of the craft).

If I try to cobble together a back-end I expect to be frustrated with it, I expect not to be able to do everything, I expect I’d need to find poor example and try to hammer them in to fit my needs, I don’t expect to be able to understand all the example snippets. Why are you on your high horse judging my tech stack this way?

If you need a good well crafted front-end for your project, you should hire a professional front-end developer. Or find a friend who is one that is willing to it in their spare time. Or spend a few thousand hours learning and mastering the craft. Alternatively you can cobble together a good-enough front-end that works, just don’t complain about how hard it is because “technology hard wheee wheee”. Us professionals use it every day and are fine with it.


"here I am, at the end of the maze, telling people at the beginning how straight forward it is" is basically all I'm getting here - and you call my eval problematic.

Multiple accounts of people not in your position telling you a problem exists. Ok, great, you worked through it. Doesn't mean it's as good as it should be.


Well you come across as an outsider telling us that the tools that we use—and do a fine job with—are no good, and that our literature sucks.

I am here to argue that this sort of attitude is problematic. If you browse through this thread you will find no shortage of comments describing how absolutely basic this article is (and a little void of insight, and a little out dated), and that there are people in the industry getting six figures while not knowing this stuff. Frankly it is a little insulting. And I think the attitude that you presented above is part of the problem. There definitely exists a lack of respect for the craft of front-end development within our industry. This sort of attitude is not helping.


> There definitely exists a lack of respect for the craft of front-end development within our industry. This sort of attitude is not helping.

There is xenophobia involved in people's attitudes toward kebabs. It doesn't change the impact of phosphates on the human body.

Here: https://www.bbc.co.uk/news/world-europe-42238363

Your argument doesn't change the impact of poorly-encapsulated complexity on the brains and mental health of your fellow programmers.

https://blog.codinghorror.com/programmers-and-chefs/

> Well you come across as an outsider telling us that the tools that we use—and do a fine job with—are no good, and that our literature sucks.

https://en.wikipedia.org/wiki/The_Jungle

---------

Backend programming has this problem too. So does systems programming. The problem of unencapsulated complexity is core to the craft of software engineering.

So is joining the fight against this problem. https://tonyarcieri.com/would-rust-have-prevented-heartbleed...


Or spend a few thousand hours learning and mastering the craft.

Surely the point is that you shouldn't need to spend thousands of hours "mastering" something like CSS? It's not that complicated and it's not that important. If you told a developer working on desktop or mobile applications that they'd need to spend years "mastering" the design tools in whatever GUI framework they were using before they'd be able to independently build a good user interface, you'd be ridiculed.

Anyone with the aptitude and interest to become a web developer, which isn't a particularly high bar as technologies go, should be able to get the hang of all the important parts of modern CSS in at most a week even starting from scratch. The fact that we don't reliably train new developers up that efficiently is a damning indictment of the current state of the industry.


100% agree. I found this to be a good guide: https://developer.mozilla.org/en-US/docs/Web/CSS

After spending a few hours reading up on topics I thought would be relevant, I find that I am significantly more productive with CSS. Instead of trying to find answers on google, I find that I’m better equipped to build things and diagnose issues on my own.


Once I got the basic concepts of CSS I came to realize that of the trio of HTML, CSS, and JS (and SVG for that matter), CSS is the one you really miss when you have to make something using another system.

The amount of suffering I've endured in Latex, PDF, different native layout systems, or even React Native's slightly restricted version of CSS that would have been resolved by a stylesheet is immense.


I totally agree. A good book that introduces CSS in a methodical perspective is a must. I personally cut my teeth on CSS with the book Web Design in a Nutshell, a 2006 book. I remember having written CSS in a haphazard try-and-see fashion before that, which utterly confused me, and then reading an actual book made everything clear. This is an investment worth making. Many years later I'm still almost always "the guy" on my team to go to when there's a weird CSS issue.


> A good book

One under-appreciated value that actual books have over online documentation is that you know immediately what order you're supposed to read them in.


I have tried both approaches a fair amount, and realized that every time I try the cobbler approach I end up getting blocked on some major thing and thus having to rewrite everything because of some basic things that could have been avoided.

I feel like it's getting both better and worse now with docs getting better in general(no of times I end up on stackoverflow has gone down significantly), however a lot of times I end up on medium posts with a list of steps and absolutely zero reason why. Whenever I try cobbling from those articles, I end up very frustrated


I completely relate. Other things I learnt "formally":

- regexps (this is a big one, being able to write a complex regexp without thinking about it is amazing)

- Git

- basic JS when it was mainly used to add snow on your page

Taking the time to properly learn things is extremely valuable.


I'm kinda curious how the long term viability of these strategies look. Intuitively I think that reading the docs will become less and less viable as there are more and more available technologies and they become more and more featured. But I'm not fully convinced. Maybe it can keep working by only teaching the most important subset.


Learning by course is generally good (rust book!), but "overlearning" certainly exists in all technologies. I've been hanging out in freenode's ##learnpython for years helping noobs, and I can't count how many times I've met the scenario of a new programmer working their way methodically and studiously through a 2k page book, stuck on page 1643, because they haven't actually grasped concepts from page 20. They'll be all kinds of worried about how to correctly use slots and metaclasses, when they can't write even basic functions.

CSS suffers massively from this info overload.

What I tell every new programmer who will listen, is that they should first grasp the absolute basic building blocks, and then learn to read the docs. That's really all you need. Unless the particular language or technology their are using sucks, you can essentially compose anything from the basics. Once you've done that, the sortcuts and sugar you learn naturally actually make sense, rather than appear before you as spooky magic boxes and incantations.

My ideal CSS course would just be the absolute basics of syntax and concepts, a primer on understanding and incorporating information from the docs, and then an index of well organised resources, such as the OP's.

This way, it's impossible to overload, and I'm left in a state where I can expand at my own personal rate. Anything that tries to set the pace for you is going to be suboptimal for 99% of readers.

Furthermore, anything that flows easily and without extremely explicit DO NOT PASS GO UNTIL YOU ARE EXCELLENT AT THE LAST CHAPTER, will lead to overload. You can't overload if you don't provide the information one can overload with. Simply ending your course after the basics and docs, absolutely guarantees against this problem. "Leave the learner in a known good state", would be my rule of thumb.


There is a learning method that hasn't been mentioned in this thread. Namely, a middle ground between pure cobbling and pure theory. In addition, you have to find a method that is optimal to you.

For myself, that's a feedback loop where bugs during cobbling naturally present themselves as theory questions needing an answer, rather than practical questions needing a solution.

It is rare to find documentation of such high quality that grasping the fundamental abstraction does not require theory-attentive debugging.


After spending years learning on the job, I started reading the documentation books cover to cover, and I have never looked back. Colleagues are often amazed at my "deep knowledge" of the technologies I use, however I mostly know what is written in the manual. It baffles me that people can't be bothered to read the documentation and at the same time complain that "X is too hard! Let's use Y instead!"


Same here. I tried finding a book about deb and rpm packaging the other day and couldn't find one. Left me feeling anxious.


There's a reason RTFM was so prevalent, and we need to make it so, again.


I built my first site in the 90's too (before CSS)! I've been in higher education lately, but have a YouTube channel with mostly CSS related content (both beginner & advanced). Check that out if you're interested in some great starter learning content for CSS and you prefer video format: https://www.youtube.com/followandrew


For me personally, documentation was just a step one, helping me to discover that some feature exists, what options are, etc. - and then "cobbling around", as you said, was the very important 2nd step where I'd really understand how something works and what's the best way to apply it in real life. Everyone learns differently, I guess...


Meanwhile, this is, oh so damn outdated. (I'm not kidding)

Most people don't know that the flow model totally changed meanwhile, and something like "display: inline-block" actually means "display: inline flow-root", everything that came after flexbox kind of had an influence to the meanwhile borderline insane display model as a result.

Everything related to inset, margin and padding has gotten an overhaul that is ready for ltr and rtl content where they switch x/y flow based on "direction: ltr (or) rtl" whereas e.g. "margin-inline" and "margin-block" are the newer properties for the updated margin.

A lot of stuff has changed for the better, too.

CSS transforms are now specified in a cleaner way, with a predictable way to render them (e.g. translate rotate will not be different than rotate translate). So all CSS transforms have gotten their own properties like "rotate: 90deg" or "scale: 1.23".

I learned a lot when I read through the actual CSS specifications, because I am implementing my own parser (for my Browser [1] project).

Also, did you know that @media, @supports and @viewport queries can be nested in any order? The media queries 4 [2] spec is kind of insane from an implementor's view.

[1] https://github.com/cookiengineer/stealth and https://github.com/cookiengineer/stealth/blob/X0/FEATURES.md

[2] https://www.w3.org/TR/mediaqueries-4/


I'm a layout implementor for Planimeter's Grid Engine. Implementing a naive subset of the algorithm for calculating the box sizes in the visual formatting model and calculating layout for normal flow, relative positioning, and absolute positioning is far easier to implement than flexbox.[1] There's nothing insane about this. And you'll learn even more when trying to draw to the screen.

Normal flow also doesn't require multiple passes, whereas flexbox does.[2] Even Yoga doesn't implement a conforming model.[3] I'd even speculate that flexbox performs slower than the standard visual formatting model just because of the differences in the algorithm.

Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.[4]

[1]: https://github.com/Planimeter/grid-sdk/blob/master/engine/cl... [2]: https://www.w3.org/TR/css-flexbox-1/#resolve-flexible-length... [3]: https://github.com/facebook/yoga/blob/master/yoga/Yoga.cpp#L... [4]: https://docs.microsoft.com/en-us/dotnet/framework/winforms/a...


> Implementing a naive subset of the algorithm

... and suddenly, a wild "overflow" and "text-overflow" appeared.

> Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.

What I meant is that the CSS specification for the new CSS transforms Level 2 has a fixed transformation matrix and order in which the properties are applied - whereas legacy "transform: rotate() scale() translate() ..." did not do this, and therefore was overly complicated.

In the new specification the transform order does not matter, because the order in which "translate: ...", "rotate: ...", "scale: ..." and "offset: ..." are applied is specified and cannot be changed. See [1]

PS: I'm talking about CSS transforms level 2, not level 1. I assume you are talking about level 1. "translate: 13% 37%" is a property whereas "transform: translate(13%, 37%)" was the legacy method.

Personally, I prefer CSS transforms level 2, because they are implementable in an easy manner. Having to write a complex compositor isn't an easy task, especially on mobile.

[1] https://drafts.csswg.org/css-transforms-2/#ctm


Overflow is easy enough to deal with, text-overflow requires more work because it actually requires you have a model that matches the W3C specification understanding of generating boxes, instead of matching elements 1:1 which is what most naive implementations do. The same can be said about the white-space property.

Both are easy to implement; in one version, you parse then push the exact order of the parsed statements to matrix transformations. In level 2, you coerce them into the standardized order.

That being said, if you wanted to do anything based off of developer-specified transforms, you have to use level 1's style of applying the transformations. I would expect that GSAP and other such libraries rely on this behavior. Anyone familiar with shader-based transform code will be thinking in this manner anyway.

I'm not sure why anyone would want to use the level 2 manner of specifying transforms if you know what you're doing, because presumably, you immediately lose the ability to push additional transforms to the transform stack.


What are your thoughts on CSS Grid? Does it require multiple passes?


If the question is about layout computation then CSS Grid layout (and ideally <table> layout) is a typical LP task [1].

And there are known way of solving these things, e.g. simplex methods or Cassowary constraint solver (CCS)[2] will work.

In fact flexbox layout is a particular case of LP task and also can be solved by CCS efficiently.

[1] https://en.wikipedia.org/wiki/Linear_programming [2] https://en.wikipedia.org/wiki/Cassowary_(software)


I have not made any website or UI designs which require it, so I'm not experienced enough with it to say. As a result, I also have not made attempts to implement it.

c-smile is a well known implementor in the space, and his comments are valuable as well.


This was a great article and I learned a few new tricks.

I learned CSS over the years by gradually solving problems I encountered building apps. Compare this to people learning CSS now as evidenced by the #100DaysOfCode tag on Twitter. The learning technique is comprised primarily of using gradient-heavy, absolutely positioned HTML elements to create a photo-realistic, 3D rendering of objects.

The results are pretty amazing, but I have my doubts about whether these skills are easily translatable for building an interactive, responsive UI. Some examples:

https://twitter.com/bauervadim/status/1282264611912327169

https://twitter.com/mercyoncode/status/1282449080132804609

https://twitter.com/ellie_html/status/1276177277315932161

https://twitter.com/thecoffeejesus/status/128204582508278169...

https://twitter.com/alyd789/status/1271200537988431873


I learnt CSS in a similar way. I'd take Photoshop designs and try to recreate them in vanilla HTML + CSS:

https://jsfiddle.net/umaar/YNA5V/

https://jsfiddle.net/umaar/fu4TT/

I'd even make 3d graphics of things like the HTML5 logo: https://i.imgur.com/kuEYpSV.png

I posted this all to a community called "Forrst" (think of it like twitter, but curated for developers and designers).

I spent time giving feedback on other peoples work, I tried to ask insightful questions https://twitter.com/umaar/status/823915022917271552 to have an open discussion, I spent hours replying to comments every few days.

Then one day, Forrst got acquired by Zurb https://zurb.com/blog/zurb-acquires-forrst and later on it got shut down, and with that, I lost access to huge amounts of my work which I hadn't stored anywhere else (some stuff has been archived online, but not everything).

When it comes to web development tips, I now self-host on my own website and it's a really good feeling knowing that it'll be preserved: https://umaar.com/dev-tips/


I like what you have done with the site — very simple and easy to check out the tips. I subscribed.


Hey thanks for that appreciate it. Yes not spending time on fancy things/random enhancements let's me actually focus on creating new content.


I like that you'e carved out a space for yourself -- one that cannot just disappear due to an acquisition followed by a "pivot".

Thank you for making and sharing!


Some pseudo elements, a gradient and some transforms and you can do some really cool stuff. Highly recommend learning how to use these effectively:

https://developer.mozilla.org/en-US/docs/Web/CSS/background-...

https://developer.mozilla.org/en-US/docs/Web/CSS/transform-o...


A lot of people make games or fun projects for #100DaysOfCode when their job might be updating a CRUD MVC app using Y framework. I think as long as it puts them in the "coding" mindset it's worthwhile.


I agree with that 100% — if it isn't fun, it's work. And if you build enough knowledge about how CSS works in general, when it comes to implementing specific layout or responsive design techniques you have a good understanding of the basics to build upon.


I looked at the one with glass and lemon and I want to cry. It's just crazy how much some people push things. I wonder how long it took though..


I believe that focal point of CSS understanding is that horrible display property. People just need to get that one as other stuff is relatively trivial.

display:xxx on some elements defines three things ( sorry, that is terrible architectural mistake authors of CSS have made initially )

1. display defines "sibling requirement" how that element wants to be replaced among its neighbors. `div {display:inline-box}` tells container to treat that div a single glyph placed inline among other glyphs.

2. In some cases it also defines "layout manager" of element's content. E.g. display:table and display:inline-table tells the renderer that content shall be treated as table having tbody , rows, cells, etc. Same thing for display:flexbox, grid, etc.

3. In some cases it defines other things like display:none; display:list-item; Note: there is still no display:inline-list-item ...

Ideally we should have these instead:

1. display: inline | block; - and just these two.

2. flow: auto | text | table | vertical | horizontal | grid...; - defines layout manager of element's content.

3. visibility: visible | hidden | none; - Note: visibility:none instead of display: none;


Don’t forget `display: contents` in which the element is instructed not to generate a box at all (neither inline nor block; I guess like `display: none` without hiding the content).

But I think the spec maintainers are aware of this and CSS Display Module 3[1] allows multi-keywords so you can do stuff like:

    display: block grid;
or:

    display: run-in ruby;
or even:

    display: inline flow-root list-item;
1: https://drafts.csswg.org/css-display/#the-display-properties


That is not a fix - just a cosmetic change that does not solve anything.

display/flow MUST BE [1] different properties as they define orthogonal concepts.

We should be able to define them separately.

   main { display: block;  flow:grid; }

   @media handheld and (width < 100mm) {
     main { flow:vertical; }
   }
Yet none from display shall go to visibility:none (as in my Sciter [2]).

I've seen too many times errors like this:

   main table { display:none; } 
   main.full table { display:block; } 
Which is obviously wrong, <table> element should have display:table or display:inline-table;

[1] https://tools.ietf.org/html/rfc2119 [2] https://sciter.com


You can define those inisde/outside display styles separately, like `display: inline grid` or `display: block flex`


I find your comment about `display: inline | block;` interesting, because when implementing the visual formatting model layout algorithm, these are the first two you'd want to implement, and they're the easiest.

In my game engine, we only support these two display types from the specification.


Yikes. I've been earning 6 figures as of about two years ago doing mostly HTML and CSS UI design for a bank. And I still did not know about many of these! I guess they are things I wish I'd known about CSS! Better late than never I guess.


Six figures? In the US?

Sometimes I wonder why companies even pay developers so much in the US. I'm a specialised medical embedded software developer in the UK and I'm not even halfway to six figures, and will likely never hit it.

It astounds me that companies don't hire twice as many non-US developers for the same price and get more work for their money. Note, I'm not talking about outsourcing to the absolute cheapest bottom of the barrel developers who cost 1/20 of the price and the quality reflects the price. Just equally skilled developers in non-US countries.


For context: I'm an American who's currently working as a software engineer in France (for a French company).

I agree that engineering salaries are much higher in the US than in Europe and other non-US countries, however it's worth considering that there are additional expenses to hiring in other countries. My french salary is ~30-40% lower than I was making in the US. However, my cost to my employer is nearly as high. Employer taxes are much higher, my company is required to reimburse my transit and all-but-obligated to cover lunch as well. Certainly, many US software companies do some/all of that, but not all.

And beyond those pure costs, there are more liabilities to the employer. For instance, if they want to fire me, they're legally on the hook for four months of severance. And, I get ~7 weeks of combined vacation time and "comp time" (based on the fact that I work more than 35 hours a week). In the US, I got 2-3 weeks.

I don't have exact numbers, and I don't disagree that there are potentially savings to be had, but I don't think it's nearly as clear cut that you could get anything close to twice as many developers.


Here is an official simulator for France: https://mon-entreprise.fr/simulateurs/salaire-brut-net

It's not 100% accurate (the exact amounts depend on many variables) but gives a good idea. For example, a cost to the employer of USD 100k (87460€/year) gives a before-taxes salary of USD 70.5k, and a salary after all taxes of USD 47k.


> before-taxes salary of USD 70.5k, and a salary after all taxes of USD 47k.

What!? That's over 30% of your income gone, and for a relatively average income. That's not even counting VAT and other taxes.... No wonder there's so much "free" stuff in Europe.


€61k before taxes isn't really a relatively average income in France. A junior engineer (with a Masters) starts around €35k ($40k) before-taxes. Country-wide median salary is €28k ($32k). But across all those salaries it doesn't change the fact that around 45~55% of the employer's cost isn't going to the employee.

And yes, taxes and cotisations are very high. On the other hand they cover most higher costs and risks in life (education, health, basic retirement…).


Isn't $70.5k USD around €61k EUR?


You're right, I mixed up. I edit it.

Still, €61k isn't an average salary. An engineer reaches that after about 10-15 years (from personal experience and some statistics I have access to). It's double the national median.


Wow, that's just crazy to me. It makes sense with the much stronger safety net, it's just a shock.

How does rent and food costs compare to America, do you know?


Even with the stronger safety net, it doesn't make up for the difference compared to the US for well-paid employees (such as engineers, or tech in general). US employees are much more well-off, there's no denying that. US levels for engineers compare more to Swiss level of living.

However the safety net is much more beneficial for less-paid people, at a relatively low cost for them.

I only visited the US so others might be able to provide a more detailed comparison. It seems to me that rent is generally significantly higher in US cities (might be different in lower CoL areas), and groceries and other smaller budgets were slightly higher in France (restaurants, tech purchases, cars…).


I have worked in the US and Europe, and may give a direct comparison.

US healthcare and education consume a vast portion of your pay. We paid cash for our daughter's college (biomedical engineering) at a total of over $300K. That buys her freedom of choice when it comes time to take a job, get an advanced degree, etc. Her colleagues will have more than $500K USD debt hanging over their heads when you factor interest payments.

The company pays for a portion of health insurance, but much of the cost is picked up by the employee, either though co-payments or deductibles.

We live modestly, drive low-end cars and don't dine out often. We see our European friends taking great vacations and their children bounce in and out of college programs. We see free healthcare, mountain cottages, and other perks unavailable to us.


Interesting, thank you. It seems the calculation becomes very different when you factor in the cost of a child (especially if he goes to college).


Without going into numbers all I can say about US vs Europe: for people with low income,Europe is much much better. For middle class, it boils down to some difficult choices( kids, education, leisure) and is probably equal. While upper middle class or highly paid professionals have it better in the US.


I'm in Scotland, my salary is about £45-£48k. I take home about £31k.

The median salary here is about £21k nationwide.

I bought my home for £170k, now worth about £230k. it's a decent sized apartment in a nice area in the city where I work. For an indication of size, my living room is about 23ft by 28ft, 2 bedrooms, 2 bathrooms.

Some photos to show what I got for my money:

https://imgur.com/gallery/6oNLRtl

My outgoings each month average out to around £1200k. Mortgage is under £450 a month.

Healthcare is all free, university is free, prescriptions are free.


This is a nice looking apartment!

Some perspective on the costs that look "scary" for the people outside of the USA. I'll share some personal data based on my 20 years since moving here. I have started with $60K and now I am making close to $250K. All this time I was living in a median cost area (one of the top 20 US cities, east coast).

My average effective tax rate over the last 20 years is 19.6% (this includes federal, state, social security and medicare taxes)

My average medical expenses for a family of four are at 3.6% of my gross salary (includes health/rx/dental/vision insurance premiums and out of pocket expenses)

I've paid cash for my oldest child's education at top 10 public university - ~1.5% of my earning over the last 20 years. I am expecting to pay similar cash amount for my other child.

We live in a 4000 sqft McMansion near the best public schools in the state. My mortgage is ~$820 at 2.5% APR

It does look like your effective tax rate is 31-35%, which is more than my all-inclusive rate of ~24.7%


Did you have a large down payment? That looks like a small monthly cost for such mortgage. Or maybe the interest on such loan in Scotland is very small.


My down payment was £70k, interest rate is 2.14%

When I renew at end of year it shoul be around 1.1%


Well damn, I don't think there is anything below 3.00% (3.50% more common) where I live.

That's nominal - 3.5% - 4.0% is the effective interest rate. I don't know much about mortgages, so not sure if I'm missing something. Congrats on your place - it looks great!


Is that right? I think inflation makes the effective interest rate lower than the nominal rate.

You could imagine that inflation pays ~1% of your mortgage for you because each dollar that you owe is becoming less and less valuable.


Effective interest rate is, to my understanding, not related to inflation. It's just a way to make loans with various compounding periods easily comparable (I'm mostly citing this from Wikipedia, I'm far from expert here: https://en.wikipedia.org/wiki/Effective_interest_rate )

I just mentioned it for the sake of providing more information to whomever was reading my comment.


You're right, I confused effective and real rates.

https://www.investopedia.com/articles/investing/082113/under...


For fun, here are the figures for Croatia (yearly take-home salary and total cost for employer, all in USD for easier comparison):

Average salary (take-home): $11874

Average salary (total cost for employer): $19875

Median salary (take-home): $10225

Median salary (total cost for employer): $16526

Starting junior dev salary (take-home): $14800

Starting junior dev salary (total cost for employer): $25800

Senior dev salary (they can go higher, but that's relatively rare for local employers) (take-home): $27700

Senior dev salary (total cost for employer): $52000

VAT is 25%. Safety net is a joke. Health care is universal, but not that good. Education is mediocre at best.


Notably, I doubt you could get family healthcare coverage in the US that reduced your financial risk as much as France’s does for under $25,000/yr. Even at that rate I bet your exposure’s still worse.


> I doubt you could get family healthcare coverage in the US that reduced your financial risk as much as France’s does for under $25,000/yr.

I'm not so sure. It looks like the average liability for a family (12 monthly premiums plus deductable) comes in at just under $23k[1]. That's the max the average family would pay. Obviously for just a single person total liability is a lot lower.

So for a person like me who makes good money being an engineer, I am still better off in America where I can make a lot of money but also pay a little more in COL / healthcare stuff.

[1] https://www.ehealthinsurance.com/resources/individual-and-fa...


Wow, that’s... much cheaper than I’ve seen. In my non-coastal middling-wealth state, you’re looking at $1500/m for an HSA family plan that still leaves you with tens of thousands in risk per year, and reducing that risk gets expensive fast (often it’s even worse, and you end up guaranteed to pay more per year than you might pay if something goes wrong under one of the cheaper plans)


The US salaries in IT are huge, but you need to take into account that they have to pay a lot to have a quality of life comparable to what a minimum wage worker is getting in west Europe.

If you have a few kids, I would bet you are not that bad in UK with one fewer digit.


Yes, This is the main difference. In Germany the education is free and medical insurance not something to worry about ( I have no idea about what deductables, deletables etc mean). This is where the difference lies.


As simple rule of thumb an employer in the EU has to pay roughly double the net salary amount, so on top of the salary pocketed by the employee yet another similar amount goes to taxes. The education/insurance aren't "free", they're just managed better and give more direct benefits to the taxpayer.


It depends. When I was a student, I did not have to spend a penny on medical biils, my wife got paid by the government for some courses (+ cost of rent etc) that would have costed us around 20K € at that time. Now that we are earning enough, I have no problem in paying back, so that others who need it will be also be able to achieve their dreams.


Deductable is a scary word but a simple concept, it represents the amount of money you must pay before your insurance begins to pay bills for you :)


That is scary. When my child had to stay in the hospital for a month, the main costs for me were the parking tickets.


I know the difference to the cost of living in the US in silicon valley, of course not everyone lives in areas like that.

But I'm talking from the employer side, not the employee and why they would employ US devs who cost twice as much


The employer pays roughly the same amount. It's just that the employee sees much less in Europe due to all the taxes.


In the United States, you can spend 6k on health insurance and 12k out of pocket for unlimited family health care.

So as long as a US job pays 18k more, it's pretty similar.

People talk about vacation, but my job pays so much I'll take months off between contracts. (Engineering)

Also it's hard to compare lifestyles in the US vs Europe. Homes in the US are gigantic, often newish, and have Air Conditioning. Cars in the United States are more feature rich and have higher safety standards (when I was an airbag engineer in 2015)


I'm sure in terms of money, working in the US as an IT person is a good deal.

But you have to think not only about you but also the others. I don't know whether you have children or grandchildren , but if you do I'm sure knowing that they will never have a bad situation is pretty nice. You can't expect all your children and grandchildren to have a well paid job and you can't finance all of them forever.


Workforce mobility means people can always move for a system that makes more sense for them. If grandpa was a good IT engineer and made some nice money in US, but the grandchild is the village idiot then moving to Germany or France is a solution. Germany has an open door policy to foreigners (there are millions of Turkish descendants of "guest workers" invited after WW2 for reconstruction), East Europeans and now "refugees" from all over Middle East and Africa. No idea how immigration works in France, but there are huge Magrebian communities and lots of other foreigners as well, so I think it is doable.


Well if your child can't make it in USA, s•he will not make it in Europe either. You can't just land in France and become a citizen without a job.

But do you want your child to immigrate because you live in a country of selfish people? I'm sure you would find the situation difficult.

By the way, the communities you are mentioning in France are French since a few generations and not foreigners.


One can live in Western Europe on welfare. Most of my colleagues in France are not born in France, they are foreigners. The trend is growing in Germany too, in our department there is no German in Germany but people from Brazil, India or Eastern Europe.


> In the United States, you can spend 6k on health insurance and 12k out of pocket for unlimited family health care.

Where? How? I... this total is about what I’m seeing for shit-tier covers-nothing insurance. Like, there are plans out there that are HCA non-conforming and not that far under $18k/year just for the premiums. Who do I talk to to get total max healthcare spending of $18,000 without an employer-provided plan, in the US? Who’s offering $12,000 annual max-out-of-pocket family plans for $500/m?


Just ran some rates in my area for an EPO with reasonable copays and zero co-insurance:

$3,600/yr individual, $0 deductible, 8k OOPL

$9,600/yr self + spouse + kid, $0 deductible, 16K OOPL

$12,000/yr self + spouse + 2 kids, $0 deductible, 16K OOPL

Although I don't really think it makes sense to compare costs based on OOPLs. For most people, the deductibles, coinsurance, and copays are much more relevant to actual costs.


> Sometimes I wonder why companies even pay developers so much in the US.

Presenteeism.

The office "has to" be in Silicon Valley. The employees "have to" be in that office, in an open plan, so the manager can physically see them working. Therefore they have to be paid huge wages to compete against the other employers doing the same.


[flagged]


When they are taxed to death on lower base wager, it is expected some to be apathetic. The saying is "they pretend to pay us, we pretend to work".


Sometimes I wonder why companies even pay developers so much in the US.

It boils down to real estate prices combined with some companies really really really wanting those people to be on site.

I had my highest rate ever during a brief, beautiful moment in Switzerland where a studio apartment costs ~$2000 per month.

I choose to think that this rate is how much our work is actually worth - otherwise those companies couldn't afford having people on site.


This is a catch 22, high wages make the rent increase (demand and offer) and high rents demand high salaries, it's a spiral going to a bubble.


Housing supply is the variable that can act as a release valve. If cities don't want to expand vertically, that's fine, but they'll inevitably end up in a Bay Area type rent spiral.

I think the real issue is that homeowners vote so much more frequently than renters (who would love to have more housing and lower rents), even though they're technically outnumbered.


Indeed, but eventually a ceiling is reached over which it would be impossible to make a profit having on-site employees.

I don't envy the locals though. I spent 2,5 months in Zurich, during which I saved so much that in pre-corona times it would be enough for the minimal allowed down payment for an apartment.

The Swiss don't have a Switzerland of Switzerland where they could pull off the same trick.


That is going to happen. Big corporations are finally waking up to 1st class remote work, and that’s the gateway to lower US wages. I say this as a remote worker, and a huge fan of remote work. But I do think the high US salaries are going to mean revert a bit.


Sounds to me like tech workers in the US should join a union, and quick!


Now, admittedly I'm a skeptic of unions by default (in my view they're mostly just another layer of bureaucracy/waste), but isn't unionization of tech workers in the US the quickest way to make themselves even less desirable?

Why hire a US union member when you can hire an Eastern European who both works for peanuts and doesn't have union hang-ups? (Admittedly outsourcing has its own problems, especially when there are language/cultural barriers)


EU has very strong employee rights, so that will come to the same point as a union in the US. The lower pay is an advantage but the time zone difference of 8-12 hours can be a disadvantage. There are no language barriers in IT between the US and Europe, by the time they graduate college the average European has gone through more than a decade of English courses. Cultural differences are minor, management style is very similar (in the East) and so is the communication culture.

So yes, lots of American companies already outsource to East Europe. There are lots of "Silicon Valley"s across EE thriving on Western outsourcing from companies who aren't quite desperate or cheap enough to go to India.


There are some phenomenal outsourced shops in EE. Those that do pay 2-4 higher the going rate in the country. These aren't wordpress sweatshops. These are usually small teams and people work on interesting,specialised projects. Management style is usually very pragmatic ( a means a and let's cut the crap) .But the best part about these is that people do get exposed to things,build experience and eventually start on their own. 10-15 years ago there was hardly any product driven company in my country.Now the ones most worth working for do have successful software product that are sold in western markets.


There is probably more to the story here. If you’re only at about 50k, you’re making $24 an hour. There’s even cheaper labor than you. It’s going to be a disgusting race to the bottom if we start paying everyone 20, 18, 15 ... dollars an hour.

At this point in my life you would have to pay me around six figures for me to do CSS seriously on a daily basis (and it’s likely I’ll still burn out and leave). The cross browser and device testing alone is so tedious and stress inducing that I simply won’t do the job below a certain price point (or I will out of desperation but definitely will bounce ASAP). The unsaid thing about doing heavy CSS work is that it doubles as a QA job from all the testing required.

And again, I’m someone that’s good at it. You can’t pay me enough to do it, not if I have choices.


If you think CSS is tedious, then you've never dealt with medical device regulations. cross browser testing will seem like an absolute breeze. If a UK employer were paying £90k for CSS, absolutely everybody and their dog would be applying for a job that pays double a typical dev salary.

I think we've already experienced the race to the bottom and come out the other side, with $24 being fairly average for the world and the US being on the high side. This all happened years bacj when companies started outsourcing development and IT to India at rock bottom prices, but then received a lot of low-quality work (you get what you pay for). I believe India has a much different approach to software quality than many other countries.

It's taken many companies years to realise that mistake, but I wouldn't call $24 a race to the bottom for skilled labour as that will land you comfortably above average income in the UK


Should we go lower than 24 dollars? Sincere question.

If not, never ever show bitterness for your fellowship that brought honor to the profession, wherever they are.

I hope never to see developers disrespected that way, anywhere in the world.


There's a whole world outside SF in the US where people do make ~$24/hr. It is well above the median salary in the US. Things may be closer to equilibrium than a lot of people think. I used to work for an outsourcing company that was roughly 50-50 people in the US and in India, and there was never any indication that the US people would be fired en masse, probably because they were somewhat more productive, and somewhat higher paid, and the differences weren't huge.


I think the important bit of info is that they work for a bank, not that they write CSS.

If I look at the equivalent compensation for people who work for me, the vast majority of developers in the UK and US earn > $100k. Like for like the US employees earn more but that's almost wholly swallowed up in other costs (basically healthcare and our US healthcare plan isn't particularly bad).

And the FAANGs and hedge funds, in my experience, have a reasonably similar dynamic.

The simple fact is that we generally don't hire for PL knowledge except in very specific circumstances (KDB for example). If all we wanted was a coder, there are much more cost effective options than hiring someone, regardless of location.


1. Why do you think UK software companies aren't more successful compared to American ones. Aren't they saving tons on development costs? 2. Have you considered that you are terribly underpaid?


Serious questions.

Which countries would you suggest for this?

Just the UK?


The only European countries where costs are as high as the US for tech salaries are basically Switzerland and Norway. In the rest of Europe you have access to a very qualified workforce for less money. But they also have more protection than in the US (fewer unpaid hours, more holidays, no cheap dismissal…).


All Europe?


I think (hope, really) that gp is just one heavy "/s". The knowledge presented in the article is so basic that it is hard to believe that a person who does html for two years and six figures doesn't know these. As for the article, I fail to see any reason for it to exist beyond cheap media presence. Or maybe I should start a blog, because I'm not even halfway too.


I've done CSS since 1999, none of this was new to me, and I've never earned 6 figures for doing HTML and CSS. I moved my career away from HTML/CSS in order to earn more.


I think we picked up a lot more of the basics back in the days because doing CSS was much less forgiving than it is now. And the whole struggle with pixel perfect between browsers just forced you to spend hours on these tiny things.


I was also waaay more limited. All those clever hacks to get equal height columns, "sliding doors", workarounds for IE5/6/7…


Yep, for sure! It was a fun ride but I'm happy it's over, though I don't enjoy CSS the same these days. Could be age and all that, who knows.


Same here (but started in 2000), except I didn't know about the ch unit. OP likely has some great soft skills and negotiation prowess.


I've never been happy with a front-end dev that I've paid six-figures to.

I once paid a senior front-end engineer far too much to do a fairly involved layout. Three months, an uncountable number of bugs, and one unusable tangle of Sass later I pulled the plug and swore off ever hiring a "CSS Person" again.

I took the Linus+Git approach and said "I'm not writing another line of Python until I understand CSS." After a few weeks of study (I read CSS: The Definitive Guide cover-to-cover) I was able to implement the layout in, and I'm not exaggerating, two hours. No bugs, responsive, cross browser support, etc. Flat out done.

I went back to the dev and asked why they tried to implement it with over a thousand lines of Sass using Flexbox over a few lines with CSS Grid.

It went like this:

Me: "Hey, why did you choose Flexbox over CSS Grid for feature XYZ?"

Senior Front-End Dev (SFED): "I used a grid. Bootstrap's grid."

Me: "No, CSS Grid"

SFED: "Like the 'display: grid' thing? I don't know how that works."

I've never met a CSS Person who has read a book on CSS. Or one that can do the arithmetic on a simple flex-grow/flex-shrink/flex-basis combo.. Even with a cheat sheet.

I'm a back-end dev, I used to think that CSS was "garbage". After learning the ins and outs I think it's a pretty remarkable set of technologies. A true discipline. But, it's hard to find someone who really understands it because it sits at a weird level in the tech stack. Most developers feel it's beneath them or that they "have the gist of it" and most CSS specialists don't have a firm grip on it or keep up with browser developments.

If you're going to work with, hire, or exist as a "CSS Person" within 6-feet of me I'm going to require you to read "CSS: The Definitive Guide" before I give your laptop charger back to you.

This article is good, but it's barely the bare minimum that you need to know about not knowing CSS.

Six-figures for a "CSS Person" who's read CSS:TDG is completely worth it.

CSS and Sass are both worth mastering.

For CSS read: "CSS: The Definitive Guide" (https://www.amazon.com/CSS-Definitive-Guide-Visual-Presentat...)

For Sass read: "Pragmatic Guide to Sass 3" (https://www.amazon.com/Pragmatic-Guide-Sass-Modern-Style/dp/...)


I too have worked with many front-end developers that were book and spec averse who preferred to gather lore from various gurus in three paragraph blurbs.


You seem to be trivializing css as something static you just have to deal with. This maybe true for 99% of websites but css has had more innovation in the last few years than anything else. And much of it hasn’t reached textbooks. For example css3 functions and now being able to mix these new techniques in undiscovered ways. CSS requires a very nimble and creative mindset. That maybe why backend devs usually are very dismissive of it. By the way I became a frontend developer after I spent many years as a backend dev. My background is in Php and Perl.


Have you looked at Definitive CSS? It's up to date and a massive 1000 page tomb of encyclopedic knowledge and guidance. Anyone who digests that entire thing is not being dismissive of CSS.

Digesting that is taking CSS more seriously than most people take learning new programming languages...which is appropriate! Because with CSS, you not only need to learn the language, you are effectively learning something like a language and a framework at the same time. Lots of folks learn the language minimally, piecemeal, on an "as needed basis," and end up wasting a lot of time because they aren't aware of the larger features and how they can be fit together.

Most folks do the equivalent of learning about goto statements, variable declarations, and arithmetic operators, and figuring you have everything you need to do good programming work.

Technically, you do have everything you need. And with a decade of work under your belt using those things, you can build some amazing and good robust systems. It's also easy to build total junk that nobody can understand but you. Perl, of course, is also infamous for having this quality.


> Have you looked at Definitive CSS? It's up to date ...

Not really, it doesn't talk about custom properties, inline svg, how to style them, etc. All very useful these days, if you want to allow color theming for your web app and not use hacks like custom fonts for icons...

And custom properties are around since 2014 at the very least.


> Technically, you do have everything you need. And with a decade of work under your belt using those things, you can build some amazing and good robust systems. It's also easy to build total junk that nobody can understand but you.

This is what’s beautiful about the frontend. It’s “magic” and underneath in code speak it may be ugly but the work speaks for itself. Arguably that is only if you own it and maintain it.

> Lots of folks learn the language minimally, piecemeal, on an "as needed basis," and end up wasting a lot of time because they aren't aware of the larger features and how they can be fit together.

The way I see it, learning about all the ingredients in a recipe will not teach you how to cook. In css techniques are unearthed by a small handful of css artisans and it’s not about learning css itself in 99% of the cases. It’s about digging and finding the best ideas on GitHub, stack and codepen. And hacker news.


Or, you know, using a well vetted, well organized resource that has already done all the digging and collating of techniques and organized into a well structured Definitive Guide.


> I've never met a CSS Person who has read a book on CSS

I'm not a CSS person, but I've read three (including CSSTDG) and I still can't do anything useful with CSS.


Ha!


Front end development is a craft, just like other crafts. People need to treat it seriously if they expect to be taken seriously and be paid accordingly. (BTW, if you still haven't met a FE dev who's ever read a book on CSS, you have now. I own quite a few AND have read them.)

I also think a lot of the value from a front end developer comes from their ability to merge the technical requirements with a designer's vision, and produce a product that is at the same time usable, accessible and (bare minimum) meets the technical requirements.

Not going to touch the CSS Grid except for two quick comments:

- they absolutely should have been keeping up with CSS Grid, where it was at, and when it was usable and when it isn't

- it is still an open question, because although the overall numbers should 90+% available in browsers, you have to check your own stats. For example, the stuff I work on is often used in Enterprise environments, so IE11 is a requirement (yes, we know our numbers, it is, it could literally cost us 6 figure sales if we don't have support for it). We are using CSS Grid, but we have to be very careful what we use it for and to test those uses in IE to make sure the old Grid spec in IE supports the things we do it with. Otherwise it's back to Flex or other layout techniques. It's not a silver bullet, but I also recognize that is becoming a more unique example these days.

Those are the kinds of things a good FE dev should know though, IMO, and be able to articulate.

Plus, FE devs also need to know HTML and semantics, accessibility, and of course, Javascript. When you can put that all together along with the skills earlier re: usability and accessibility, then you can justify the higher salary brackets.


I think this is a culture problem in fornt end dev in general. Front end devs learn frameworks, not technologies. It's very much focused on getting started as quick as possible instead of taking the time to read and understand the tech they are working with. Even though, as your story shows, you can get things done quicker when you know what's going on.


But when was this? CSS grid has only really been viable for a few years in terms of significant browser support.


Last year. Around November and 91% unprefixed usage (https://caniuse.com/#search=display%3Agrid)


CSS Grid has only been widely supported for a couple years now. Not so hard to believe a frontend dev was still using bootstrap grid.


The inexcusable fact here is that he said that he didn't know how it works. A font-end developer not knowing grid is not worth 6 figures.


I disagree, as both an engineer and a manager.

CSS grid is only recently becoming a reasonable tool to use in practice. I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.

Based on experience, the kind of person who would be able to use it from memory either 1) is very skilled AND had a reason to use it recently, or 2) someone of medium skill who just recently read the spec but in almost all other ways is less skilled than the people I mentioned in the first paragraph.


> I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.

You probably don't mean it that way, but not having to use the documentation surely isn't a requirement for competency. I resort to the docs all the time, even with topics I'm quite famialiar and experienced with.


That depends on your company I guess. If your entry salary is, or is close to 6 figures then yeah. But if you pay that only for skilled developers _specializing_ in front-end then it is not too much to ask that they are up-to-date with their field.


I agree. It's fairly common for experienced front end devs who have been bitten by browser incompatibilities in the past to wait several years to adopt the latest CSS techniques. The "old techniques" often work very well.

Most likely if you had asked me "why flexbox and not CSS grid" I would have said "because flexbox is able to perfectly well support this use case, and I'd rather not introduce a dependency on a less well supported CSS feature unless I need to".

I personally tend to prefer using the oldest (within reason) CSS feature that lets me accomplish a task. Or I'll pick the one that best conceptually maps to the task I'm trying to accomplish, if there's a significant difference.


I used to work like that but CSS Grid is actually amazing. Highly recommended.


Too bad you had a bad experience with your dev, but seriously, you just picked up css, people have been fighting it for years because of browser support. There's a reason why there are css reset stylesheets, and frameworks out there. If you are using it in one project great, but when you do it for living you will ended up building your own framework if you are not already using one. SASS also saves you so much time in development.


Yes, one of the issues with people who've recently learned the 2020 version of JS/CSS/frameworkX is that they assume what they've learned is the correct way to do things according to "the best, latest standard". It's a variation of Dunning-Kruger almost.

As you said, experienced engineers have been dealing with CSS browser support issues for years, so as a habit try to avoid using the latest shiny new features.

Also, experienced engineers do refresh their knowledge from time to time, but you might have caught them between refreshes. Remember that these engineers are also working 40-60 hours per week producing work output in addition to periodically refreshing their skillset. And depending on the environment they've worked in previously they may not have had the ability to use the latest features of whatever technology. Maybe they were working on a legacy app that didn't support ES6, for example. That would be less common now in the days of Babel, but there was a time a few years ago when it would have been reasonable for a working JS engineer not to be familiar with every detail of ES6, as an example.


This might be one of the most helpful book recommendations I’ve ever read.


Thanks. If you'd like some more book and video suggestions I sent this to a friend back when she was looking to get into front-end development a few months ago:

Here are some book and video links (with Amazon affiliate tags snuck in). I've read all of these books cover-to-cover save for the RxJS one. They approach front-end as a set of technologies that should be understood and mastered rather than the "CsS hAckS to GET YoU pAiD!" style of most web tutorials.

Not sure where to point you with React but if you decide to use Angular or Vue I have some suggestions.

CSS/Sass:

"CSS: The Definitive Guide": https://www.amazon.com/CSS-Definitive-Guide-Visual-Presentat...

"Pragmatic Guide to Sass 3: Tame the Modern Style Sheet": https://www.amazon.com/Pragmatic-Guide-Sass-Modern-Style/dp/...

This Sass book has the best structure of any introductory tech book I've ever read.

"TypeScript":

Mastering TypeScript 3: https://www.amazon.com/Mastering-TypeScript-enterprise-ready...

"Programming TypeScript": https://www.amazon.com/Programming-TypeScript-Making-JavaScr...

RxJS: Reactive programming the most significant development in UI technology in 20 years. Once you get the hang of it managing asynchronous events (user generated, network generated, time based, etc) become a breeze.

"Build Reactive Websites with RxJS: Master Observables and Wrangle Events": https://www.amazon.com/Build-Reactive-Websites-RxJS-Observab...

RxMarbles - Interactive RxJS visulizations: https://rxmarbles.com/

Angular:

"Angular Development with TypeScript": https://www.amazon.com/Angular-Development-Typescript-Yakov-...

"Architecting Angular Applications with Redux, RxJS, and NgRx: Learn to build Redux style high-performing applications with Angular 6": https://www.amazon.com/Architecting-Angular-Applications-Red...

Videos:

I watched most of the Layout Land videos when I was getting a grip on the state of CSS. Jen Simmons is a developer advocate at Mozilla and has the best overviews I've seen.

Basics of CSS Grid: The Big Picture: https://www.youtube.com/watch?v=FEnRpy9Xfes

Using Flexbox + CSS Grid Together: Easy Gallery Layout: https://www.youtube.com/watch?v=dQHtT47eH0M


Thanks for sharing this list. If you happen to have any recommendations for pure JavaScript, I'd love to hear it. Otherwise, I'll probably take a look at the TypeScript recommendations and work my way through the material.


Interesting, I am really really bad at css but knew all of this. Long ago, someone gave me 7 euros an hour to do some of this (and html/js/php; I never designed anything, I just edited an existing site to specifications, but css was still my least favorite part). Aren't these just things you run into and pick up on in the first webdev projects you do?!


Six figures for HTML and CSS, sorry, but I don't believe you.


I don’t thnk the author’s recommendation to include

     img {
        display: block;
     }
in your reset is generally a good idea. It will break some common uses of images, for example to hold bits of math inline with the text when you are not using mathjax. If you want a displayed image, you should wrap it in a <figure> tag, which will give you a block element.


If you wrap an image in a figure, but leave the image still inline, you’ll probably get a few pixels of extra space at the bottom of the image due to line-height and vertical-align. People find that really confusing. With how most people use images, I agree that `img { display: block; }` is what you want >99% of the time, and would rather people reverse it for the rare occasion when they want something else. (BTW, doesn’t MathJax emit SVG? Viz., not <img> anyway.)


I’m confused by your reply. Did your eye skip over the word “not” in my comment?


Sorry, you are correct. Drop the final parenthetical, then, but I stand by the rest.


Yes, your other point was something I hadn’t thought about. I guess his advice would be good for some people, but I’m not sure about the 99%. It’s not uncommon to use small images as text-like elements, and when you do that, if you have this reset, you will need to explicitly make them inline. Not a huge deal, but people tend to copy and paste their own CSS libraries between projects, and redefining basic default semantics of elements may create confusion and extra work down the line when things don’t behave the way that any documentation you may consult assumes.


I’m going to stick with the >99% figure. I think it is uncommon, rare even. Other than chat systems with custom emoji rendered as an img, I honestly can’t think when I last saw a site with inline <img> tags. (I’d guess it to be within the last month, maybe even the last week, but it wouldn’t surprise me if it wasn’t.) Twenty years ago, sure, but they’ve gone out of fashion stylistically as well as technically. Technically, I suspect background-image and icon fonts are both used more commonly for small iconography.


It depends on what kind of sites you tend to visit, I guess. I see this several times per day. But I often visit pages with math on them. Before mathjax became standard, inline images was the only way to do it. And visit any Wikipedia page with math: they use mathML and have fallbacks, but the end result is, you are looking at inline images. Also, I often see such things as sparklines and similar things, also inline images. The >99% may be true of what you consume, but without data I am skeptical about the numbers.

Also, some people use CMSs that substitute inline images for missing Unicode glyphs, and other things. If it’s done well, you may not even notice. You don’t know if the correct figure is 99% unless you have examined the source of a sample of sites.


Something like this then:

    figure img {
      display: block;
    }

    figure figcaption img {
      display: inline;
    }


Yep, this stood out to me too. Drives me absolutely nuts when an element you expect to be inline is now suddenly block.

Especially because the author's reasoning is "it can cause confusion when trying to position them or add vertical margins", after just explaining that with inline-block "you can apply vertical margins to these".


Useful article. Getting started with CSS must be harder these days than it was 15-20 years ago. Not only for mobile-friendliness, but also because of the coexistence of flexbox/grid/traditional layouts. I'm wondering if the standard will ever been simplified, instead of being added more and more features.


CSS and HTML are constantly evolving, and so its demands. However for me CSS is way more straight-forward than in the 90th and 00th.

The standards addressed a lot of the pains and struggles we had with floats/clearfix etc. This was challenging but nothing im comparison to supporting IE 6-9, FF, Safari, Opra etc. at the time. Also hacking in JavaScript added to the complexity.

Nowadays I can do with 10 lines of grid and flex what great CSS frameworks like Bootstrap abstracted away behind 1000th of lines of code.

Also testing is way easier, since browser vendors follow standards and there is chromium everywhere.

Earlier we did a lot of div soup, I remember fondly CSS zen garden as well as OneDiv.

Awesome times to be a web dev, you work on products (PWAs!) not on browser hacks.

My 2 cents.


Btw, there is an effort to have modern-day CSS zen garden: https://stylestage.dev


"div soup" – I like that.

The present-day CSS frameworks use "class soup."

For example, tailwind (which I like):

  <button class="bg-teal-500 hover:bg-teal-600 focus:outline-none focus:shadow-outline">


This sort of class soup brakes the principal of DRY. Much better to use CSS to style.

    button {
      --background: teal;
      --focus-ring:
        2px 2px 5px skyblue,
        -2px -2px 5px skyblue;

      background: var(--background);
      box-shadow: none;
    }

    button:hover {
      --background: wheat;
    }

    button:focus-visible,
    button:focus:not(:focus-visible) {
      outline: none;
    }

    button:focus-visible {
      box-shadow: var(--focus-ring);
    }
Now you will never forget to add that `hover:bg-teal-600` class to your buttons.


I avoid Tailwind-style CSS frameworks. I prefer SCSS and, if needed, mixins. Meaningful class names are much better, IMO.


“Getting started with CSS must be harder these days than it was 15-20 years ago.”

Not like I’m teaching anyone these days, but I’m not sure about that. Yes, there’s just more now. Grid and flexbox and transforms and on and on.

But if you were totally starting from scratch, certain stuff is just way easier now, or at least, not a pile of hacks upon hacks. Basic beginner stuff that comes to mind…

• How can I center something vertically and horizontally without having to explicitly know the size of the container and object to be centered?

• What is all this float stuff, how do I just make a grid of icons?

• Wait, borders fundamentally change the size of my div? What?

• I have to do what now to have a drop shadow?

• How do I keep my branding colors consistent without having to make really sure I plug in the right hex values in every little color declaration?


The whole float-based layout thing was a hack. Floats make perfect sense if you only ever use them as floats: box-outs to run text around.

The fact you could use them to build all sorts of header/column/footer layouts was both very helpful and entirely confusing.

It became the default way to use CSS, for good reason. Yet, I always felt it was a shame it wasn’t often described as the hack it was.


Just use flexbox (and grid if you need to control both dimensions at once). You can ignore all of the old ways of doing layout. Flexbox is supported back to IE11.


As an occasional CSS user, I second that. Every time I have had to use CSS for anything more complicated than diddling item appearance has led to a lot of time on Stack Overflow trying to find answers to questions like "why did my height change work on this element but not that element?" or "how can I center this text vertically in this space?".

I don't use CSS frequently enough to not forget these things by the next time I need it.

I'll still probably forget parts of Flexbox between the times I need to use CSS, but it will be things like forgetting like what spacing modes are available, which is easy to quickly look up.

Flexbox is now my turtle [1]. Well flexbox and grid.

[1] https://en.wikipedia.org/wiki/Turtles_all_the_way_down


> Flexbox is supported back to IE11.

Nope.

An incompatible and broken version of Flexbox is supported in IE11. Therefore, layouts look completely different (and broken) when rendered in it.

Only people who recommend Flexbox in IE11 haven't tried using it in IE11. I might via a library that did the heavy lifting for me, but there's just too many bugs to recommend anyone write Flexbox and expect it to just work -- it won't/doesn't.

PS - I'd link all the IE11 Flexbox bugs but Microsoft took them offline with Microsoft Connect's retirement.


I write a fairly substantiate app (60,000 DOM elements...) that uses flexbox and SVG for all the rendering and it's fine in IE11. The layout problems are more often SVG related. That said, if you don't need to support IE11 it's much easier not to.


Did you use AutoPrefixer/PostCSS?


15-20 years ago it was exceptionally more complicated to have rounded corners on things.

The complexity has just shifted. While previously you could easily start using floats, you might run into issues down the road with them, or with browser compatibility

Now, you might struggle a bit more trying to understand Gris syntax and how to use it, but once you do you’re probably set.


I started around 2006 and there are definitively more standards — as in more ways to achieve the same thing. And yes, you have mobile — though we did fluid and "responsive" layouts back then as well.

One thing that is better is the browsers adherence to standards. I spent my first years learning all IE6 rendering bugs and how to overcome them.


CSS is way easier now when it was 15-20 years ago (source: 24 years with frontend, 22 professionaly). Alas, that's probably one of the reasons why people do not spend any effort learning it. I'd argue that 15 years ago was the golden age for CSS innovation and web standards in general. Technologies are much more powerfull now, but the attitude of those using them could use some improvement.


Css is getting better not harder.

Back then, you had to put some image to make a fake border-radius.

Or some weird hack because table layout doesn't wrap.

And using a different technology that is flash because css couldn't animate.

Not to mention the existence of transpilers like stylus that make writing far easier and we no longer have IE6 that behaved on its own rule.


https://xkcd.com/927/

Backwards compatibility support will always require adding on new ways to do things and not removing stuff.

I personally find flexboxes frustrating at times and tend to limit my usage to non-grid spacing (footer columns, horizontal menus) and responsive vertical alignment.

CSS grids are pretty cool, and maybe if you were just starting out it would be easier to pick up fresh than having to unlearn floating divs.

Funny thing is that if you go back 25 years (pre-table layout era), everything was not only mobile compatible but your target viewport was 800x600 which I find the painful part of mobile compatibility these days - it's that ugly zone in-between a nice mobile/cell phone layout and having the whole desktop to work with.


Guys we need to talk. Are you capsbold serious? These are things that you learn in a first week of doing web development tutorials. I read this thread and it makes me think that I'm delusional because of a heat wave. Margins collapse? :focus exists? Me not getting a joke? I don't understand.


I think you may be underestimating the fact that many people have been writing CSS for well over a decade now, and that it has evolved considerably since they first read a web development tutorial. If you've not been paying close attention (or not been able to), there are many things that will have passed you by.

It's a blessing to learn css fresh today, in as much as it's a curse to still have practices from ten years ago still lodged in your memory.


> and that it has evolved considerably

GP is pointing out the parts that haven't changed at all, and are old (over two decades), simple, and common enough to be considered basic knowledge. I had the same reaction to those and one or two others.

Now if this was someone relatively new to CSS I'd understand, but the opening paragraph establishes how long this person was around. Padding-vs-margin in particular was necessary knowledge to do good layouts back in those earlier days (less so now only due to flex and grid, which aren't on here).


> GP is pointing out the parts that haven't changed at all

Doesn't read that way to me:

> These are things that you learn in a first week of doing web development tutorials.

Sure, padding vs margin isn't exactly new, however `display: inline-block`, ::before and ::after, rem, ch, and :nth-child() certainly weren't in the old html4/xhtml and css2 guidebook that got me into web development!


To add, I think another post by the same poster on this HN post proves the point that they're not dismissing individual parts, but rather disputing (or sorry but trolling) the article as a whole:

> I think (hope, really) that gp is just one heavy "/s". The knowledge presented in the article is so basic that it is hard to believe that a person who does html for two years and six figures doesn't know these. As for the article, I fail to see any reason for it to exist beyond cheap media presence. Or maybe I should start a blog, because I'm not even halfway too.


I was disputing the article in a comment that you quoted, and this thread's other comments in ggggp, if it may help with the investigation.


I think you are point on. The two existing sibling comments have contradictory excuses for this:

1. New developers might know this, but standards change fast, and it’s hard to keep up.

2. You can’t expect people new to the craft to know everything in the field.

I personally found this article sub-basic. You could probably learn more and better on MDN. I think CSS might be one of few areas on HN where a sub-par article doesn’t get the constructive scrutiny it deserves in the top comments.


It's also good to remember that new devs make up something like 50% of the developer population each year (I forget the exact number, maybe it's every 2 years). So while this may be basic information to someone who's been doing this for at least a few years (and I'd argue it isn't, particularly since the site isn't aimed at Front End Devs, per se, but others who have to do front end development), it is valuable information for the target audience.


> These are things that you learn in a first week of doing web development tutorials.

You meant CSS tutorials? Never read about "margins collapse" in web development tutorials.

Web development tutorials I read (like 10 years ago) were usually about having a web server renders some data queried from a database into some basic HTML. And adding a form to create/edit rows in the database. Then perhaps adding some basic style like colors and paddings and some jQuery to validate the form. Finally moving that page from localhost to internet.

Let's be honest, web development covers a very large area of knowledge and CSS is not the most interesting part (not saying CSS is not interesting!). I guess most people just skip the CSS documentation and learn it by inspecting other pages and copying rules, and searching "how to do X in CSS" and reading tutorials about their specific question.


Yeah I thought this was going to be quirks with CSS Grid or something.

The "CSS Zen Garden" from 1999 gets posted about every 3 months and makes it to the front page...


There are couple of things that author still don't get.

display:inline means that element does not establish a box. Such element is rather a collection of individual content boxes (e.g. glyphs). These boxes can be placed on different lines (text wrapping) and so on. As no element box as no margins and paddings applied to such elements.

img element (and input and other replaced(^) elements for that matter) is not a display:inline but rather display:inline-block. Even you will define them as display:inline they will be treated as display:inline-block and so e.g. margins will apply to them.

(^) representation of replaced elements (img,input,textarea,iframe,etc.) is outside the scope of CSS - they are always treated as solid boxes.


That is really useful.

I have been writing small html front-ends since 2008-09. HTML5,CSS3 made many things easier like gradients, Round borders, and many things that now developer do takes as granted. I clearly remember, how boring and frustrating it was to slice borders and corners from photoshop psd.

CSS3 and HTML5 made many good changes, but new css feature like grid, Flex-box all are still confusing. I have to look at the references every time I start new frontend work.


I felt the totally opposite about grid. I spent a little time learning it, and now EVERYTHING is easy (except for things that aren't, of course)


yes everything is easy now, except for things that aren't/


Have you ever taken some deliberate time to really „play“ with those?

My recommendation: take a calculator or spreadsheet and start with some simple cases and build up your knowledge in a exploratory manner. A few hours, a session for each feature (flex, grid).

Its not only fun but also really helpful!


> Have you ever taken some deliberate time to really „play“ with those?

I know just the thing!

https://flexboxfroggy.com/

https://codepip.com/games/grid-garden/


Thanks, froggy was on front page of HN so I knew it for sure, grid garden is new one for me.


yes, I really did play with it multiple times. Its just sometimes I require more revisions.


Anybody knows a good book on CSS for ppl with a solid programming background? Every couple of years I try something and fail. Somehow the tutorial rave about the cascading on and on, and when it comes how to strategically design a good SAP working on different devices the stuff gets mute quickly.


Not a book but https://developer.mozilla.org/en-US/docs/Web/CSS is my go-to for all things CSS, I love mdn it's a fabulous resource.

Also zeal (dash on Mac which is paid or you can build zeal yourself like I did) has docsets for CSS which are good.


https://caniuse.com/ is also invaluable to check whether the cool CSS feature is actually supported. it's very much today's quirksmode.com.

Once upon a time I would have recommended Eric Meyer's CSS Definitive Guide without hesitation (I think I still have my 1st Edition copy) and it looks like he's re-released with updates for flexboxes and grids.


Can't recommend Andy Bell and Heydon Pickering's Everyday Layout enough. It's a wonderful resource for learning (and re-learning) contemporary best practice CSS.

https://every-layout.dev/


I have every book written by Heydon and am currently doing Andy's 11ty course. They're both stellar teachers and some of the most knowledgeable programmers when it comes to HTML and CSS. Every Layout is amazing. Strong recommend.


Best resource I've found to learn the foundation of HTML/CSS is Shay Howe's guides [1]. I think it doesn't cover Flexbox and more advanced layouts, but it's totally worth a read. I still go back to it as reference from time to time.

[1] https://learn.shayhowe.com/


I’ve written a small CSS ebook if that interests you. [1] It teaches you how to build a webpage from scratch.

I’m currently writing my second one, which will be more theoretical and cover things like this blog post actually. I’d be interested to know what kind of problems you’re facing in CSS, so feel free to drop me an email.

[1] https://jgthms.com/css-in-44-minutes-ebook/


I'm curious about your book, as it seems small enough for the kind of things I write as well [1]. Can I ask if it earns you enough for anything?

Sorry for coming out of nowhere, but I have lots of small tutorials I could use (I teach in a local college) which I could make small ebooks out of them.. Looking for some side money..

[1] https://github.com/joaoventura/full-speed-python


I've been earning a bit on a regular basis since I published it 1 year and a half ago. Not enough for replacing a salary, but enough as side pocket money. I'm lucky to have a decent following, so I didn't have to market it a lot. I'm currently writing a second one which is longer and more advanced, so hopefully it will earn me a bit more.


Thanks for the reply! Do you have any practical tips you may want to share? Maybe how did you grow your audience, how you wrote your book (technologies, etc.)?


Well I grew my audience on Twitter by building open source projects. [1] I didn't really plan or aim for anything. It mostly happened.

As for technologies, I just wrote the book in markdown using Sublime Text. Then I used a markdown-to-pdf library from GitHub to generate my ebook, and voilà. Nothing fancy really.

[1]: https://twitter.com/jgthms


It feels like HTML and CSS could be useful for print layout, but I’ve rarely seen a high quality PDF renderer.

I know Atom’s markdown preview uses headless chrome under the hood. These are hugely heavyweight tools but the output is very high quality.

Are there any other recommended tools for going an HTML route, for typesetting? I’d much rather design pages that way than use InDesign, PDF scripting, or TeX.


We use WKHTMLTOPDF (https://wkhtmltopdf.org/). In our case it's in the Rotativa package (.NET MVC). There are a few caveats; it uses an older headless WebKit engine that doesn't support everything. We use the QT Web Browser (http://www.qtweb.net) to test/debug when needed. We do design pages to be specific "paper" sizes and lean on SVG a lot for anything fancy. We have some JS that breaks long tables into multiple tables, etc. But the resulting output looks flawless.


I have been using Python with Jinja2 templates and Weasyprint[1] for PDF creation for a side project of mine. The libary does have its css limitations but the PDFs it produces look good enough for me.

[1] https://weasyprint.org/


Yes, I was going to recommend WeasyPrint as well.


> but I’ve rarely seen a high quality PDF renderer

What exactly do you mean by this? That HTML-to-PDF converters mess up the layout, or similar?

You might be aware of this, but it's still worth pointing out that you can specify a different stylesheet for the print version of an HTML page than the default one. I've used this in the past for websites where the customer wanted to use a product description page directly for generating PDFs, without having to do the work twice. We also used some Java-based HTML-to-PDF renderer, which was not perfect but had full support of CSS 2.1 and some support of CSS 3 (and this was several years ago). I think the library was Flying Saucer (based on itext).


Although not exactly what you want, my day job is basically implementing systems that take SVG's produced in design tools, pipe them through to a customer UI for designing print books, posters etc, then renders high res images server side with Chrome headless and finally sending them off to the printer. SVG does a great job, but still requires a lot of coding for laying out the text, line breaks, pages, etc.


Modern CSS technologies such as grid are convenient for laying out webpages. But there can be no “high quality PDF renderer” from HTML/CSS. The result will always look as crude as a web page. In order to produce a high quality document, you need a sophisticated line breaking algorithm such as that deployed by TeX or some other software.


It is possible to use CSS to have justified text with hyphenated line breaks. Font technology like Opentype will manage ligatures etc. I feel like the basics of laying out glyphs are all there.

What doesn’t feel so great is page filling, and knowing how to break sections so that one doesn’t have a new section at the bottom of a page with only a few lines of text.


I use wkhtmltopdf without much issue. Sure, it has some limitations and is built around an older html rendering engine, but it works well for a free tool.

I use it mainly via the wicked_pdf ruby gem and I'm sure there are wrappers available for other languages too.


A true CSS+HTML-powered print renderer is PrinceXML. https://www.princexml.com/samples/

Having used it for over a decade, it's a wonderful tool.


That product's license tiers are a complete non-starter, unprofessional, and they "call for pricing" on the only potentially usable license (but don't provide a copy of the CSO License for review before calling).

> A Prince Server License can be installed on a single server to produce PDF documents for company-internal use, or documents that are made available to everyone free of charge.

They never define what "company-internal use" means, even in the actual terms[0]. This was clearly written by a non-lawyer, and any company worth its salt wouldn't touch this (the "FAQ" isn't a legally binding document, and even that is incredibly vague/unhelpful).

> You many not use Prince to generate documents that are part of a Commerial Service, for example invoices and monthly statements.

So "company-internal use" doesn't include order/remittance/invoice/receipt to your company's suppliers/vendors? That's just bizarre, the whole licensing is. The "Service License" feels like a Honey Trap.

[0] https://www.princexml.com/license/


> Using pixels (px) is tempting because they’re simple to understand: declare font-size: 24px and the text will be 24px. But that won’t provide a great user experience, particularly for users who resize content at the browser level or zoom into content.

Pixels (px) in CSS are relative as well, and scale with zoom. What is the benefit of em/rem?


>What is the benefit of em/rem?

They (em*) scale with the element's font size, and if you set an elements font-size itself in em, that will be relative to the parent element's font size.

For example:

    body { font-size: 18px }
    .something { border: 0.1em solid black; }
    .something > .inner { font-size: 1.5em }
If you change the font-size on body, everything on that page will re-scale seamlessly. This is most useful for things like buttons/icons that are supposed to flow properly with text. So now even if you use them once in big text, and once in a small footnote, they'll still fit perfectly within the line.

The biggest limitation to this approach is that you can easily end up with computed values that are weird fractions of pixels, so you have to be a bit smart and pick an easily divisible number for your base font-size if you're aiming for something pixel-perfect.


The challenge with em units is that if you modify a parent element's size it changes the children as well. In your example, if you put 'font-size: 2.0em' on the .something class then the .inner would end up changing to 3.0em. That's rarely what you actually want to happen (especially in a web app). If you just want to control the overall font scaling of everything on the page using rem is preferable, because then they'd ignore the parent and scale based on the root element size.


The key is to use rem for font-size and em or unitless for all other properties: padding, border-width, margin, line-height. That way the size of the element is independent of the context.


Ok, I can kinda see the value of that - e.g. if you put a "tag button" inside some text, it will have the right size in relation to that text.


There's no date on the article, and this was the entry that made me wonder if it's 5+ years old, back when text zoom was more prevalent. When full zoom became the default, em/rem became less necessary, and at least to me appear to be falling out of favor as extra unnecessary complexity.

(Quick edit: Mentioned but not really given much focus is that em/rem can be used on, say, image width and margin, as well - making it adjustable in a text-zoom world. That's mainly what I have in mind here.)

(Even aside from affecting non-text, in the newly popular component-oriented design, you typically don't want relative font sizing to leak between components.)


Yeah I came here to ask this. Using relative units for layout seems like a terrible idea. If you want to make your text a little bigger, your entire layout changes too. That's fine if it's something like text padding or paragraph margins, but stuff like border width, or dimensions of boxes? That seems weird.

Browsers have been able to zoom pixel widths for years.


"Relative" and "Absolute" have their own definitions and by that definition "px" is indeed an absolute unit.


Not anymore, as most px units now is based on a reference px, a size determined based on screen density and viewing distance. That's why something rendered at 600px on an iphone takes almost all the width, even though the screen has more than double that in pixels. And when zooming, the reference px is zoomed. So the old reason for not using px and instead use rem doesn't apply.

https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel


If you're looking for world-class CSS knowledge, start with https://every-layout.dev; if you build UI for a living and haven't encountered axiomatic css and layout primitives, they're likely to change your world.


To save clicks, it's $100, just covers page layouts.


That's a radically misleading comment. It covers much more than layout, and the free content on the site is incredibly helpful and compelling. The full version more than justifies its price. And they offer it for free to students or anyone else for whom the cost is a problem (relying on the honor system).

It's far and away the best resource on CSS I've encountered in my 22-year career working with web technology for a living.

No affiliation, just a grateful patron.


not that the free thing is relevant but from https://every-layout.dev/blog/you-pay/ "The honour system is now closed"

> That's a radically misleading comment. It covers much more than layout

Given the site and all 3rd party reviews just mention layout, how is it misleading? Cant find TOC anywhere?

Also, found working discount code 'BRANDEMIC' for 60% off in my travels should any1 bite the bullet.

prev hn sub/182 comments: https://news.ycombinator.com/item?id=20196061


Ok,I missed that the honor system closed recently - but they continue to give it away freely to students or those facing hardship, on request.

The focus of course is on layout (by far the hardest part of CSS to get right), but it's in the context of building up your entire UI from robust, composable, accessible, standards-compliant, profoundly well-engineered primitives, based on first principles -- which principles are clearly articulated and demonstrated in the site.

It also covers typography (IMO by far the best explanation I've encountered of _why_ to use a typographic scale as the foundation of your design system), as well as touching on things like web components, shadowDOM, custom properties.. . and providing a deeply-expert perspective on the relative merits of utility classes (a la Tailwind et al), among other approaches.

I've been working in web-related roles for a living for over 20 years and have never once encountered a CSS-related resource that was this compelling and useful.

"Can't find TOC"? Um, it's in the site's primary navigation, in the left column. Literally impossible to miss.

I paid the full $100 and was glad to do so. The authors aren't popular (they've clashed on twitter with some big-name FE people like MDalgleish) but their ideas and body of work are unparalleled, and that's what I support.

If I were more selfish I might try to keep my newfound FE superpowers [axiomatic css and composable layout primitives are transformational] a secret, but I find myself wanting to spread the word and support https://every-layout.dev every chance I get.


The ; in your link sends me to about:blank#blocked.


For the benefit of others: https://every-layout.dev


Thanks! Wish I'd caught it in time to fix my 1st comment.


Thanks for the recommendation! I'm mainly a back end developer. I can hack around with CSS, but have never been very good at it.


Cached URL since the server is apparently over capacity: https://webcache.googleusercontent.com/search?q=cache:jcSTVF...



Thanks, clearly many people want to have a look.


An element that has:

    display: inline-block
is inline outside, block inside.

That is, the element is inline for the containing block, but its children feel like they are in a block.

An inline-block element can be vertically aligned with respect to the baseline: it acts a bit like a character in a paragraph. That's why you can vertically center things using vertical-align:center on an inline-block element.

At least, this is my intuition of inline-block, this comment is far from being normative.


To be even more pedantic: It is inline outside and flow-root inside. From MDN:

> The element generates a block element box that establishes a new block formatting context, defining where the formatting root lies.

https://developer.mozilla.org/en-US/docs/Web/CSS/display-ins...


Ah but then it does not work as a mnemonic anymore!

I'm kidding. Thanks, TIL I learned that with now have display-inside and display-outside (and flow[-root]). This makes perfect sense. Finally, even, I'd say. Having a property that defines both the behaviors of an element outside and inside without being able to define these behaviors separately was both strange and limiting. I'm happy I even used the terms that have been chosen to speak about these notions in CSS by chance.

How do you track all these useful additions to CSS conveniently though? I can't rely on random comments on HN to learn about them by chance (no offense intended to your valuable comment btw, being random is perfectly fine). I also can't possibly systematically learn about each and every addition neither. Are there resources addressing this?


I recommend taking the State of CSS[1] survey, it is a nice way of keeping up with the latest features. Other then that I use PostCSS with the postcss-preset-env[2] plugin. There you can enable various future features of the language and have it compile down to a more supported version. If your really want to dive into the future of CSS you can read the issue board for the CSSWG[3] (beware, it can suck hours out of your days). Smashing Magazine[4] and A List Apart[5] also sometimes have articles about a new(ish) or upcoming features.

But the CSS community could really benefit from the spec maintainers having more active bloggers among them (e.g. like Rachel Andrew[6]) and provide a regular update of the language like 2ality does for JavaScript[7].

1: https://stateofcss.com/

2: https://preset-env.cssdb.org/

3: https://github.com/w3c/csswg-drafts

4: https://www.smashingmagazine.com/

5: https://alistapart.com/

6: https://rachelandrew.co.uk/

7: https://2ality.com/2019/12/ecmascript-2020.html


Thank you very much :-)


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: