CSS now at 70.9k characters lol

35k of it was caused by animating 152 buttons that cycle in groups of 38 on different times... I could have grouped a few that repeat patterns but it would make it harder for maintainability

Websites that let me scroll down and up without any annoying animated hindrance have my thanks.

Oh yeah, I forgot about that. This issue has been going on for quite awhile. Cbox collects some statistics, and Firefox has been flagging it as tracking/fingerprinting because it's a CORS iframe. Cbox claims it's a false positive and that they just collect IPs that interact with the chat to show stuff like a visitor counter, the amount of unique visitors, and countries of origin as a feature for users, and also to let the user block IPs if someone is trolling/spamming the chat, and that there is no cross-user/cbox tracking and they have requested to be whitelisted, but to this day Firefox hasn't gotten back to them.
Cbox is whitelisted by uBlock Origin, AdGuard, by Brave's tracking protection and most importantly it's not on any of HaGeZi's list, so yeah I believe Firefox is tripping, so I just added an Enhanced Tracking Protection exception on my browser to be able to interact with cboxes on the wild (I surf a lot indieweb)

I think I'm just blocking too much. At one point I got a message something like "if you're seeing this, your browser is blocking chatbox". Before that the links did nothing. The color changer buttons worked.

You mean when you click the Links label it doesn't change the content displayed (it's just a radio input, working here on Firefox 148 and Brave 1.89), or that clicking outgoing links are not working? (there is only one on the Links section so far)

Links don't work for me.

OS          Debian GNU/Linux forky/sid x86_64                            
Browser     Firefox 152.0a1
Kernel      6.19.14+deb14-amd64                                                                        
Resolution  2560x1080                                                    
WM          i3                                                           
CPU         AMD Ryzen 7 7840HS w/ Radeon 780M Graphics (16) @ 5.137GHz   
GPU         AMD ATI 66                                                   00.0 Phoenix1 
Memory      4423MiB / 25839MiB

Creating a sticky header is an easy task with position: sticky. But what about a sticky header that sticks for real?

I don't get it. Sticky is sticky. What is "sticks for real"? The example looks no more sticky than normal sticky. Except is has a different shape.

Weird. Works on Firefox android

Great. Does not work for me on Firefox!

Agreed though the article has this disclaimer:

Before we dive into the code, I think it’s worth pointing out that the goal is largely to be immersive and expose some lore. I think this design and effect fit because of the theme and because it’s not for critical content. My point is that it’s just an aesthetic component for a game that makes this acceptable — I don’t think this is necessarily a good user experience for your every day website where there are stakes.

I don't find it super easy to read. Even white on white is somewhat readable, but the black tree part on the left is particularly hard to read. Certainly not scan-readable / fast, like I would be able to read normal text.

It falls back exactly the way I think.

This article talks about flashes, and proceeds to say fallbacks should be defined. It explains how fallbacks work, but fails to describe what actually leads to the flashes, how fallbacks get replaced, and fails to say anything about solving that flashing issue they talk about.

Defining a more similar fallback font may reduce the issue visually, which is not mentioned either, and either way is not a solution for the flashing.

Dunno why one would expect lower precedence CSS rules be integrated into more specific CSS rules without explicit "inherit". That's not how CSS works. Dunno if that's a common enough misunderstanding to warrant a "not the way you think it is" title.

There's a lot of "classless" css frameworks.

Custom hand-rolled css will always be best, but when I need something fast I've been using the confusingly named purecss for years this since it's compartmentalised in such a way that you can just exclude the parts that you don't use (e.g. tables) to save on network size.

There are a billion of these frameworks. This site allows you to compare a lot of them, though it does not yet include dev.css:

https://dohliam.github.io/dropin-minimal-css/

What is actually the attraction of reading progress indicators on webpages?

I get that it's fun to do active things with CSS instead of javascript, sure.

But aside from goofing off and/or tech demos -- is there a target audience who is excited and happy to have a progress bar on their pages and misses it when absent? I've been seeing this feature frequently and for me it's kind of annoying.

The trick is that it’s purely CSS using animation-timeline: scroll(y). Previous approaches for this had to lean on JS.

Interesting experiment. Didn't know CSS could do that.

so you’re invented a scroll bar? Or did you break the scroll bar with some other CSS trick?

Wow thanks!, Really, it took me this long while to figure out this existed. So far, I was just using font-family: monospace for everything numeric that required cell-like alignment.

Yeah, and the author even addresses this, maybe they left the title this way to let people be able to find this article along with others they bash about being click bait:

Well, in my opinion, the headlines describing the bug as a CSS exploit in Chrome are a bit clickbait-y, because they make it sound like a pure CSS exploit, as though malicious CSS and HTML would be enough to perform it.

[…]

Even re-reading the reports more carefully, they feel intentionally misleading, and it wasn’t just me. My security-minded friend’s first question to me was, “But… isn’t CSS, like, super validatable?” And then I dug deeper and found out the CSS in the proof of concept for the exploit isn’t the malicious bit, which is why CSS validation wouldn’t have helped!

It doesn’t help the misunderstanding when the SitePoint article about CVE-2026-2441 bizarrely lies to its readers about what this exploit is, instead describing a different medium-severity bug that allows sending the rendered value of an input field to a malicious server by loading images in CSS. That is not what this vulnerability is.

It’s not really a CSS exploit in the sense that JavaScript is the part that exploits the bug. I’ll concede that the line of code that creates the condition necessary for a malicious script to perform this attack was in Google Chrome’s Blink CSS engine component, but the CSS involved isn’t the malicious part

Sensationalist crap title. Let's name things how they really are.

An Exploit in Chrome-like Browsers

, which are browsers made to exploit and extract your information.

However in this case the opposite is true, as Chromium currently doesn't support this feature.

Same difference. GoogleCSS, if you'd want to be brief.

Do you mean features only currently available in Chrome?

Yeah it's pretty weird.

I'm getting the impression this sub is getting spammed with Google-promoting or nothing-burger posts these last few weeks.