Allow viewport scaling (zooming) of frontend

[davidjb]

Breaking change

I don't believe this is a breaking change but as user-scalable is a defacto standard, there may be some device out there that behaves strangely. As mentioned below, it should only affect users who are zooming the UI, a new 'feature' since it wasn't possible before.

Proposed change

The inclusion of the user-scalable=no value in the viewport meta tag
prevented viewport scaling, disabling the ability to zoom the webpage.
This most typically affects mobile devices, given the nature of the
<meta name="viewport"> tag.

Removing the restriction allows a user to zoom in to see small and fine
detail in the UI -- such as zooming in on particular areas of a home
security camera streams or other images, inspecting detail in state and
other graphs, and so on.

For users with accessibility requirements, such as low vision
conditions, being able to zoom the frontend means they can enlarge UI
elements to suit them (MDN explains several accessibility concerns at
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name#Accessibility_concerns_with_viewport_scaling)

This change has no effect on users that choose not to use it (for
example, only those that engage zooming such as via pinch-to-zoom on
mobile devices will see the change) -- the frontend remains the same
otherwise. Elements of the frontend that do use pinch-to-zoom (e.g. the
Map) continue to work as expected, with pinches on that screen area
being captured by the map.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

N/A

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[bramkragten]

@balloob would there be an objection for this? Not sure if this was added for a reason?

[bramkragten]

I see the header doesn't deal with this very well, but other than that it seems to work ok...

[davidjb]

Seems to work okay for me; I've been using this in my HA install for several months.

[balloob]

We have this tag because we behave like a mobile app. We're not a normal website. Just like you can't zoom in when using sms etc. I think that removing this tag also has impact on how windows are initially sized

[bramkragten]

Closing this as it has gone stale

[davidjb]

@bramkragten Would me reopening this PR be worthwhile? As mentioned in my comment above, I've been using this change since before opening the PR and had no issues to date.

I understand that Home Assistant may not be considered a normal website, but it is a web-based platform and should aim to be accessible. As I mentioned in my original PR, https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name#Accessibility_concerns_with_viewport_scaling explains the various benefits of allowing viewport scaling and is echoed by Google's web.dev reference at https://web.dev/meta-viewport/, which includes it as part of PWA success criteria.

[bramkragten]

I think this could also cause problems with double clicking actions zooming the page?

I'm personally not agains this if it doesn't break anything, Safari already ignores this tag.

[davidjb]

@bramkragten So with the PR applied (aka user-scalable=no removed) iOS 13 in the HA app at least, double-tap actions on essentially all targets (buttons, entities, markdown card text, menus etc) did nothing. For targets with a double-tap action set (e.g. button card) the double-tap action ran as expected. The only zooming I find was when double-tapping on the contents of history graphs, the device will zoom the graph to the width of the screen. When double-tapping a history graph in a modal however (e.g. single tap an entity card, it shows a popup with the history graph), the screen zooms to fit the graph as well, but the original zoom level is restored when the modal is closed.

Other platforms' behaviour will vary, but this will already be the case given differences in support for the non-standard tag (apparently certain versions of Android require the value set as 0 rather than no, so for them, they'd already see this tag ignored; Samsung browser doesn't/didn't support it etc). As you say, in Safari/Webkit views on iOS, the tag is already being ignored. Unfortunately, I can't find any source describing the tag's level of support but given Apple's partial removal, that seems to indicate its future.

I'll re-open the PR in that case?