The text inside the figcaption element is always aligned left but the element itself is centered. When the text is longer, figcaption grows to a 100% width while the text is still aligned left.
To make your explanation spot on, you need to add some more text after "figcaption" in the latter two cases. This is the key point: an inline block will auto-width, by default, to its contents. In this technique, the contents will always be left-aligned, but the container centered.
Thank you, your explanation was a lot clearer than the one in the article which I found hard to read. I think it would have been much more clear if they had shown the markup for the content.
I think what best explains this is modifying the .figcaption css to include a background color. This illustrates what that element actually does and how/why this works. Especially helpful if you don't have a really good understanding of the css `display` property.
Technically very cool, but as a designer, I wouldn't want captions to behave like that. Center all, or left align all. Or if there really is a difference between short caption and longer description, differentiate also typographically, by changing font size, style and line height.
Agreed, this would also look bad if a caption was just a few chars short of the width causing it to look indented compared to surrounding multiple line captions.
Use left, right or centre, not a mishmash.
As a designer, too, I have no problem with this caption behaviour. I would chose a nicer font and fix the padding, but over all I really like the solution to a problem that I have certainly faced at some point.
I remember that eight or ten years ago, there were a lot of blog posts dedicated to sharing nice tricks and hacks to work around the limitations of CSS and browser implementations. Some techniques even got catchy names[1] and some of their authors became quite popular.
I dreamed of coming with a clever technique myself that would buy me some 15 minutes of internet fame after being published in A List Apart or something. Unfortunately my poor english skills at the time crushed my dreams.
Since CSS3 became the norm and browsers got better I stopped
seeing such articles. I supposed we have CSS pretty much figured up. Anyway, all I wanted to say is that this post made me nostalgic and I actually learned something today.
Good riddance! Back in my day we had character cells, and we had pixels. Is it not self evident that the entire browser ecosystem is wholly dysfunctional and psychotic? Personally, I'm holding out for left-align text as a service that uses a client with a 2GB dependency tree and infinite polling.
There's no easy solution to this. Mainly because CSS barely knows what a baseline is and there's very little in CSS that affects the baseline or something to that effect. What we call baseline can vary from font-to-font, browser-to-browser, platform-to-platform; all affecting how the font gets rendered.
Plus, based on the description and requirements of the problem it's likely to not be solved because the font-size is an unknown variable in the equation. If it was known how the font-size is determined and applied then maybe something could be leveraged to adjust for the problem.
The easy solution, knowing the font size, is to position a parent element at the coordinate and then move a child element containing the text upward an amount based on the font-size. That way the first line of text in the child element sits on the top line of the parent element, more or less. But we don't know the font-size and it is easily broken if the site is constantly being changed code-wise. In fact, a badly thought out line-height may break it as well.
I'm puzzled to try and figure out when and where you would need to do something like this. OP notes, "This is important, because I don't want to change all the positions in my CSS whenever I change fonts."
Which leads me to ask how frequently and where he's changing his fonts. My design specs are usually pretty simple and consistent and would never require something like this.
Well, sometimes the UX designer wants to change all the fonts in the interface at once (perhaps to a slightly different font). It is cumbersome to have to reposition all the texts in those cases, because many fonts have their baselines defined in a different way.
At other times, we may want the user to define/select the font, and keep the baselines at the same position.
It's possible using nested elements and transform: translate(0, -100%) on the inner element. It's elegant enough for CSS, I suppose. (I'd make an example if I wasn't on my mobile atm.)
Are you dismissing this article because you consider it too trivial?
Getting elements to align nicely in CSS is a real pain point for a lot of developers. The popularity of layout frameworks is also evidence of that. It's not trivial to take a design from balsamiq or photoshop and replicate it in CSS. Tricks such as this can make it a lot easier to do with CSS rather than relying on javascript tweaks.
I've seen functions attached to window.resize which are principally there to resize a whole bunch of elements dynamically so they still fit together well on a new layout.
If you're replicating a design based on the "Draw a picture in Photoshop and use the crop tool a lot" thesis, this is probably why you're having to use CSS tricks. Starting from markup first, and then considering styling, makes your life a lot easier.
And if I were building a site myself, that's how I'd work.
Unfortunately people outside the software development team don't think in markup, and they're the ones from whom the requirements often come.
Even more technical users often base their designs on the worlds of desktop software, or type-setting, or desktop publishing, or a myriad of other domains where "I want these two boxes to always be the same size and aligned to the bottom of this third box, and I'd like the font size to fit across the resultant size" is a perfectly reasonable request.
We can't keep going saying "Well the web doesn't work that way, you're going to have to rethink how you think about sizing" all the time, eventually the web has fix itself so that sizing and aligning fits better with how a lot of other domains work.
Flexbox is a step in the right direction but it's not a complete solution. (And we're still supporting IE9, so we can't even use that yet, thanks Vista!).
Considering the CSS horrors I've seen produced by top-notch hardcore programmers, I guess a little and quick CSS trick here and there isn't bad at all.
On the contrary, I found this interesting. As someone who doesn't do CSS as part my day job, these still loads of clever CSS tricks/methods I'm totally unaware of.
I agree. Setting an element as inline-block is not much of a trick.
I read this blog post thinking I would see something amazing... but it was simply basic css. I may be biased because I actually learned CSS instead of randomly trying stuff until it work...
Initially, when figcaption text is short, it behaves something like this:
The text inside the figcaption element is always aligned left but the element itself is centered. When the text is longer, figcaption grows to a 100% width while the text is still aligned left.