CSS Findings from the Threads App: Part 2 | Hacker News Reader

CSS Findings from the Threads App: Part 2

ishadeed.com

61 pointssysadm1n22 comments

    I added the following CSS to every element on the page
    An outline with 0.5px width

I actually often do the same to look at how a website is structured.

I use this bookmarklet which when clicked does it on the current page:

    javascript:(function(){Array.from(document.body.getElementsByTagName('*'), e => e.style.outline = '2px dotted orangered');})();

Wait so are you trying to add a .5px outline, or a 2px outline?

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.

replace orangered with random color, lil more visually descriptive:

javascript:document.querySelectorAll("*") .forEach(el=>el.style.outline=`1px solid ${ Math.floor(Math.random()*2*16).toString(16) }`)

Sweet. We could pull the colours from an array instead of generating them randomly:

javascript: (function() { const colors = ['red', 'green', 'blue']; const setColor = (el, idx) => { el.style.outline = `1px solid ${colors[idx % colors.length]}`; [...el.children].forEach(child => setColor(child, idx + 1)); }; setColor(document.body, 0); })();

Thus green is always inside red. Any advances?

Idk. Animate it?

make it do a barrel roll

javascript:(function() { const applyRotation = (el, t) => { el.style.cssText = `transition:transform ${t}s; transform-style:preserve-3d; perspective:2048px; transform:rotateY(360deg)`; [...el.children].forEach(child => applyRotation(child, t + 0.4)); }; applyRotation(document.body, 1); })();

fuck that was sick

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

> 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".

(Pure speculation)

It’s most commonly done with virtual lists/infinite scroll to keep the position of the scrollbar consistent and relative to the virtual list.

> 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

Thanks! Unfortunately, though, this very much depends on one's overall setup and is not possible in our case. :(

This sounds like an issue with CSS authoring tools, and not CSS itself.

You're asking why it can't do something at build time while also acknowledging that there is no build time? Huh

very interesting write up; thanks for sharing.

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

Curious!

Reply on news.ycombinator.com