Change 292063 had a related patch set uploaded (by Niedzielski):
Enable pinch to zoom

https://gerrit.wikimedia.org/r/292063

Change 292063 abandoned by Niedzielski:
Enable pinch to zoom

Reason:
Too much to bite off right now.

https://gerrit.wikimedia.org/r/292063

There was some recent discussion on the team that Gmail implements zoom functionality in a way similar to the patch above. I'll reopen the patch if we can limit the expectations to exclude native components at least initially

@RHo @Dbrant @Mholloway, is there any interest in turning this on? iOS now has the footer and related articles as HTML which would minimize some of the wonkiness of zooming and native components.

I mean, in principle, it would be nice to enable this.

What was the impetus for iOS rendering the related articles and footer in HTML? Bernd had proposed doing that at one point a long time ago, I think when first building out the content service, and I wasn't too keen on the idea of pushing more of the app into HTML-land rather than native components. I'm a little more open to the idea these days, especially given that it looks like we'll be centered on a WebView for the foreseeable future.

@Mholloway, @Mhurd has the scoop but my understanding is...

• Improved accessibility; mixing native and HTML components breaks accessibility like text to speech and element focus
• Better code for the domain and fewer bugs; there are some yucky hacks to make it seem like the native component lives in the WebView and there are still some pretty bad bugs around it like stealing the scroll event and not rendering until the page is scrolled
• DRYing up code and the usual wikimedia-page-library benefits

It's good to identify the tradeoffs. For me, number 2 was so compelling that I didn't really question this change!

Interesting points. There's also a kind of ugly hack required to coerce the "Read more" header to the article language (maybe that's one of the yucky hacks you were referring to), though it's used elsewhere as well where we want to make UI chrome match the article language rather than the system language.

WRT article vs app language, I've learned I have no idea what the user wants. It hasn't come up much but the page library has been moving forward under the assumption that if it looks like page content, it should probably have page language. I hope resolution will come soon, perhaps in T142019. I don't think that changing the language will be an issue if we need to later but I believe @Mhurd's implementation correctly uses article language right now.

Going out on a bit of a limb here, why not render the article header in HTML, too? At least on Android, there are no interactive native components remaining there (except the lead edit pencil, which we know how to inject in HTML) and there's nothing about it that can't be accomplished with web tech.

Between that and footer HTML rendering, we'd then have one unified, pinch-zoomable page. :)

An additional benefit of this is that we could then remove the app-level text-size setting, and move the dark mode option to the settings menu so that it's discoverable and people will stop asking for it. ;)

I think @Mhurd has done some interesting experiments on iOS of converting the header and lead image, including face offset. I'd personally be for it now given how much complexity is in integrating our current native implementation with the WebView.

I'm not necessarily opposed to pinch/zoom, but iirc there's a cascade of things which are potentially complicated by using pinch-zoom:

• native overlays
• apps JS which deal with element locations - such as scrolling the web view when table of contents selections are made (without factoring in pinch/zoom scaling factor these may explode)
• find-in-page matches having to potentially scroll on x axis as well as y axis
• weird interaction with existing text size adjustment controls (UX and maybe technical). On iOS there's some interplay already between the user's system-wide Dynamic Type font size preference and the article web view's text size slider (we default the slider to a size approximating the user's system preference). Introducing a third way to adjust font size would need to be pondered.

Just saying it's potentially not as simple as flipping a switch and product and design will probably want to think these bits through.

I'd recommend this be re-visited after we've consolidated *all the things* in the page-libary.

It just seems like it would be easier to consider if we want to do this for both platforms *after* we've DRY'ed up more of our JS bits - rather than potentially introducing new complications for our JS bits - i.e. if Android pursued this now but iOS wasn't able to and it impacted some JS we'd be complicating our consolidation efforts.

@Mholloway

Going out on a bit of a limb here, why not render the article header in HTML, too?

Oh yes as @Niedzielski mentioned the iOS app *did* at one time ship with the lead image presentation in CSS and HTML - it even worked with face detection offsets. I can try to dig that up. May be a nice starting point for a lead-image transform for the page-library.