Dialog vertical positioning changes ?

etc · 2024-12-10 11:48:46

phiw13 wrote #338471:

Is it me? The preview(iframe) dialog feels quit slow to appear, in both Safari and Firefox.

Also, if styles are served via css.php (default for <txp:css />), it sends no-cache headers in debug mode. So they are fetched on each full preview reload, which takes time. Serving flat styles from disk is a better idea here.

Bloke · 2024-12-10 15:50:51

etc wrote #338472:

We can open the dialog before the content is loaded, but you will have to watch an empty frame for a while on the first load.

I’ve not tried this yet but from a UX standpoint, I’d rather have an immediate response and a ‘loading’ spinner in the empty iframe than nothing happening for a short while. Doing “nothing” is bad and invites multiple clicks/frustration.

Pat64 · 2024-12-10 16:20:01

Maybe the “sanitize” link could benefit from having a tooltip. We know perfectly well what it is about; but not necessarily final users (this may affect the public site because not all necessary resources are always loaded).

etc · 2024-12-10 17:01:26

Pat64 wrote #338478:

Maybe the “sanitize” link could benefit from having a tooltip. We know perfectly well what it is about; but not necessarily final users (this may affect the public site because not all necessary resources are always loaded).

Good idea, but I think the whole View/Preview block needs some pophelp.

Bloke wrote #338477:

I’ve not tried this yet but from a UX standpoint, I’d rather have an immediate response and a ‘loading’ spinner in the empty iframe than nothing happening for a short while. Doing “nothing” is bad and invites multiple clicks/frustration.

It opens immediately now, we just need to style .disabled class with some ‘spinner’.

Bloke · 2024-12-10 17:28:16

etc wrote #338479:

It opens immediately now, we just need to style .disabled class with some ‘spinner’.

Sweet, thank you. It doesn’t even have to animate. Even “Fetching content…” or “Just a moment…” or some other holding message we could add to our lang tables would do. Not sure if we have one there already. I don’t recall anything that would suit offhand. But it could be useful in other places, potentially.

Of course, a spinner is more universal and sidesteps the need for a string and translation.

Are there any pure CSS spinners out there? Edit: Answer is yes there are. Quite a few. An abundance, even!

Last edited by Bloke (2024-12-10 17:34:34)

etc · 2024-12-10 17:40:56

Cool, we can leave it with theme authors! Then .not-ready or .loading class suits probably better here.

Bloke · 2024-12-10 17:43:38

Yep. This one is simple and effective:

.loader {
  width: 48px;
  height: 48px;
  border-radius: 50%;
  display: inline-block;
  border-top: 3px solid #FFF;
  border-right: 3px solid transparent;
  box-sizing: border-box;
  animation: rotation 1s linear infinite;
}

@keyframes rotation {
  0% {
    transform: rotate(0deg);
  }
  100% {
    transform: rotate(360deg);
  }
}

Needs tweaking for dark mode but honestly, any would do.

etc · 2024-12-10 21:44:13

I’m sure our css gurus can turn it into a nice animated mask.

phiw13 · 2024-12-11 01:09:05

Bloke wrote #338480:

Are there any pure CSS spinners out there? Edit: Answer is yes there are. Quite a few. An abundance, even!

etc wrote #338481:

Cool, we can leave it with theme authors! Then .not-ready or .loading class suits probably better here.

What is the class now ? And to which element has it been applied? I think I saw the .disabled class on the@<iframe />@ , not sure.

Whether anything can be applied to the <iframe /> is another story. Most CSS spinners actually are applied as an actual html element. Applying it to the <iframe /> itself looks rather tricky (and you don’t want the <iframe /> itself to start rotating). Generated content – ::before – is a common technique, but that does not apply to the <iframe /> element as it is a replaced element.

At best, I think, a static SVG background image: iframe { background: url(some_image.svg); background-size: 50px 50px; background-position: center; } (and hoping the source document specifies a background-color…)

–^–

The dialog (iframe) opens immediately now, then waiting (briefly) a moment for the resources to load.

–^–

PS – Before your latest changes, I checked the dialog (iframe) loading on a live server. It was already much less slow then on localhost. Not sure was accounts for the slow down locally. Maybe the URL resolver (host file based).

etc · 2024-12-11 07:34:18

phiw13 wrote #338484:

What is the class now ? And to which element has it been applied? I think I saw the .disabled class on the@<iframe />@ , not sure.

Yep, for the moment.

Generated content – ::before – is a common technique, but that does not apply to the <iframe /> element as it is a replaced element.

But it can be applied to its div.ui-dialog:has(#preview-frame.disabled) container, so I’d leave it with theme authors.

Bloke · 2024-12-11 11:01:09

Tangential: is this com_article_image behaviour connected to the development of the preview/sanitize tool? Or is it by design in the plugin?

phiw13 · 2024-12-11 11:33:05

etc wrote #338486:

Yep, for the moment.

But it can be applied to its div.ui-dialog:has(#preview-frame.disabled) container, so I’d leave it with theme authors.

Yes, there are a few possibilities. One has to figure out which combos is stable – hence me asking about the .disabled class, and the HTML element it is attached to.

Textpattern CMS

Textpattern CMS support forum

#13 2024-12-10 11:48:46

Re: Dialog vertical positioning changes ?

phiw13 wrote #338471:

#14 2024-12-10 15:50:51

Re: Dialog vertical positioning changes ?

etc wrote #338472:

#15 2024-12-10 16:20:01

Re: Dialog vertical positioning changes ?

#16 2024-12-10 17:01:26

Re: Dialog vertical positioning changes ?

Pat64 wrote #338478:

Bloke wrote #338477:

#17 2024-12-10 17:28:16

Re: Dialog vertical positioning changes ?

etc wrote #338479:

#18 2024-12-10 17:40:56

Re: Dialog vertical positioning changes ?

#19 2024-12-10 17:43:38

Re: Dialog vertical positioning changes ?

#20 2024-12-10 21:44:13

Re: Dialog vertical positioning changes ?

#21 2024-12-11 01:09:05

Re: Dialog vertical positioning changes ?

Bloke wrote #338480:

etc wrote #338481:

#22 2024-12-11 07:34:18

Re: Dialog vertical positioning changes ?

phiw13 wrote #338484:

#23 2024-12-11 11:01:09

Re: Dialog vertical positioning changes ?

#24 2024-12-11 11:33:05

Re: Dialog vertical positioning changes ?

etc wrote #338486:

Board footer