Being a backend developer, I've always assumed CSS to be magical.
Recently I needed to learn CSS to make my website viewable, so I started with w3schools. But the pace was too slow, and it made me search for other alternatives. A good amount of SEO friendly sites containing the list of best CSS books suggested `CSS In Depth - Keith J. Grant`. With low hopes, I thought to give it a try just for a day but it did not disappoint me. Being a CSS noob I liked the way `Layout` concept was presented. It started with `float` and ended with `grid` with a couple of chapters in between dedicated to `flex` and other techniques. Then it picks up responsive design. The concepts were presented in such a way that it became a responsibility for me to replicate whatever the author has done in the chapters. It was a satisfactory experience.
Afterward, it presents the transition and animation related concepts which I read but I've forgotten because of not using them in day to day work.
Hmm.. I see chapter 3 is "Mastering the Box Model", which is the part my co-workers really don't understand and seems to be the whole reason they treat CSS as magical. So that definitely sounds like a plus for that book (especially since one of the headers mentions border-box), although I've never read it myself.
From the headers it's not clear if it touches on block vs inline vs inline-block though, nor how margin/border/padding are related to each other (though that could just be mixed in with the border-box section). Is it complete there?
I can second this and also mention that if you buy it through manning it is DRM free! They also have a "livebook" version that lets you try code right inline with the book. Highly recommend.
This site which was posted here a while back is great, it's up to date and explains the concepts CSS is based on clearly with examples using Codepen so you get to see both the HTML and CSS as well as the result, plus you can open them in Codepen to edit them yourself. I've been doing CSS for close to a decade and learnt quite a few things from reading through it :)
I only started feeling a sense of actually understanding CSS (as opposed to working on it based on acquired intuition) when I started reading the official specs. I think that most other material is an abstraction over those that usually doesn’t explain the broader context surrounding a feature or its edge cases / interactions with other features. For example here’s the spec on positioning: https://www.w3.org/TR/css-position-3/
I’ve found directly useful information in specs that was not commonly pointed out in tutorials/stack overflow/etc when discussing those features (not remembering a specific example right now unfortunately). Can say the same for JavaScript.
I think in general when learning about an API it’s best for understanding to read primary sources. And thankfully the W3C specs are quite good documents and not too inaccessible in my opinion.
> Articles on features that haven’t shipped yet and may never ship everywhere.
> Advanced features that address specialised use cases you’re never going to encounter.
This is why, as a backend developer, with little time to invest into CSS, I will rely almost 100% on frameworks like Bootstrap or Tailwind. I do not have time to go and check if a feature has been adopted on most browsers or whether they are super advanced or unorthodox.
By using a framework I trust that people much smarter than me at CSS and who actually gives more of a damn at keeping up with it have worked a feature into the framework and if it is not found then that is a limitation that I do not wish to overcome with research, hard work or trial and error.
If I can use some brevity: I have other, usually more important, shit to do.
I’m a backend engineer too and I learned most of this css stuff fairly easily in a few weeks without much pain. The truth is something like tailwind can get you to understanding 95% of css, just by digesting someone else’s editorialized model of it. You also sidestep a lot of issues with class-based nature of CSS, which just complicates the learning experience.
I can copy/paste an extremely complicated layout that I made in tailwind to an entirely different section of html or the codebase, and 99% of the time it just works.
Anyway I highly recommend to everyone who comes from a backend background to just learn something like tailwind. It’s basically css, just expedited and editorialized by professionals. When you run into gaps in the metaphor they’re easy to understand why they’re there, and you can easily add them yourself using their plugin system, which fit me just enhanced my own learning.
Maybe I'm not using the right terminology - definitely not an expert - but I think Tailwind is "utility based".
When I said side step issues with class-based natured of CSS, I meant there's really no way to leverage the cascading nature of CSS using tailwind. You don't even really write css in tailwind. Because of this you get code duplication, but your styling is super portable. This, I think, is the nature of using a utility based framework. You can literally copy and paste almost anything and it will probably work, because the specificity doesn't depend on any sort of class hierarchy or make any assumptions about the structure of your css classes.
They're basically inline styles but use class names that are designed to be more useful than just writing css inline. Basically a light amount of editorialization.
But like I said I don't really know, so if someone knows a better way to word what I'm trying to say please correct me. I think the tailwind creator said something like "the canonical way of writing 'modular' CSS just doesn't work" (I'm paraphrasing but something to this effect).
The "other" options to utility/tailwind approach is to avoid classes, and use semantic html (easier in HTML5, where you can just decide you'll have an <article> with <lede> and <section>s) or heavily customized css classes (like bootstrap).
Main difference between tailwind and bootstrap, is that bootstrap still assumes you'll have some container-elements that wrap other elements - while theoretically tailwind styles every element in isolation. (sort of)
As a developer, my problem with css has always been this:
I want to build a website for some project I'm working on, then I realize I have no idea how to design it, so I start looking for nice looking templates online and get to a rabbit hole of templates that has nothing to do with css.
Them I basically realize that css is not my (first) problem. I have no idea how to design a website that looks good.
I suggest taking an used A4 piece of paper and fold it in thirds on both the horizontal and vertical side.
Holding the paper vertically, you'll notice you now have 3 main sections (header, intro, rest of the page) and 3 columns you can arrange your content into.
Take another A4 piece of paper, fold it in 3 and then in half this time, you'll have 3 main sections and 2 columns in each section.
Now cut each of the 3 blocks from each paper, you will end up with 6 sections (3 with 3 columns and 3 with 2 columns)
Try and write some of your content down on these 6 Lego blocks you created, sketch images (or just draw a rectangle with an X inside, that means "image placeholder" in graphic design layouts).
This exercise will help you understand how design is just content split in manageable parts.
You'll soon notice most sites are not monoliths, but the very same blocks you jotted down on paper.
This will make your template-scavengig effective, you'll notice you like certain types of blocks (say 3 columns with a background image) and dislike others (say hero banners with buttons). Steal the ones you like (crop screenshots and save them), then see if you can see what you like in each of those you saved. Try and recreate them as abstractly as you can either on paper or by using the rectangle tool in any graphic editor (don't get lost making it perfect, you'll get there faster by doing it by code instead than using graphic design tools).
Toy with design, it's all a fad anyway and what matters is what I've outlined here: blocks, columns, steal what you like.
Most bad designs I’ve seen can be dramatically improved with some very basic design concepts that I think most developers can learn, at least towards getting the design looking relatively ‘clean’.
If you can’t apply a theme or make use of a designer, keep all your colors gray, and just focus on the shades. Darker shades to bring emphasis.
Secondly, make sure there is consistent padding, margins, and alignments. This is more tricky because it requires you to see the empty spaces and think of them as their own elements. Always be looking for areas of inconsistency and misalignment. This finicky because just two pixels offset here and there can have a big impact, but it is very much worth making thing look more consistent.
Lastly, look for opportunities to reduce the total number of visual elements in busy areas (within reason). Good examples of superfluous elements example might be outlines around icons, underlines, borders, two “empty space rectangles” that can become a single rectangle.
I’ve found 70% of my design methods are just applying these three concepts over and over again, and formulating somewhat logical principles to apply them. My designs aren’t as good as what a designer would produce, but are much higher quality than I didn’t apply any thought to design at all.
I was looking for a static site template just earlier today (along the lines of Hugo, Jekyll, etc.) and was quickly reminded that a lot of templates available online, and there are thousands both free and paid ... do not look that great or work that well. Even ones you like at first blush will likely need a ton of customization to fit your use case.
Rabbit hole, indeed!
For picking a usable one, I think other comments in the thread have it right: look for basic things like consistency of the spacing, non-obnoxious colors and fonts, etc. Does it just seem "clean" and usable at first glance, or does it give you an instinctive mental itch that something about it seems clunky or poorly done? Or too contrived or too opinionated for your use case?
And whether or not the design breaks on mobile. Even if you don't really care about mobile for your use case, if a pre-built design gets it right, that's a good indicator that some care and thought went into it.
I have this problem too. And unfortunately as I go through the templates. I don't really like any of them. And I generally quit and just use basic bootstrap.
And even the templates I have used end up being so incredible messy and full of things like bootstrap overrides that effect the rest of the site in unexpected and unwanted ways that I try to stay away from them as much as possible now.
I just really want isolated designed components that I can put around the site. But I haven't found an option I like their either. :(
I recommend learning about BEM and Inverted Triangle CSS (itcss) approaches. ITCSS dramatically improved how I write css as it naturally works with the cascade and removes most duplicate efforts.
I found this particular article instrumental in building my understanding of CSS's flexbox feature, which largely replaces decades worth of ugly, nasty positioning hacks with a handful of simple definitions:
Beyond that, the only advice I can give when starting out is to avoid inline "style=" attributes like the plague, and figure out how you want to organize your elements, styles, and classes. This is the trickiest part to get a feel for, and there's no substitute for practice. Frameworks like bootstrap and semantic ui make for especially good starting points, giving you a collection of opt-in helper classes for the basics, letting you focus on adding whatever custom stuff you need for your site without implementing a ton of extra boilerplate. You don't need to use them, but they can help you get a v0.96 built very quickly during your prototype stage, and they're battle-hardened enough to be used in the wild if you decide you like their opinions.
The book chapter outlines the philosophy, and Tailwind provides a functional system for putting it in practice.
For both of these, you don't need any CSS background. Not only does the video series teach you Tailwind, it'll also give a foothold onto CSS, and how to use it in practice to make reasonable websites even if one is design-challenged.
I think Kevin Powel[1] is worth more than one mention... Although I think Video-Tutorials are usually inferior to text based tutorials regarding the time it takes to learn something, I don't think so in this case... he has mostly awesome stuff and really focuses on the important things.
A lot of my personal collection of CSS tricks[2] are inspired by his videos...
I also am taking that course (1/3 completed so far, it’s a long course) and have some things to say. Not affiliated in any way, my company paid for it.
I think it doesn’t teach anything you couldn’t learn yourself by reading the spec or css-tricks etc, however there’s just no way I would have bothered reading those things myself as in depth as I am going with the course. There’s definitely some information in the course that I don’t feel is useful, and I already knew quite a lot about css so most of it is familiar, but I still learn important things every time I sit down and go through a module. And I love the interactivity and actual practical challenges included.
So overall I give it an 8/10, and would recommend to anyone working (or who aspires to work) on the frontend.
Is it worth $350? If you’re on an average dev salary then yes, if you’re in school or not exactly floating in money, then I’d say stick to just reading free content online or making things you enjoy and learn by doing.
I second charesjrdan's point. If money isn't a huge factor for you and it's a course you're excited enough to pursue then go for it.
The course isn't necessary however. Reading through MDN docs in addition to Josh W Comeau's blog should get you 90% of the way there, if not all the way there.
I took this course and it really is superb. Josh builds mental models like media queries as IF statements and compares selector specificity to prototypal inheritance. It's mentally really sticky stuff. He also goes in depth into the different layout modes(flow, position, flex, grid) and ensures you know the differences between them, when to use one over the other, in which cases one overrides the other, etc. If when youre building something you go through every combination of flex, grid, & position and not really sure which one is going to get you closer to the layout you want, these exercises will build your confidence. He breaks down lots of edge cases and quirks that go into CSS that Id consider "mastery" level that only someone who dreams in CSS would know off the top of their head.
If you live somewhere where this price is too expensive (south America or some SEA country for example) Josh offers to send him an email and he will give discount, if he agrees that it is fair.
Edit: adding source for my claim.
Go to the website of the course that was already posted here and search for “Purchasing Power Parity”
I can confirm and share additional details. Located in India, I automatically see a message that says I can choose a purchasing power parity discount if I wish to. The discount is 70%, but it applies only to the most expensive package (bringing it down from $349 to $105). The lower tier packages are marked as not eligible for such pricing. It clearly says that the access will work only in India (I’m guessing this whole thing is based on IP addresses).
I don’t yet know if I’m interested enough in this course, but I really appreciate content authors who consider pricing variations in different locations. Bonus if they offer to help people in tough situations (even in countries where PPP may be higher).
Just echoing the other users. It’s definitely great and the community that comes with it is good, but the value prop it’s asking for, particularly since it’s attempting to charge a college course, you can be fine through trial by fire. A meetup, or even a proper discord can give you similar value.
I don't see A List Apart mentioned - it has a lot of great content, but has perhaps become less relevant as CSS has stabelized quite a bit. But articles like:
I'm surprised no one mentioned Lea Verou's "CSS Secrets" [0]. Most books I've read will give some depth at how aspects of CSS work, or recommend a best practice, but Verou's work is the only one I've seen that sees using CSS as an engineering solution. The book is a collection of problems, e.g.
"how to add multiple borders?", And the shows different ways to solve the problem given the available CSS. Each solution discussed trade-offs, constraints, etc.
It will go the farthest in teaching you how to think about CSS
I am a backend engineer and recently had to improve my CSS to work on a side project. I highly recommend book "CSS in Depth" by Keith J Grant - it helped me to build a solid foundation.
My rant about CSS. There is nothing like "compiler error messages" for CSS. The best we have is "inspect" in browsers. It shows the final state of browser has done, not the intermediate "why" or "how" part of it. For example, we will know that an image overflows a div, but browser won't tell why.
Firefox's developer tools shows a warning against CSS properties that will not function as intended (i.e. flex properties on a non-flex container). It can be quite helpful for debugging unexpected behaviour.
I have the same complaint, but I also don’t know how such a thing would be addressed. Ideally I would like to right-click a computed style value in the devtools and be able to hit a “But Why?” option, but I feel like even linking to the relevant part of the relevant spec would be a monumental engineering effort.
The problem is almost never that the CSS you wrote has a syntax error.
The problem is almost always the CSS with no syntax errors you wrote isn't doing what you wanted it to do. The browser doesn't know what you wanted it to do so it can't help you.
That's obviously true, the browser just blindly interprets the rules. However, sometimes spec changes or solidifies in a way that can break existing code so there are other cases to consider.
There's also tooling to catch these errors if it really matters.
In Firefox (not sure about the others), they do give some info on some errors, such as what might be overriding a rule (other rules or not an appropriate display type or something) or some invalid property or value. Not perfect, but it is not all in the dark.
And the ability to directly manipulate the CSS and see the impacts can make getting the right visuals fairly quick, not to mention the ability to change the view size and directly interact with that in all the different screen sizes.
To get some great gamified practice with some CSS concepts, I recommend https://codepip.com/ The well-regarded Flexbox Froggy and Grid Garden come from that site, but there are a number of other ones. I believe they all have some mini-tutorial aspects to them in addition to using the syntax to accomplish specific goals.
I also recommend two that were already mentioned but I have found them extremely enlightening: CSS-in-depth and CSS-for-JS-devs (I am a programmer first so it speaks to me).
I have also enjoyed the first few episodes of The CSS Podcast though I have not gotten to far into it.
If you want to make CSS make sense read about its history, it isn't sensless its just layers on layers of really old tech used for someting completely different than what it was designed for. CSS was made for typewriters and because the first web were just text on a page it was used for that, then a long dark age began which was finally vanquished by the light of flexbox.
I’ve been primarily writing css for 15 years and I learned through reading spec and MDN about what I needed when I needed it. If you already know some css I strongly recommend reading the spec about the basics like display and position. A lot of junior developers I’ve hired can use css, but don’t understand why you’d use block vs inline or flex vs grid… and knowing this stuff can help avoid a lot of frustration that comes with kludging around until you get it to work.
Flexbox became much easier for me once I had some experience with tools like QT Designer and GTK's Glade. Those tools force you to understand the mechanics and elements that drive responsive GUIs more or less immediately.
Once I came back to styling with CSS, I immediately understood how to use flex and develop slick UIs with it.
The source of web sites that have good design. Use developer mode on a browser. You can edit their CSS live and see the results. You can change the viewport and see how it renders on mobile. You can figure out what's using JS and you'll come to your own conclusions on whether that's the right way to do things.
While you're reading, start building things from scratch. MDN is a great resource if something doesn't make sense.
I believe there are two things everybody should know about HTML/CSS that could help you immensely.
1. Know that everything is a box that wants to float up. Learn about `display` and `position`.
2. Know about how things are measured. I think this is what causes the most troubles. You think something is 50% so it should fit, but it doesn't.
Almost all of these problems go away with `*{ box-sizing: border-box}` but you should learn about this.
Makes sense in general. However there's a geat deal of expectations related to the intended look. These expectations are formed by the current looks of the popular sites, which may be built on frameworks. So trying to achieve such outcomes from scratch would be quite a lengthy journey.
For a practical way to learn CSS, perhaps a set of simple styling objectives should be sufficient in order to understand the mechanics of CSS. I'm not sure if there's any value in memorizing the myriad of tweakable props or "the tricks" and browser specifics.
I agree, no need or even possibility to build a football stadium to learn construction. Fix that screw holding the radiator. Maybe make a shelf out of wood. If you are brave maybe construction a patio from scratch. I think people don't realise how CSS and tech in general is about fiddling with things. And literature is becoming out dated at a faster pace than ever. So I would rather warn against "good" reads rather than recommend that path.
Fixing annoyances of highly-obfuscated Google+ sourc using Developer Tools under Chrome and (my strong preference) Firefox, a style-manager extension (Stylus), the W3C documentation, Mozilla's web dev discussions, and Stack Exchange and Reddit discussions did the trick for me.
(Given my recent adoption of a B&W e-ink device, I'd either reverse my preference for off-white / off-black for straight white/black, or use @media queries to probe for device colour depth. On balance, I'd probably opt for the first, simpler option. Getting font-size correct for the reader, line-lengths to a readable width, and margins such that text does not run into the gutters is really the principle objective.)
I like writing CSS to some extent. You get the immediate satisfaction of visibly getting things done and compared to a lot of other things, it's just memorization of few tricks and rules. It's the persistence of wanting to get things just right and not being satisfied with them being a little wonky that I guess makes the great dividing line.
If you don't like polishing details, well you are in a bit of bad luck. Unlike with backend code, with CSS your mistakes will show and be evident to everyone who can distinguish bad design from good.
And often doing less is better. It might sound self-evident but when you are making some dumb positioning with tops and lefts you are probably doing it wrong. Or there can be an easier solution. And when you color or add borders you probably want them to blend in, not stand out. Often a very small change in hue can be enough to provide depth and contrast.
It turns out most users do not really care for visual bells and whistles since visual noise gets in the way of doing things, which is why the lowest common denominator of shopping and restaurant sites have all converged on a basic design with a few splash photos or pretty typefaces to spice things up.
Of course. Simple is not necessarily easy or obvious, and then you have to fight the countercurrent of everyone and their mother having an opinion on what things should look like, the facts and metrics be damned.
People don’t just RTFM for the same reason people learning a language don’t just read a dictionary.
The manual doesn’t tell you how people do things in practice, common gotchas you need to handle, tooling, or how to combine different bits together. Not to mention there are multiple manuals, and it’s unclear to a beginner with which one you’d start.
I think that CSS is 80% learning how to position things. Once you really grasp that, rest 20% is a lot easier. I also struggle with the whole container/box thing and not to mention position:relative vs absolute and what not. But then there are the easy ones like margin/padding/color etc.
The article seems to focus on what is and isn't good to read. I'd say, don't focus on reading at all, focus on building. Decide to build something that'll need some CSS, and search and read and try things in pursuit of the goal of getting that thing working right. It's more interesting and easier to remember things that you've actually used, or at least tried and decided not to use, than to just read about 50 things that you might never use at all.
I've always found value in at least scanning some articles and books for general overview of what is possible. Many dev get to a point where they learn a method and abuse it. It's the method they know and have never been exposed to an alternative. They found something that solves the problem sorta so why go look for something else.
While reading a lot of articles and books gives you a wider view, you don't have to memorize but as the article says, know it exists.
You really can't avoid CSS unless you use turgid, opinionated and increasingly out-of-date stuff like Bootstrap and it's ilk.
If you just want to be able to execute your will intuitively, it's much better to learn "enough" modern CSS and stick to modern browsers.
Now with CSS Grid for layout it's so much less frustrating than just having Flexbox, and a world away from the dumpster-fire that was Floats (and before that, html tables).
I agree, for all functional layouting (not text) grid gives you so much for so few. You can spend a year trying various float tricks and get nowhere, or napkin write a grid layout and get going in 5 minutes.
Writing modes, box-model, margin, padding, positioning (relative/absolute), flexbox, grid, media queries and units (px, %, rem, em).
I've tried following the blogs mentioned in the past but it wasn't really worth the bother. I don't really care about CSS beyond the need to use it to solve problems - and to do so with confidence that I know what I'm doing.
That's the most important thing in CSS, to really understand the fundamentals so you're not frustrated or in a state of trial and error. Seen too many devs who work this way.
Even with years of experience, probably the fastest way to debug tricky CSS is to disable all even close-to-applicable rules, and re-enable piece by piece until you find the culprit.
My first job out of college was writing html/css for email messaging. In the case of webmail you had to contend with the butchery of email clients, email servers, and the browser. That was when IE7 just came out which had a different box model than IE6. That was the school of hard knocks.
After that CSS has been mostly trivial to write cross browser for me. The biggest challenges I would encounter are helpers, like jQuery or frameworks, getting in the way and breaking things.
It even helps to just study frameworks’ documentation. Tailwind and Foundation/Bootstrap are both great ones that approach CSS through different opinionated structures.
it really depends on what you are trying to make and several common designs are not entirely intuitive.
for example, if you want to make a single screen app (the body doesn't scroll) I know of no css frameworks that do this. Tailwind, Bootstrap, are for height unrestricted pages. I'm not sure what a good example of single screen pages are, maybe codesandbox, google maps, google slides, codepen.
Maybe someone has a suggestion for a framework that handles l the conatraints of keeping a bunch of content panes filling the window and no more with all the pane's content able to fill the pane with zero issues. I always find that trying to get say a canvas to be 100% of its container in such a situation to be trial and error.
another imo unintuitive CSS design is the Medium style of paragraphs have a max-width but images do not. The arguably normal way to constrain a bunch of content is a wrapper for all of that content and the wrapper is set to the max-width. But that doesn't work if you want images to go bigger than that wrapper. I'm not saying it's hard, only that it was different than just about every previous site out there. and imo "margin: 0 auto" is not an intuitive way of centering
vw/vh are units based on the viewport width and height. 1vw is 1% of the viewport interior width, 1vh is the same for height. The border box box model ensures that padding and borders subtract from the interior dimensions rather than add to the exterior
dimensions.
Grid might solve some issues that Flexbox didn't but my experience is that without fail, I try to make the various panes, then I try to put some content inside the panes and either (a) the content doesn't correctly fill the panes (b) the panes get warped in ways I wasn't expecting because of the content. And, it's always a bunch of trial and error and unintuitive crap like "max-width: 0" to get it to work
If you are just getting started, take an online class. Seriously. Reading page source or inspecting the applied css on other website will be slow confusing process.
Go to lynda.com (now linkedin learning unfortunately) and take the css essential course, then build your own personal website. The videos will give you good fundamentals and your website will give you real world experience.
No amount of advice or tricks can help you when you don't know the fundamentals.
> how you optimally structure your CSS for composition and reuse.
I have the most trouble with this with CSS. I'm ordinarily at keeping my programming logic well-organized and maintainable, but with CSS I do bad and feel bad about it.
Appreciated the references for some things to read on this.
I feel like your approach should depend on your particular project/needs.
With modern frameworks, CSS/SCSS is often "scoped" to components which could lead to just a handful of general purpose or page specific CSS files that need no organizing as files go.
Content of said files is another topic. Inheritance is built in and you can overwrite pretty much anything from everywhere. That's both good and bad.
If you happen to reuse something, put in (one of your) main css file. Having your own set of lego block goes a long way.
I live and breathe CSS and have since its inception. Having interviewed job applicants of all levels for front-end positions I can only say, boy oh boy, most people seem to think CSS is arcane magic.
I would recommend learning by doing. Don't waste time reading a book - just get out there and do things.
Top tips for someone starting out: learn the box model, then look at flexbox or grid. MDN is pretty much all you will need in terms of reference and pared-down examples
Totally this ^^^. I still battle with CSS. I have no love for it but the best way I've found to approach it is to have some idea of what I want to achieve visually and work from there. Almost everything one would seek to achieve has been done by $someone and is out there on the internet. Steal it! Sometimes it's blog posts, sometimes I just scrape other sites (modern browser really help here). But yup, grid, box, floats. MDN rocks.
Speaking of battles, I’ve liked trying CSS Battle’s challenges. Kevin Powell and some others have YouTube videos where they compete but it’s not really that competitive.
Don’t worry about minimizing the number of characters, try to match the challenges 100% with just enough HTML and just enough CSS rules and properties to be elegant.
Somewhere on the continuum between "learn by doing" and "learn by studying", the truth lies.
I mostly learned CSS by happenstance "doing" and have been able to do a fair bit, but I didn't really understand selectors until I went through a book on CSS.
There is a good MDN page on CSS selectors that takes about 5 minutes to read. Sorry you wasted time reading a whole book! You can't get that time back.
That page is actually part of an MDN module, which is sort of like a book. I actually considered going through that MDN module methodically, but ultimately chose a book I thought was more suitable for my needs.
For me, developing a sense of mastery over selectors meant studying all their variations and practicing with all of them. I also had to understand that "selectors" were a thing in the first place — a coherent and scope-limited topic that I could study and master. I didn't really get that from all of my CSS practice — the book gave me an agenda I wasn't able to develop on my own.
> Sorry you wasted time reading a whole book! You can't get that time back.
It's not like it was an entire book on selectors. I don't need that time back — it was productive, and I learned a lot about many aspects of CSS.
Of course, it would have been less productive if I had not
already accumulated a lot of knowledge via the "learn by doing" method. I'm certainly not opposed to that... it's jarring to see someone so adamantly opposed to books.
(For the curious, the book was Architecting CSS by Martine and Michael Dowden. It's not really a beginner book. I chose it because I needed to understand how to organize CSS in large projects to get more predictable behavior and reduce time spent on maintenance and debugging).
Css classes will complicate the css it can for example become hard to see what takes precedence when you mix classes and element. And it doesnt help that CSS is also has significant white space as in .foo.bar vs .foo .bar
So by practicing withot classes you will find that classes are rarely needed and in turn all your CSS get more simple - as long as you understand specifically. And you will also start to appreciate semantic HTML, and hopefully replace some of the divs with the appropriate semantic element!
I couldn’t agree more, and the hilarious thing is that I have spent much of the last few months doing exactly this. I’m writing yet another static site generator so by definition it must use classless HTML as the output. I am greatly enjoying the challenge of preserving semantic information while also making the output attractive. Thanks for the clarification!
Not just more specific rules, ones that just come later in source order too (with an identical specificity).
Oh, and more "important" rules too. "!important" overrides everything. Well, except more specific instances of !important, or instances of !important with the same specificity but later in source order.
Specificity is easy, the amount of specificity a selector has is measured using four different values represented by four single digits in four columns. (Of course, a single ID will override a thousand nested class selectors.)
And that's ignoring the origin of the rule (author, user, or user agent stylesheet).
> You are basically doing the same using another syntax…
You seem to be thinking of Tailwind as just syntactic sugar. If that's your lens and you're not leveraging its strengths as a framework, then yes — you might as well use raw CSS.
I do thing that it's a bit more than replacing the style attribute with the class attribute using a billion classes and css rules that needs to be removed later on, but not much more. You need to know a lot of CSS anyway to understand what tailwind is doing.
Raw css is not the perfect solution either, I personnally prefer SCSS but I hope to see better solutions.
I could empathize if you were talking about political "unpopular opinions". But this doesn't seem to be that. You sound to me like the person who said "I won't hire anyone who salts their food without tasting it!"
Like everyone's saying: read the specs and start with basics. everyone thinks they can just skip over that, and it's too common to see a lot of poor choices even by the frameworks. I was fortunate enough to have to learn before flex or grid display lol
The movie industry took this very seriously. They got Norway to raid the home and prosecute the one known author. Hosting a file with the name DeCSS led to copyright infringement complaints.
So some wise guy wrote another app also called DeCSS that had the sole purpose of removing Cascading Stylesheet references from an HTML file. It became one of the most popular hosted applications for a while.
I also remember. The previous generation DRM tool (macrovision) only needed a simple ~5 dollar filter to defeat. You could buy aftermarket boxes that would strip it in-line, plug and play style, for about 10-20 dollars in the early 90s.
Thankfully for the rest of us, the inevitable failure of all rent-seekers is that rent-seekers don't tend to be very smart / innovative (by definition, I suppose).
Recently I needed to learn CSS to make my website viewable, so I started with w3schools. But the pace was too slow, and it made me search for other alternatives. A good amount of SEO friendly sites containing the list of best CSS books suggested `CSS In Depth - Keith J. Grant`. With low hopes, I thought to give it a try just for a day but it did not disappoint me. Being a CSS noob I liked the way `Layout` concept was presented. It started with `float` and ended with `grid` with a couple of chapters in between dedicated to `flex` and other techniques. Then it picks up responsive design. The concepts were presented in such a way that it became a responsibility for me to replicate whatever the author has done in the chapters. It was a satisfactory experience.
Afterward, it presents the transition and animation related concepts which I read but I've forgotten because of not using them in day to day work.
https://www.manning.com/books/css-in-depth