Dialog vertical positioning changes ?

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.

etc · 2024-12-11 12:40:54

phiw13 wrote #338489:

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

It’s iframe#preview-frame, disabling the jQUI wrapper dialog itself might be risky. Something like this should work:

div.ui-dialog:has(#preview-frame.disabled)::before {
    content: '';
    width: 64px;
    height: 64px;
    border-radius: 50%;
    border-top: 4px solid var(--txp-primary-text);
    border-right: 4px solid transparent;
    box-sizing: border-box;
    animation: rotation 1s linear infinite;
    position: absolute;
    left: 0;
    top: 0;
    right: 0;
    bottom: 0;
    margin: auto;
    z-index: 100;
}

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

The tricky (without js) part (for me) is to replace the fixed 64px diameter with something depending on the dialog size, since the spinner width and height should be equal.

Bloke wrote #338488:

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

It’s the plugin, I guess. I didn’t want to update the images preview panel on each manual field input (too heavy). But blur might work, let me see.

What is related to article previews, is that as long as the dialog is open, Enter hits will update the preview, instead of saving the article. More feature than bug for me, dunno.

phiw13 · 2024-12-11 13:07:47

etc wrote #338490:

It’s iframe#preview-frame, disabling the jQUI wrapper dialog itself might be risky.

You could (eventually) change the classname to something more logical – e.g. .loading applied either on the JQUI wrapper or the iframe.

The tricky (without js) part (for me) is to replace the fixed 64px diameter with something depending on the dialog size, since the spinner width and height should be equal.

Container queries are your friend.

.ui-dialog:has(#preview-frame) {
  container-type: inline-size;
  container-name: iframe-holder; 
}

@container iframe-holder {
  .ui-dialog:has(#preview-frame) iframe {
    --w: 30cqi; /* 30% of the width of the container - .ui-dialog*/
  }

  .ui-dialog:has(#preview-frame.disabled)::before {
/* … */
    width: var(--w);
    height:  var(--w);
    inset: 1em; /* logical property, shorthand,   estimated height of the titlebar */
  }
}

I have prototyped something like that this afternoon, Untested.

Container Units and Container queries

etc · 2024-12-11 14:36:06

phiw13 wrote #338491:

Container queries are your friend.

That’s what I thought, but failed to get it working. I’ll have to wait until they land in Sandspace.

jakob · 2024-12-11 16:42:09

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).

Sorry, a bit late to the show here, but is there a case for shifting “Sanitize” to the dialog itself, either next to the refresh button (preferable) or alternatively like it is for the text preview at present. I can see end users being non-plussed by this option right at the top of the page, and the term sanitize right at the top kind of conveys the impression that something is tainted/polluted before one has even begun writing an article.

We also now have three different preview variants: view (front-side), preview (in the modal) and preview again (textarea modal).

etc · 2024-12-11 17:25:34

jakob wrote #338493:

Sorry, a bit late to the show here, but is there a case for shifting “Sanitize” to the dialog itself, either next to the refresh button (preferable) or alternatively like it is for the text preview at present.

It actually sanitizes the front-end view too, so ‘hiding’ it behind the dialog can be problematic. But front-end sanitizing is probably an overkill, feedback welcome.

We also now have three different preview variants: view (front-side), preview (in the modal) and preview again (textarea modal).

View is static (saved data) and previews are live. I find previews handy, since I can test txp tags without saving an article, but if they are too disturbing, we can bind them, say, to Enable dev theme preview pref.

etc · 2024-12-11 22:51:38

I have slightly reworked the preview frame. Please test it against all sorts of xss with JS enabled. If usable and nothing evil happens, we then might remove the checkbox and leave sandbox="allow-scripts" enabled.

Textpattern CMS support forum

#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:

#25 2024-12-11 12:40:54

Re: Dialog vertical positioning changes ?

phiw13 wrote #338489:

Bloke wrote #338488:

#26 2024-12-11 13:07:47

Re: Dialog vertical positioning changes ?

etc wrote #338490:

#27 2024-12-11 14:36:06

Re: Dialog vertical positioning changes ?

phiw13 wrote #338491:

#28 2024-12-11 16:42:09

Re: Dialog vertical positioning changes ?

Pat64 wrote #338478:

#29 2024-12-11 17:25:34

Re: Dialog vertical positioning changes ?

jakob wrote #338493:

#30 2024-12-11 22:51:38

Re: Dialog vertical positioning changes ?

Board footer