4 ms·

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

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.

munk-a 7y ago
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?
- cbeley 7y ago
  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...
  - heyoni 7y ago
    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.
  - munk-a 7y ago
    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 https://github.com/whatwg/html/issues/552
wpietri 7y ago
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.

munk-a 7y ago

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?

cbeley 7y ago
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...
- heyoni 7y ago
  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.
- munk-a 7y ago
  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 https://github.com/whatwg/html/issues/552

wpietri 7y ago

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.