This anti-scraping tech is getting a little ridiculous, and will only end in accessibility issues (while still not actually preventing or even slowing down scraping).

But it is a feature, there's a few different (good) reasons to do that. Here its almost surely tied to CSS-in-JS/React.

HTML class names would not affect accessibility.

That's still not a feature, in that it's something that serves developers, not users. I'm fine with people making better CSS tools; they should feel free to add dynamically named classes. But when the remove the static ones, they break things for some users. That's definitely not a feature.

It's a feature for developers, because it's in the code, and it doesn't break their product. It won't affect anyone but users like you and I that are developers themselves, it might break their code, but that's not Twitter's responsibility.

Non-deterministic class names are quickly becoming the norm for a lot of good reasons.

Something done for the developers is not a feature. Features are things we build for our users.

It's not always wrong to do things that are self serving at the expense of our users. But we should never confuse ourselves into thinking of that as a feature. It's always important to keep in mind who we serve.

Sorry, what are these good reasons that aren't in the realm of specifically impeding user's ability to use the site as they please? My understanding is that the sole reason for dynamic class names is to confuse user style sheets that may reformat the page (how dare they not use our beautiful UI!) or to combat tools trying to ad-block based on a CSS selector rule.

Is there some advantage other than removing these two features that dynamic CSS classes provide?

Since they are likely using CSS modules or some other type of scopped CSS, it means the classes they write are human readable, but not guaranteed to be globally unique. For example, you have FooComponent and BarComponent. Both may have a button, so as a developer, you decide to make a class called 'button' for both of those components. The tooling will then create a unique CSS class name in each of those cases and replace FooComponent.button and BarComponent.button with a hash of some sort.

The best they could do to make it less obfuscated is to include the name with the hash. So the class name may look like 'fkljdkldjf9303-button'. However, the hash may change if the component changes for example, so still not super reliable from your point of view. Also, most users won't care, so they'd just be including extra page bloat to add the human readable names along-side the hash in production builds.

I'd argue that CSS modules and similar reduce many many bugs I've seen people make over the years and that it's a huge win in terms of developer speed and reduction of bugs. I highly doubt anyone made the decision explicitly to obfuscate the CSS...

There was a prior request to actually have a scoped CSS tag in the HTML+CSS standard[1], why aren't we seeing a stronger advocation for it if that's all people are looking for? I'm a small fish but I certainly would love to see this HTML spec be revived.

[1] https://github.com/whatwg/html/issues/552

This is a terribly weak argument. Just use post or prefixes and at least you know which scope you’re working in, or combine classes.

I wonder if using any kind of extension/devtools to make changes to twitter, even if it's only UI, is a break on their ToS

It's most likely not at all intended stop or affect scraping. Although I haven't looked at how obfuscated it is.

https://github.com/css-modules/css-modules or similar does this because the CSS global scope is more and more painful as applications get bigger.