RFC: preview widget position / usability

phiw13 · 2024-01-09 03:20:09

Problem: the panel opens midway down the page and expands downwards

sequence (in slow motion):
- user clicks on preview button
- dialog opens, sizes itself based on the empty pane plus the tools buttons
– positions itself (centered in viewport)
– then the actual content –article text– is loaded, the whole dialog expands downwards

(this is different from TXP 4.8.8 where the panel immediately positions itself based on the content )

On desktop/laptop type devices (mouse, trackpad) this is 25% OK as the user can drag the dialog upwards. On touch based devices (smartphones / tablets) this is at best 1% OK as the user can NOT drag the dialog around.

The question is then: are there options to improve this in some way ? e.g instead of having the script positioning the dialog from the center, place it offset from the top ? I’ve looked briefly at the JQUI APIs, that doesn’t seem possible, but I am certain I have overlooked something. Or are other options / finetuning possible ? I am certainly not asking for using another script-set to manage this type of dialog.

At the admin-theme level, forcing some (better, initial) positioning with CSS is possible, although far from ideal, particularly on desktop/laptop type devices – it would make the drag and drop repositioning of the dialog rather problematic.

etc · 2024-01-09 08:53:26

I have not paid attention to it, thank you for the report. The 4.8.8 behaviour should be restored now, please test.

phiw13 · 2024-01-09 09:40:47

Quick quick first test: great! I’ll test more tomorrow across various devices.

Thank you 😊

etc · 2024-01-09 10:19:11

phiw13 wrote #336307:

Quick quick first test: great! I’ll test more tomorrow across various devices.

Fine, but don’t expect it to work in Safari <16.4. Because.

And dragging on touch devices is still a problem.

phiw13 · 2024-01-09 11:48:07

etc wrote #336309:

Fine, but don’t expect it to work in Safari <16.4. Because.

Yeah, that is unrelated. Is there a way to test for support for that constructor and if not ignore the stylesheet? (I know… messy rendering)

And dragging on touch devices is a problem.

JQUI dragging never worked on touch devices anyway.

etc · 2024-01-09 12:51:33

phiw13 wrote #336312:

Is there a way to test for support for that constructor and if not ignore the stylesheet? (I know… messy rendering)

Certainly, but I have no Safari 15 under the belt for testing. You can try to replace textpattern.js block

        if (!pane.shadowRoot) {
            const sheet = new CSSStyleSheet();
            const css = await fetch('preview.css');
            sheet.replaceSync(await css.text());
            pane.attachShadow({mode: 'open'}).adoptedStyleSheets = [sheet];
        }

with

        if (!pane.shadowRoot) {
            const shadow = pane.attachShadow({mode: 'open'});

            if (shadow.adoptedStyleSheets) {
                const sheet = new CSSStyleSheet();
                const css = await fetch('preview.css');
                sheet.replaceSync(await css.text());
                shadow.adoptedStyleSheets = [sheet];
            }
        }

phiw13 · 2024-01-09 13:09:14

Will do that tomorrow when sleepy head is replaced with active head. It is late, this side of the bleu ball.

phiw13 · 2024-01-10 01:14:37

etc wrote #336314:

Certainly, but I have no Safari 15 under the belt for testing. You can try to replace textpattern.js block

That works perfectly on my Luddite certified iPhone SE (generation 1) running iOS15 with Safari 15.7. The pane loads / displays my test article with a bit of scrolling mess (very long unbreakable string, larger 6 column table) but displays fine, the sanitiser script fires its warning(s) etc. The scrolling mess is of course not unexpected.

No problems to report with Firefox 102LTE & Firefox latest, Safari17 (both iOS 17 and macOS 13 & 14), Brave (Chromium latest).

Thank you for all that.

Textpattern CMS

Textpattern CMS support forum

#1 2024-01-09 03:20:09