CupertinoTextField default font differs from that of UITextField's default. #67953

Activity

1. DanielEdrisian

   added

   p: cupertino_uicupertino_ui package in flutter/packagescupertino_ui package in flutter/packages

   on Oct 12, 2020
2. DanielEdrisian

   self-assigned this

   on Oct 12, 2020
3. pedromassangocode

   added

   frameworkflutter/packages/flutter repository. See also f: labels.flutter/packages/flutter repository. See also f: labels.

   passed first triage

   a: fidelityMatching the OEM platforms betterMatching the OEM platforms better

   a: text inputEntering text in a text field or keyboard related problemsEntering text in a text field or keyboard related problems

   on Oct 13, 2020
4. DanielEdrisian

   removed their assignment

   on Dec 8, 2020
5. justinmc commented on Oct 5, 2022

   

   justinmc

   on Oct 5, 2022

   Contributor

   More actions

   CC @MitchellGoodwin maybe something to look at in the comparison tool, not sure what's different.
6. MitchellGoodwin commented on Oct 20, 2022

   

   MitchellGoodwin

   on Oct 20, 2022

   Contributor

   More actions

   Compared to the text in both CupertinoSearchField and CupertinoTextField, the font weight of a SwiftUI text input does seem to be different slightly (or I've gone crazy from staring at pixels too much). Here's an S side by side for comparison.
   
   The Flutter text is on the left, the SwiftUi is on the right. The tricky thing is that the text's font weight seems to be in between our FontWeight.w400 and our FontWeight.w500. Maybe by about 20%, as far as my eyeballs can tell. In order to match native, seems like we'd have to either:

   • Adjust the font weight enums to match perfectly.
   • Do something tricky to the default font to get it to match, which the developer would likely not be able to match fully with a style overwrite.
     Both of these feel like overkill and a small breaking change that may break too many goldens compared to the benefit they'd bring.

   However the padding of both CupertinoSearchField and CupertinoTextField can be adjusted to match native a little better, which causes the text to overlap a little more naturally.

   CupertinoSearchField defaults before:
   

   And after adjusting:
   

   It's a little harder to see with the CupertinoTextField, but here's the SwiftUi text field overlayed the Flutter CupertinoTextField at 50% opacity. Before:
   

   After
   

   I think for now just making the adjustments to the padding would be fine? And we can see if there's interest in making the small adjustment to the font size?
7. justinmc commented on Oct 20, 2022

   

   justinmc

   on Oct 20, 2022

   Contributor

   More actions

   Thanks for doing that detailed analysis! The padding change seems like a major win to me...
8. MitchellGoodwin commented on Oct 26, 2022

   

   MitchellGoodwin

   on Oct 26, 2022

   Contributor

   More actions

   Partially addressed by #113958 adjusting the padding. If there's enough interest in getting the font width for the weights 100% aligned, we can reopen this issue, but I'm going to close this as that would be a fairly substantial change for a lot of apps for seemingly not a lot of interest.
9. MitchellGoodwin

   closed this as completedon Oct 26, 2022
10. MitchellGoodwin commented on Oct 26, 2022

    

    MitchellGoodwin

    on Oct 26, 2022

    Contributor

    More actions

    Reopened from merge failure
11. MitchellGoodwin

    reopened this on Oct 26, 2022
12. MitchellGoodwin commented on Nov 30, 2022

    

    MitchellGoodwin

    on Nov 30, 2022

    Contributor

    More actions

    Addressed by #115164
13. MitchellGoodwin

    closed this as completedon Nov 30, 2022
14. github-actions commented on Mar 5, 2023

    

    github-actionsbot

    on Mar 5, 2023

    More actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
15. github-actions

    locked as resolved and limited conversation to collaborators on Mar 5, 2023