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

151–160 of 231 posts

Re: WebAssembly Studio

#151

Post by ddevault »

fiddlerwoaroof wrote: post #139
corytheboyd wrote: post #113

Earlier quoted context omitted.

I didn’t downvote because I can agree to a certain extent. Are you suggesting a completely unstyled web or something? Maybe if you fleshed out that idea you would be met with less criticism. There is a good lesson here though, native browser controls should ALWAYS be your first consideration when building UI for the web. Try everything under the sun to stick as close to these as possible before you give up. You will…

Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.

"Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.

Re: WebAssembly Studio

#152

Post by zamadatix »

simonh wrote: post #112
zamadatix wrote: post #93

Earlier quoted context omitted.

> What does being MIT licensed have to do with it It's a non commercial non government project. > And please, don't anyone dare chime in with the the standard "if people want a feature in open source they can 'simply' implement it themselves". Already talked about it in the parent comment, would be interesting if you could respond to that instead of asking nobody mention it. > UI technologies that don't include acces…

>It's a non commercial non government project. Yes I know that, what's that got to do with not having accessibility? And no it doesn't have to be perfect, it comes down to what we consider acceptable.

> Yes I know that, what's that got to do with not having accessibility?

Many (most?) will have different accessibility expectation for software from each of these categories, particularly since in many jurisdictions government and commercial have accessibility laws to follow or expectations on service because of payment/funding. In this case the question is what does accessibility have to do with the project not the other way around and the answer is "whatever people want to contribute to the project" not "what simonh finds acceptable of the project".

> And no it doesn't have to be perfect, it comes down to what we consider acceptable.

But you don't decide what's considered acceptable for someone else's freely available open source software they do. It's also not translated into every language and won't run well on every device. A very large portion of the world can't use it but it's just someone sharing what they've managed to make not someone saying everyone in the world will find the software acceptable or that they owe any functionality out of it to anyone else.

Re: WebAssembly Studio

#153

Post by sgzfx »

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?

Definitely not, it does not look pleasant to me either. At first I thought it was just the small font size, but I noticed it on the "Edit" page as well.

Re: WebAssembly Studio

#154

Post by fiddlerwoaroof »

ddevault wrote: post #151
fiddlerwoaroof wrote: post #139

Earlier quoted context omitted.

Dropdowns are frustrating because the select/option is only really good for simple cases and browsers block restyling: as soon as you get a requirement like “Dropdown with multiselect”, you have to rewrite the whole thing: and, for visual consistency, this usually means rewriting all the dropdowns.

"Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.

Nope, per MDN:

> When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown.

This is not “dropdown with multiselect” because it doesn’t “drop down”

Re: WebAssembly Studio

#155

Post by ddevault »

fiddlerwoaroof wrote: post #154
ddevault wrote: post #151

Earlier quoted context omitted.

"Dropdown with multiselect" is addressed by adding the "multiple" attribute to your select tag. Which has been possible since the 90's.

Nope, per MDN: > When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown. This is not “dropdown with multiselect” because it doesn’t “drop down”

Tough shit? It does what you want. It doesn't have to look like what you want.

Re: WebAssembly Studio

#156

Post by iratewizard »

thwarted wrote: post #72
spicybright wrote: post #54

Earlier quoted context omitted.

Exactly this. Yes, accessibility is very important, but as of right now, it takes non-zero effort to implement correctly. So you must balance that with other priorities depending on the goals of the project.

The goals of the project includes "custom buttons"? There's so much functionality that you get for free/low effort if you don't feel the need to customize everything to the nines.

I don't understand this entitled attitude. The OP can build things however they want. If their style of building makes it hard for the 0.05% of internet traffic that uses a screen reader, it's not open season to be a shitty person. If I were the OP and received feedback like this, I'd personally start aria describing how you all need a better mix of anti-anxiety and antidepressants.

Re: WebAssembly Studio

#157

Post by jablan »

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…

How do you know what styling the project needed? What styling requires a button to stop being a button?

Re: WebAssembly Studio

#158

Post by fiddlerwoaroof »

ddevault wrote: post #155
fiddlerwoaroof wrote: post #154

Earlier quoted context omitted.

Nope, per MDN: > When multiple is specified, most browsers will show a scrolling list box instead of a single line dropdown. This is not “dropdown with multiselect” because it doesn’t “drop down”

Tough shit? It does what you want. It doesn't have to look like what you want.

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.

Re: WebAssembly Studio

#159

Post by Stratoscope »

chrismorgan wrote: post #133
pickpuck wrote: post #74

Earlier quoted context omitted.

> > The buttons are clickable divs, not actual HTML buttons > It'd certainly be nice if everything just automagically worked about accessible UI but we're not there yet OP's suggestion is that the author should have used native HTML , a simple solution that has worked since the beginning. But you're right that it's not so elegant in reality: You must remember to add type="button" attribute, otherwise clicking it coul…

I quibble over a few of your points: (a) type="button" only does anything if the button is form-associated—otherwise it’s the default. And even then, if your button within a form is semantically submit buttons (as the Create button here is), the semantically-best technique is instead to leave the button as a submit button, and instead of using a click handler on the button, to use a submit handler on the form and do…

> if your button within a form is semantically submit buttons (as the Create button here is), the semantically-best technique is instead to leave the button as a submit button, and instead of using a click handler on the button, to use a submit handler on the form and do event.preventDefault() within it.

This is my biggest pet peeve with so many modern websites and web-based desktop apps. It's not just a matter of being semantically correct in some abstract sense, it completely breaks the user experience for a keyboard user like me.

If you have a form with, say, two text fields, I expect to be able to type into the first field, hit Tab to the second one, type into that one, and press Enter to submit.

All too often, when I press Enter, nothing happens! This is because of the very problem you described: the developer used a click event handler on the submit button instead of a submit handler on the form as they should have.

It's such an easy thing to get right; why do so many get it wrong?

Re: WebAssembly Studio

#160

Post by k4rli »

mwcampbell wrote: post #10

The "Create New Project" dialog has serious accessibility problems when used with a screen reader. The buttons are clickable divs, not actual HTML buttons or even marked up with proper ARIA. I haven't yet ventured any further into the app. Given that the app is a WebAssembly development environment, my first guess was that it was built in WebAssembly itself, with a custom UI framework. But in fact, it's plain React,…

Do development tools really need a11y? I haven't come across anyone with this need before.
Post reply on HN