161–170 of 196 posts
For that, I strongly recommend "Flexbox Zombies" and "Grid Critters" by Mastery Games. They're good games, and excellent educational resources for learning CSS layout.
https://flexboxzombies.com/p/flexbox-zombies https://gridcritters.com/
Earlier quoted context omitted.
It was a fairly common issue when .dev first launched. https://andycroll.com/ruby/clean-up-broken-dev-domains-after...
Aha, interesting. Thanks.
Earlier quoted context omitted.
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…
CSS has absolutely 0 knowledge of your BEM hierarchy, they're just different names as far as its concerned. The developer has just chosen to pretend that a hierarchy exists where there is none.
CSS cannot do trees, but it can do logical AND and OR, so you can somewhat express a hierarchy as a union of the different levels of your tree, so
.button.login.green has a logical meaning in CSS where .button__login--green is no different than using .pinapple as a class name.
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.
In addition to yourself, there are other people in other situations who are looking for different kinds of content.
Earlier quoted context omitted.
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…
CSS does have a preference. CSS has absolutely 0 knowledge of your BEM hierarchy, they're just different names as far as its concerned. The developer has just chosen to pretend that a hierarchy exists where there is none. CSS cannot do trees, but it can do logical AND and OR, so you can somewhat express a hierarchy as a union of the different levels of your tree, so .button.login.green has a logical meaning in CSS wh…
Earlier quoted context omitted.
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…
Well yeah, you can't do it in pure CSS because you can't do most things in pure CSS. The HTML element you're looking for is "details." (this seems to be one a lot of react people miss.)
Earlier quoted context omitted.
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…
>accordion. You simply can't make one that works in a visually pleasing way Well yeah, you can't do it in pure CSS because you can't do most things in pure CSS. The HTML element you're looking for is "details." (this seems to be one a lot of react people miss.)
You a moment ago:
> half the stuff things like React are used to do could be accomplished much better with a small amount of CSS
you now:
> yeah, you can't do it in pure CSS because you can't do most things in pure CSS
Earlier quoted context omitted.
This is my favourite resource for learning about flexbox: https://flexboxfroggy.com/ > And this for grid: https://cssgridgarden.com/ >
I've learned flex using similiar game, some kind of tower defence I think, it's astounding how quickly I memorized these things compared to standard learning by reading
Does anyone have recommendations for tutorials/books/courses that go beyond explaining the basics of CSS to how to actually design stuff with CSS. I've gone through numerous this is how Flex and Grid work, this is list of all the options for Flex and Grid, this is why we used tables in the old days and Float had it's problems. I'd like to learn how to use the building blocks of CSS as they are now and ... you know be…
Are you building in a react environment? Are you building WordPress websites? Are you just building simple landing pages? Are you building in a team environment? These could all have different solutions, they could also use similar solutions.
But you need to decide how you want to think about CSS. Which to me, is atomic vs component driven.
Atomic is building small reusable classes, then use those classes everywhere in your HTML. It keeps things consistent. [Tailwind CSS](https://tailwindcss.com/) is the winner of this race at the moment. Lots of people are moving to it. There are solutions for standard CSS, SCSS, or even working with it in React type environments.
Component driven is how I think of BEM, "Block Element Modifier". Break things into reusable components, keep your naming structure consistent according to BEM specs.
I personally prefer BEM type of process (break your pieces into components), but with usage of utility classes also, these can be thought of as atomic (one use, like text-align: center;).
I'm going to try Tailwind on a project soon (I've been following it for years), but I will still think of it in a BEM type structure. Things get messy in atomic when you have complex UIs that have different needs across device sizes. I personally have a hard time looking at HTML when one element could have 10+ classes on it if you go pure atomic.
I've kept things consistent without Tailwind with my own set of config (for things like colors, units, font stacks, z-index stack, etc), then various helper functions for things like keeping breakpoints consistent.
There are lots of great resources (look up atomic css and BEM css), you should browse through many of them to get a well rounded picture of how people work with CSS.
But figuring out how you want to think about CSS and putting a system around it seems like where you are. I recommend trying various methods out, and see what works best for you. Just be flexible if you are in a team environment. A team sticking to a defined standard (even if it isn't your favorite) is better than lots of competing standards.
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…