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
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.
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.
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.
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.
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
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.
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
> 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.
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).
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)
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’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”?
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!
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
🤦♂️ Facepalm #UI from @TwitterDesign
Adding an image description to a draft tweet in Twitter app:
1. Tap *Apply* to ‘save’ the description. (Do not tap *Cancel* or your description is lost.)
2. Then tap *Cancel* to ’save’ the tweet.