☁️ Nx Cloud Report

CI is running/has finished running commands for commit 2689f9e. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Sent with 💌 from NxCloud.

@CatchABus not 100% sure about perf consequences. But I think.it is always best to put that behind a property. Another reason to use a property is that components extending text-base (plugins) will also benefit from it. While if you do it in onCreateView and the plugin has its own onCreateView it won't get it.
We could try a perf test with collectionview to see If we see any slowdown because of it. But I dont think there will be any.

@CatchABus not 100% sure about perf consequences. But I think.it is always best to put that behind a property. Another reason to use a property is that components extending text-base (plugins) will also benefit from it. While if you do it in onCreateView and the plugin has its own onCreateView it won't get it. We could try a perf test with collectionview to see If we see any slowdown because of it. But I dont think there will be any.

I think we could add an accessibilityAdjustsFontSize boolean property and register it to text-base. Default value could be true (nowadays most frameworks force you to enable most of a11y anyway) and check for native view instance inside since the native API we'll be using has no support for views like UIButton.

I've tested the changes on iOS and i'm happy to report that it does fix scaling of labels / texts - however - this PR does not fix font-scaling in buttons - its missing an adjustsFontForContentSizeCategory in ui/button/index.ios.ts when creating the native view
I will keep testing font-scaling (as accessibility is a very important for our project), and report back if i find anything else missing

It seems that using UIFontMetrics API is not a suitable option for NativeScript right now.
The main problem is that even if adjustsFontForContentSizeCategory takes care of automatic resize, the height of affected elements will have to be recalculated manually by requesting a new layout. This would require traversing entire view tree to find affected views.

According to a11y guidelines, an iOS developer can align views with scaled font by meddling with layout constraints mechanism, and this isn't functional in {N} right now.
More information: https://a11y-guidelines.orange.com/en/mobile/ios/wwdc/2017/245/#auto-layout-system-spacing-constraints-1131

What we can do now is fix existing behaviour, it's like 1 or 2 missing lines to apply scale using an inherited property called _fontScale. The main problem right now is there is a flaw in Page elements related to inherited properties propagation and we'll need to fix that first.

@CatchABus on iOS you dont need to find all the necessary views and call requestLayout. Simply relayout all pages
Even if you call requestLayout on a single view, the way it works in N is that it will go up to the parent page and relayout the full page (though not optimized at all)

@CatchABus on iOS you dont need to find all the necessary views and call requestLayout. Simply relayout all pages Even if you call requestLayout on a single view, the way it works in N is that it will go up to the parent page and relayout the full page (though not optimized at all)

Yes, that was my initial thought but unfortunately it didn't work as expected since it's going up as you mentioned. You have to call requestLayout or sizeToFit on those views directly so that they update their direct parents too.

We have already gotten an inherited property called _fontScale that's doing what we want, and I think it's part of an unfinished work from initial a11y merge to core.

I'm preparing another PR for fixing a problem related to inherited properties, then I think we can complete unfinished work for font scale. :D

@dkzeb Things took a different turn and I ended up extending current functionality for a number of reasons.
Can you try new changes? They should work along with changes from PR #10225

@CatchABus - thx - i'll test it out :)

@CatchABus, i still doesn't scale text in buttons

@CatchABus, i still doesn't scale text in buttons

Strange, I have Button texts scale in the app I'm testing this.
Can you try it on a fresh new app or give me an app sample to check?

I'll have to double check, but I believe the added

apps/automated/src/ui/styling/style-properties-tests.ios.ts

file will prevent running the tests from

apps/automated/src/ui/styling/style-properties-tests.ts

because it "overrides" it during the webpack build. Checking for global.isIOS would likely be a better solution (or whatever is used in other tests that check for the platform).

If that test fails we’ll swap that, good mention.

I'll have to double check, but I believe the added

apps/automated/src/ui/styling/style-properties-tests.ios.ts

file will prevent running the tests from

apps/automated/src/ui/styling/style-properties-tests.ts

because it "overrides" it during the webpack build. Checking for global.isIOS would likely be a better solution (or whatever is used in other tests that check for the platform).

I think I might have accidentally missed this. The initial plan would be to have a common file and a blank android file that exports tests from common too. If checking for global.isIOS is an acceptable option, then sure I can change it to check for platform flag.
@rigor789 Should we display any message for the android plarform?