[yjbanov]

(disclaimer: I work on the Flutter team)

The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where "open in new tab" isn't part of the toolkit. Perhaps it's fixable via education and platform-specific guidelines.

We're aware of the input blur issue. I think the bug is in the TextEditable. You can write your own, of course, but since we offer it as part of the Flutter framework, it's on us to fix.

[capableweb]

> You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer

This is the issue. Instead of having one codebase that works the same on all platforms (ios, android and web), you get (as a developer) the blame for not implementing things correctly across the different platforms.

Instead of a cross-platform development environment doing that for you.

[refulgentis]

I have to be honest, not trolling at all, genuinely curious to me: I have the same opinion for the completely opposite reason! _without_ "Skia everywhere", Flutter for Web was annoying, because then there was this autogenerated CSS/JS and it might be _close_ to other Flutter platforms, but it often couldn't be 100% of what it was

I think its because we might be seeing it from two different points: i.e. you see Flutter Web using Skia is not consistent with _other websites and thus traditional webapps_, I see that Flutter Web using JS/HTML made it _not consistent with deployments of the same Flutter code to Android/iOS/Mac_

Definitely see that viewpoint and why it's problematic, would argue as an independent dev, would care much more about 100% self-consistency across my product line up for ease of support than whether people open the app in a web browser, you can right click on anything that looks like an image and download it.

Understand that viewpoint _also_ sounds like sacrilege, but as someone raised on iOS dev, reminds me of when Mac devs being upset over years as "iOS-isms" made their way to the desktop. I love that this approach is an example of solving hard problems over years, fixing a industry-wide yak shave that ended with you having 50 copies of chromium. solves the same problem Electron is solving with none of the downsides

[singhrac]

> Perhaps it's fixable via education and platform-specific guidelines.

I think this is right, but I also think it should be clear to everyone (i.e. in the first tutorial) that not using a Link widget will make this work wrong for all sorts of accessibility and UX reasons. And the Link widget should work across platforms and implement the equivalent of page history correctly.

Maybe it's worth writing down somewhere what the equivalent of each tag from HTML is; what is the canonical way to create an h2, input, textarea, button, a, img, etc.