Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn CSS

web.dev

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Learn CSS

#151

Post by blacktriangle »

ericwood wrote: post #131
blacktriangle wrote: post #62

Earlier quoted context omitted.

I'd say that "nesting is bad" has replaced SASS. Nesting encourages long selector chains which are generally a bad practice. That CSS makes this painful is a nice reminder to only use long selector chains where necessary.

Sass still has a lot of popularity in the BEM world where you can use nesting to generate flat classnames that would be tedious to write out by hand, e.g.: .element { &__title { color: red; } &__subtitle { color: blue; } } which compiles down to: .element__title { color: red; } .element__subtitle { color: blue; } There's a lot of (valid) criticism that this makes code harder to grep, although if you structure things…

This is where I'd step in and argue BEM is a terrible idea. Any time you're encoding hierarchy like this into strings you have failed. BEM is the worst of both worlds since you have higherarchical class names and you have still created CSS that's heavily dependent on the hierarchy.

CSS wants you to write:

.element.title { color: red; } .element.subtitle { color: blue; }

Any technique that depends on discipline and organization has already failed.

Re: Learn CSS

#152

Post by abraham »

macintux wrote: post #127
Jemaclus wrote: post #125

Earlier quoted context omitted.

OK, I think I see what's happening. There's some other software that overrode the *.dev cert. I'll remove that and see if it works. Thanks for your help!

Huh, that's...unexpected. My best guess was that somehow the root certificate was missing from your computer's trusted certificate store. Glad you got it sorted, happy to help.

It was a fairly common issue when .dev first launched. https://andycroll.com/ruby/clean-up-broken-dev-domains-after...

Re: Learn CSS

#153

Post by macintux »

abraham wrote: post #152
macintux wrote: post #127

Earlier quoted context omitted.

Huh, that's...unexpected. My best guess was that somehow the root certificate was missing from your computer's trusted certificate store. Glad you got it sorted, happy to help.

It was a fairly common issue when .dev first launched. https://andycroll.com/ruby/clean-up-broken-dev-domains-after...

Aha, interesting. Thanks.

Re: Learn CSS

#154

Post by suyash »

SirSourdough wrote: post #112
suyash wrote: post #102

Earlier quoted context omitted.

Yes, I found that odd as well, no plan to listen to 15 min podcast on a web-page when Im just trying to quickly learn something I need to know to fix my code. Though overall the aesthetics of the site are nice, very clean look and nicely organized.

Content designed to answer individual questions (eg StackOverflow) is often different in form than content designed to provide comprehensive education like college classes.

That's poor strategy when creating developer docs, no one wants to listen to a 15 min podcast when they come to a page to learn something or find an answer to their question. Most people on website are scanning for relevant information and they don't want to spend more time than needed, that is how good content should be presented.

Re: Learn CSS

#155

Post by lintroller »

suyash wrote: post #154
SirSourdough wrote: post #112

Earlier quoted context omitted.

Content designed to answer individual questions (eg StackOverflow) is often different in form than content designed to provide comprehensive education like college classes.

That's poor strategy when creating developer docs, no one wants to listen to a 15 min podcast when they come to a page to learn something or find an answer to their question. Most people on website are scanning for relevant information and they don't want to spend more time than needed, that is how good content should be presented.

These are not developer docs first. There are plenty of wonderful other resources that serve as CSS dev docs as a primary resource.

Re: Learn CSS

#156

Post by ericwood »

blacktriangle wrote: post #151
ericwood wrote: post #131

Earlier quoted context omitted.

Sass still has a lot of popularity in the BEM world where you can use nesting to generate flat classnames that would be tedious to write out by hand, e.g.: .element { &__title { color: red; } &__subtitle { color: blue; } } which compiles down to: .element__title { color: red; } .element__subtitle { color: blue; } There's a lot of (valid) criticism that this makes code harder to grep, although if you structure things…

This is where I'd step in and argue BEM is a terrible idea. Any time you're encoding hierarchy like this into strings you have failed. BEM is the worst of both worlds since you have higherarchical class names and you have still created CSS that's heavily dependent on the hierarchy. CSS wants you to write: .element.title { color: red; } .element.subtitle { color: blue; } Any technique that depends on discipline and or…

I don't think CSS has any particular preference, which is why there's so many different ways to approach these problems. But I do agree, I don't think I've ever worked on a BEM codebase that didn't end up messy, and the disciplined approach almost always means making tons of small naming/organization decisions as you code, which is tiring and difficult to maintain.

People scoff at CSS-in-JS and atomic approaches like Tailwind (although Tailwind seems to get a lot of support around these parts now!), but I've really come to see the value in side-stepping these issues entirely.

Re: Learn CSS

#157

Post by exogen »

I've always wanted to write my own CSS guide, because (in my experience) people are rarely focused on the right thing when they're writing CSS.

Developers (especially junior) think that if it looks right, that it is right, and they're done. But CSS is not just specifying how something looks, you are also very much specifying visual behavior, not just appearance. Content is dynamic, layouts change at different breakpoints, new elements come and go, another dev comes in and adds something later... you need to account for all of these things.

For example, a developer rotated an element using CSS transform because the library we were using only supported a horizontal layout and not a vertical one. Sure, everything looked right in isolation, but now this element doesn't play nicely with others, because transform only affects the visual position, not the offset position of the element, so all its siblings still think it's horizontal, and they're getting all jumbled together.

Or, using absolute position to, say, anchor a close button to the top right of an element. Sure, the way you did it happened to put it visually in the right spot, but it's not actually in the right spot according to the layout engine because its offset parent is not the element you're trying to anchor it to, so if other content gets put in there eventually, it will be in the wrong spot.

Or, they'll use `line-height` to add space around some copy, without thinking about how that text will now look when wrapped.

So in my opinion, any CSS tutorial worth a damn needs to hammer home that (1) just because it looks right doesn't mean it is right, (2) you can't really ever style an element in isolation, you need to think about how it interacts with its parent and sibling elements, and (3) elements actually have two different positions, one that you see, and a potentially different one for layout.

Knowing those things is key to understanding whether you've designed things "correctly" vs. something that just happens to look right in the moment.

(I've only skimmed this course so far, so I'm not sure whether it satisfies what I want. But I'm hopeful!)

Re: Learn CSS

#158

Post by onlyfortoday2 »

goto11 wrote: post #33

Looks great! Small pet peeve regarding tutorials: When learning a new technology I don't care about the headaches people had 20 years ago. My first concern is how I use the technology and what it can do for me. The section about layout starts with: " In the early days of the web, designs more complex than a simple document were laid out with elements. Separating HTML from visual styles was made easier when CSS was wi…

agree 100%

Re: Learn CSS

#159

Post by z3ncyberpunk »

goto11 wrote: post #80
atsjie wrote: post #42

Earlier quoted context omitted.

Don’t agree. Historic context is important to understand legacy codebases, code examples in other resources and colleague’s behaviors.

Sure, but that is an advanced subject. Don't put it before explaining what the technology actually does!

you often need to know how things came about to explain what they do and why they do it. you can't just decouple the two, and to do so at all would be dismissive of all of the work that went into getting the tool made you so shallowly want to use.

Re: Learn CSS

#160

Post by exogen »

swiley wrote: post #7
hmoy wrote: post #2

I've always found CSS infuriating to use when working with it (albeit not often). This looks like a clean and easy to follow course so will be one for me to look at over the weekend.

I think most web users wished web devs understood CSS better (even if they don't know what it is.) I'd be willing to bet half the stuff things like React are used to do could be accomplished much better with a small amount of CSS and probably no javascript at all.

I wish you were right, but this is unfortunately wrong – and it's not because developers don't know CSS well enough, but rather that CSS is just plain not good enough. And ridiculous new features keep being added to it when we still don't even have some of the necessary primitives that should be there.

As an example, one of the most basic components I can think of is an accordion. You simply can't make one that works in a visually pleasing way (the way most people would expect!) in CSS because you can't animate to or from `height: auto`. The best you can do is some cop-out technique of fading out or squishing the content with `transform` and then having the content that follows it do an immediate jump up/down.

Instead, animating an accordion that actually animates the layout around it smoothly absolutely does require JavaScript, to tell CSS what non-auto values it needs to animate to and from.

And that's just the most basic component I can think of!

Another example: anchoring one element to another, when those elements don't have a parent-child relationship. Think tooltips. This requires JavaScript to measure the anchor element's position on every goddamn frame and keep the other one in sync, when the layout engine already has all the necessary information and could easily be built into CSS.

Post reply on HN