A user complains - editing a long article on an iPad.

phiw13 · 2019-06-18 08:01:49

The lady needs to edit a longish article (~1500 words). She’s using an iPad (the 9.7inch non-pro model, but it doesn’t really seem to matter). Hive is the theme in use. The textarea is nicely (hmm…) expanded to show the whole article. She’s working on some part midway through the article.

The problem: the “Save” button is invisible and requires a (very) long scroll upwards (landscape mode) or downwards (portrait mode) to reach. Once the article is saved, she has to scroll back to the editing location and continue with her work. Not exactly a good example of “fun to work with”.

In theory, the “Save” button should be sticky in landscape mode. It isn’t, according to her description, once the keyboard is onscreen (I confirmed that using the Simulator, I currently don’t have an iPad). And of course in portrait mode, that button is never sticky.

ATM, I managed to disable the script for the main textarea on the Write panel. Not great as it affects all 3 users of the company on any device. I currently don’t have time & energy to debug further.

My Sandspace / Darkspace themes do not have the problem (sticky button is always sticky in landscape mode), but then, those don’t use the offending script.

Things to consider for the future

have a mechanism that the theme can use for users preferences like in this case disable the script), could be used for dark/light theme,…

disable the offending script completely on tablets & phones (or device sizes).

phiw13 · 2019-11-29 02:38:18

Ping ?

etc · 2019-11-29 08:16:19

phiw13 wrote #318523:

In theory, the “Save” button should be sticky in landscape mode. It isn’t, according to her description, once the keyboard is onscreen (I confirmed that using the Simulator, I currently don’t have an iPad). And of course in portrait mode, that button is never sticky.

Any possible fix on this side?

jakob · 2019-11-29 08:35:48

I haven’t checked it, but as I think Oleg is suggesting, could you add a css position:fixed fix to the button/button container and put it in custom.css (see here) in the admin theme – or duplicate the admin theme under a new name with the fix included.

The same should be possible for your other point about reduced-motion in the other thread.

phiw13 · 2019-11-29 08:39:33

etc wrote #320314:

Any possible fix on this side?

Hmm, I dunno. One possible option is a general user-options system (in the UI) that would allow disabling that script for the Write area (it might have side effects, as I think the size of that textarea is rather smallish). This might be more work than the schedule for TXP4.8 allows

Another option is providing an example for a custom.js on how to disabling that script for the main textarea without hacking the main.js file (possibly with some match-media media query). Not perfect as that user does not have have SFTP access.

—
While it is no secret that I’m not a great fan of that textarea expanding script, it does have its uses, such as the small textareas in the sidebar of the Write panel, allowing for a tighter UI. But then that benefit is partly lost when the fields are filled (the expand onload or something). In another thread somewhere on the forum we once mused about having those fields only expand when the textarea actually has focus (thing is in active use).

phiw13 · 2019-11-29 08:42:12

jakob wrote #320315:

The same should be possible for your other point about reduced-motion in the other thread.

No, that should be part of the theme. Of course it is possible to add it via custom.css, I know that.

jakob · 2019-11-29 09:00:10

phiw13 wrote #320317:

No, that should be part of the theme. Of course it is possible to add it via custom.css, I know that.

Apologies. I was just being pragmatic…

You’re right that the main theme should honour those device preferences.

philwareham · 2019-11-29 14:24:48

OK, because autosize is so universally loved 😀, I have now added the option to disable that script in Hive theme(s) by adding the following line into Textpattern ‘config.php’ file (before the closing ?> line if there is one):

define('no_autosize', true);

It’s in dev branch now and will be in the upcoming 4.8.0 official release (planned for beta release in a matter of weeks).

Bloke · 2019-11-29 16:15:06

Woohoo! Thank you. I find the autosize thing just odd.

Not sure if it’s related but the two columns seem to scroll independently sometimes. Check out this 10-second video (SFW) I made showing me scrolling the screen down using the two-finger gesture on the trackpad in MacOs Sierra. Watch the scrollbar and see how the main content area slides a little, then the sidebar scrolls on its own, and finally the main content joins in again later as the excerpt scrolls into view.

stefdawson.com/downloads/support/TxpScrolling.mov

Is that expected? Something to do with the autosizer? Or a feature of our layout? Or just my site?

philwareham · 2019-11-29 16:19:22

Bloke wrote #320325:

Not sure if it’s related but the two columns seem to scroll independently sometimes.

I can’t reproduce that quirk in Safari 13 or Firefox 71 Mac here, sorry. It shouldn’t do that though.

Bloke · 2019-11-29 16:28:09

philwareham wrote #320326:

I can’t reproduce that quirk in Safari 13 or Firefox 71 Mac here, sorry. It shouldn’t do that though.

It only does it (currently in both FF 70.something and latest Chrome, not tested Safari yet) if I have long sidebar content (expand all, lots of CFs, etc) that is longer than the Body field. I have so many plugins and stuff installed here it may be one of those interfering. Doesn’t happen on 4.7.3. Weird.

etc · 2019-11-29 16:28:35

Bloke wrote #320325:

Not sure if it’s related but the two columns seem to scroll independently sometimes.

abc_article_image in action :-)

Textpattern CMS

Textpattern CMS support forum

#1 2019-06-18 08:01:49