My two solutions in order of preference would be:
1. Get rid of the inner flexbox, so the layout engine can see through to the text inside and use its baseline for alignment. Rely on the pill's parent for vertical alignment. I don't think I've ever come across a double-nested <span><span></span></span> (or div) that couldn't be flattened out.
2. Give .pill `vertical-align: middle` so its baseline is not used for alignment at all--but then the other non-pill items will need `vertical-align: middle` too in order to line up.
The author went the opposite way as #1 and added dummy text inside the pill, but outside the flex. Since the text is not inside a block element, the layout engine can see it. It has the same font size as the outer text, so with `vertical-align: baseline` both baselines line up again.
That’s actually not what happened.
Images have their baseline at the bottom edge, so Pill 1 is simply aligning its text to the bottom of the <img> element which is the first item in Pill 2.
You can confirm this behavior by enlarging the image, you can see Pill 1 shifting vertically to align the text baseline to the new bottom edge of the image.
You can also swap the order of the <img> and <span>Pill 2</span> so that the text goes first. You will see that they will now align despite the fact that the inner text is supposed to be “hidden”.
An easy way to solve this is to give .wrapper a hidden pseudo element with a bit of text so it becomes the first item to be used for alignment.
.wrapper:before { content:"a"; width:0; visibility:hidden; }
You can also just set the image as background to avoid the <img> element altogether.
I understand why `vertical-align: baseline` is the default, but it seems like such a bad default for all the ways designers like to (over) use Flexbox. (Especially because designers really love the baseline alignment at first but often can't seem to think two and four dimensionally enough when designs meet real world constraints and user data and need to expand/contract/shift to available space.)
- https://codepen.io/romellem/pen/rNZbPZQ
TL;DR: whenever you are using `display: inline-block`, be aware of `vertical-aign` issues that may crop up.
Just to give a fictitious example (inspired by real events)... I wouldn't really expect a Label react component to be made up of 26 nested html elements, 80% of which coming from third party libraries. Stuff like that can be hard to style, but that's just because there's inappropriate abstractions involved.
Keyword searches seem to pull up an unstructured soup of random essays and 'tips-n-tricks' type articles.
I have yet to see a long term css file that's not a birds nest of fixes.
My advice for those who constantly complain about CSS: give it the respect you give things like programming languages or SQL. You're not just understanding a text file, you're understanding the way browsers interpret and render styles. You probably need an expert to "just do what you want to do", and if you don't have an expert available you'll need to make do. Just like anything other sufficiently complex development problem.
Not to say CSS isn't hard, but they encountered a pretty basic problem in CSS. I'm baffled that it took them multiple meetings to come to such a janky fix. Why they couldn't just open up DevTools and troubleshoot it?
In my experience, front-end engineering has gotten so easy the last few years that there's now a whole generation of quite adept programmers that also manage to have very limited understanding of basic webdev concepts. I can't tell you how many times I have been told "we don't need a CSS framework - we're using React!" only to be dragged into a meeting to explain to how to clear floats.
All this to say, if you are doing any amount of front-end engineering, it probably pays to have some old-timer who remembers how to build webapps before flexbox was a thing.
Smells like baseline / vertical alignment issues. The author hones in at the end,
<div style="display: inline-block">
<span style="display: flex; align-items: center">
<span><!-- empty --></span>
<span>Text</span>
</span>
</div>
The flexbox [spec][1] talks about how flex items become "blockified," but I don't see anything that indicates empty children which demonstrate this weird behavior.
2d layout was something that was “solved” by desktop application layout mechanisms like 25+ years ago. One would have thought given all the attention paid to web apps at the dawn of “web 2.0” that this problem would have been licked fast, but no, instead we had 15 years of floundering with floats and the proliferation of turgid frameworks like bootstrap to get by.
So much confusion and suffering just because there was no will power to straighten this stuff out into something sane and cogent.
I enjoyed web development quite a lot in the '90s, but after CSS came along it was an endless source of frustration, and I gave up on it all.
In a way, yes, I think so.
Grid has similarities to tables. These similarities are not accidental. They're a consequence of thinking about layout in terms of rows and columns. I recall back in the day the purists always decreed that tables were supposed to be semantic construct and not used for layout. Pragmatists just ignored that advice for years because there was nothing but a lot of obstacles if you went "table-less" for layout.
But yeah, tables "just worked" for layout despite what purists said. Now we have "grid" and it's part of css, so it's "OK" now for the purists.
I remember this comic strip from 2005, it captured the essence of the situation perfectly: https://web.archive.org/web/20100125163107/http://okcancel.c...
I just wonder what CSS implementers were thinking when people started replacing desktop application with web-apps and they could see that application developers could zip through a dialog layout in minutes whereas the same thing in a browser would take endless effort and workarounds.
I was initially apprehensive about making plots with D3.js but once I got over the hump it was such a breath of fresh air. Instead of the usual second guessing, head scratching and "you can't get here from there" it was just... easy! Want bar charts by date where the weekends are a different color... easy!
I'd also point out the endless complaining people have about things like puppet, terraform, kube files and such. I always found that building out cloud infrastructure with Java or Python programs that use the AWS/Azure API and write bash scripts that boot up on the machines or Python programs was... Easy! Often I'd have complicated systems up-and-running and checked into git while people were still fighting with leaking abstractions with various value-subtracting tools that never absolve you from knowing bash.
D3 is awesome but not trivial: I consider it a more low-level tool than any GoG.
It makes fairly complex things very easy. One does not have to be a graphics programmer or good at math to perform very powerful operations.
I finally stopped claiming I knew CSS until I took a few months to work through a top to bottom overview. None of the skills I had 10 years ago apply to modern CSS; I had to give up every habit. This is a good time to do a review, because CSS development seems to have slowed down considerably, and browsers are all pretty good.
However, CSS has become very big, and web development teams should really start respecting it as a specialty in itself, and making sure they have at least one person who knows it all. Even if they use tailwind.
first/last main-axis baseline set
When the inline axis of the flex container matches its main axis, its baselines are determined as follows:
[...]
Otherwise, if the flex container has at least one flex item, the flex container’s first/last main-axis baseline set is generated from the alignment baseline of the startmost/endmost flex item. [...]
(for https://codepen.io/jsteel64/pen/rNrPYNQ) The first img sets the baseline for the .wrapper, which sets it for the pill, and then two pills are aligned according to their baselines.
And yes, anything that has to do with baselines is a source of pain and bugs, it sucks.
If you're interested in actually learning css, and don't just want to complain about how poorly written css is bad, this website is invaluable and provides concrete examples of how to build layouts and style elements.
You just need to actually understand the box object model and a handful of common gotchas.
How selectors are written has exponential performance implications. Using the wrong type of transform might make your page forego hardware acceleration, or use more battery on a mobile device.
At least typical programming languages are targeting a known set of environments and devices with known characteristics.
You definitely need to understand a lot more than the box model and a handful of gotchas.
https://codepen.io/mikemaccana/pen/WNgWmdY
Please note I didn't bother extracting the icons out the design (it's 11PM and I should be in bed) so just used emojis.
Choices:
- Box model border-box (padding inside box, most CSS resets do this for you now)
- Grid by default because we don't need flexing.
- No margins, at all. Space between items and their parents are determined by padding, space between items and their siblings are determined by 'gap'.
- No issues with vertical centering because items are aligned for the middle.
- CSS borders on the right of each grid each cell for the lines. We'd need a lot less HTML/CSS if the lines were removed BTW since many of items inside the cell have their own borders, part of good design is knowing the costs of your designs.
- Took 36 mins.
Original: F*k it. Live coding. Come watch: https://codepen.io/mikemaccana/pen/WNgWmdY
Also, the less CSS, the better. + no shame in using !important sometimes.
All in all, CSS requires experience
Sure they have their place, but goddamnit do some people abuse them and make huge messes with them :(
This is something I run into with flexbox. The tool is great, but the default mode is almost never what I want.
I'm looking to do X with Y tool. here are all the things it could be called in other tools. and/or layman terms.
It is easy to make a database of effects that work in isolation, for that matter GPT-4 will do a great job writing CSS to make isolated visual effects.
It’s when you need to put those visual effects to work inside of a real application or web site that you find it doesn’t work or rather almost works because of very fine details in how HTML and CSS work. Often you find you can move something forcibly a few pixels this way or that way but what works for the personal web site will be a nightmare for a complicated application that has multiple parts that multiple people are working on because you’ll need more hacks to deal with the consequences of those hacks.
It is real, global, and comprehensive understanding we need, not just another cheat sheet.
Good thing that we have the specificity checker, that makes sure that the semantics of your application of styles remain sound if you change the structure of the document in ways that could affect the selectors!
Oh wait, there's no such thing, bummer.
Seems more like a browser default issue than a tool choice issue.
You probably don't need flexing.
/If you don't know what flexing is/, you should use grid.
My issue is, ever since 1997, the spec hasn’t really lent itself to composability. Just a list of definitions. Maybe some shareable effects but not idempotent in and of themselves. From tables, to floating divs, to grid 960, to flexbox. We keep inventing new ways of dealing with the shortcomings of the standard.
Inheritance and composition should be paramount. Sass and Less help but still fall short of the ideal state.
When I encounter a “this isn’t lining up” problem. I think about the composition first before I think about styling. Should I put it in a div and give that the right properties that I can then shim a span in there with the rest of the required style? Or do I need a new style definition to achieve the look. I try to avoid creating new styles if I can.
Also known as the C in ”Cascading Style Sheets”. Embrace the cascade instead of having every class fully represent a component-piece.
I have found that there are many tools out there:
- Design systems - Web components - Frameworks - Naming conventions - Higher level transpiled languages
Tools are meant to be used together, not in isolation. Any sufficiently complex app or page can benefit from mixing and matching these tools. At Aha! we have a design system, we use the BEM naming convention, we leverage web components, utility classes, and LESS.
With so many tools you can definitely get yourself into a mess unless you apply each one appropriately. That is where experience, discipline, and good old fashioned code reviews will help prevent a CSS nightmare file.
I think the problem starts with the phrase "a css file". If you're building something complex, you gotta bite the bullet and split things up.
If you're building apps, one way is doing self-contained components, which share absolutely nothing between them. You can have a "base CSS" for the page that is very small, just a few lines (plus maybe a reset), but the rest of the style should be "owned" by components and scoped to them using whatever methodology you choose.
Another possibility is going the completely opposite direction and having only helper classes (like Tailwind) that know absolutely nothing about the elements they're styling.
I don't believe in a middle ground. A lot of messes start by having a single CSS block that is responsible for styling 20 different parts of the screen with a very complex CSS selector targeting multiple components. This is like a COMEFROM in INTERCAL. I don't think you can't have your cake and eat it, except in toy projects. If you want to have a single-source-of-truth for colors, you gotta use variables (SASS, native CSS variables, etc), or a helper class.
Working with frameworks also requires care when you want to slightly change the default appearance, and a lot of people abuse !important for this. You don't have to do it.
To avoid !important when you want to "extend" some third-party CSS, use specificity rather than !important. Have a root class, for example .my-app-with-custom-style (it can be applied to the body tag or some other root element), and then extend each block of the framework using the root class + the same selector. For example, if your framework is .b-button.main-btn and you want to extend it, extend it with .my-app-with-custom-style .b-button.main-btn. This way specificity wins and you don't need !important.
There are numerous React frameworks that supply a "widget set" either of web page elements, UI controls or both that work out of the box.
If you (your client, your employer, ...) like the way these look out of the box they are a great way to build something quickly and not have to understand the underlying CSS.
If you are required to customize the look, however, or you want to combine components from various sources and have them look consistent you have to understand all the concepts of the frameworks, the frameworks the frameworks depend on and CSS.
Ideally as you write more code you get more reuse and writing future code becomes faster. In theory CSS classes act like this too. As you have more (well designed) CSS classes then writing future CSS becomes easier because you can reuse the past work.
Tailwind breaks this benefit that by encouraging you to write your CSS with glorified styles.
And code that uses Tailwind is reusable as long as you use components (React, Vue, Svelte, WebComponents, CSS components with @apply, it doesn't matter). Those are reusable.
Trying to use Tailwind without components, in a CSS-garden style page for example, is just trying to fit a square peg in a round hole. It's just the wrong tool for it.
i think one d3.js succeeds so well because it treats scales as functions, which is what they really are. as such it gives you the tools to implement ‘grammar of graphics’. Also it is giving you full control of the attributes of svg and other objects and puts them at the service of the GoG viewpoint as opposed to offering you declarative access to an impoverished and inevitably flawed toolbox.
I believe the original GoG theory/specification does not suffer from the same impoverishment and flaws, it having been formally proven and all... But the same cannot be said of any particular implementation "merely inspired by it". I would very much like to implement it in a pure FP language like haskell (and/or perhaps even proven correct with Coq) some day, that would be fun.
Myself, I think ggplot2 is one of the more solid and least-crippled implementations. Unfortunately, my distaste for the R language is such that I hope I never have to use it again.
.animal {
font-weight: bold;
}
.animal.bear {
color: brown;
}
<div class="animal bear">...</div>See elsewhere in the thread where I solved this and / or submit a fork your own version using flex.
https://codepen.io/mrdanimal/pen/VwGNOQw?editors=0100
As far as I could tell there was no visual change. It's not drastically different, but once you make everything flex, it's possible to remove a few of the grid properties.