[HN Gopher] CSS Findings from the Threads App: Part 2
___________________________________________________________________
CSS Findings from the Threads App: Part 2
Author : sysadm1n
Score : 49 points
Date : 2023-09-24 15:09 UTC (7 hours ago)
(HTM) web link (ishadeed.com)
(TXT) w3m dump (ishadeed.com)
| lbotos wrote:
| > 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)
| CaveTech wrote:
| It's most commonly done with virtual lists/infinite scroll to
| keep the position of the scrollbar consistent and relative to
| the virtual list.
| mg wrote:
| 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(documen
| t.body.getElementsByTagName('*'), e => e.style.outline = '2px
| dotted orangered');})();
| mock-possum wrote:
| Wait so are you trying to add a .5px outline, or a 2px outline?
| eyelidlessness wrote:
| 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?
| bluepod4 wrote:
| 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.
| eyelidlessness wrote:
| 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.
| Jerrrry wrote:
| 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) }`)
| flir wrote:
| 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?
| fiddlerwoaroof wrote:
| 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
| kamikaz1k wrote:
| 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!
| codethief wrote:
| > 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.
| beebeepka wrote:
| > 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?
| codethief wrote:
| 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.
| porridgeraisin wrote:
| 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
| Raqbit wrote:
| This sounds like an issue with CSS authoring tools, and not CSS
| itself.
___________________________________________________________________
(page generated 2023-09-24 23:01 UTC)