Preview dialog - Dompurify parsing error with image shortcode

Pat64 · 2024-11-05 03:41:17

The latest commit with a better dark mode support is perfect!
For the custom-preview.css problem, maybe it could be a subject to a community plugin or a new preference setting in order to set the CSS file URL?

phiw13 · 2024-11-05 05:54:54

phiw13 wrote #338129:

Ok. Here is an idea:

A very first pass, only dealing with the preview dialog atm

/textpattern/core.css

:root {
  --txp-prism-token-1: #708090;
  --txp-prism-token-2: #905
  --txp-prism-token-3: #690;
  --txp-prism-token-4: #a67f59;
  --txp-prism-token-5: #07a;
  --txp-prism-token-6: #dd4a68;
  --txp-prism-token-7: #e90;
}

in lib/txplib_head.php line 130:

Txp::get('\Textpattern\UI\Style')->setSource('core.css').

modify preview.css to use the custom-properties:

.token.cdata,
.token.comment,
.token.doctype,
.token.prolog {
  color: var(--txp-prism-token-1);
}
.token.punctuation {
  color: var(--txp-prism-token-1);
}
.namespace {
  opacity: 0.7;
}
.token.boolean,
.token.constant,
.token.deleted,
.token.number,
.token.property,
.token.symbol,
.token.tag {
  color: var(--txp-prism-token-2);
}
.token.attr-name,
.token.builtin,
.token.char,
.token.inserted,
.token.selector,
.token.string {
  color: var(--txp-prism-token-3);
}
.language-css .token.string,
.style .token.string,
.token.entity,
.token.operator,
.token.url {
  color: var(--txp-prism-token-4);
}
.token.atrule,
.token.attr-value,
.token.keyword {
  color: var(--txp-prism-token-5);
}
.token.function {
  color: var(--txp-prism-token-6);
}
.token.important,
.token.regex,
.token.variable {
  color: var(--txp-prism-token-7);
}

I have not minified it for readability. If you want to do that, codebeautify.org/css-beautify-minify is an online tool, works fine for small snippets like the above.

Todo, dark mode maybe – at least for now, it still works OK. Sandspace completely ignores that part of the preview.css stylesheet anyway (I do not use that Hive darkmode/lightmode toggle widget).

Todo: if anyone has good, non-abbreviation naming for those custom properties, all suggestion welcome.

If you want to see the effect of overrides by an admin theme, an updated sandspace stylesheet is available here.

Pat64 wrote #338130:

The latest commit with a better dark mode support is perfect!
For the custom-preview.css problem, maybe it could be a subject to a community plugin or a new preference setting in order to set the CSS file URL?

If the above suggestion is implemented, you should at least be able to manage the colors using a custom.css in your theme of choice.

etc · 2024-11-05 10:05:06

phiw13 wrote #338129:

Ok. Here is an idea:

Thank you, sounds like a plan.

Create a core stylesheet at the root of /textpattern/ that is always loaded independent of theme.

This is what I’m advocating for since ages, also because a large subset of css rules (like .hidden) is required for proper functioning of txp. Currently, every admin theme has to implement them, resulting in much code redundancy.

Your addition to prism.js to handle (nested) txp tags is quite interesting and after a very brief test works fine here.

Could that also be used outside of Textpattern admin, e.g if one uses prism.js for code colouring on the public side? Or is your code dependent on other things in Textpattern.js (haven’t really tried to untangle all).

It should work independently, just include prism-txp.js after prism.js. And you can remove txp-darkmode related code.

etc · 2024-11-05 10:07:48

phiw13 wrote #338131:

Todo, dark mode maybe – at least for now, it still works OK. Sandspace completely ignores that part of the preview.css stylesheet anyway (I do not use that Hive darkmode/lightmode toggle widget).

Yep, and even better if it can be done in a theme-independent (but theme-stylable) way.

Bloke · 2024-11-05 12:18:02

etc wrote #338132:

This is what I’m advocating for since ages

Then let’s do it. I’m all for reducing redundancy.

phiw13 · 2024-11-05 12:41:36

etc wrote #338132:

This is what I’m advocating for since ages, also because a large subset of css rules (like .hidden) is required for proper functioning of txp. Currently, every admin theme has to implement them, resulting in much code redundancy.

What would that buy you? 10 lines of css, at best? I remember vaguely you suggested including this that widget(forgot which, though). In practice I would have to override 95% of that code to match my theme. I thus remain completely uninterested in that part.

What I am suggesting is having a set of core css settings (custom properties aka css “variables”) that themes and plugins can rely upon. Basic building blocks , no more: basic colours (foreground and background, a basic spacing parameter (for e.g. margins or paddings)

etc wrote #338133:

Yep, and even better if it can be done in a theme-independent (but theme-stylable) way.

This is actually more complicated, at least where Hive is concerned. The core.css can including specific values for the set of custom properties tailored for dark mode:

@media screen and (prefers-color-scheme: dark)  { /* set */ }

but that does have no effect in Hive as that stylesheet hides all behind that body.darkmode filter.

etc · 2024-11-05 14:28:38

phiw13 wrote #338135:

What would that buy you? 10 lines of css, at best?

Much more, I think. UI icons solely take hundreds of lines.

What I am suggesting is having a set of core css settings (custom properties aka css “variables”) that themes and plugins can rely upon. Basic building blocks , no more: basic colours (foreground and background, a basic spacing parameter (for e.g. margins or paddings)

That fits well the idea of core styling by variables that can be overridden by themes? And if you fancy tweaking everything, that’s your right.

This is actually more complicated, at least where Hive is concerned. The core.css can including specific values for the set of custom properties tailored for dark mode … but that does have no effect in Hive as that stylesheet hides all behind that body.darkmode filter.

I thinks Phil’s script takes prefers-color-scheme into account, so they could cohabit for a while.

phiw13 · 2024-11-05 23:41:32

etc wrote #338136:

Much more, I think. UI icons solely take hundreds of lines.

Oh, sure. Those you can have, although I have to check how many I customised though (iirc I inserted them separately, but I am not sure).

That fits well the idea of core styling by variables that can be overridden by themes? And if you fancy tweaking everything, that’s your right.

Yes, that is the idea.

I thinks Phil’s script takes prefers-color-scheme into account, so they could cohabit for a while.

I really don’t know. Investigation needed.

–^–

In your latest update:

Thanks for creating that core stylesheet. We’re moving a step forward to make the preview more theme friendly.
in the preview.css update you set the white-space: property for code[class*=language-],pre[class*=language-] to white-space: break-spaces for the text-preview but not for the html preview. Please please handle both view the same way, code blocks are soo much more easy on the eyes and soo much more easy to use.
also in preview.css, the user configurable example .token.txp > .token.tag {color: rebeccapurple;}. Please comment it out as it takes precedent over the custom-property value (that selector has higher specificity) and I cannot find a way to override it in my own stylesheets.

jakob · 2024-11-06 10:02:48

phiw13 wrote #338135:

This is actually more complicated, at least where Hive is concerned. The core.css can including specific values for the set of custom properties tailored for dark mode:

@media screen and (prefers-color-scheme: dark) { /* set */ }…

but that does have no effect in Hive as that stylesheet hides all behind that body.darkmode filter.

Philippe is right. Currently the dark mode settings for 4.9 are set here and use a sass mixing as defined here which at present only sets custom properties for the .darkmode class.

The mixin could conceivably be modified to include the browser setting, e.g. (untried)

@mixin dark-mode {
    body.darkmode {
        @content;
    }

    @media (prefers-color-scheme: dark) {
        @content;
    }
}

That said, more settings may be necessary to cater for user-overridden lightmode when the OS is set to dark mode.

etc · 2024-11-06 17:50:22

phiw13 wrote #338137:

in the preview.css update you set the white-space: property for code[class*=language-],pre[class*=language-] to white-space: break-spaces for the text-preview but not for the html preview. Please please handle both view the same way, code blocks are soo much more easy on the eyes and soo much more easy to use.

This should be done carefully, since linebreaks are important in, say, js blocks, so they’d better be rendered as is.

also in preview.css, the user configurable example .token.txp > .token.tag {color: rebeccapurple;}. Please comment it out as it takes precedent over the custom-property value (that selector has higher specificity) and I cannot find a way to override it in my own stylesheets.

I’ve put it in a css variable (names to be discussed). Anyway, now you have a possibility to inject any rule in preview, placing it in a special txp-preview layer in your theme stylesheet:

@layer txp-preview {
    /* rules shared with the light dom */
    :host(#pane-preview) {
        /* shadow dom only rules */
    }
}

Encapsulating in :host is not really necessary, but prevents the light dom pollution. Please test.

phiw13 · 2024-11-06 23:00:19

etc wrote #338149:

I’ve put it in a css variable (names to be discussed). Anyway, now you have a possibility to inject any rule in preview, placing it in a special txp-preview layer in your theme stylesheet:

layer txp-preview {…@

Encapsulating in :host is not really necessary, but prevents the light dom pollution. Please test.

Oooh… That is great. I’ll try testing today if the old body allows it (asthma is a tough lover).

Pat64 · 2024-11-07 03:39:30

I think you could remove the rule width:auto into the preview.css file.

Textpattern CMS

Textpattern CMS support forum

#25 2024-11-05 03:41:17

Re: Preview dialog - Dompurify parsing error with image shortcode

#26 2024-11-05 05:54:54

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338129:

Pat64 wrote #338130:

#27 2024-11-05 10:05:06

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338129:

#28 2024-11-05 10:07:48

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338131:

#29 2024-11-05 12:18:02

Re: Preview dialog - Dompurify parsing error with image shortcode

etc wrote #338132:

#30 2024-11-05 12:41:36

Re: Preview dialog - Dompurify parsing error with image shortcode

etc wrote #338132:

etc wrote #338133:

#31 2024-11-05 14:28:38

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338135:

#32 2024-11-05 23:41:32

Re: Preview dialog - Dompurify parsing error with image shortcode

etc wrote #338136:

#33 2024-11-06 10:02:48

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338135:

#34 2024-11-06 17:50:22

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338137:

#35 2024-11-06 23:00:19

Re: Preview dialog - Dompurify parsing error with image shortcode

etc wrote #338149:

#36 2024-11-07 03:39:30

Re: Preview dialog - Dompurify parsing error with image shortcode

Board footer