Despite what you might read in some corners of the internet, it’s been possible to vertically centre an element inside a parent for a very long time now. The align-content property from the Box Alignment spec does the job, however browsers require that you make the parent element either a flex or a grid layout. While the property was specified to work in block layout, no browser had implemented it, until now.
Chrome 122 implements align-content for block containers, and it’s being implemented in WebKit too. If you view the following CodePen in Chrome 122 (Canary at the time of writing) you’ll see that the text is vertically centred—no display: flex required.
See the Pen align-content in block layout (Chrome 122) by Rachel Andrew (@rachelandrew) on CodePen.
110 Comments
@rachelandrew Awesome! This might seem small, but it is a big deal for any case where you’d want to have something like `text-overflow: ellipsis`, as flex/grid required having an extra inner element due to the anonymous box creation.
I immediately went and checked the block layout alignment when I saw the PR by @fantasai — it feels like magic to finally be able to center things without these side-effects! Hopefully, Firefox will implement this soon.
@rachelandrew oh thank goodness, about time!
@siblingpastry On its own — I agree. When it is possible to provide a full content on hover + focus — things are a bit different.
@siblingpastry
Ideally, of course, it would’ve been nice if content was always visible. In practice, this is often impossible. And even without an ability to provide the full content easily, reality might require you to make a choice: either you use text-overflow and get at least a marker that the content is clipped, or you clip it hard with overflow: hidden, or get content overlapping other content, thus making even more content inaccessible, or multitude of other things that can happen.
@siblingpastry Flex and grids might be used not only for macro-layouts, but also for micro-layouts, like buttons, lines in data-grids, tables, lists like in mail clients, file systems and so on. Any place where you could want to see only a snippet of some content, clipped intentionally, with an ability to dig deeper, etc.
@siblingpastry Yep, of course. I think a lot of the cases that I mention are not for the content strategy, but closer to the exceptions for the 1.4.10. For example, here is a screenshot of your original reply: it has two cases of text-overflow:
1. An in-content link. Done not via CSS, but intentionally trimmed by Mastodon UI.
2. A preview of the shared content’s paragraph: I think a legit case for a text-overflow, as there is a limited space for the text, and an unknown quantity of it.
@siblingpastry Of course 🙂 The mastodon case is also a case of user-generated content.
Every link takes 23 symbols from the default 500 symbols limit regardless of its length; links due to the params junk can often be very long; if displayed untrimmed, they could potentially result in unusable UI and very difficult to read text due to them going over multiple lines and overshadowing the actual content.
Same for the link description, though I’d argue it could be improved 🙂
@rachelandrew this is terrible! All this time the property only had effect when another property was turned on, and now all of sudden they make the property possible in all states, which means it is not backwards compatible. It’s like if border-color started doing something even if when border-style is set to none!
@robotalien It’s always been specified to work in block layout, it’s not a change to the spec. It’s only due to a lack of browser implementation that it hasn’t worked in practice. If you’ve gone and added alignment properties when you don’t want alignment then you probably want to remove them.
@rachelandrew if it’s never worked in block layout I wouldn’t expect it to ever work in block layout. I wish more people started considering the UX of devs who click the same button as they did yesterday but now are surprised by a completely different behavior 🙁
@robotalien You could say the same of any unimplemented feature. Out of interest why did you add non-functional alignment properties to your CSS?
@rachelandrew I had a div inside of a container that conditionally switched to flex through a media query. Which width made it switch varied on the class of the container. In order to avoid retyping all the flex properties on every media query (including align-content), I just used all of them in a common base outside of media queries, and then just used .container–switch-on-500px { display: flex } or something like that to switch it all on at the same time.
@robotalien I can see why you did that, but it’s likely a bad idea to include stuff that currently doesn’t seem to do anything, there are lots of partial implementations out there.
I’m wondering if this is something that could be better highlighted in DevTools to make it clear you’ve used something that actually is specced to do a thing.
@robotalien @rachelandrew yeah I expect this to fail we compatability hard, there must be a lot of websites which have display block and content-align set to something, since it doesn’t have any effect today. I doubt Chrome will care about web compatibility, so then it will be implemented there but not in Firefox…
@rachelandrew This is great news!
Do you know if there’s work going on to also make self-alignment work in block layouts? (i.e. justify-self)
Likes
Reposts