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

Reopening #6157 as per discussion with @bramkragten

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: Allow viewport scaling (zooming) of frontend #6157
• 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

[Brahmah]

I don't believe such a change is a great idea. It causes unusual bugs and worsens the user experience (especially on mobile). If you are really keen on adding such functionality, maybe contribute to a project such as Custom Header or develop an option in the user profile page that enables zooming. Maybe @balloob can further tune into the decision.

Bad 1min Mockup:

[davidjb]

@Brahmah On mobile iOS Safari at least - support for this tag was removed in iOS10 (ref). This doesn't currently affect embedded web views, though, which includes the iOS app.

As for making the user experience worse, having the tag present affects accessibility (my personal use case) and usability. The HTML 5.2 spec covers why user-scalable=no shouldn't be used:

Authors should not suppress or limit the ability of users to resize a document, as this causes accessibility and usability issues.

The following examples illustrate code that should be avoided:
<!-- DO NOT DO THIS -->
<meta name="viewport" content="user-scalable=no">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">

There may be specific use cases where preventing users from zooming may be appropriate, such as map applications – where custom zoom functionality is handled via scripting. However, in general this practice should be avoided, and HTML conformance checking tools should display a warning if they encounter these values.

On this last use case, Home Assistant does have a map embedded but the map zoom still works as expected with user-scalable=no removed (I've been patching my frontend since just before original PR).

In any case, because the tag is non-standard, support on different platforms will already be mixed: apparently certain versions of Android require the value set as 0 rather than no - so those devices would already see this tag ignored. In a similar vein, the Samsung browser doesn't/didn't support it at all, Edge mobile disabled its support in 2017. Information is scattered because the tag is non-standard but https://adrianroselli.com/2015/10/dont-disable-zoom.html anecdotally sums up most of what's of on the web around this tag.

A user profile or app option could be a solution, but the HTML spec highlights the risk with doing this because "[it] may however not be immediately apparent to users". If an option were to be provided, the most accessible option would be to have zooming enabled by default - and then if a user would prefer to zooming be disabled, they could.

[maykar]

Sorry for intruding on this, but if this isn't pulled I will have Custom Header remove the tag by default with an option to disable. I'm even willing to make another project who's sole purpose is disabling this tag. That way all a user needs to do is install it.

That being said, I shouldn't need to do either of those things. Accessibility should always be a top priority and accessibility options should never be removed. I see no reason for this not to be pulled as the setting has already been ignored in multiple mainstream browsers. If this causes any issues then those issues need to be addressed anyhow as they are currently a problem for any browser that doesn't support this tag.

[maykar]

I created a project on the custom-cards repository in case this isn't pulled, or while waiting for it to be pulled and released, or for testing this change easily:

https://github.com/custom-cards/viewport-accessibility

[T-bond]

I think this PR is a good idea. We just got 5 new cameras, and we would like to zoom into them.

And yes, blocking zooming on a webpage is a bad idea I think. If somebody doesn't want to zoom into, they won't. Or if they zoom into it accidentally, they can turn of this feature. But who really needs this, can't do this without this PR.

[zsarnett]

The issue is that HA is not really a webpage. its a webapp. You cant zoom on Twitter...

[maykar]

The Twitter app offers the ability to increase text size and in most cases will follow the text size when set in the mobile device's accessibility settings. You can also tap photos in twitter to enlarge them, zoom, etc.

So, okay, HA is a webapp, but without accessibility settings. Being a webapp doesn't just exempt it from such things.

Edit: Also, if using Chrome on Android to access Twitter's webapp you can absolutely pinch to zoom.

[zsarnett]

I cannot pinch zoom on the chrome twitter page.

[maykar]

That just reinforces the whole, non-standard support argument:

[bramkragten]

Only thing I'm worried about is double tap actions, will they make the page zoom?

[maykar]

@davidjb Answered that in his previous PR #6157 (comment)

I haven't given it a thorough testing myself though. Happy to do so when I'm able to.

[davidjb]

@bramkragten I've re-tested with HA 0.115.6 and companion app v2020.6 (11) on iOS 14.0.1, testing as much of the UI as I can:

• Targets with a double-tap action set (e.g. button card) run as expected
• Double-tapping only zooms the UI in one specific location (that I've found, anyway): in empty space on the <app-header>; to the left of the icons in <paper-tabs> initially or in the empty space to the right of the icons when icons are scrolled to the far right.
  • Double-tapping on other targets (buttons, entities, markdown card text, menus etc) does nothing
• Pinching will zoom in the UI everywhere generated by Lovelace (e.g. not the app UI), with the exception of:
  • Map - pinch to zoom zooms the map; pinching on the menu bar will work if the pinch remains inside the bounds of the menu bar (e.g. horizontally)
  • General Configuration page - location map; the map zooms rather than UI

For reference, from my previous testing , the behaviour is the same with the one difference that double-tapping a history graph now does nothing at all in the current HA / iOS 14.0.1, in the main UI or in a model (it previously zoomed the UI in iOS 13 / whichever was the Release version of the app on 28 Aug 2020).

So, in short, all double-tap situations work as expected and the only place that double-tapping zooms the UI is in the empty space in paper-tabs.

[maykar]

I can confirm, have tested on Android and on a Microsoft Surface touchscreen with multiple browsers. Everything works as expected although, contrary to @davidjb, I do not see zooming when double tapping empty space, near paper-tabs, or anywhere in the header. Running 0.116.0b2. The zooming action itself causes no strange artifacts or glitches that I have found.