Things I wish I’d known about CSS
cssfordesigners.com
cssfordesigners.com
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 ;)
The issue for me is the format these courses and resources take. CSS is the most jam packed with non-intuitive technology I've met. How many dozens of pages or segments of video would I have to go through in a course to learn what the author in OP summarised in two or three sentences? Any time I've considered the structured approach for something like CSS, the material drones on and on with technically correct explanations and example code, but somehow against the odds, almost nothing of substance.
Worse yet are the top google result reference resources. Look no further than the top result for "css grid" if you're in the mood to claw your brain from its stem, and flush it down the toilet.
Link: https://css-tricks.com/snippets/css/complete-guide-grid/
Behold, 8 zillion words and symbols across 7 trillion seemingly randomly organised boxes full of both all of the information, and simultaneously none of the information, about css grids.
Which brings me to where I am now, cobbling. It's more effective for me to cobble, than to spend an entire day figuring out css grids "the right way". If the going gets tough I'll just use some grid tool, or look up some sandbox examples, and be on my way.
If there was more material like the OP, and someone organised it well, well, I'd actually get around to learning it rather than cobbling. It's the best bit of writing I've ever seen on CSS. This is shocking. Not that there is anything wrong with the writing, but it's very, very simple. What on earth have all of the other CSS wizards with basic writing skills been doing? Confusing the issue, that's what.
Which leads me to a sort of meta frustration with learning CSS. I know it's not hard, I know that if someone just wrote about it even half decently it would take only a moment to digest each concept, but watching learner-disconnected authors create resources I can tell have lost sight of what it's like to learn, turns me off.
It absolutely is.
The web was meant for static documents and some link magic.
Now allmost every complex programm can run in the browser with web technologies. And in the time between you had lots of powerful organisations with their own agenda, as well as millions of single developers with a agenda and a loud voice. How could a sane, clear spec be made, under these circumstances?
Besides, it would be very hard, to make a clean spec that satisfies the needs of the whole population. So by now I say, all in all, it works pretty good.
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.
And no. I don't think you can expect the whole world to wait for some spec commitee.
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.
This was solved trivially by just reading the history of CSS. It was shocking to finally have made clear all of the quirks and weird aspects of CSS that always made it difficult for me to connect the dots and feel myself lost in a messy tangled up language.
By far the best source I went through was found here: https://news.ycombinator.com/item?id=22215931 - it's a long read, but extremely enlightening!
https://www.w3.org/Style/CSS20/history.html was also useful.
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.
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.
I am a front-end dev by trade and I could really easily say similar things about the tech stack you work with daily.
If you want a good reference and a learning guide start with this: https://developer.mozilla.org/en-US/docs/Web/CSS it is what us professional use.
For us professionals that use CSS in our jobs, that have put the same amount of hours into front end technology as you have done for back-end, CSS is a perfectly cromulent technology. It is easy to work with, it is intuitive, it is easy to find a good reference (go to MDN not random blog posts from people that are admittedly not masters of the craft).
If I try to cobble together a back-end I expect to be frustrated with it, I expect not to be able to do everything, I expect I’d need to find poor example and try to hammer them in to fit my needs, I don’t expect to be able to understand all the example snippets. Why are you on your high horse judging my tech stack this way?
If you need a good well crafted front-end for your project, you should hire a professional front-end developer. Or find a friend who is one that is willing to it in their spare time. Or spend a few thousand hours learning and mastering the craft. Alternatively you can cobble together a good-enough front-end that works, just don’t complain about how hard it is because “technology hard wheee wheee”. Us professionals use it every day and are fine with it.
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.
I am here to argue that this sort of attitude is problematic. If you browse through this thread you will find no shortage of comments describing how absolutely basic this article is (and a little void of insight, and a little out dated), and that there are people in the industry getting six figures while not knowing this stuff. Frankly it is a little insulting. And I think the attitude that you presented above is part of the problem. There definitely exists a lack of respect for the craft of front-end development within our industry. This sort of attitude is not helping.
There is xenophobia involved in people's attitudes toward kebabs. It doesn't change the impact of phosphates on the human body.
Here: https://www.bbc.co.uk/news/world-europe-42238363
Your argument doesn't change the impact of poorly-encapsulated complexity on the brains and mental health of your fellow programmers.
https://blog.codinghorror.com/programmers-and-chefs/
> Well you come across as an outsider telling us that the tools that we use—and do a fine job with—are no good, and that our literature sucks.
https://en.wikipedia.org/wiki/The_Jungle
---------
Backend programming has this problem too. So does systems programming. The problem of unencapsulated complexity is core to the craft of software engineering.
So is joining the fight against this problem. https://tonyarcieri.com/would-rust-have-prevented-heartbleed...
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.
See also: https://css-tricks.com/lets-define-exactly-atomic-css/ "Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function."
Or from: https://acss.io/ "CSS is a critical piece of the frontend toolkit, but it's hard to manage, especially in large projects. Styles are written in a global scope, which is narrowed through complex selectors. Specificity issues, redundancy, bloat, and maintenance can become a nightmare. And modular, component-based projects only add to the complexity. Atomic CSS enables you to style directly in your components, avoiding the headache of managing stylesheets. Most approaches to styling inside components rely on inline styles, which are limiting. Atomic CSS, like inline styles, offers single-purpose units of style, but applied via classes. This allows for the use of handy things such as media queries, contextual styling and pseudo-classes. The lower specificity of classes also allows for easier overrides. And the short, predictable classnames are highly reusable and compress well."
Mostly though, Atomic CSS is a state of mind or design pattern. So you can do it from scratch without support from something like Tachyons etc. -- but it helps.
You might even find it fits right in with your "cobbling" style of development. As an example, if you want to make some text red, you add the style "red" to it. If you want a border all around something, add a "ba" class. If you develop using HyperScript (like from Mithril) to define your UIs, code might look like this: h("div.red.ba", "This is red and has a border")
I refer to the Tachyons style sheet as essentially a menu of options: https://github.com/tachyons-css/tachyons/blob/master/css/tac...
In the rare case something is missing I do an inline style or add something to a single supplemental stylesheet written in a similar way.
There is also a verbose version of Tachyons without the abbreviations, so "ba" would be "border-all" (though I prefer the abbreviations): https://github.com/tachyons-css/tachyons-verbose/blob/master...
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.
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 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.
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).
How many people here could explain the link between Working Memory and React.js?
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 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
- regexps (this is a big one, being able to write a complex regexp without thinking about it is amazing)
- Git
- basic JS when it was mainly used to add snow on your page
Taking the time to properly learn things is extremely valuable.
One under-appreciated value that actual books have over online documentation is that you know immediately what order you're supposed to read them in.
Most people don't know that the flow model totally changed meanwhile, and something like "display: inline-block" actually means "display: inline flow-root", everything that came after flexbox kind of had an influence to the meanwhile borderline insane display model as a result.
Everything related to inset, margin and padding has gotten an overhaul that is ready for ltr and rtl content where they switch x/y flow based on "direction: ltr (or) rtl" whereas e.g. "margin-inline" and "margin-block" are the newer properties for the updated margin.
A lot of stuff has changed for the better, too.
CSS transforms are now specified in a cleaner way, with a predictable way to render them (e.g. translate rotate will not be different than rotate translate). So all CSS transforms have gotten their own properties like "rotate: 90deg" or "scale: 1.23".
I learned a lot when I read through the actual CSS specifications, because I am implementing my own parser (for my Browser [1] project).
Also, did you know that @media, @supports and @viewport queries can be nested in any order? The media queries 4 [2] spec is kind of insane from an implementor's view.
[1] https://github.com/cookiengineer/stealth and https://github.com/cookiengineer/stealth/blob/X0/FEATURES.md
Normal flow also doesn't require multiple passes, whereas flexbox does.[2] Even Yoga doesn't implement a conforming model.[3] I'd even speculate that flexbox performs slower than the standard visual formatting model just because of the differences in the algorithm.
Transform order absolutely matters. Any attempts to coerce order into a standardized sequence means developers have to account for this information.[4]
[1]: https://github.com/Planimeter/grid-sdk/blob/master/engine/cl... [2]: https://www.w3.org/TR/css-flexbox-1/#resolve-flexible-length... [3]: https://github.com/facebook/yoga/blob/master/yoga/Yoga.cpp#L... [4]: https://docs.microsoft.com/en-us/dotnet/framework/winforms/a...
... 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.
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.
And there are known way of solving these things, e.g. simplex methods or Cassowary constraint solver (CCS)[2] will work.
In fact flexbox layout is a particular case of LP task and also can be solved by CCS efficiently.
[1] https://en.wikipedia.org/wiki/Linear_programming [2] https://en.wikipedia.org/wiki/Cassowary_(software)
c-smile is a well known implementor in the space, and his comments are valuable as well.
I learned CSS over the years by gradually solving problems I encountered building apps. Compare this to people learning CSS now as evidenced by the #100DaysOfCode tag on Twitter. The learning technique is comprised primarily of using gradient-heavy, absolutely positioned HTML elements to create a photo-realistic, 3D rendering of objects.
The results are pretty amazing, but I have my doubts about whether these skills are easily translatable for building an interactive, responsive UI. Some examples:
https://twitter.com/bauervadim/status/1282264611912327169
https://twitter.com/mercyoncode/status/1282449080132804609
https://twitter.com/ellie_html/status/1276177277315932161
https://twitter.com/thecoffeejesus/status/128204582508278169...
https://jsfiddle.net/umaar/YNA5V/
https://jsfiddle.net/umaar/fu4TT/
I'd even make 3d graphics of things like the HTML5 logo: https://i.imgur.com/kuEYpSV.png
I posted this all to a community called "Forrst" (think of it like twitter, but curated for developers and designers).
I spent time giving feedback on other peoples work, I tried to ask insightful questions https://twitter.com/umaar/status/823915022917271552 to have an open discussion, I spent hours replying to comments every few days.
Then one day, Forrst got acquired by Zurb https://zurb.com/blog/zurb-acquires-forrst and later on it got shut down, and with that, I lost access to huge amounts of my work which I hadn't stored anywhere else (some stuff has been archived online, but not everything).
When it comes to web development tips, I now self-host on my own website and it's a really good feeling knowing that it'll be preserved: https://umaar.com/dev-tips/
Thank you for making and sharing!
https://developer.mozilla.org/en-US/docs/Web/CSS/background-...
https://developer.mozilla.org/en-US/docs/Web/CSS/transform-o...
display:xxx on some elements defines three things ( sorry, that is terrible architectural mistake authors of CSS have made initially )
1. display defines "sibling requirement" how that element wants to be replaced among its neighbors. `div {display:inline-box}` tells container to treat that div a single glyph placed inline among other glyphs.
2. In some cases it also defines "layout manager" of element's content. E.g. display:table and display:inline-table tells the renderer that content shall be treated as table having tbody , rows, cells, etc. Same thing for display:flexbox, grid, etc.
3. In some cases it defines other things like display:none; display:list-item; Note: there is still no display:inline-list-item ...
Ideally we should have these instead:
1. display: inline | block; - and just these two.
2. flow: auto | text | table | vertical | horizontal | grid...; - defines layout manager of element's content.
3. visibility: visible | hidden | none; - Note: visibility:none instead of display: none;
But I think the spec maintainers are aware of this and CSS Display Module 3[1] allows multi-keywords so you can do stuff like:
display: block grid;
display: run-in ruby;
display: inline flow-root list-item;
display/flow MUST BE [1] different properties as they define orthogonal concepts.
We should be able to define them separately.
main { display: block; flow:grid; }
@media handheld and (width < 100mm) {
main { flow:vertical; }
}
I've seen too many times errors like this:
main table { display:none; }
main.full table { display:block; }
[1] https://tools.ietf.org/html/rfc2119 [2] https://sciter.com
In my game engine, we only support these two display types from the specification.
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.
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)
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.
If you have a few kids, I would bet you are not that bad in UK with one fewer digit.
But I'm talking from the employer side, not the employee and why they would employ US devs who cost twice as much
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)
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.
But do you want your child to immigrate because you live in a country of selfish people? I'm sure you would find the situation difficult.
By the way, the communities you are mentioning in France are French since a few generations and not foreigners.
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?
$3,600/yr individual, $0 deductible, 8k OOPL
$9,600/yr self + spouse + kid, $0 deductible, 16K OOPL
$12,000/yr self + spouse + 2 kids, $0 deductible, 16K OOPL
Although I don't really think it makes sense to compare costs based on OOPLs. For most people, the deductibles, coinsurance, and copays are much more relevant to actual costs.
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.
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.
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.
How does rent and food costs compare to America, do you know?
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…).
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.
The median salary here is about £21k nationwide.
I bought my home for £170k, now worth about £230k. it's a decent sized apartment in a nice area in the city where I work. For an indication of size, my living room is about 23ft by 28ft, 2 bedrooms, 2 bathrooms.
Some photos to show what I got for my money:
https://imgur.com/gallery/6oNLRtl
My outgoings each month average out to around £1200k. Mortgage is under £450 a month.
Healthcare is all free, university is free, prescriptions are free.
When I renew at end of year it shoul be around 1.1%
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!
You could imagine that inflation pays ~1% of your mortgage for you because each dollar that you owe is becoming less and less valuable.
I just mentioned it for the sake of providing more information to whomever was reading my comment.
https://www.investopedia.com/articles/investing/082113/under...
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%
I'm not so sure. It looks like the average liability for a family (12 monthly premiums plus deductable) comes in at just under $23k[1]. That's the max the average family would pay. Obviously for just a single person total liability is a lot lower.
So for a person like me who makes good money being an engineer, I am still better off in America where I can make a lot of money but also pay a little more in COL / healthcare stuff.
[1] https://www.ehealthinsurance.com/resources/individual-and-fa...
Average salary (take-home): $11874
Average salary (total cost for employer): $19875
Median salary (take-home): $10225
Median salary (total cost for employer): $16526
Starting junior dev salary (take-home): $14800
Starting junior dev salary (total cost for employer): $25800
Senior dev salary (they can go higher, but that's relatively rare for local employers) (take-home): $27700
Senior dev salary (total cost for employer): $52000
VAT is 25%. Safety net is a joke. Health care is universal, but not that good. Education is mediocre at best.
It boils down to real estate prices combined with some companies really really really wanting those people to be on site.
I had my highest rate ever during a brief, beautiful moment in Switzerland where a studio apartment costs ~$2000 per month.
I choose to think that this rate is how much our work is actually worth - otherwise those companies couldn't afford having people on site.
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.
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.
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.
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
If not, never ever show bitterness for your fellowship that brought honor to the profession, wherever they are.
I hope never to see developers disrespected that way, anywhere in the world.
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.
Which countries would you suggest for this?
Just the UK?
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.
I once paid a senior front-end engineer far too much to do a fairly involved layout. Three months, an uncountable number of bugs, and one unusable tangle of Sass later I pulled the plug and swore off ever hiring a "CSS Person" again.
I took the Linus+Git approach and said "I'm not writing another line of Python until I understand CSS." After a few weeks of study (I read CSS: The Definitive Guide cover-to-cover) I was able to implement the layout in, and I'm not exaggerating, two hours. No bugs, responsive, cross browser support, etc. Flat out done.
I went back to the dev and asked why they tried to implement it with over a thousand lines of Sass using Flexbox over a few lines with CSS Grid.
It went like this:
Me: "Hey, why did you choose Flexbox over CSS Grid for feature XYZ?"
Senior Front-End Dev (SFED): "I used a grid. Bootstrap's grid."
Me: "No, CSS Grid"
SFED: "Like the 'display: grid' thing? I don't know how that works."
I've never met a CSS Person who has read a book on CSS. Or one that can do the arithmetic on a simple flex-grow/flex-shrink/flex-basis combo.. Even with a cheat sheet.
I'm a back-end dev, I used to think that CSS was "garbage". After learning the ins and outs I think it's a pretty remarkable set of technologies. A true discipline. But, it's hard to find someone who really understands it because it sits at a weird level in the tech stack. Most developers feel it's beneath them or that they "have the gist of it" and most CSS specialists don't have a firm grip on it or keep up with browser developments.
If you're going to work with, hire, or exist as a "CSS Person" within 6-feet of me I'm going to require you to read "CSS: The Definitive Guide" before I give your laptop charger back to you.
This article is good, but it's barely the bare minimum that you need to know about not knowing CSS.
Six-figures for a "CSS Person" who's read CSS:TDG is completely worth it.
CSS and Sass are both worth mastering.
For CSS read: "CSS: The Definitive Guide" (https://www.amazon.com/CSS-Definitive-Guide-Visual-Presentat...)
For Sass read: "Pragmatic Guide to Sass 3" (https://www.amazon.com/Pragmatic-Guide-Sass-Modern-Style/dp/...)
Here are some book and video links (with Amazon affiliate tags snuck in). I've read all of these books cover-to-cover save for the RxJS one. They approach front-end as a set of technologies that should be understood and mastered rather than the "CsS hAckS to GET YoU pAiD!" style of most web tutorials.
Not sure where to point you with React but if you decide to use Angular or Vue I have some suggestions.
CSS/Sass:
"CSS: The Definitive Guide": https://www.amazon.com/CSS-Definitive-Guide-Visual-Presentat...
"Pragmatic Guide to Sass 3: Tame the Modern Style Sheet": https://www.amazon.com/Pragmatic-Guide-Sass-Modern-Style/dp/...
This Sass book has the best structure of any introductory tech book I've ever read.
"TypeScript":
Mastering TypeScript 3: https://www.amazon.com/Mastering-TypeScript-enterprise-ready...
"Programming TypeScript": https://www.amazon.com/Programming-TypeScript-Making-JavaScr...
RxJS: Reactive programming the most significant development in UI technology in 20 years. Once you get the hang of it managing asynchronous events (user generated, network generated, time based, etc) become a breeze.
"Build Reactive Websites with RxJS: Master Observables and Wrangle Events": https://www.amazon.com/Build-Reactive-Websites-RxJS-Observab...
RxMarbles - Interactive RxJS visulizations: https://rxmarbles.com/
Angular:
"Angular Development with TypeScript": https://www.amazon.com/Angular-Development-Typescript-Yakov-...
"Architecting Angular Applications with Redux, RxJS, and NgRx: Learn to build Redux style high-performing applications with Angular 6": https://www.amazon.com/Architecting-Angular-Applications-Red...
Videos:
I watched most of the Layout Land videos when I was getting a grip on the state of CSS. Jen Simmons is a developer advocate at Mozilla and has the best overviews I've seen.
Basics of CSS Grid: The Big Picture: https://www.youtube.com/watch?v=FEnRpy9Xfes
Using Flexbox + CSS Grid Together: Easy Gallery Layout: https://www.youtube.com/watch?v=dQHtT47eH0M
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.
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.
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.
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.
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.
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.
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.
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.
I'm not a CSS person, but I've read three (including CSSTDG) and I still can't do anything useful with CSS.
img {
display: 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".
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.
figure img {
display: block;
}
figure figcaption img {
display: inline;
}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.
Nope.
An incompatible and broken version of Flexbox is supported in IE11. Therefore, layouts look completely different (and broken) when rendered in it.
Only people who recommend Flexbox in IE11 haven't tried using it in IE11. I might via a library that did the heavy lifting for me, but there's just too many bugs to recommend anyone write Flexbox and expect it to just work -- it won't/doesn't.
PS - I'd link all the IE11 Flexbox bugs but Microsoft took them offline with Microsoft Connect's retirement.
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.
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.
The standards addressed a lot of the pains and struggles we had with floats/clearfix etc. This was challenging but nothing im comparison to supporting IE 6-9, FF, Safari, Opra etc. at the time. Also hacking in JavaScript added to the complexity.
Nowadays I can do with 10 lines of grid and flex what great CSS frameworks like Bootstrap abstracted away behind 1000th of lines of code.
Also testing is way easier, since browser vendors follow standards and there is chromium everywhere.
Earlier we did a lot of div soup, I remember fondly CSS zen garden as well as OneDiv.
Awesome times to be a web dev, you work on products (PWAs!) not on browser hacks.
My 2 cents.
The present-day CSS frameworks use "class soup."
For example, tailwind (which I like):
<button class="bg-teal-500 hover:bg-teal-600 focus:outline-none focus:shadow-outline"> button {
--background: teal;
--focus-ring:
2px 2px 5px skyblue,
-2px -2px 5px skyblue;
background: var(--background);
box-shadow: none;
}
button:hover {
--background: wheat;
}
button:focus-visible,
button:focus:not(:focus-visible) {
outline: none;
}
button:focus-visible {
box-shadow: var(--focus-ring);
}
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.
Not like I’m teaching anyone these days, but I’m not sure about that. Yes, there’s just more now. Grid and flexbox and transforms and on and on.
But if you were totally starting from scratch, certain stuff is just way easier now, or at least, not a pile of hacks upon hacks. Basic beginner stuff that comes to mind…
• How can I center something vertically and horizontally without having to explicitly know the size of the container and object to be centered?
• What is all this float stuff, how do I just make a grid of icons?
• Wait, borders fundamentally change the size of my div? What?
• I have to do what now to have a drop shadow?
• How do I keep my branding colors consistent without having to make really sure I plug in the right hex values in every little color declaration?
The fact you could use them to build all sorts of header/column/footer layouts was both very helpful and entirely confusing.
It became the default way to use CSS, for good reason. Yet, I always felt it was a shame it wasn’t often described as the hack it was.
Back then, you had to put some image to make a fake border-radius.
Or some weird hack because table layout doesn't wrap.
And using a different technology that is flash because css couldn't animate.
Not to mention the existence of transpilers like stylus that make writing far easier and we no longer have IE6 that behaved on its own rule.
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).
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!
> 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.
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.
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.
The "CSS Zen Garden" from 1999 gets posted about every 3 months and makes it to the front page...
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.
My recommendation: take a calculator or spreadsheet and start with some simple cases and build up your knowledge in a exploratory manner. A few hours, a session for each feature (flex, grid).
Its not only fun but also really helpful!
I know just the thing!
It's far and away the best resource on CSS I've encountered in my 22-year career working with web technology for a living.
No affiliation, just a grateful patron.
> That's a radically misleading comment. It covers much more than layout
Given the site and all 3rd party reviews just mention layout, how is it misleading? Cant find TOC anywhere?
Also, found working discount code 'BRANDEMIC' for 60% off in my travels should any1 bite the bullet.
prev hn sub/182 comments: https://news.ycombinator.com/item?id=20196061
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.
Also zeal (dash on Mac which is paid or you can build zeal yourself like I did) has docsets for CSS which are good.
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.
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.
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..
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.
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.
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).
Having used it for over a decade, it's a wonderful tool.
> 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.
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 it mainly via the wicked_pdf ruby gem and I'm sure there are wrappers available for other languages too.
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 }
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.
(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.)
Browsers have been able to zoom pixel widths for years.
Some time ago, I wrote up a series about CSS. It’s still quite relevant (but CSS has come quite a ways, since then).
The thing I’ve found that is often misunderstood, is specificity. It’s a fairly non-trivial concept: https://littlegreenviper.com/miscellany/stylist/introduction...
display: inline-block
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.
> The element generates a block element box that establishes a new block formatting context, defining where the formatting root lies.
https://developer.mozilla.org/en-US/docs/Web/CSS/display-ins...
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?
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].
2: https://preset-env.cssdb.org/
3: https://github.com/w3c/csswg-drafts
4: https://www.smashingmagazine.com/
https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_...
CSS and front-end browser work drives me up the wall.
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.
...which kinda reflects "things I wish about CSS", so 10/10.
But "it works differently every time I try" wouldn't have made a good CSS joke. Oh, wait.
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.
So understand what creating a block means. Inline-elements don't.
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?
em is often used for the padding of elements. For example buttons that exist in different sizes.
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.
my-element::part(custom-selector) {
/* ... */
}
.container { display: flex; align-items: flex-start; }
OMG!!! where have you been my whole life you little flex darling :)
you have no idea how much trouble and pain it is to align elements that are table cells.
(c) Elon Musk, speaking about CSS (maybe)
https://css-tricks.com/examples/nth-child-tester/
eg. try 3n+1, 3n+2. 3n+3 and then different multipliers
You got me at, "This was back in 1999, when we’d write things like <font size="4" color="#000000"> and DHTML was a thing."
’twas the time when understanding the CSS Box-model was the graduation opportunity to be part of the CSS-Pros.
OR it counts rows from zero instead of 1, rather than all this about siblings...
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 browsers zoom dynamically nowadays? When is this actually an issue?
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.
"So, you've been doing CSS since 1999. Please tell me how the width/height of a box is calculated?"
Sadly, everything has to follow Webkit these days...
Unless of course you set an input to display: block....
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 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.
1. If I already know the tidbit, I give myself a pat on the back
2. If I don't know the tidbit, yay, I learned something.
Someday I'll be 100% in the #1. What got me in this article "ch" size.
Fact: the heigh/width calculation has changed over the years. It is likely this article captures the final method, let's hope so.
Link: https://pitayan.com