I just gave a talk on how to use more CSS and less JS; it’s uncannily like they were watching what little JS I still had in there and decided to make it unnecessary. This is awesome.

Half of them are exclusive to Chrome for the time being.

there are more aggressive css "resets" that set the default display type to flex. there's no problem making anything a flexbox if it displays the way you want it to

Not sure what best practice is broadly, but in general display: flex is the first tool I reach for if I need to position child elements a little more carefully.

It's good for most things more complex than just margin/padding/text-align. If it gets too complex for flexbox, dig into CSS grid.

Is it a good idea to make body a flexbox? Is there any standards for doing this?

I would suggest poking around on that page to find what you're looking for. It has a decent search function.

Check out Flexbox!

How to make it centered vertically as well?

https://www.w3schools.com/howto/howto_css_center_website.asp

Use a container element and set a specific max-width . A common width many websites use is 960px. To actually center the page, add margin: auto .

I'm a beginner doing the odin project. So i don't really know.

Why not body {margin: auto;}?

This proposal is an early design sketch by Blink Layout Team in Google to describe the problem below and solicit feedback on the proposed solution. It has not been approved to ship in Chrome.

linked src

There is no such proposal I’m aware of. @function will enable a finite combination in a more convenient way and maybe the ident() function can help building comma separated values in new ways. In general using classes for this is tricky though because the position of each value in the list matters (if you want something like layer-1 = gradient-blue, layer-2 = gradient-red, …). Each class would need to represent a tuple (index, image) so you would need every permutation ( layer-1-gradient-blue, layer-2-gradient-blue, …)

Thanks! Works like a charm. Didn't even know that inherits: false was an option.

Do you happen to know if there is any proposal to make it more native? For example with a syntax like background-image: +, radial-gradient(....

The corresponding property would be background-image (background-color does not seem to pick gradients, at least, as they are not color declarations) but the core problem is the same: there doesn't seem to be a mechanism refer to precomputed values of those properties.

You can compose layering backgrounds in the way you described by using using custom properties:

@property --gradient-1 {
  syntax: "<image> | none";
  inherits: false;
  initial-value: none;
}

@property --gradient-2 {
  syntax: "<image> | none";
  inherits: false;
  initial-value: none;
}

.gradient-1, .gradient-2 {
  background-image: var(--gradient-2), var(--gradient-1);
}

.gradient-1 {
 --gradient-1: linear-gradient(60deg, red 0%, orange 50%, red 100%);
}

.gradient-2 {
  --gradient-2: radial-gradient(at center, blue 10%, teal 50%, transparent 50%);
}

Using the @property syntax with ’inherits: false‘ prevents that the parents value for this property get inherited, so that arbitrary nesting is possible.

This. The styles should cascade

There are more granular properties that make up the composite background sugar. You can use background-color, for example. Can you make it work piecemeal?

I don't know how exactly people define what is or is not a thing for the purposes of "pseudo-elements applying to things" , but my first expectation was that, by design, :closed can not be the same as :not(open). The former would in theory apply to things, and only to things, that can have a state of closed-ness and are in that state of closed-ness, whereas the latter should be able to apply to things that may not have the possibility of being open or closed.

But if that's not the case, then I don't really see a point for :closed existing, yeah.

I'm a bit confused, because MDN ::after says in the accessibility section:

Using an ::after pseudo-element to add content is discouraged, as it is not reliably accessible to screen readers.

which contradicts the article saying ::after content gets included as per spec. They conclude though with

While it’s good and certainly useful that we can now provide alt text for CSS generated content, I do not recommend using CSS to insert meaningful content into the page.

Not only will some of your screen reader users miss meaningful information when the alt text is not announced by their screen reader (looking at NVDA with Chrome 👀), but there are also other reasons why inserting meaningful content in CSS is not yet recommended…

so I assume it's a spec vs real world thing.

If you want a teaser what this is about, the / content syntax for screen read representation (to evade misrepresentative emoji translations, for example).

::after {
    content: " \2197" / "Opens in a New Window" ; 
}

They also talk about image alt text and ::after url.

Note that it has been pointed out in the comments and Mastodon that this solution is far from accessible.

The issue was they changed their server URL and added www, so I've updated the link accordingly.

How strange. It was definitely working when I shared it.

This service has been suspended by its owner.

This is all I see on the linked webpage.