The fact they're using gpui is... Bad. Is someone trying to make it integrate with native accessibility frameworks? If not (and if they force the native app on us) this transition is going to lock out a ton of people who use assistive technologies.
Yes, see: https://github.com/longbridge/gpui-kit. I've been following these rust UI toolkits and things like accessibility have consistently been missing. This is the first time I've seen a UI library that appears complete enough to build a real product with.
Yeah, that's what worries me. Pretty much every Rust UI library I've seen which isn't wxdragon/Relm/GTK lacks accessibility. And most of them don't even have the primitives for it (given that most of them are abandoned).
You are dismissing again the answer you are getting. Why do you think it is lacking accessibility despite using a framework claiming " GPUI Kit ships 75+ documented components and primitives, WebAssembly support, AccessKit accessibility"
I don't know why people are ignoring the pink elephant here. For medium scale projects, like a Discord app is going to be, LLMs are now at a superhuman level of competence, including on higher level architectural/structural type decisions. I would be beyond surprised if the rewrite wasn't largely done by Claude (or similar). And in this context accessibility is also just a prompt away, if it wasn't included from the get-go, which it probably would have been.
Accessibility isn't just something you one-shot. It takes a lot of back-and-forth and testing with actual screen readers/accessibility scanning tools to be good.
I'm not dismissing it, just uncertain how good it is. Quality over quantity and all that. You can have 75 or 100 or 200 UI components and some can be perfectly accessible while others might not be even things accesskit supports right now. Or Accesskit may only partially support a widget. As I've said downthread, I'm hoping that Discord using a UI toolkit like this will cause upstream effects with respect to Accesskit coverage, so we'll have to see when they start migrating people over to it.
This is exactly why I started working on Day (https://daybrite.dev) as a successor to Skip (https://skip.dev). It uses platform-native toolkits everywhere, and so accessibility comes for free.
I haven't exactly "launched" it yet, but I'm already shipping apps through the App/Play Stores. See https://daybrite.dev/showcase/ for the 5-minute tour.
Yes, and this is good progress (my comment downthread was before I just looked). According to it it uses accesskit, which is quite good already but still in development so accessibility would not be as good as using UIA directly. I am hopeful though that accesskit (which is also used in Godot) will keep getting better and these gaps can be closed.
This is one angle. I do not see it as a deal breaker in the way you phrase it. I suppose we all have our own. If everyone's had to be satisfied, we'd have no software!
I think in the specific case of Discord, I.e. from a big company, I agree they should handle this properly. As a broader standard, I am not as concerned.
This is a dealbreaker for me even if I didn't want it to be. If your application does not either interact with a11y frameworks (UIA, AT-SPI, NSAccessibility, ...) or does not implement an equivalent that communicates with my screen reader, I literally cannot use your application. I could OCR your application, or use AI and have it use your app for me via screenshots, but neither are even remotely comparable to using the native platform accessibility frameworks.
Could someone use AI to make the GPUI kit become accessible? You (or someone else) mentioned that it doesn't even have the primitives so is it a non starter?
No, I mentioned that most rust UI toolkits lack even the primitives. The primitives for even basic accessibility, without accessibility frameworks, would be things like focus events, carrot navigation, navigation in containers such as list/combo boxes, line/paragraph handling in multi-line edit boxes and the like. Adding native accessibility forces you to do a lot of this but just in a different way than routing text directly to a screen reader.
As for me doing it? According to prior comments in this thread it's already done, although I haven't tested it so I don't know how complete it is. Adding UIA support to a framework is different from making that support good (screen readers can be very picky). As an example, say you have a label of an edit box. If you position the label just right within it's parent container a screen reader will pick it up automatically and just announce it as you focus the edit box. But if you don't, all you'll hear is "edit ". There are ways around this (e.g., you can override label detection) but the "ideal" state is that the screen reader picks up that stuff automatically and you just give it the bounds of the various controls and UI elements.
It’s potentially a dealbreaker for millions of people whether they want it to be or not unfortunately. For them accessibility is not optional or can otherwise be taken as a “wait and see” issue.
gpui does have a11y support for accessibility, Zed just hasn't piped it through yet. I'm also pretty sure Discord is using their own fork of gpui with patches to add any missing functionality they needed
weird how the website doesn't have a single screenshot on it, considering it's for a GRAPHICAL user interface. You'd think the examples page would have some screenshots, but in fact it's just example code snippets with no indication of what the code would render as.
I was a big fan of pico! Such an inspiration. I created https://github.com/lekoala/actual-css as an attempt to get something modern yet as compatible as possible with older browsers (still ended up using popover because it's such a welcome addition to modern css). I'm still not sure modern css frameworks need to use layers (it breaks on older browsers) or anchor positioning (minimal js does the job, sometimes even better, and again: more compatible).
It's broken in the exact same way in the last version of Vivaldi that works on Windows <10.
From a quick look at the second horizontal strip that starts "what is this?", and without wasting time doing too much digging, it appears to be ultimately caused by using a grid layout for a heading followed by a few paragraphs, all of which fill the available (constrained) width, which amounts to one of the absolute simplest layouts possible in CSS - block. Last time I saw something similar, albeit with flexbox not grid, it was from a junior developer who appeared to have only learned flexbox and nothing else.
As a quick semi-fix, just disabling grid-template-columns on .base-layout is enough to fix almost everything except the constrained width.
Sounds like that older Vivaldi version does not support CSS nesting. I looked into it. I'm assuming you are using Vivaldi 5.6 which uses Chromium 108, native CSS nesting became supported in Chromium 112.
It uses CSS Grid to create a centered, width-constrained content area while allowing individual elements to break out of it or span the full viewport width. This provides a flexible, consistent layout without the need for additional wrapper elements in the HTML.
CSS nesting has had full browser support for more than 3 years now, I recommend updating. I'll also add fallback for older browsers, but the Grid layout itself isn't the issue.
Yes, that's right. I thought I'd try it in that older browser that I still happen to have installed, as the user above didn't immediately let us know what that mobile browser was. It may or may not help by at least giving you a browser version you can use to test. As I mentioned somewhere else, it makes sense to use some sort of older browser as a proxy for older browsers in general, when testing.
Developers are always looking for new ways to do what we've always done, often using more technically complicated ways to recreate the simplest things. It's fun from the puzzle-solving point of view, but your choice of earliest browsers you want to support depends on your user base.
I built https://purecss.com (not pure-css.github.io), maybe you'd find the site helpful? Currently it's 77 CSS patterns and another ~20 coming in the next few weeks. Each have a demo and the code underneath. Check it out and let me know if there's something you can think of that you'd like to see there. Happy CSS'ing!
Yea, exactly and thanks! I love making CSS things that were previously only possible with JavaScript. Carouses, accordions, toggle switches, etc. I love how powerful CSS has become over the last few years!
Yes it is a pain. But the whole thing is like two pages, so I^H my LLM just reads it. I used to read it. It was ok readable (and I'm not very good at CSS).
Ios 13.6 in my case, which was released just 6 yrs ago, 2020. For some context, flexbox gap was added in ios14.1, released in 2021. So iOS 13.6 was still usable atleast couple of years beyond that. So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
People keep forgetting that css3 was announced in 1999. And adoption roughly started from 2010. The css3 of that time is not the same as css3 you get to see in latest browsers. These minimal css frameworks are really useless if you don’t know what css3 features you are writing and who you are targeting.
And, I Haven’t even tested those in less capable browsers like dillo or netsurf, but I doubt they will even work there.
If you start looking into browser market share, you will quickly realise that there are millions of worldwide users who can’t use the web normally.
> When you say something is minimal, you are implying that what little you provide will also work.
No you do not. You just saying it’s got very little code and/or very few features.
Support for older browsers might not be one of those features. Which means this minimal frameworks isn’t suited for the kind of projects where that kind of compatibility is a concern.
If you look outside of CSS (and particularly web development as a whole) you’ll find a plethora of minimal frameworks that intentionally make compatibility trade offs.
As you're mainly complaining about CSS layout features being used here:
For a long time we were forced to use the ugliest hacks imaginable to get to the nice (responsive, design-minimalist(!)) layouts we wanted, because CSS layout tools were utter archaic bs, for years on end, because browsers iterated so slowly.
Then things started speeding up, and we're getting to make better websites (and apps!) that are way easier to design (with the correct design theory equivalents), implenent (with less code) and easier to maintain (i.e., understand). And you're not missing out if you just keep your browser up to date.
I know it sucks if you're on an unsupported device that doesn't get any updates, fair.
But let's face it: 99% of the population is better off security-wise when we're not enabling them to run unpatched devices forever.
Security updates have nothing to do with level of support for css3 modules.
Much of the issues of layout were already solved more than 12 yrs back, ie when css3 became mainstream.
The issue is devs are unaware about different levels of css3 or just plain ignorant about it.
Are you aware about the different levels of css3? Are you even aware there are levels to css3? Why are these frameworks not listing them and simply saying that they comply with web standards? Which specific web standards do they comply?
Any new css3 feature should have a fallback if they say they comply to web standards, which these frameworks don’t add.
To be fair on this particular point, talking about iOS Safari before version 14 isn't "some random old build". It depends on your own users, but I saw plenty of 6-year-old iPhone user agents in the web logs when dealing with a doctor's surgeries app.
They don’t unfortunately but it is a good reference for me to check how it looks on previous versions of browsers and less powerful devices. That way I know if the UI or UX needs improvement.
ios updates unfortunately ties everything to a single batch. Unlike android. I have an older blackberry, that still gets latest app updates.
What is even hilarious is ads render with pixel perfection on older devices. So for some reason, ad networks care about browser compatibility than devs putting the same ads on their incompatible website.
Exactly. Ad creators know that the purpose of what they're building is more important than their personal dev experience of using shiny new tools. It's such a shame the fashion is the other way for so many web developers, largely the younger and less experienced ones.
And yes, it makes sense to use one particular old browser as a general proxy for older browsers in general, so people shouldn't get hung up on the particular version of Safari you happened to mention.
> It's such a shame the fashion is the other way for so many web developers, largely the younger and less experienced ones.
I don’t care about what’s trendy, but using outdated, insecure browsers to surf the web is just plain stupid. Even more, expecting developers to waste time working around all the bugs in those old browsers is just insane. I do the opposite: as soon as a browser reaches EOL I drop the support. Don't encourage lazy admins and bad habits.
It's a shame such an arrogant attitude exists, to call everyone who can't afford to replace their iPhone with a newer model "stupid". And developers really should know better than to fall for the marketing nonsense that anything more than 5 minutes old is "insecure".
> expecting developers to waste time working around all the bugs in those old browsers is just insane
What bugs? The ancestor posts are talking about frameworks immediately using features that were just added to browsers - i.e. more recently than those older versions. Nothing at all to do with bugs. Can you help us to see what you've misunderstood here? Perhaps not dismissing users as "stupid", developers as "insane", and admins (?) as "lazy", would be a good starting point.
I guess at that point I have to assume you have no idea about front-end development. Otherwise you would know what a pain in the ass old browsers with their inconsistencies are (e.g. remember the struggle with the early flexbox implementations?).
I don't disagree! But at the same time, part of our job as web developers involves acknowledging the reality of what our users actually do.
What do early flexbox implementations (something like 12-15 years ago?) have to do with anything? We're not talking about browsers as old as that! They weren't even bugs, they were early implementations of early versions of the standard, so who exactly is the one with no idea here? That level of browser inconsistencies is long gone.
Those of us with years of experience of building user-centric front-ends are not the ones who jump to use new browser features too quickly.
I won't be continuing this conversation, due to the general arrogance and condescension displayed in your posts - following "stupid", "insane" and "lazy" with "bad decision", "where have you been" and "you have no idea".
> What do early flexbox implementations (something like 12-15 years ago?)
It shows that a) new technologies may add value and also that browsers constantly fix bugs due to complex or underspecified standards. It was just an example, go through the issues lists and you find a lot more.
> not the ones who jump to use new browser features too quickly
That's reasonable but there is a point where support just should be dropped. Don't support IE 5 for ages just because someone is too scared to update. Let them fix their technical debt. Encouraging people to access the internet with insecure software is not acceptable. Btw. that was the argument you completely ignored in your reply.
OP was referring to a meme from the iPhone 4 era, where users complained about a dropped signal, and Steve Jobs responded to one person saying to not hold it a certain way.
I haven't been around HN toooo long, this is the first time anything posted here has brought a tear to my eye. That's very sweet, and I'll be throwing a little rebeccapurple in to projects from here on out.
hey, maker here. I have no idea of this one, looks pretty cool! I've rolled out my stickman game here with deep care on everything, from DO multiplayer setup, to game-feel.
The pre-stuffed, pre-configured, plug-n-play, extra-spooky-box method described in the article is just one of many methods.
Someone I know buys cheap "IPTV" service by the year. Access is paid for by buying potted plants or something else that looks random on some web store and is delivered in the form of a .m3u playlist that hides behind a username/password pair.
The usual way they use it is with slimey-feeling closed-source sideloaded apps on mass-market streaming devices from such unknown companies as Amazon and Google, or directly on a smart TV itself. Wherein: Despite the dingy back-alley ambience of the subscription and installation processes, the UI is snappy and responsive in use.
And the slimey software is also avoidable. Since it's all based around a playlist that is hiding behind basic http auth, it also works with open-source projects like Dispatcharr, which in turn can emulate an HDHomeRun network-connected OTA TV tuner. This combination can then present new possibilities, like live streaming TV for Plex users.
(It'd all be very interesting to me if I had any motivation to sit down and absorb live television like a slug, but I didn't do much of that even when I worked for a cable company and got the uber-premium package for free as a perk.)
Pocket Casts was originally developed by a South Australian startup, Shifty Jelly. Sold to a consortium of public broadcasters which included NPR. Then there was a change of heart the the public broadcasters decided that they actually don't want to be in the game, so was divested in a firesale.
Automattic has picked up a few of these assets for peanuts, Tumblr and Pocket Casts are amongst them. All are assets which were once much more high flying, but still have a core of dedicated users/fans.
[0]: http://zed.dev/
reply