Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly Studio

webassembly.studio

Post reply on HN
Print view View original

171–180 of 231 posts

Re: WebAssembly Studio

#171

Post by danShumway »

zamadatix wrote: post #105
ddevault wrote: post #101

Earlier quoted context omitted.

You don't add ARIA tags to the UI - you use UI elements which are already accessible. You should never, ever make a button out of a div. The JavaScript community needs to grow up and stop chasing shiny things, because they're leaving huge numbers of people behind in their wake.

Bikeshedding about the best approach to making it accessible aside I think we all agree there was no out of the box button with the exact functionality and styling the project needed. Many ways to build such a thing but all of which require someone actually making the software that way as part of the project scope. Difficult? Not really. Priority to implement from day 1 in this project? Well that's what started the c…

> I think we all agree there was no out of the box button with the exact functionality and styling the project needed

We don't agree on that. Styling a real button to look the same way this does would require basically the same amount of work as styling a div. The only difference for most people is that you would need to search for a style clear for buttons, which will be the first result in DuckDuckGo: https://css-tricks.com/overriding-default-button-styles/

And it's a little bit debatable if you even want that style clear, because you should be using some of the stuff that buttons give you for free like graphical changes when the button is pressed, visual indication of focus, etc... That's all stuff that the final developer didn't even know they were missing from the final project.

So it's not even really a question about "does the button look exactly like what I want." Many times, 'exactly what the dev wants' is explicitly the wrong choice to make. Most developers don't know every graphical effect and interaction that a button should have, and they shouldn't have to. The point of native components is to make this stuff easier; you don't have to think about every interaction and use case that every non-typical user might require.

----

In Firefox, I opened the dev tools, changed the div to a button, and added one line of CSS:

  border: none;
And the button looks exactly the same as the div, except now it's visually focusable and accessible. Same is true in Chrome. And those are likely the only two rendering engines that the original developer cares about, it's not like IE11 is worth supporting for a WASM IDE.

No bikeshedding needed here, I didn't even need to look up a button reset style.

Re: WebAssembly Studio

#172

Post by fiddlerwoaroof »

ddevault wrote: post #168
fiddlerwoaroof wrote: post #158

Earlier quoted context omitted.

It doesn’t do “what I want”, it’s completely unsuitable for most of the use cases I’ve run into. Additionally, this sort of response will never work with a product manager or ux designer.

It's your job as the engineer to tell the product manager or UX designer "no" when they ask you to build interfaces which lock disabled users out of the product. Take some responsibility for the code you write. And if you really cannot use , then have the discipline to read the AIRA guidelines and make sure that whatever you come up with works for everyone.

Not really, the point of having these people is for them to make product and ux decisions. It’s my job to implement the use case they come up with (or quit): I can provide technical advice and suggest easier/better ways to solve their problems but, ultimately, it’s their call.

Re: WebAssembly Studio

#173

Post by josephg »

Vinnl wrote: post #126
rhencke wrote: post #103

Earlier quoted context omitted.

Perhaps you could open a pull request to fix this.

That would presumably be roughly equivalent to send a PR to translate a single dialog to English when the entire interface is in French. Sure, if an app is not fully translated and there's a lingering French string somewhere, submit a PR. But in this case, I don't see how this can be a serious suggestion.

Based on what other commenters have said, it sounds like the button is implemented in a custom react component. In that case ideally it should be as simple as changing the component to output a button instead of a div, with some css to remove the default button styling. Which would be the equivalent of translating a decent chunk of a website to French with one tiny change.

Re: WebAssembly Studio

#175

Post by crisnoble »

skrebbel wrote: post #64
spicybright wrote: post #57

Earlier quoted context omitted.

The accessibility mode in the firefox debugger is a good start.

Wow nice! I feel pretty stupid for just having looked over that all the time. It comes pretty close to what I hoped to get. I do see some surprising behavior though, eg I ran it on WhatsApp Web, where it complains about image links that have no `alt`. But these links do have a `title`. Wouldn't every screen reader fall back to the `title` when there's no `alt`? What I mean is, is that an actual issue or just a "satis…

If you are using a mac, try using the web for a few minutes with the built in screen reader turned on. It is actually pretty fun, and definitely helps get a feel for what a non sighted user would be dealing with. Your example with alt is a good one, but they should still have an empty alt if it is not needed/applicable. Here is an intro to voiceover https://webaim.org/articles/voiceover/

Re: WebAssembly Studio

#176

Post by worik »

TheRealPomax wrote: post #84
dboreham wrote: post #70

Earlier quoted context omitted.

I'm also intrigued by the possibilities of WebAssembly. However I also have a nagging feeling "didn't we already do this with Java, 20 years ago?". Wondering what's different this time, or is this just a MySpace vs Facebook second-times-the-charm thing.

For one, no one needs to install WASM, nor are they going to run into versioning issues because the OS has a hard dependency on it. Every single person with a computer, from a smart phone to render farm workstations, will have WASM support because those devices will have a browser. The only browser that doesn't support it is the legacy IE line of browsers, of which only 11 is still supported, and which only runs on s…

Unless your user is using a iPhone.

Re: WebAssembly Studio

#177

Post by austincummings »

worik wrote: post #176
TheRealPomax wrote: post #84

Earlier quoted context omitted.

For one, no one needs to install WASM, nor are they going to run into versioning issues because the OS has a hard dependency on it. Every single person with a computer, from a smart phone to render farm workstations, will have WASM support because those devices will have a browser. The only browser that doesn't support it is the legacy IE line of browsers, of which only 11 is still supported, and which only runs on s…

Unless your user is using a iPhone.

Safari has support for WebAssembly.

Re: WebAssembly Studio

#178

Post by ddevault »

fiddlerwoaroof wrote: post #172
ddevault wrote: post #168

Earlier quoted context omitted.

It's your job as the engineer to tell the product manager or UX designer "no" when they ask you to build interfaces which lock disabled users out of the product. Take some responsibility for the code you write. And if you really cannot use , then have the discipline to read the AIRA guidelines and make sure that whatever you come up with works for everyone.

Not really, the point of having these people is for them to make product and ux decisions. It’s my job to implement the use case they come up with (or quit): I can provide technical advice and suggest easier/better ways to solve their problems but, ultimately, it’s their call.

That's a really shitty way to think about your job. If you don't have the courage to advise your peers (which is what the product manager and UX designer are, your peers), then you aren't worth your salary as an engineer. Thinking for yourself and pushing back against bad designs is part of your job. Do your job.

Re: WebAssembly Studio

#179

Post by Alexendoo »

bestinterest wrote: post #141
skrebbel wrote: post #58

Something similar but also totally different is https://makepad.nl/ - a graphics programming IDE in Rust, for Rust, targeting the browser. It's a totally different use case but there's some similarities, somehow, anyway. Unlike this app, its actually all WASM and the author frequently tweets about how he feels more productive building a web UI in Rust than he would HTML+CSS+JS. And you can say what you want, the thin…

Is it just me that finds all the text rendering on this page really bad?

Everything is rendered directly to a canvas, at the very least it lacks subpixel rendering

Re: WebAssembly Studio

#180

Post by fiddlerwoaroof »

chrismorgan wrote: post #140
ddevault wrote: post #59

Earlier quoted context omitted.

You should fix this attitude, becuase it's making your applications worse. The browser is the best at doing the things it does, and any control that you implement yourself is going to be worse. If the browser can do something for you, you ought to let it do that for you. If you insist on writing your own controls, its behavior will differ from how the browser's own UI works in subtle ways, repeated indefinitely for e…

To those disagreeing with Drew here: he’s expressing it very bluntly, but what he’s saying is absolutely correct. People keep on reimplementing what browsers already provide, and they seldom do a good job of it. In fact, often it’s impossible to do a flawless job of it—e.g. you can’t get a custom dropdown to behave (not look, behave ) like a native without some fairly detailed user-agent and platform matching (I mean…

I don't disagree with this, the main issue I have is that the browser controls are stuck in the 90s/00s: browsers should implement new controls so we have less need for custom work here.
Post reply on HN