https://kotlinlang.org logo
Join Slack
Powered by
On Compose web is there a reason why textboxes don...
# compose-web
f
On Compose web is there a reason why textboxes don't behave like normal web ones? When typing in a compose text box all of my shortcuts (vimium) get invoked and can't input the text that want. Is there a way to get the text boxes to behave like standard html ones?
j
Well it's because Compose UI for web completely reimplements everything itself and uses no "native" controls
r
Everything in Compose Web is rendered to a canvas. If you want native controls you can use Compose HTML,
f
Yeah that makes sense, but if compose-web is going to be useable, it will need to over come some of these limitations.
a
True, that is one of the major drawbacks of Compose via Canvas. All the usability and accessibility features browsers have had for decades need to be reimplemented manually in a less performant way. I am not a big fan of Compose via canvas ;)
f
CMP is very powerful, I hope these limitations are overcome one day.
➕ 2
r
Flash developers also thought so for a long time 😁
😮 1
💥 1
🤣 2
😅 2
🚑 2
😁 1
o
Given that Compose originated in Mobile land where sophisticated accessibility is a commodity, does it make the slightest sense to compare it with Flash?
a
Yes, because it is about the target. And the target is a drawing canvas with some basic event handlers. The sophisticated accessibility is rendered void in this new target
o
I was referring to mobile app platform’s accessibility, not the browser’s.
a
True, and that is rendered void in the browser
o
You’re thinking that they don’t have an idea about how to make the same thing work in Compose for Web?
a
Of course they have an idea. They are clever and hard working people. It’s just a lot of work. And the experience will always be limited compared to native devices and their sensors. Compose for Web will have its own usecases. But I just don’t see it succeed as a full fledged target for apps. There are architectural aspects outside of Jetbrains control and they will limit the features and behavior. Desktop and Android are less so limited by this and are way more mature than canvas.
But I’d love to be proven wrong.
Look at Flutter for Web. They’ve had a head start. Look where they are. Same target, same technology (Skia).
o
If we stick to the topic of usability and accessibility: Could you point out concrete capabilities that you think cannot be implemented in Compose for Web, but are available in browsers?
a
They can all be implemented. It’s just a LOT of work. And my guess is that Web is not the target with the most FTE working on it. But…. The TS talks about text boxes not working as expected. Other things at the top of my head: Aria labels. Tabindex without focus on canvas element. Search in text and page with browser search.
r
Browser capabilities are evolving rapidly. IMHO canvas rendering will always lag behind, no matter how fast the team will work.
o
Isn’t the reverse true as well? Compose UI (Skia) is evolving rapidly (e.g. animations, complex layouts, DX), browsers being tied to their HTML/CSS/DOM legacy and the necessity of vendors agreeing on a common standard will always lag behind.
r
It's true as well. And nobody says CMP for Web is useless crap 😉
o
In the end, it all boils down to context. What does the actual use-case require today? What does the evolutionary path look like? For example, if you need screen reader support or today's SEO, you cannot use Compose for Web out of the box. Tomorrow that may change in many ways: SEO may no longer be a thing if our websites are crawled for AI model training data only, without giving anything (traffic) back. Another possible change is that Compose for Web may acquire accessibility support like UI element descriptions available to crawlers. On the other hand, if you have a desktop application which you'd like to demo in a browser, Compose for Web is a viable option today. And once accessibility is addressed, I wonder if we'd still see a large amount of conventional browser or desktop applications at all, if we can deliver a full-fledged Compose UI app on all platforms from a single code base. (Limitations may apply in low-bandwith/unreliable networking scenarios.)
☝️ 2
➕ 2
💯 2
f
Thanks for the perspectives guys 🙂 looking forward to evolution of this tech over the next few years!
z
As someone who was highly involved in writing 
BasicTextField
for Compose for Android, i think it's pretty safe to say Compose for Web text fields will never match platform ones completely. First of all, that would require the CfW impl to implement custom behavior for every browser + OS combination, which is probably unfeasible and just not worth the herculean effort. Second, even Compose for Android doesn't perfectly match Android text input, and while theoretically it could get to that point, it isn't necessarily even the goal since there might be text editing behavior improvements Compose might want to make on its primary platform, and the same likely applies way more for CfW.
➕ 2
And third, while some effort has been made to expose an IME API as a web standard, AFAIK the proposals never went very far and the options for web to interact directly with device soft keyboard are quite limited compared to native apps, which makes matching text field implementations 1:1 much harder if not completely impossible.
➕ 1
a
Interesting. So what is the goal of Compose for Web then? A choice for an “okay” target in favor of portability to and from other platforms?
z
I can't speak for that, but I highly doubt it's matching exact browser-specific behaviors for every component+browser+platform out there. That's virtually impossible. No cross-platform toolkit does that without using actual platform components under the hood.
o
Portability is just one aspect. Why limit Compose for Web to the browser's legacy? In the end, it could be the better web target.
🤔 1
z
Getting into the weeds here, but would it actually be better if it will always be inconsistent with every other webpage out there? As a user, that's just going to be frustrating, even if in a perfect world CfW could be "better" for some definition of "better".
✅ 1
f
One of composes benefits is that it doesn't match platform specific behaviours. It allows room for creativity, improvement and different thinking. But there must be a minimum set of requirements for it to be useable on these platforms, one of them typing reliably into a text field.
z
Personally, this is why I hate most apps built with cross-platform toolkits. It's uncanny valley, and suddenly i'm thinking about how inconsistent the interface is instead of whatever i was trying to do initially.
✅ 2
o
Has the web ever been a consistent ecosystem?
☝️ 1
z
With hardware keys, it's probably possible for CfW's text field to at least be usable. Not sure about for software keyboards. But that's a different question than directly matching platform behaviors.
➕ 1
Has the web ever been a consistent ecosystem?
True, but when you have an input element that uses a text box, at least it's up to the browser to make sure text editing works in there, and usually consistently across websites.
o
The OP mentioned a browser extension that actually rewires the browser's keyboard mappings. From that point on it stops being consistent with anything else. Websites usually expose inconsistencies between browser products and versions. I'm not saying that cross-platform toolkits always provide a better solution, but if done properly, they could potentially win over browsers in terms of consistency.
I think it's fair to add that we're approaching the consistency aspect from two different directions here: First, the website user's expectation, which would be that their browser operates consistently across sites. Second, the website creator, who would want their site to perform consistently across browsers. In the former case, the browser would have a competitive advantage, in the second one, the browser-independent UI toolkit might have it.
✅ 1
f
The competitive advantage is write once run on different platforms, but if multiple if/defs or platform dependant work arounds are required, it no longer becomes competitive (maybe slightly more for experienced kotlin devs, attracting dev's from other platforms will be an impossible task).
o
I agree that cross-platform consistency should come with minimal developer effort, and my impression is that Compose goes a long way towards that goal. But I wanted to point out something different: If we look at the web ecosystem, we are frequently experiencing that websites render differently with different browser products and versions. A consequence might be that the "Buy" button is off screen. With Canvas rendering we can be sure that it renders the same on all targets. And that's even more true if a large part of the complex machinery below is identical across platforms, which is the case with Compose. In other words: Compose has a single set of bugs, each browser has its own.
f
That is a great point @Oliver.O. It's all just drawing commands at the end of the day. But the edge cases lay outside of those simple drawing commands, like input. Hopefully these get smoothed out over time. And if/defs are unavoidable for any crossplatform app.
➕ 1
a
There are rendering differences between browsers on canvas ;)
🤔 1
o
Are there? Which ones?
a
But it isn’t that strange right? The canvas is a specification and even the best specification has ambiguities. Not even taking implementation faults into consideration there will by default always be rendering differences between browsers. These are outside of Jetbrains control
o
That's not how Compose for Web works. It renders everything via Skia/Skiko, which does not even run in JS on the browser but in WebAssembly. So Compose for Web is actually consistent across browsers (and other targets) where browsers are not. In this case it's Compose 1 vs. Browser 0. Edit: The conclusion in the last sentence is probably incorrect: See below.
j
More like Compose 1 vs. Browser 10000
😕 1
o
❓
j
The browser is the canonical cross-platform toolkit against which everything should be compared. Compose UI eschews basic fundamentals of a UI toolkit that doesn't make it a good choice objectively. The only reason to choose it is because you have existing Compose UI and don't have the resources to build a web app.
✅ 5
o
How does that relate to the specific rendering issue in cross-browser consistency I was referring to?
j
If that's the case, though, you probably should have built a web app first and then you'd already be done
o
I'm not sure I follow. We've been discussing upsides and downsides of Compose for Web in different contexts in this thread. No one has claimed that CfW would make a viable option for every use case. So are you implying that someone claiming that Compose for Web works in specific contexts has never actually tried it? And browsers being the "canonical" reference, but then behaving inconsistently across the board is a good thing?
j
Summarizing browser behavioral differences as "inconsistent" is ridiculous hyperbole
Compose UI varies more far wildly across platforms than browsers across vendors
f
The real question is, and it will be situation specific, when is CMP a viable solution for your product? At the moment it just seems like a fun prototyping tool for Web.
a
I think what Jake mentioned: if you have a CMP app and don’t have the resources to make it properly web
✅ 1
f
I can't even type in the text box for my App ... so not very viable imho
a
@Oliver.O you do realize it doesn’t matter if it is wasm or Js? I know it is Skia. But Skia for web doesn’t directly address the graphics layer of your system. It addresses the canvas api which can have differences in implementation. As far as I know there isn’t a web tech that allows you to directly address the hardware. Be it WASM or JS. Even WebGPU is still a layer on top which is a spec implemented differently across browsers. I believe it all goes to WebGL context.
🤔 1
o
It's not a matter of rendering to the hardware. What matters is: Who does the text shaping? Regarding the font rendering issue, I was probably wrong: Skia does not shape text on its own, instead, it uses the platform's font scaler engine. On browsers this is CanvasRenderingContext2D: fillText(). So if neither Skia nor Compose mitigate the text rendering quirks mentioned above, Compose for Web would probably suffer from the same problems as browsers in JS contexts when drawing text on Canvas. Having said that, I think that generalizing from one's own (necessarily limited) experiences is just not helpful. This ecosystem is so large and so are its use cases, that we're all better off being as specific and providing as much context as possible. For example until early this year, a CfW text field would lose the text cursor (caret) when typing. I was tempted to say "CfW is completely useless until that is fixed". I'm glad I did not. There are folks creating web apps without text fields (or rendering their own). In that regard, I stand by my point: context matters.
r
Someone mentioned less of a need of web apps if a single codebase can give you native apps. But web still has so many advantages in deployment and updates and control. It's hard to compete with those.
But a counterpoint: so many web apps are complete c*** on a mobile browser that it makes me suspect if it were a Compose web implementation of a mobile app (or a desktop/mobile app in a mobile form factor) the UX would have been much better.
r
Other things at the top of my head:
Aria labels. Tabindex without focus on canvas element. Search in text and page with browser search.
Yep. Here is another one: select text and copy. Its just not a great UX for most web use cases. Canvas apps just feel foreign to the web, because, well, they are.
j
Right. The web becomes a distribution mechanism, not a runtime. And that's fine, especially for things like games which have always used custom UI. But when you're trying to replicate the experience of native it's a long climb out of the uncanny valley.
👍 4
4 Views
Open in Slack
PreviousNext
Powered by