Live data from Hacker News

Learn CSS

web.dev

91–100 of 196 posts

Re: Learn CSS

#91
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…

It is relevant in html emails, which are basically a time machine to inline styles and table layouts if you want consistent rendering. This would make no sense to a developer unless they understood the progression to where we are today.

Re: Learn CSS

#92
post #41

This looks good. I've been using mdn mostly; but I usually go deep into CSS for a bit then leave it for long periods of time. That said, what has replaced SASS? I'm struggling to find a preprocessor that allows nesting/grouping etc. Or is that built into CSS by now? Being able to nest CSS was a game changer for me in terms of css organization.

Nesting is not possible in vanilla CSS. However, there is an Editor's Draft about it which has gained some momentum recently.

https://linkedlist.ch/ref/25/

Re: Learn CSS

#93
post #47

Earlier quoted context omitted.

Nah, I think the history is important, especially for web development where modern tech stacks are technologies built on technologies built on technologies, and pretty much everything has to be backwards compatible. I've run into so many situations while learning web development where a design decision seems like nonsense until later when I learn about the history of how it evolved. First example that comes to mind i…

History can be important, but I don't see what knowing that developers used to (ab)use for layout explains about modern CSS. By all means, include historical context if it helps explain why something works the way it does, but otherwise drop it. And while backwards compatibility remains a concern for browser vendors, it's much less of a concern for web developers nowadays given the vast majority of users are using au…

I think it adds a lot of colour to a relatively boring part of the tutorial

Re: Learn CSS

#94

I'm the content lead for web.dev. Just wanted to give a quick shout out to the people who made this happen because it's not clear on the site. I think this is also useful information because you'll see that a lot of CSS experts we're involved in this project. Adam Argyle [1] and Una Kravets [2] created the podcast series. Una mainly drove the overall project to convert the podcasts into this written series. Adam prov…

It is interesting that this uses a podcast + text rather than what would have been a more conventional video based tutorial. The use of a podcast for describing something so fundamentally visual as CSS looks really unusual. I just started going through and came back here to note that it somehow seems to work well!

I've listened to some of the podcast and it is really good, even in the car where you're highly unlikely to have devtools open.

Re: Learn CSS

#95

I never really "got" the float model for layout, so Grid is a welcome improvement these past few years. That said, this is still missing the one thing I've yet to find in any discussion of CSS. How to appropriately size text. No -- for the 1,000,000th time -- I will not use Modularscale, which feels obtuse to me. Using some formula on a website that someone says works also feels arbitrary. Not to mention that the SAS…

What exactly about sizing text causes issues? Do you mean fluid/responsive sizing? AFAIK, the best modern way to do it is `font-size: clamp(0.75rem, 1rem + 2vw, 3rem)` (the use of rem as well as vw is to not break zooming for accessibility)

Never use viewport-relative units (like vw) for text sizing, it is not a best practice for accessibility (part of the reason it's not in the examples here).

Modern browsers handle zoom just fine, regardless of units. We use rem in case a user has set their own preferred base text size (the same reason we don't use viewport-relative units).

Re: Learn CSS

#96
post #71

Earlier quoted context omitted.

I see. That just goes against the way I naturally think, unfortunately— which is why I thought SASS was such a great breakthrough. I do understand it, though, because when I want to modify something in some over-written hunk of garbage CSS it is a real pain to try to get the selector that actually works (thank god for dev tools).

One of the challenges with CSS is that it has so many ways to do the same thing, and it needs that because there are so many different workflows. If you are in an environment where you have 0 control over how the HTML is structured I can see where long selectors are helpful, but when you do have full control over the HTML they are a huge anti-pattern.

Agreed, if by "helpful" you mean "painful but necessary because the asshole that wrote it didn't put a unique class on the main target of the div." But nesting doesn't necessarily imply long selectors, if done properly IMHO. If I have full control, I can put a class on the likely-to-be-selected element (ultimate target- the content) that allows me to get to it immediately so that I can, say, change the font.

In other words, I like nested CSS when I have a nested structure on the page. Then each class relates to one thing, and I can maintain continuity of the outer containers (say) as I change the inner ones.

In the old days, we didn't have column inside of content inside of page inside of ..... We just had whatever we had and css nesting wasn't as logically congruent with the structure.

Now, though, we have hugely nested pages (which stinks, but whatever), including a lot of inline-written CSS and the only way to get to it is long selectors. I agree it's an anti-pattern.

But you can have nesting and not require long selectors. And if you do need them for some god-forsaken reason, they are easy to find from a SASS structure.

Re: Learn CSS

#97
post #47

Earlier quoted context omitted.

Nah, I think the history is important, especially for web development where modern tech stacks are technologies built on technologies built on technologies, and pretty much everything has to be backwards compatible. I've run into so many situations while learning web development where a design decision seems like nonsense until later when I learn about the history of how it evolved. First example that comes to mind i…

It's also useful to be able to know what you're looking at when reading code that others have written.

Exactly this. When you're starting something _new_ it's possible that you don't care at all about the history. It's when you inherit something _old_ that the history becomes very important.

Re: Learn CSS

#98
post #18

Earlier quoted context omitted.

I’ve seen this more times than I can count… A lot of people think of CSS as if it’s not code itself. Modularize it and create patterns like you would for any other piece of code(ie. react components), and it becomes fairly straight-forward to do things that would normally take 100+ lines of code in JS, in just a fraction of the time and code.

Could you give an example? (not trolling - genuinely would like to see where the Venn Diagram between framework and CSS lie)

That's fine, I didn't think you were trolling. But I'm not sure what are you an asking an example for? Do you want me to write up a comparison or just tell you some cases where HTML/CSS is lighter than JS? I'd honestly just recommend building a flashy animation primarily with Javascript and then try and build it using only HTML/CSS. Most of the time it will be easier and more readable to go with the latter, as well as more performant and likely to stand up to the test of time.

There are definitely a lot of times where Javascript makes sense, but what I really just wanted to point out is that people usually default to 'Well I'm already writing tons of Javascript, I may as well write more!' as an excuse to create simple animations or transitions with dozens, or hundreds of lines of code, or bringing in a dozen external dependencies to handle it that also break in weird ways. I'm definitely not a NoJS zealot either -- I've been working primarily with React code full-time in production systems since 2014. But over time I've found CSS to be far more pleasant and faster to work with than testing, maintaining, and/or relying on someone else to do the same thing in JS.

Re: Learn CSS

#99
post #81

Earlier quoted context omitted.

Tailwind isn't quite inline styles (technical details) but yes, it replaces having to name 'login-box' with a copypasted set of styles that you can't change easily without massive regex work.

Until somebody has another similar box so they reuse login-box a bunch in your application, then you realize that they actually need to be customized and have to tear it all apart. Tailwind doesn't make you copy and paste, it moves the reuse of styles out of CSS which sucks at managing reuse into whatever HTML building system which likely has some concept of reusable views.

> Until somebody has another similar box so they reuse login-box a bunch in your application

Then they make `.box` and include it as a mixin. Like CSS developers have done for a decade (and which tailwind itself does using PostCSS)

> Tailwind doesn't make you copy and paste

Yes it does. Moving all styles into individual elements without reuse is copy and paste.

Re: Learn CSS

#100
Looks really nice from what I’ve seen! One thing that I think could be especially helpful as an extension is booking into CSS from JS especially for animation. I feel like it helps because then you can do stuff like destroy an element after a fade out animation without having to know how long the animation takes or do chains of animations.
Post reply on HN