browser zoom text rather than the whole window.

An event listener for the window's resize event works in many browsers. You can also use matchMedia() to detect changes.

More information:
https://www.geeksforgeeks.org/how-to-detect-page-zoom-level-in-all-modern-browsers-using-javascript/
https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia

hello david

i am testing with both firefox (rather outdated version) and opera mobile. the resize event was the first thing i tried. it does not fire.

maybe this is because i am using

        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=0"/>
since i clearly do not want the zoom to allow the body to be wider than the screen.

additionally, the media tag is ignored by opera bbut that's another issue.

i have been playing with touchstart and touchmove as a (bad) alternative since it won't kick on ctrl+ or mouse wheel zoom in/out in browsers. currently i do not really get it. but there is an online example that does work so i should be able to fix something if it does actually make sense. the docs are very limited and i have no idea if it is supported in webviews, other mobiles, ...

maybe removing the meta tag makes sense since i am pretty sure the resize event will fire but i had rather avoid the resulting ui. i am not coding a kid's game and had rather avoid animation effects and messy js code. actually i had rather find a way to make this work without js at all.

thanks a lot for your help so far

actually, the resize event does not even fire in FF with a different meta tag either ^^

expending on my last attempt

it is quite easy to set the width in css pixels.

nevertheless the reported initial size is wrong and the css pixel sizes change when you pinch zoom.

additionally, FF does not report window.devicePixelRatio adequately : whatever the zoom factor, the reported ratio is the same.

thanks. hammer is indeed mentioned in the thread and the S.O. link is just above the code stanza ;)

i made subtle but significant changes to make it work.

beware i lazily used the body font size which induces an obvious bug if said font size is set in the css using a unit other than %. it probably should be hooked to the html element.

the hard part was actually to figure out "[0].pageX" given the lack of documentation and serialization of the event's properties.

thanks a lot for testing !

--

@scott << preference >> i see where you are going at. there is room for debate regarding overriding a feature the users commonly use. nevertheless, producing a behavior that forces the user to scroll laterally in order to read each individual line of text is imho entirely unacceptable. it only makes sense for sites with multiple columns which are not tuned for mobiles and to ease the work of some lazy devs. i am also concerned folks who need a bigger font may have a hard time finding said button while pinching would be natural. all in all, i think my choice makes sense but i will definitely double check with test users.

this app does not use cookies (which i tend to avoid nowadays) except when authenticated with a browser that does not feature JS at all. 

--

i am keeping this thread open for a little while as i am still hoping for a better way to handle the situation possibly in pure css by playing with layout vs physical viewports and/or media queries.

my own media query attempts failed miserably on ff because i never found a media query that actually kicks. pixel change sizes and the pixel to dimension ratio is not reported or i failed to find where.

i also do not really like inhibiting a feature with a meta tag and reproducing it with js : imagine the former works and the latter does not... i am unsure this can be fully js-ified

for those interested, the wheel event allows to do similar stuff on different devices. it makes less sense as other device types usually reapply the layout when zooming is involved.

Everybody is different. I actually like the way the pinch zoom works. I tested on some of my sites and EE and all work the same. If I need to pinch zoom, everything zooms and it is easy enough to move side to side. If I can't read something because the font is too small, that is an issue with the site.  Otherwise, I can't be much help with the js right now.

I might make further comment later, but for now:

this app does not use cookies (which i tend to avoid nowadays) except when authenticated with a browser that does not feature JS at all.

You could use localStorage to store the font-size.

@scott : indeed we are all different. most sites nowadays zoom the whole thing. the result is pinching produces a situation where the lines of the text you read are longer than the viewport. this happens in many situations such as regular text spawning the whole display where the rendering would not even need any tweaking to be correct. as a result, folks end up turning their phones in all directions and sometimes get bored. i do often in such cases. i just tried EE again. if i zoom by about 150%, the menus disappear from the page and i cannot read anything comfortably without scrolling line per line.

@david : thanks. i already use ***storage for such things. namely for session tokens. i do not plan on remembering the preferred font size atm.

i am very open to a solution that does not rely on js !

Actually FireFox has a setting under general settings for the Zoom function to only zoom text.

Settings >> General >> Zoom

I am just trying to understand what you are seeing. I am near sighted. Without glasses or with the reading portion of my progressive lenses, I see my phone fine as far as typeface.  

With the far portion of my glasses or my single lenses, I do have to pinch zoom.

For a couple of paragraphs it is fine to pinch zoom. Reading a lot more would be hard. But, I do not need the zoom. If I did, I would change my assessability settings because most sites are seen just like EE.

@fred : thanks, but the whole point is i cannot ask each and every user to do that.

additionally, i know for a fact many users are reluctant because changing accessibility settings breaks too many sites.

@scott : most sites indeed display this rather new browser feature. not by choice but rather because most developers never cared about such issues or ever learnt to deal with them properly. when the browsers changed their behaviors, there were still many docs suggesting to use fixed widths and many sites would overflow all over the place with larger fonts. nice layouts were also harder to achieve without css calculations, media queries and the likes, not to mention lack of browsers normalization.

these are not trivial issues nor things that we can expect the users to solve. i frequently need to pinch on perfectly readable sites to click on links, and i am not using the same text size at 3am than during the day. easily changing the font size by a few percents while keeping the ui readable and without bothering with menus seems very legit to me.

@scott

not sure whether this is some new feature but ee has a solution of their own : the paragraph width is adjusted somehow after the zooming kicks in at least in opera which i use for ee. different but nice approach as well. it comes with disadvantage of flakyness and inconsistent viewport width but it is indeed usable.

Not sure I understand.  I have many of my customers set up with Zoom configured for text only.  I also add the (- 100% +) zoom button to their Firefox taskbar.  They can very easily increase/decrease the text size or for sites that mess up the text its easy enough (just click 100%) to revert back.

Its not an accessibility setting, it controls the FireFox dynamic zoom function.  All tabs open initially at 100%, then the zoom whether you use ctl+/- or pinch or the taskbar button just zooms text.   However they make that work, sounds similar to what you want.  

i am using a shorter and optimized version of the above code.

although it does not cover all aspects of the issue, it is decent enough.

the event related original question is currently best answered with window.visualViewport with the limitation mentioned in corresponding post.

@fred : i am working on the server side. there are many users and i do not know them all or even a tiny fraction of them. my clients are NOT end users.

@scott : i see EE went into gret lengths recently to offer better visual displays. (resizing on the fly, removing cols from tables, etc...). this essentially works in Opera mobile for most reasonable sizes and is comfortable enough except in places where there is probably no way to do better. wrapping cols in list views would make things even better imho. i remember experimenting the described behavior and some other annoying ones in FF. said issues only affet some pages such as "message" conversations in opera as well. FF is currently not usable as most links including the menu are broken. i assume js or a great part of the js ui does not load at all.

thanks all. i closed the thread.

i will happily respond to comments and PMs though if anyone wants to discuss things further