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.
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).
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.
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.
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.
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 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.
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.
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.
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."
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")
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.
Backend programming has this problem too. So does systems programming. The problem of unencapsulated complexity is core to the craft of software engineering.
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.
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.
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'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!"
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.
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]
... 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.
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.
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:
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/
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 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.
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:
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.
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.
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…).
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.
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.
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 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.
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!
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.
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.
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.
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.
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?
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.
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.
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
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?
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…).
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'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.
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.
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.
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.
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.
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.
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.
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.
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?!
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.)
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.
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.
“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?
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.
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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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..
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.
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.
> 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.
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.
> 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?
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.
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.
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.
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.
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].
20 years ago knowing CSS’s inheritance and tree traversal structure was critical to finish sites that worked flawlessly across all browsers. There was a lot of beauty in it, so much so that borrowed some ideas from CSS models for the architecture of the custom template system behind the CMS that powered CNN and a number of other large media sites with many sub-properties.
A little secret opinion of mine is that I think the global usage of rem instead of px is a fad. The only real argument I've heard is that the mobile devices have their own definition of it, and will thus optimize in their own way, but then again I see that benefit as being nearly non-existant and definitely not demonstrated.
Using relative units makes it very easy to scale things. If you use pixels or other absolute units everywhere, you'd have to edit every instance of that, which can range from an annoying chore to being completely unfeasible.
It's a fad nowadays, but if you remember the bad old days when the "zoom" function in browsers was useless on most pages, that was because the browsers did it "by the book": they only zoomed elements with relative sizes, px units were always pixels. Then browser makers just gave up and reimplemented the zoom function to work with "broken" pages too (I think Chrome did it first and the rest followed suit). Of course the advent of Hi-DPI screens probably also played a part...
When I read that section about rems and ems and ch and px it made me think of Python's "There should be one-- and preferably only one --obvious way to do it."
CSS and front-end browser work drives me up the wall.
The most relative units are calculated in turns of the font size of the root element (usually 1rem = 16px). I find it a lot easier to read and maintain units that are based on the font-size of the current element (e.g. `em`, `ex`, and `ch`). “This element has block margins 2 times the size of the font”, as opposed to some magic absolute `px` or `rem`. Also if margins and paddings are defined relative to the font-size (e.g `padding: 1ex 1em;`) resizing the entire element with `font-size` is way more manageable.
I just use rem when it needs to be relative to the text size, px everywhere else. This way when you scale the text for accessibility you don't get any clipping.
Most designs and typography are referenced of a basic unit, the body font size. Setting that size once and using rem makes it easier to build out and change.
Apart from the course promoted (which sounds really good!), does anybody know a really good book that already presents this kind of material about CSS use in a similar "logical" way and is not being written the style "margin defines the margin" (how insightful)?
I'm also searching for the material that is specifically oriented on:
- depending on the features existing in all browsers since the last 3-4 years, also mentioning how to make the features "usable" with the older vendor prefixes, but not depending on the JavaScript "fixes" for older browsers, and then showing the examples with minimal number of lines.
- demonstrating all the functionality that can be achieved with CSS only, no JavaScript
- addressing the real-life problems encountered during the design of the modern looking pages, and the goal to use all the power of the commonly available CSS features.
for people who want to go deeper on stuff like the box model and specificity and selectors, i highly highly recommend Una Kravets and Adam Argyle's The CSS podcast https://pod.link/thecsspodcast - they are the two CSS devrels from google and they really break it down in depth while explaining things in an accessible way. no vested relationship, just a fan.
This is content marketing done right. I really don't mind that this article is there to promote the book when it actually offers some value to the reader (I actually learned a new thing, nth-child and nth-of-type)
This is actually really nice. I've worked with CSS for a long while with the "Stackoverflow it until it works" philosophy, so some of these things (e.g. margin collapses) I had no idea about.
Good stuff here, I certainly learned a few new tricks.
I've been doing web development since around 2005 and to me, CSS and HTML has become far easier to use (although that could also be from experience). I took a web development course in college and found it interesting, later joining a small marketing company as an intern. My internship was unique, the company would travel to local businesses and sell them on advertising. They'd record a small ~2 minute commercial showcasing their business and then I'd build an application that compiled all of this data into a "local tourism" application. The real kicker - we didn't host the content, we burned it onto CDs and distributed the discs (think AOL). The company didn't profit well, but it was small and able to survive on what income it did make. I'm actually surprised to see it still around today - however, it seems they've moved on to actual hosted web development and graphic design work now. During this time we mostly used a combination of Tables and Photoshop "slices" to do layout (yuck!).
Today I use CSS/HTML/JavaScript daily building internal applications (and a few external). There is certainly more things to worry about such as building applications that are responsive now that mobile devices are so prevalent, however my arsenal has improved dramatically over the years with the addition of Flex and Grid (and many others). I actually enjoy the challenge of creating something beautiful and functional.
This is great! I've been hacking away at CSS for years and learned heaps from this. Also, reminded me to look up the differences between `rem` and `em`, which I've been meaning to do for ages!
I think a better understanding between inline and block is, that inline-elements do not generate a block. The idea of a block breaks down for inline elements, especially when they go over multiple lines. It's not just a horizontal expansion.
So understand what creating a block means. Inline-elements don't.
In his explanation inline-blocks do generate a block. It's just a block that doesn't fill the entire horizontal space, but expands with the inner element.
> If your CSS reset doesn’t include this already, I’d suggest adding the following rule: ...
If I'm trying to build a site design from scratch (rather than using Bootstrap or similar), is a CSS Reset a good place to start? Is there one in particular that's recommended?
It can be a very helpful start, but I'd review to make sure you're learning from it as well, rather than building onto something that could set you up for confusion later if you end up working without it. Here's one that's popular, lightweight, and helpful in my experience:
Definitely review multiple, because I find normalize.css to be pretty useless as it doesn't set `box-sizing: border-box;`, or `img { max-width: 100%; }`
I prefer a combination of reset/normalize, but because of that I agree with your statement re: learning from what you are using. Then you can make informed choices about how you are using those things.
Yes. There are different philosophies for how to write CSS, but assuming you're aiming at something like BEM (Block, Element, Modifier) style, it's typical to start with a reset of the raw elements into a standard form, and then follow that with the CSS for you class components, and finally some !important override utilities. Basically all the CSS philosophies agree that you should never use #id selectors at all and use of element selectors should be (mostly) limited to resets.
Ignore all above is you are not keen to go the path of cargo-culting. Most of those philosophies were brought to you by people who were too lazy to learn CSS.
Most are from very respected people to help others benefit from their knowledge and to avoid the pitfalls they ran into a various levels of scale. Do you need BEM for a brochure-ware site, no, styling by IDs and tags would probably work just fine. But a web app with 1000s of lines of code, while I don't specifically endorse BEM, some sort of pattern and methodology will save you a world of pain in the long run.
I wish the author had gone a bit further into em vs rem. I'm reading other articles on the topic but they're simply technical explanations and I'm still not clear on what features of the page are best designed using em or rem.
Just to mess with your mind: in media queries and in the root element’s font-size declaration, em and rem mean the same thing, being the browser’s default font size, which is 16px in most browsers by default, but customisable in some browsers and different by default in some environments (e.g. I seem to recall Kindle using 19px). I call this unit the “browser em”, or bem. No one else really talks about it. One thing I haven’t investigated and probably should: does this unit depend on the language the document is specified in? (Because you can define different default fonts and sizes for different languages in at least Firefox.)
I would guess it does matter about the language, but likely because as the language changes the font itself may actually change. And different fonts would have different relative font sizes. But like you, I haven't investigated it enough to make a definitive statement about it.
em: unit based on the font size of the element it is querying.
rem: unit based on the font size of the body element.
rem is helpful if you want to make an entire page scale uniformly if you change the base font size (imagine accessibility settings) while keeping the same proportions with padding to font size.
em is great for things like buttons where you may want to make one class for `button.cool-button{ padding: 1em; font-size: 14px; &.xl{ font-size: 20px;
}}` and then you can change the font size by setting the `.xl` Class on that button and the padding will go from 14px to 20px. One button, shared proportions.
CSS is such a weird abstraction. Who thinks in blocks and inline blocks? Who thinks in paddings and margins? Floats, etc? I know these are more flexible, but I've always found grid-based frameworks to be far more intuitive
CSS is a very reasonable abstraction for the job it was originally designed for: layouting of mostly textual documents. As such it borrows its concepts from the desktop publishing world. Margin and padding make absolute sense when you think in terms of headings and paragraphs. Float is an established term for having text flow by an image or other rectangular insertion. And so on. You have to remember the context in which CSS was first conceived. The Web looked quite different then.
Dear lord it's 2020 CSS has its own grid system, it's CSS Grid, and it's both easier to understand and more flexible than adopting the old frameworks. It also has variables, pseudo-selectors (which, like with html elements, you can invent new ones to suit your purposes), and more.
Well, I wouldn't recommend it, but certainly you can programmatically apply a pseudo-element or pseudo-class and programmatically define behavior around those things.
An off-the-shelf grid system is too inflexible, and you spend more time customizing it or fighting it to get the result you need than you would have just building what you need.
> Notice how it’s the odd-numbered rows with a background? Given our selector (p:nth-child(even)), we might expect the even-numbered rows to be highlighted instead.
OR it counts rows from zero instead of 1, rather than all this about siblings...
It’s amazing how software engineers can get things done without actually knowing the tools they are using. CSS is one of these tools that i never bothered to learn properly but instead hack it until it works as expected.
CSS was designed to make sense in a context that is no longer relatable, same with Git. This will never, ever happen if you'd designed your system to mimic nature (unless global warming fundamentally changes it).
Very good. I skimmed through it, since I am busy with some work.
But, I still code most things by hand. I only use WYSIWYG when I really have to. Most often I find it faster and easier to create things with plain CSS.
What I mean is that browsers used to zoom in a way where all the texts were automatically resized but nowadays the zoom works pixel-by-pixel, removing this issue.
I’ve always thought of ch as a unit intended for monospaced fonts or languages with monospaced characters. Does anyone know of any other practical uses?
I personally feel it’s a good spacer between labels and form controls, icons and text and can also be useful for other inline-like elements that should have a natural spacing. Another possible use is in setting min and max widths for content areas where ideal line-length for comfort of reading is considered important.
Yes. A good column width or grid card inline-sizes is between 30ch and 45ch, generally you don’t want text to exceed 90ch.
These numbers come from print design for magazine or journal layouts. In general the `ch` unit is perfect for defining the inline-size of text containers.
People really didn't know this? To be clear, I'm not criticizing anyone for not knowing this stuff, as nobody can be expected to know everything (and everyone was a beginner at one time). I'm just surprised that within this community, where a lot of us are employed to build websites, that the basics of CSS are still a mystery to so many of us. And I don't think that's the fault of any individual. But clearly our industry has a problem.
Granted, if you spend most of your time on the backend, and only dabble in CSS a little bit, or you're new to web development, it's completely understandable to be fuzzy on the specifics of CSS. But that doesn't explain all the comments from designers and front end people. So what's going on?
One possibility is that CSS is too difficult. Maybe? It certainly has it's flaws. And it was harder to use in the past. But I don't think there's a huge learning curve to understanding the difference between padding and margin, or between block and inline elements, is there? Don't we do that sort of thing in Word documents regularly?
Another possibility, then, is that the mental model of a document doesn't match the designer's expectations. But I don't think this alone explains why so many of us struggle with CSS. It's true that many of us are trying to make applications on a platform meant for documents. It's also true that magazine-style page layouts aren't a natural fit for a Word-like model of document editing. But the features described in this article don't seem related to that discrepancy - I can't see how ignorance about nth child or rem units relates to the mental model of documents.
Here's what I think is happening: We spend too much time building new tools and not enough time learning the tools we have. I've seen this with javascript as well. There were some recent posts here about vanilla javascript, and comments from React developers were surprised by some of the things JS could do on it's own. Now React has it's place of course, just like how CSS frameworks have their place. But I see a lot of people using these things as a boilerplate, instead of using them where appropriate. And thus, we don't take the time to learn how to do stuff with just HTML, CSS, and JS.
And granted, I don't think everyone needs to know that, just like how not everyone needs to know assembly. But if not enough people understand what's going underneath the hood, then the default response to any limitation is "abstract more" and everything grows more and more bloated.
I'm not sure how we solve this. I suspect the time pressures of our industries incentivize building things quickly, which leads to this problem. Another possibility is that the browsers take too long to adopt new standards, which leads people to seek out workarounds.
Has anyone here thought about this? Any ideas on what we should do?
I think the linked article is a good start. The explanations of CSS properties is very clear, and I like the examples.
I think the industry has an attitude problem towards the front end stack. HTML and CSS is not what programmers do. Nobody takes the time to learn it, everybody neglects it, managers hand it over to their newest junior developer, project managers are happy as long as it looks shiny, bootcamps don’t teach it properly, curriculums don’t teach it properly. In the end we have a bunch of people that don’t know anything about the craft, that accept poor craftsmanship as an industry standard.
I had a conversation about this with my partner—who is a woodworker—this morning after reading this thread. I explained my perception of the status of front-end within our industry as such:
It’s as if woodworking and carpentry were synonymous. There are woodworkers that do cabinetry, but all of them learned carpentry. At most they took a single course on cabinetry, but that course probably used outdated methods, tools designed for carpentry, and the teacher them self has build a couple of chairs and a few tables in the past. Most of the people new to the field of cabinetry would come for bootcamps that last for maybe a month where they had to learn woodworking from scratch. Good furniture makers are only expected to be good at woodworking in general. Master carpenters are often expected to be able to finish—or at least manage—furniture projects at their job.
You can imagine the sloppy craftsmanship you would see in the furniture building industry if that were the case. And yet, as tech workers, here we are.
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 ;)