Preview dialog - Dompurify parsing error with image shortcode

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.

phiw13 · 2024-11-07 04:45:32

phiw13 wrote #338151:

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

Maybe I am holding it wrong. Safari 18.1 completely ignores all of the :host(#pane-preview) {} style rules. In preview.css, in my theme stylesheet or with theme Hive. Firefox and Brave do what is expected.

At the moment I have no clue what is going wrong (and there are no errors in the console). It does not help that Safari’s inspector show next to nothing of the rules inside the shadowdom.

PS – The documentation page at MDN (developer.mozilla.org/en-US/docs/Web/CSS/:host_function) works perfectly fine

Last edited by phiw13 (2024-11-07 04:51:59)

phiw13 · 2024-11-07 08:11:32

phiw13 wrote #338153:

Maybe I am holding it wrong. Safari 18.1 completely ignores all of the :host(#pane-preview) {} style rules. In preview.css, in my theme stylesheet or with theme Hive. Firefox and Brave do what is expected.

progress… I have it working with Safari Technology Preview. There is hope that maybe maybe Safari 18.2 will cary those fixes. Need to check the pre-release release notes.

phiw13 · 2024-11-07 08:27:36

Meanwhile, here are some preliminary notes for some core custom-properties:

primary & secondary color (--txp-primary-color)
primary & secondary background (--txp-primary-back)
form controls input + select / button
color, background, border (input + button)

borders: light normal dark: --txp-border, --txp-border-light, --txp-border-dark

success / warning / error/ info: --txp-success-text, --txp-success-back, --txp-success-border

eventually: “selected” and “active” background color

--txp-spacing (space between blocks, as margin or padding, gap, -> 1em, use calc() to adjust depending on need, eg @calc(var(—margin) * 0.5)“ for smaller or larger spacing

The idea is to use, for each, the same value as Hive currently uses. Names can be discussed.

jakob wrote #338145:

Philippe is right. […]

Thanks for testing and checking what Hive actually does! Anyway, Hive will need some updating, at least teach it to use core custom-properties (aliasing them as a minimum).

etc · 2024-11-07 10:13:44

phiw13 wrote #338155:

progress… I have it working with Safari Technology Preview. There is hope that maybe maybe Safari 18.2 will cary those fixes. Need to check the pre-release release notes.

That might be JS as well, will check. Annoying, anyway.

Meanwhile, here are some preliminary notes for some core custom-properties:

Nice, thanks. But you UX gurus would code it much better and faster than me ;-)

Thanks for testing and checking what Hive actually does! Anyway, Hive will need some updating, at least teach it to use core custom-properties (aliasing them as a minimum).

+1. And it looks rather easy to combine user/system colour preferences.

etc · 2024-11-07 10:17:11

Pat64 wrote #338152:

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

I’d leave the choice of a minimal ruleset with you guys, my css-fu is very outdated.

etc · 2024-11-07 10:45:10

phiw13 wrote #338153:

Safari 18.1 completely ignores all of the :host(#pane-preview) {} style rules. In preview.css, in my theme stylesheet or with theme Hive. Firefox and Brave do what is expected.

Does some of this work without including in :host(#pane-preview) block? It is not necessary in preview.css, and in external stylesheets it just prevents polluting the light dom, but can be removed too.

Nothing on caniuse.com/ seems to stop Safari 18.1 from working properly, though.

phiw13 · 2024-11-07 11:34:53

etc wrote #338161:

Nice, thanks. But you UX gurus would code it much better and faster than me ;-)

It is intended as note for discussion – e.g. naming, but also things that could be nice to include…

Anyway, I think for 4.9 we can start with a minimal set of building blocks and then improve or broaden the options later on.

phiw13 · 2024-11-07 12:04:51

etc wrote #338164:

Does some of this work without including in :host(#pane-preview) block? It is not necessary in preview.css, and in external stylesheets it just prevents polluting the light dom, but can be removed too.

Nothing on caniuse.com/ seems to stop Safari 18.1 from working properly, though.

Yes what you select in the :host(#pane-preview) block in preview.css would work (from within preview.css) without the :host() part. Or from the them stylesheet, but then it leaks everywhere With :host() is very nice to be able to style something in the preview dialog only.

phiw13 · 2024-11-13 01:03:50

Two building blocks for textpattern.css:

I have extracted the whole block of ui-icons out the Hive stylesheet, you can find it here: dev.l-c-n.com/txp-css/txp-ui-icons.css
A set of basic custom properties: colors, background-colors, border-colors, notification colors, which is available here: dev.l-c-n.com/txp-css/txp-css%20custom%20prop.css. Values are those used by theme Hive.

Todo: a basic set for handling form controls: inputs fields, buttons, etc.

Please incorporate in textpattern.css , thank you.

(I will be traveling for a couple days, further will have to wait )

Textpattern CMS support forum

#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

#37 2024-11-07 04:45:32

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338151:

#38 2024-11-07 08:11:32

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338153:

#39 2024-11-07 08:27:36

Re: Preview dialog - Dompurify parsing error with image shortcode

jakob wrote #338145:

#40 2024-11-07 10:13:44

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338155:

#41 2024-11-07 10:17:11

Re: Preview dialog - Dompurify parsing error with image shortcode

Pat64 wrote #338152:

#42 2024-11-07 10:45:10

Re: Preview dialog - Dompurify parsing error with image shortcode

phiw13 wrote #338153:

#43 2024-11-07 11:34:53

Re: Preview dialog - Dompurify parsing error with image shortcode

etc wrote #338161:

#44 2024-11-07 12:04:51

Re: Preview dialog - Dompurify parsing error with image shortcode

etc wrote #338164:

#45 2024-11-13 01:03:50

Re: Preview dialog - Dompurify parsing error with image shortcode

Board footer