I unfortunately recommended a Firefox addon somewhere. Maybe it (Disable JavaScript) or some versions of it got hacked/backdoored because the repository just up and poofed itself. Luckily, Firefox isn’t that popular.

Addon files are usually zips and CRX Viewer is good for corner peeking. I look around corners thrice, occasionally, sometimes, maybe?

I’ve just learned something the hard way. There’s stuff out there that spins console.clear() and debugger in infinite loops. I don’t know why that’s a thing but I like to call it: clear console log debugger abuse.

In Chrome/Chromium limit debuggers and logs. In Firefox, enable log persistence/timestamps and control breakpoints manually.

My brain was picked apart the other day. Virtual scrolling is, in a handwavy sense, pagination with (semi) automatic navigation. Touché.

Infinite scrolling is unusual. Most implementations are “almost infinite” to avoid excessive DOM length (memory).

• Infinite scrolling: Limits content to an arbitrarily large amount to avoid exhausting memory.

• Virtual scrolling: Unload everything except the visible viewport + a top and bottom offset. Pad the rest.

Virtual scrolling is infinite, but breaks auxiliary actions ( CTRL + F ) because what’s on the screen is the content.

document.addEventListener("scroll", function() {
  console.log(document.querySelectorAll('*').length)
});

The most popular library appears to be https://infinite-scroll.com.

It’s amazing how trends in modern mainstream web development have seemingly inverted. One such example (an old bookmark) while following tech more closely in school;

Therefore by purposefully giving the user a blank page, we are giving him information that the app is still loading. The user knows that the app will be functional when he sees boxes and buttons.

The truth was it didn’t matter, at least, not so much as “position independent code”, kind of. Tech appears to do a ten year amnesiac/discovery routine. Web components arrived around that time too.

The best CSS Framework? I don’t know. Complexity moves in mysterious ways. The many interpretations soc model must be satisfied.

1. CSS in CSS (canonical)
2. CSS in HTML (write once and time driven)
3. CSS in JavaScript (framework driven)
4. CSS in Shadow DOM (company/department driven)
5. CSS in Scoped Formats (IDE driven)
6. CSS in Preprocessors (design system driven)

I’d say, choices reflect environmental factors (social or otherwise) at play. If you’re lucky enough to choose, then suitability favors what draws the finish line closer?

I’ve no advice since I’d rarely have the time/luxury to choose anyway. I’m usually thinking about the possibility of more types, sub–types (i.e in #1: bem, classless, etc), and the transposition strategy and speed between each class/type.

Text fragments are a Chromium feature from a couple years ago. They (#:~:text=) emulate CTRL + F or window.find() from a URL. I experimented in times past with a snippet–like approach using <mark> with URL encoded terms on id + :target logic, such that clicking this link highlights the paragraph below.

https://web.dev/text-fragments/#:~:text=Text%20Fragments%20let%20you

After perusing the web dev blog feeds (finally).. it seems that there’s a “mainstream” coordination away from the client side;

• https://intercoolerjs.org/
• https://unpoly.com/
• https://htmx.org/
• https://turbo.hotwired.dev/handbook/introduction

Time until a transition to ‘json over the wire’? These are very handy libraries btw — I tried htmx previously.

So as you may know we have, knowledge.. or in the old black books of web witchcraft; the checkbox hack. I wonder though; did anyone ever go the final mile and create a kinda generalized “progressive polyfill” to fix the semantics of this so called hack?

Tangentially, a query for a details/summary polyfill brings up either rstacruz/details-polyfill or chemerisuk/better-details-polyfill with demo. Interesting.

A no build repository for SolidJS. Don’t ask. I found this splendid repository while strategically traversing the void. Demo.