Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spike to understand how to match dynamic text size from iOS #4902

Closed
1 task
Tracked by #3663
romaricpascal opened this issue Mar 26, 2024 · 3 comments
Closed
1 task
Tracked by #3663

Spike to understand how to match dynamic text size from iOS #4902

romaricpascal opened this issue Mar 26, 2024 · 3 comments

Comments

@romaricpascal
Copy link
Member

romaricpascal commented Mar 26, 2024

What

Investigate how a page inside a webview may adapt to the user's having configured a specific Text Size on their iOS device.

  • Can we use Apple specific values for font?
  • Does native code need to pass a font-size to the root of the page?
  • Do Android webview need a similar feature, or on the contrary need to be isolated from such feature?

Why

This would help us understand how to match the font size configured by the users

Who needs to work on this

Developers

Who needs to review this

Developers

Done when

  • We've tested and documented different techniques for adapting to the dynamic font size configured by users.
@romaricpascal
Copy link
Member Author

There's an old PR exploring this: #1716

@romaricpascal
Copy link
Member Author

romaricpascal commented Apr 8, 2024

We'd be particularly keen to see if we can update the root font size and benefit from our font sizes being set in rem/em. For that we'd need a way to forward the font-size set by the user via Dynamic Type to the webview.

My current (and possibly misguided) mental model for how content gets loaded in a webview makes me think of the following moments we could pass a font-size:

  1. When the WebView requests the page, through a query param, cookie, or header. This would require the service to handle the injection of either some inline <style> or a --govuk-root-font-size custom property in the style attribute of the <html> tag. Puts a good chunk of the work on the service being embedded.
  2. When the WebView receives the response, but before rendering it. If there's an opening, maybe we could add a custom property to the <html> tag ourselves, from the app, without requiring anything from the service. Would be neat, but require something to exist in how the WebView handles the server response to let us modify it.
  3. When the page gets rendered, some JavaScript could ask the native app for the root font size. There are some messaging mechanisms letting the page post messages to the app, and the app run JavaScript code on the page in response. Might have to be asynchronous though and delay the display of the page a little. If not by much, users might think it's part of the loading of the page, maybe? This example might come handy.
  4. Once the page is loaded, the app could set the root font size by evaluating some JavaScript. This might cause some 'flash of unsized text' while the page is rendered, though, so potentially not idea.

However we do it, we also need to handle the fact that users may change the setting for Dynamic Type while the app is running, so the app will have to adapt to that. The app will be notified of the change, and will need to forward it to the WebView.

@romaricpascal
Copy link
Member Author

Closing this as the cycle of work was completed. There's a sample iOS app to test Dynamic Type on the spike-css-custom-properties-ios-app branch.

Adapting the font size works 🥳 It brings questions on how our typographic scale and spacing scale should adapt to the change of base font-size. We'll also need to consider whether/how to match other 'named' values for the type scale that are available on the native side or as other font values, like -apple-system-headline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done 🏁
Development

No branches or pull requests

1 participant