the one thing i’ll say about the new twitter website is that the code’s filled with a bunch of (i assume) machine-generated classes, which makes it much, much harder to customize or hide parts of the UI with browser extensions

anyway, here’s how i’m currently hiding promoted tweets and various engagement-y sidebar modules with uBlock Origin, it may break, always write markup for people, okay good night friends

Unamused.gif

ftw

i use and love @Twitterrific, but i need to use the website if I want to search or view stats

True.

to be honest, as a developer, i don't feel particularly obliged to write code so that people can easily write scripts that mess with my site. i won't go out of my way to make it harder, but i'm also not going to go out of my way to make it easier either.

Hmm, dev too & think people should be able to easily do whatever they want. Part of point of separation of content from presentation, isn't it? Can't accurately predict all user's needs so want to make it easy for them to meet their needs themselves.

separation of content from presentation is for developers - you separate your data sources/structures from the way in which they're rendered. it doesn't mean you have to provide a consistent public API to for your UI.

hey folks, mind leaving me off this thread? thank you.

I noticed after I hit send that I'd forgotten to remove you (not obvious, should be a little X right there!), went to apologise & thought that'd just be another ping, which this now is. So double sorry for that.

noooo worries. appreciate it.

people should easily be able to do whatever they want/need to, yes, but "people" doesn't mean other devs, it means all your users. you should build a good product that people enjoy using and get value out of.

Thank you for that! :) IIRC didn't fb pull the same trick?

God bless you for your service.

Faved, retweeted, and bookmarked

r-1habvwh is my new favorite band name.

opening tomorrow night for The Lovecraftians at the roxy

clearly an aphex twin track

🤣

It’s built with React Native for Web, right?

Nice Dreamweaver throwback.

99.99% sure this is styled-components

Nope this is react-native-web. styled-components (assuming you use the Babel plugin) outputs human-readable names like .sc-Button-Primary-asdf123!

Oh fair enough, my mistake!

Hello

It also makes auditing difficult. I know @stommepoes has talked about it.

ugh i can TOTALLY see that, jeez

How does it make auditing difficult?

I believe the gist of it was: - Class names aren't human-friendly, therefore more cognitive overhead for an external auditor. - Sifting through the extra DOM cruft makes identifying root nodes laborious. - Machine-generated class names dynamically shift, breaking reports.

Is this also true with generated class names that are prefixed with the component name a la when you use Styled Components? Thinking <li class="ListItem_ ...">

(genuinely interested since I work in an org that uses CSS-in-JS and want to use as wisely as I can)

Can't speak for Mallory, but preserving the human-friendly bit has been very handy for both auditing and non-auditing concerns for projects I've worked on.

I think since this is an unstoppable trend, browsers need to offer some other way for users to set their own styles/stylesheets. You can no longer make a custom one, for example if I wanted to see keyboard focus on new twitter in Windows High Contrast (twitter bug).

I haven't seen those problems manifest in practice. An external audit can be done against an environment displaying additional markers ('data-testid') and rely on React Dev Tools too. FWIW, this app has a LOT less "DOM cruft" and more semantic HTML than the old one

Bit of a tangent, but while I have your attention I'm wondering about all the redundant ARIA. Is this a Twitter serves-a-very-wide-audience sort of thing? I don't usually get an opportunity to hear about these sorts of things at this sort of scale and I'm very curious.

I didn't want the framework to rely on tag semantics to communicate accessibility purpose, so automatic auditing tools can assert against ARIA properties. It also helps enforce the allowed roles for specific tags (e.g., no <h1 role="button">; per w3.org/TR/2014/REC-ht…)

Gotcha. Any place I can read more on this? I know some people tinkering/interested this sort of thing (including myself), namely identifying and preventing antipatterns from hitting prod without user intervention.

Basically developers can only annotate a handful of React "primitives" with accessibility props, and those are used to limit and produce the resulting DOM/ARIA. I'm currently working on a simpler and more feature-rich API for this at Facebook

Ah cool, thank you! One other question, if you don't mind: How are you handling testing AT/browser reporting? I've found that the spec and what's supported often… differ in practice, especially when it's more than one ARIA property in flight.

Manual testing, automated testing, responding to issues surfaced by people using AT's, accessibility audits, and drawing on the expertise at Facebook and beyond. Everything still has room for improvement but we want to incorporate as much as possible by default

Thanks, that's cool to hear. A lot of this is a black box from an outsider's perspective, so it's always great to hear the reasoning behind it. I really appreciate you taking the time!

Agreed. Thank you!

There's a lot more – the behaviour associated with ARIA constructs, supporting all modalities, containing focus within trees, managing roving focus – that we're currently working on baking into React

Very cool. One thing I run into a ton of is over and mis-application of ARIA, then nasty behaviors like disabling linting and forcing merging without verifying if it works as intended. It'd be great to be able to corral that sort of thing.

baked-in is going to make things so much better. I expect developers to know basic HTML semantics but some of these widgets are even difficult for a11y pros. Having much of it solved in tools will help.

I could not agree more, captured some of my thoughts about baking in accessibility here earlier:

Not all auditors post Issue and Remediation code but I do. On "normal" sites we leave the classes so the client can find the code, but I'm wiping the generated ones because they're useless. Not everything has an id or unique data-foo attribute. Takes more time and I charge more.

But to be honest, generated class names are worse for user stylesheets than auditors. What's actually awful for auditing is extended abstraction: :root variables linked elsewhere to thing to find the property I need. Browsers should fix that though.

Supporting user style sheets hooking into 'class' is not practical or important. If a product wants to explicitly support user styling, the 'data-testid' attribute is more reliable and intentional, as that's what unit and webdriver tests rely on to select elements

I’m not sure I agree with that. Hooking into a human-readable class requires a lot less cognitive overhead and domain and framework knowledge to accomplish.

> If a product wants to explicitly support user styling This actually isn't optional. I mean, the method is optional (doesn't have to be per-se user stylesheets), but allowing end-users to adjust styles is required in the web standards.

I don't know what the call the "web standards" is about. People can still "adjust styles", not that that has ever been reliable. The current app also has more theme, font-size, and colour options available than ever before

Thanks so much for the tip on `data-testid`! I just looked, and it seems like it’s only selectively applied to key structural elements, and to tweet containers. If I want to style, say, certain components in the sidebar, `class` seems to be the only option.

You could ask the team at Twitter to add more hooks in the sidebars and ads. Or use selectors like [aria-label="Timeline: Trending now"] { display: none }

Yeah, I was just looking at a few labels as an option. Thanks again.

I've seen a lot of 'classes are for styling and not document semantics' in literature relating to a11y so I'm kind of surprised to hear that. Could xpaths make more sense in audit report like that, as well as work for browser extensions? Do you know if there's some limitation?

We literally just say "issue code: <div class="foo" aria-label="bar"><ul><div>some stuff</div></ul></div>" and then post remediation. I can't really show what's wrong or how to fix with xpaths. Everything, in the end, is HTML, CSS, and behaviour (JS).

Oh @stommepoes is absolutely right. I have had migraines trying to audit this kind of markup.

are you sure it's machine generated because "r-utggzx" is EXACTLY the sound i make when i do a style

r-utggzx in the style streets, css-1dbjc4n in the style shee—yes i’ll hold

first of all how dare you

Some time ago, I heard argument that source code should be readable for browsers not humans. Unfortunately, inspecting source code is partly how I learned HTML and CSS.

and it's how people can override author styles with the styles they need. Which hits not only plugin writers, but affects accessibility (probably not so many people writing their own CSS but at least sharing sheets amongst people with various needs)

I've got you covered

oh, thank you! i use firefox, but this looks marvelous.

In firefox you can load this file with the Greasemonkey extension github.com/giuseppeg/refi… addons.mozilla.org/en-US/firefox/… I should add that to the instructions. The downside is that you will have to update manually. Maybe I'll find the time to wrap it in a Firefox extension :)

ah, nice—thank you!

r-d0pm55 seemed obscure to me too at first but it turns out 75% of the web now uses it so maybe we should just make it a standard element. <r-d0pm55>Pave the cowpaths.</r-d0pm55>

Not sure if this is satire or not.

⭐️⭐️⭐️⭐️🐴

I like my toast with a hearty spread of r-d0pm55 in the morning.

...built-in button element semantics, to match expectations.

Please: <std-rd0pm55>

Tangent for the smart folks in this thread: anyone know of a tool to generate a Twitter list based on who you follow? I just want a chronological feed that doesn’t flip back to controversy (top tweets) every few days.

I feel like there must be something out there, but I don’t know of one—sorry!

Glad I am not the only one who has noticed this, it's DIV soup at the worst. I cannot reliably fix a bunch of things which are really bugging me.

Yeah, I hear you. It’s really challenging.

I’m as annoyed as you are because this whole thing is an unforced error on their part. 😠 I’m not sure whether this might help, but is there any chance that :nth-child() or :nth-of-type() might do any good, à la “the third <div> child, and then the fourth <div> child of that”?

Unfortunately that's kinda flakey with layouts that get changed depending on the window size.

Ah, yeah—fair point.

I will say I’ve noticed there are a few `aria-label`s kicking around, and there’s a `data-testid` attribute on a few key structural elements. Don’t know if those’d help at all, but I hope your styling goes well!

Those sound like potentially promising leads! And for whatever it’s worth, I too have a passing-to-moderate interest in futzing with twitter·com’s styling through Stylus or the like—so if yinz might come across any breakthroughs as this goes, I’d love to hear about it!

The first time I looked at the code my mind was force shutdown. It's a mess to say the least. And Facebook too now! There's like an ocean of negative space that just ruins it for me.

Also, an element with `role="article"` should reeeeeally not have `tabindex="0"`. Yikes.

Ha, weird—I was *just* wondering about that.

Would love to hear the explanation for that one. Also, big fan of CSS classes that start with `css-`.

That namespaces it to css. If you don't do that, fortran muscles its way in and starts styling things instead.

Fucking fortran. Should’ve known.

Seeing that makes me pine for the days of a regular fail-whale.

Article in a feed should have tabindex. Can’t see the parent here to know if this is the case.

It shouldn't be interactive with that role. This breaks the focus order criterion.

It doesn't have the feed role, it has the article role (both explicitly and implicity)

As I said in my original reply I cannot see from this fragment if there is a feed parent.

Yep, sorry, see my other reply.

Oh wait I see what you mean. Mind you, I can't imagine users having the first clue what is going on there, even with the role supported and keyboard events correctly implemented.

its react-native-web, they rolled it out in the previous iteration

there's still some attrs like `data-testid="tweet"` that you can use for coarse selection, but it seems like those are fairly sparse

Why are they a part of an apps api? In my limited experience it seems css/ dom structure often changes and isn’t advertised as a platform to develop against.

yeah, i probably shouldn't have called it "your public API" since that implies its supported/documented, not just that its accessible

but it _is_ accessible, and your power users -- who could be your _most valuable_ users -- are the people using it

at this very moment I'm building a component library with a CSS framework that uses inscrutable generated classnames, but i'm _also_ using stable and human-readable data attributes and css variables

because I know that our most enthusiastic users have custom stylesheets and extensions that they're using for our app, and there's no reason for us to alienate them

In this scenario a power user would primarily select via data attributes?

Yeah, every component has an attribute like data-module="Avatar" or something like that. Those attributes are also essential for testing in Cypress so it's not like it's _just_ for power users, but they're part of our considerations

But I think our users are more concerned with "theming", so all of our fonts, colors etc are set with user-overridable CSS variables

I wish I could delete my use of “power user” in my last tweet. This sounds pretty good. Will you be releasing soon?

Right, any thing that can reliably mark ui elements will eventually become an implicit api that people are going to get mad about if you don't preserve.

let's be honest: it's garbage

Yayyyy—oh no boo.

ok, it's rotting garbage on a hot summer day

Don’t know if this is still a thing: twitter.com/schofeld/statu…

Oh god 🤦‍♀️

Looks like they fixed this. A small step forward. Other things on my list though: twitter.com/schofeld/statu…

One small step for UX: one giant leap back for humanity