base-ui icon indicating copy to clipboard operation
base-ui copied to clipboard

[docs] Input font-size below 16px mobile Safari focus zoom bug

Open oliviertassinari opened this issue 1 year ago • 5 comments

Steps to reproduce

See the video in #224, it zooms, the UX isn't great. It also prevents rapid tap on the +/- button.

Context

https://defensivecss.dev/tip/input-zoom-safari/. I believe it shouldn't be allowed to use an input font size <16px on mobile. We should update all the <input> demos in this case.

I think we should also git blame the source for finding who didn't use 16px on mobile so we can notify him/her about it, so this can turn into a learning opportunity.

Your environment

npx @mui/envinfo
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: font size demo

oliviertassinari avatar Mar 22 '24 00:03 oliviertassinari

Big chance that was me :) I've since learned about this Safari thing, so it's all good. I'm pretty sure @colmtuite knows about it, too, and will tackle it moving forward on future demos. I'd say we can close this issue, though; otherwise, it'll be open until all of the demos are re-designed (as all of the APIs are being rewritten).

danilo-leal avatar Mar 22 '24 12:03 danilo-leal

Yep we're aware, there are a couple ways to handle it, we'll chat about which one to go with. +1 on closing this since it's not specific to [Input], it's more of a high-level approach to docs style guides.

colmtuite avatar Mar 22 '24 14:03 colmtuite

I'd say we can close this issue, though; otherwise, it'll be open until all of the demos are re-designed (as all of the APIs are being rewritten).

We could turn this into an umbrella issue. The pages I can spot:

  • [ ] https://mui.com/base-ui/react-autocomplete/
  • [ ] https://mui.com/base-ui/react-input/
  • [ ] https://mui.com/base-ui/react-number-input/

I'm not aware we have this issue on Joy UI or other pages.

It's also possible to have one focused PR on updating the font sizes. I imagine it won't break the designs. It can be a quick win.


As for closing the issue, I think it's best to be closed once the bug is fixed. It allows to using the open/close state of this issue to communicate progress. Now, it's not necessary important. It could be something we delegate to community contributions.

oliviertassinari avatar Mar 22 '24 15:03 oliviertassinari

I'm just not sure if it's worth spending time/energy into fixing these bugs in the current implementation, particularly here (Base UI), given all of these components should be rewritten and their demos updated in the near future. Still, I guess it's fine to have them in the back of our minds to ensure they're not repeated. But I wouldn't personally dedicate time to the state of Base UI today and just keep implementing the new stuff. We'll override all of this soon. (Unless it's an incredibly horrendous bug? But in this case, as it is just the demo styling, I'd leave it).

danilo-leal avatar Mar 22 '24 15:03 danilo-leal

It's not necessarily a "bug" either. It's just how iOS Safari chose to implement the spec, which is incorrect. So it's something for users to handle in their own apps, our NumberField won't address the issue.

colmtuite avatar Mar 22 '24 16:03 colmtuite