If you know the height of the container that holds the text and the text is on only one line, it’s very easy to do this. Set line height to that of the element’s height.

Granted that’s a very specific use case and doesn’t cover most cases. If you don’t know container height and/or the text is multiple lines, you can use position: relative; top: 50%; transform: translateY(-50%);.

See my demo which shows both methods. I do agree that text-align: center center would be nice. Though it would require modifying an existing rule to become shorthand. Instead of text-align we would need text-align-vertical and text-align-horizontal, and simply text-align would become the shorthand, and if passed only one value would it apply it to both? text-align: center would be the same as text-align: center center? That would be problematic. Because if you did text-align: left would that try to apply “left” to text-align-vertical?

The idea is good but I’m not sure how it would be executed.

It’s already possible with preprocessors like SASS, but it’d be nice to have it natively on plain CSS.

Some proposals have huge challenges, take container queries for example, such feature could easily trigger an infinite loop of repaint, if two elements react to changes in a way that triggers the other element to change and so on, like parent and child or two siblings.

Then the parent selector, which I could not find an official proposal, but most articles suggest a syntax with < or :parent. It’s not simple to introduce something like that, imagine the following: a < img to select anchors that have an image child, but then someone writes this: a < img + span or a < img > span, it could be maddening, it’s even going against the “cascade” part of CSS.

Enough with line-height, it is seriously terrible.

Leading would allow for vertical rhythm (if you want it), and more importantly to be able to match print to web or web to print more seamlessly (or the whole gamut print to web to print).

I worked hard to find a way to create leading in the web, but it shouldn’t have been hard to do. (https://github.com/shalanah/baseline).

Also, shout-out to having consistent white-space wrapping for text cross browsers.

div {.styel1.};
div p {.styel2.};
div p .someclass {.styel3.};
div p .someclass:hover {.styel4.};

why not write on “Cascade”?. Something like this:

 div [
      {.styel1.}
      p [
          {.styel2.}
          .someclass [
               {.styel3.}
               :hover {.styel4.}
          ]
       ]
 ]

Pros:
* you really see the cascade in one place.
* its easy to change and debug
* its more compact, reducing the file size

This isn’t as powerful as your comment suggests, but have you seen the coverage tab in chrome dev tools?
Saw this article today:
https://umaar.com/dev-tips/121-css-coverage/

Or:
https://www.vojtechruzicka.com/measuring-javascript-and-css-coverage-with-google-chrome-developer-tools/

Oh, well, it’s not like Chrome doesn’t now have something even better – the ability to animate CSS variables, which means we can animate different components of a gradient differently.

For example, let’s consider the following gradient:

linear-gradient(var(--ang), var(--col-0) var(--pos-0), var(--col-1))

Here we can have a different animation (different set of keyframes, different duration, different timing function, different delay) for each CSS variable, whereas animating the gradient itself (as it is possible in Edge today) means animating everything the same way.

Of course, it’s still all behind a flag (Experimental Web Platform features from chrome://flags) that’s apparently hard to find judging by how often I’m told my Houdini demos don’t work. For anyone wanting to know more, I wrote an article on it right here.

clip-path: path(). It’s already been implemented in Firefox. Quietly, without saying a word about it. It needs the layout.css.clip-path-path.enabled set to true in about:config in order to work.

My honest opinion? Meh. And here’s why: the value in the path() is a string value that, just like the value of the d attribute of an SVG path, only accepts unitless values. What do these values translate to in CSS? Pixels! So the coordinates used for this path are always pixel coordinates relative to the top left of the clipped element. Here’s a test. Needs to be opened in Firefox with the flag mentioned above set to true.

Want anything responsive this way? Sorry, nope. Better option at this point is to use a child SVG and modify its d from the CSS. Only works in Chrome and doesn’t reflect the latest spec changes, but at least it’s responsive! Basic example and something a bit more interesting.

Useful mathematical functions like floor(), abs(), pow(), trigonometric functions. This is one I personally hit the need for a lot. Off the top of my head, some use cases:

1. Modulo. I may have a bunch of similar items that let’s I say position on a circle (think something of the kind). This is done by setting an index custom property --i on each of them and another custom property --n representing the total number of items on their parent and then setting the item transform to rotate(calc(var(--i)*1turn/var(--n))) translate($r). And now let’s say I want to make every other item black. Currently, I can do this with something like :nth-child(odd) { background: black }, but, if I could use modulo, I could set the background only once (!!!) with background: hsl(348, 83%, calc((var(--i)%2)*47%)). Demo.

2. abs(). Starting from the same example of items distributed on a circle, let’s say I want to have their opacity increase linearly for the first half of the circle and then decrease linearly for the second half. With abs(), we could have opacity: calc(1 - abs(2*(var(--i) - .5*var(--n))/var(--n))), but now we have to change the sign for half the elements and that means hardcoding the number of elements in a selector like :nth-of-type(-n + 6).

3. pow(). Let’s say I want to have a secondary rotation. Or let’s say I want to have a cubic increase in the height of items.

4. Trigonometric functions. My primary use case is for syncing rotation angles and scale factors or translation distances when I animate multiple elements such that corners/ edges match throughout the animation. In this demo, I need to sync the rotation angle of the bright yellow squares and the post-skew scale factor of the orange squares. This is achieved by doing the trigonometric computations in the JS and then setting the values to the custom properties used in the transform. I could also try to fake it with different timing functions for rotation angles and scale factors or translation distances as I did in this demo, but that’s just hardcoding the cubic-bezier() for every case.

This is a layout issue, not a text alignment one. And it’s not a one-liner, but flexbox accomplishes this very easily.

.my-child-element:parent(.my-parent-element) {
    // Style the parent
}

This is currently possible! More info here.

A very useful feature!

It is! It’s been possible for more than half a decade. Demo.