Dialog vertical positioning changes ?

phiw13 · 2024-12-09 04:26:27

Oleg, did you change something to the initial vertical positioning of the preview dialog ? After the latest changes – preview refactoring or adding preview for custom fields – the dialog now opens at about halfway down the page, no matter how much content it has. Before (before the WE) the preview dialog (vertically) centred itself on screen based on its content

(note not the one with the iframe)

Pat64 · 2024-12-09 07:02:44

Right, Philippe: noticed too.

Off-topic: The preview iframe could benefit from adding a corresponding CSS rule in the official admin themes:

.ui-dialog:has(iframe){min-width:80vw!important;min-height:70vh!important}

Are you considering adding a tooltip to the display link? In order to inform the [Shift]+clic keys combination for the Easter Egg?

etc · 2024-12-09 07:39:30

Ah, inadvertently. The dialog was opened before the content is loaded. Reverted, thanks for your eyes.

Pat64 wrote #338456:

Are you considering adding a tooltip to the display link? In order to inform the [Shift]+clic keys combination for the Easter Egg?

Good idea, but it needs an extra string? Sure, there is a room for improvement UX-wise.

phiw13 · 2024-12-09 07:49:20

etc wrote #338457:

Ah, inadvertently. The dialog was opened before the content is loaded. Reverted, thanks for your eyes.

Much better thanks!

etc · 2024-12-09 09:26:39

Probably, these pre/view controls should be dissociated from new/duplicate article panel (not the same functionality)? We could then add an extra button for iframed preview, to clearly distinguish from the ‘external’ view, but where to put them all?

phiw13 · 2024-12-10 06:04:22

etc wrote #338462:

Probably, these pre/view controls should be dissociated from new/duplicate article panel (not the same functionality)? We could then add an extra button for iframed preview, to clearly distinguish from the ‘external’ view, but where to put them all?

I see you’ve gone ahead with some changes, moving the “View” / “Preview (in iframe)” up together with the title. Hmm… The whole panel start to feel a little overloaded me thinks. ButOK.

If you decide to keep that layout, two requests:

could you add a class to the paragraph: <p class=txp-actions>. That is the same class used on the “new article” / “duplicate” block, or the “Expand all“ / “ Collapse all” widget (they all share the same internal layout basically).
could add a class the wrapper div you inserted (e.g. div class="pane-header"). Or eventually it should be prefixed with txp-.¹

It is a little confusing to have two “Preview” buttons. A new string might be needed? Not sure what the addition of that “update” button under the iframe brings. Refreshing after edit in the body textarea?

Also, thanks for allowing to preview Live articles in the iframe without sanitising.

–^–

¹ I dislike working with id selectors!

etc · 2024-12-10 07:54:20

phiw13 wrote #338469:

I see you’ve gone ahead with some changes, moving the “View” / “Preview (in iframe)” up together with the title. Hmm… The whole panel start to feel a little overloaded me thinks. ButOK.

Agree. I would certainly make it better if I knew how. Shift+click is not intuitive enough for a feature that might be useful. Ideas welcome.

If you decide to keep that layout, two requests:

Sure, no probs.

It is a little confusing to have two “Preview” buttons. A new string might be needed?

We can separate them better. I don’t like adding new strings, it takes time to translate and to load too.

Not sure what the addition of that “update” button under the iframe brings. Refreshing after edit in the body textarea?

Not necessarily the body, you can also change the article image or whatever. Since the preview dialog is sticky, the button is always at hand.

phiw13 · 2024-12-10 08:15:20

Is it me? The preview(iframe) dialog feels quit slow to appear, in both Safari and Firefox. Click on the button, a few moments nothing happens, then the dialog appears then the it gets populated with the actual page.

Not necessarily the body, you can also change the article image or whatever. Since the preview dialog is sticky, the button is always at hand.

I haven’t tested, does the view/page updates if you: View, close the dialog and do some edits (some field) and reopen the dialog?

Btw, try this, with Sandspace :

#pane-header {
  display: flex;
  flex-flow: column;
  /* outline: 1px dotted red; */
}

#pane-header p {
  display: flex;
  flex-flow: row wrap;
  gap: 0 var(--spacing);
  margin: 0;
  padding-block: var(--spacing-4);

}

#pane-header p > * {
  display: inline-block;
  line-height: 1.571429;
  margin: 0 0 1px;
  padding: var(--spacing-4);
  border-radius: .1875rem;
  /* outline: 1px dotted cyan */
}
@media (min-width:780px) {
  #pane-header {
    flex-flow: row;
  }
  #pane-header p {
    margin-inline-start: auto;
    align-self: center
  }
}

If you replace all of --spacing with --txp-spacing it might even work with Hive.

etc · 2024-12-10 09:41:16

phiw13 wrote #338471:

Is it me? The preview(iframe) dialog feels quit slow to appear, in both Safari and Firefox. Click on the button, a few moments nothing happens, then the dialog appears then the it gets populated with the actual page.

I don’t see a noticeable slowdown on the demo site, but preview processing/loading surely takes some time, since it happens on the server side. 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 haven’t tested, does the view/page updates if you: View, close the dialog and do some edits (some field) and reopen the dialog?

View link outputs the saved article data. Preview uses you current edits, even unsaved, and is updated by clicking on Preview or Update buttons.

Btw, try this, with Sandspace :

Will try, thanks. I actually have thought of putting the links aside the Write heading, whence their common div#pane-header wrapper. Would it be possible to do it without the wrapper? The simpler the better.

etc · 2024-12-10 09:51:56

BTW, Safari 18.2 is released today. Does it support importing from

@layer txp-preview {
    :host(#pane-preview) {
        /* here? */
    }
}

phiw13 · 2024-12-10 10:00:31

etc wrote #338472:

I actually have thought of putting the links aside the Write heading, whence their common div#pane-header wrapper. Would it be possible to do it without the wrapper? The simpler the better.

The wrapper is fine, gives much more flexibility.

etc wrote #338473:

BTW, Safari 18.2 is released today. Does it support importing from

layer txp-preview {…@

Not yet available here.

Pat64 · 2024-12-10 10:08:34

The current position of links is logical (latest commits), IMHO.

The live preview within the non-modal frame is impressive! 👌

Last edited by Pat64 (2024-12-10 10:08:58)

Textpattern CMS

Textpattern CMS support forum

#1 2024-12-09 04:26:27