Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Dialog vertical positioning changes ?
phiw13 wrote #338489:
One has to figure out which combos is stable – hence me asking about the
.disabledclass, 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.
Offline
Re: Dialog vertical positioning changes ?
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.
.loadingapplied either on the JQUI wrapper or the iframe.The tricky (without js) part (for me) is to replace the fixed
64pxdiameter 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.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Offline
Re: Dialog vertical positioning changes ?
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).
TXP Builders – finely-crafted code, design and txp
Offline
Re: Dialog vertical positioning changes ?
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.
Offline
Re: Dialog vertical positioning changes ?
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.
Offline
Re: Dialog vertical positioning changes ?
Oleg.
I’m sorry, but your previous commit was much better: latest one causes lots of problems with some CORS rules…
Patrick.
Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.
Offline
Re: Dialog vertical positioning changes ?
etc wrote #338492:
That’s what I thought, but failed to get it working. I’ll have to wait until they land in Sandspace.
I don’t think I would implement a spinner that way, personally. At the moment I am more inclined to put some fixed width spinner in the top left corner.
(after checking the whole thing with a couple of different devices)
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Dialog vertical positioning changes ?
etc wrote #338495:
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.
View is static (saved data) and previews are live.
In order to make that preview iframe marginally useful: is it possible to, please please, to at least have an option to permanently disable that sanitising thing in the iframe – not blocking, not blocking webfonts, and in Safari not blocking stylesheets. Thank you.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Dialog vertical positioning changes ?
Pat64 wrote #338497:
I’m sorry, but your previous commit was much better: latest one causes lots of problems with some CORS rules…
Details might help. The preview seems to degrade gracefully on the demo site, even if some fonts are blocked.
phiw13 wrote #338499:
In order to make that preview iframe marginally useful: is it possible to, please please, to at least have an option to permanently disable that sanitising thing in the iframe – not blocking, not blocking webfonts, and in Safari not blocking stylesheets. Thank you.
I really really don’t want such a permanent pref (unless you let me call it Hackers Open Bar). One day you don’t pay attention and voilà. In body/excerpt previews you can at least analyse potentially unsafe content, but analysing the whole page is meaningless. I would even forbid unsandboxing it at all, but you seem to say stylesheets are blocked in Safari (which is weird), need to investigate.
Please keep in mind that preview frame is for the content, not for the style, so develop your public themes accordingly.
It looks like credentialless iframe might be ideal, but it is not widely implemented yet.
Offline
Re: Dialog vertical positioning changes ?
Oleg,
Thank you for this. That makes the iframe more useful for me, at the cost of one extra click.
Note:
- situation1: sole owner/editor/author/designer of a website (but I am sure my cat accesses the website…)
- situation2: small organisation with 2~4 (occasional) users.
Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern
Offline
Re: Dialog vertical positioning changes ?
Thank you lot, Oleg: your latest commit is much better! 👌
Patrick.
Github | CodePen | Codier | Simplr theme | Wait Me: a maintenance theme | [\a mi.ni.ma]: a “Low Tech” simple Blog theme.
Offline