- This means that your browser finds the right-most sub-selector first, then tests each item that matches to see if it matches the next sub-selector
- Avoid using element sub-selectors, and the * for this reason - every element that matches this sub-selector will be tested (that can be a lot of elements!)
- Specificity is the biggest pain in the arse about CSS, so make it easier for future-you by not being overly specific
- If you make a selector overly specific, the next time you use that component you'll have to be more specific and so on - imagine that after using something 5+ times
- Consider that every time you nest something in your SCSS, you're adding another sub-selector - do you really need to nest it there, or would it style it without being even more specific?
- Your SCSS should not look like your markup. Don't nest everything! You're making crazy long selectors that don't need to be, and the more specific they are, the more of a pain they'll be later when you have to override them.
- If you take your component away from it's current location, does it break? Is it dependent on it's parent's width, or prior element's height to work? If so, it's not really a component - the whole point of a component is that it can be used anyway, not just that it's CSS has a namespace!
- After you've written your CSS, see what properties you can remove in your browser - this helps to trim your CSS down (less rules for the browser to parse), and means there's less things for you to override later.
- Your CSS is for presentation, and should make sense on it's own - it shouldn't need the HTML to give it meaning. I'm talking descriptive classes that actually make sense and describe what they do.
- A bit of a cliché, but this has more of an impact than just performance: it forces you to think about your component as an instance (no more "oh, it doesn't matter, as there'll only ever be one on the page anyway" excuses)
- This also applies to JavaScript - using classes rather than IDs forces you to think of your CSS as a component
- This means that the "adjacent sibling" selector is actually the "adjacent, younger sibling" selector, because an element cannot see the previous element, only the next one. Yes, CSS is a lie.
- Essentially, your CSS is not affected by that which came before it (hence, cascading) - this applies both the the CSS itself, and when it's applied to a page. Parents can be seen, but previous siblings cannot. Yes, it's fucked.
- SCSS: .card-number { input[type='text'] {
- Compiled down, it looks like this: .card-number input[type='text']
- As far as the browser sees it, this is actually two sub-selectors: input and [type='text']
- So, we'll find everything with a type of text, then check if it's an input... wait, what? Only inputs can have a type of text... we don't need to check this, it'd be like checking if everything that was a ford mondeo was a car... it's implied. Think about what you're writing.
- This isn't the card number - it's the container for the card number and it's label. I wouldn't necessarily know this unless I knew what the markup looked like, especially if I was looking at just .card-number, styled further up. You might know what it is, but the next person to come along doesn't.
- This smells of non-reusable CSS! It's a container, and based on what it does maybe it should be .row or something similar? Something that's not specific to this form, because the styling itself isn't, so the class should reflect that.
- All elements on page -> get those that have type text -> get those that're an input element -> get those that're in .card-number -> [...] -> style
- .card-number should probably be the input itself - maybe even .card-number-input - then our selector could simply be .card-number, because that's all we're actually interested in, and we want to get there as fast and simply as possible.
- .card-number container should be something reusable, so that we don't end up duplicating styles/work.
- All elements on page -> get those that have a class of card-number -> [...] -> style