Adding `html { transform: scale(0.8) }` also is pretty helpful in combination with this outline trick: it helps you see boxes that overflow the page boundaries which are frequently a source of issues
They’re using a recognizably similar technique. They recognized the similarity and said so. What purpose does it serve to nitpick a detail which apparently isn’t material to their usage, and which could trivially be adapted for anyone who cares about the outline size?
I think the person took “do the same” too literally lol. Likely there was no ill intent.
They also might have been asking the question: “Does 0.5px vs 2px matter in any significant way?” The answer to that question is still no. But I could see how someone who’s unfamiliar with the outline property could ask the question.
I’m sure there wasn’t ill intent. And I know the article discusses the author’s reasoning for their choice of outline size, so that might have informed the overly literal response. But in context it’s a kind of pedantry that can be tiresome.
> Adding a fixed height for out-of-view feed items
When scrolling the feed, each feed item that is out of the view will get a fixed height. See the following video:
I can’t think of a reason for that. What do you think?
===
I wonder if this is an Meta Framework micro-optimization that makes viewport rendering faster with a gazillion DOM items or something because the element heights are "known".
> I would always add a fallback for a CSS variable, as a defensive CSS approach. You never know what could go wrong. Accounting for that upfront yields more future-proof.
God, I hate CSS. Why can't CSS come with static checks of variable and class names at build time like any other sane language? (Yes, I know there's no build time.) SCSS does solve the variables issue (at least as long as their value is known at build time) but unfortunately I still have no way to ensure my CSS will actually get applied to my DOM elements. So for the tiniest bit of sanity I already need JavaScript/TypeScript and some CSS-in-JS library.
> I still have no way to ensure my CSS will actually get applied to my DOM elements. So for the tiniest bit of sanity I already need JavaScript/TypeScript and some CSS-in-JS library.
What do you mean with all this? Valid CSS is applied to matching selectors as soon as they are in DOM. What problem would you like to get solved here?
Yes, but how do you ensure your selectors actually match the DOM elements, beyond testing them manually in the browser? How do you ensure there's not another selector somewhere else in your code base that accidentally overrides the first selector under certain conditions?
I should mention, the above questions are largely driven by my experience of working on large code bases of tens of thousands of lines of CSS, written by dozens if not hundreds of people over the course of a decade. Then again, OP says "You never know what could go wrong." and this precisely matches my feeling whenever I work on some non-trivial CSS, so I don't think I'm the only one struggling with this.
Not the solution you're looking for, probably. But if you hover over your selector in vscode the extension shows the html nested. structure that matches that selector
The insane nested div is typical of React codebases where people want to wrap their component code. No styling on thosw divs though, so I am a bit surprised. And there's no list, so this isn't a case of not using a React.Fragment
I use this bookmarklet which when clicked does it on the current page: