Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#13 2023-12-06 11:46:29

etc
Developer
Registered: 2010-11-11
Posts: 5,053
Website GitHub

Re: How much should we trust other authors?

phiw13 wrote #336035:

But how would that work to hook it up into the sandboxed document ?

We would somehow import them via js after content clean-up. We could actually do it with the main document stylesheet, but

  • it is too large
  • txp does not know its name/path (default.css? textpattern.css?)

Offline

#14 2023-12-08 08:40:39

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,076
Website

Re: How much should we trust other authors?

I am coming around the idea of just doing nothing and let it render with the default UA stylesheet, except – as it is currently – use the font properties (-size, -family, line-height) and the color value from the main admin.css.

Reason: render it all as raw as possible to eliminate all distraction. It is good to see that the HTML view has all the –naughty, possibly harmful– attributes still visible.

It is a little bit of a wasted space (that default padding-left on lists / blockquote…) particularly as the dialog box is not large (in Hive esp.) at all.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#15 2023-12-08 09:18:12

etc
Developer
Registered: 2010-11-11
Posts: 5,053
Website GitHub

Re: How much should we trust other authors?

phiw13 wrote #336058:

I am coming around the idea of just doing nothing and let it render with the default UA stylesheet, except – as it is currently – use the font properties (-size, -family, line-height) and the color value from the main admin.css.

There is no main admin.css file, theme authors are free to use whatever name they want, whence my second point above. And we have to style the preview at least with *{max-width:100%}. Otherwise most images, say, will be overflowing.

Offline

#16 2023-12-08 09:26:27

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,076
Website

Re: How much should we trust other authors?

There is no main admin.css […]

I could have written theme.css or default.css or textpattern.css or whatever – it is obvious from context what is suggested: the current admin theme’s stylesheet


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#17 2023-12-08 09:34:21

etc
Developer
Registered: 2010-11-11
Posts: 5,053
Website GitHub

Re: How much should we trust other authors?

What is the current admin theme stylesheet? AFAIK, there is no name convention neither php function/method to retrieve it. There is a way is to access document styles via js though, needs testing.

Offline

#18 2023-12-08 09:39:30

etc
Developer
Registered: 2010-11-11
Posts: 5,053
Website GitHub

Re: How much should we trust other authors?

This is my document.styleSheets:

StyleSheetList(3) [
 CSSStyleSheet http://localhost/textpattern/textpattern/admin-themes/hiveneutral/assets/css/textpattern.css,
 CSSStyleSheet http://localhost/textpattern/textpattern/admin-themes/hiveneutral/assets/css/print.css,
 CSSStyleSheet http://localhost/textpattern/textpattern/plugins/com_article_image/style.css ]

Which one is main?

Offline

#19 2023-12-10 02:18:19

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,076
Website

Re: How much should we trust other authors?

The thing you “know” for sure is the $theme_name, you can discrard anything in the plugins ($plugin_path), in the case pf your theme, one stylesheet has a media type of print, you can discard it. Theme can also have one custom stylesheet, “custom.css” by default (users can customise that, check relevant Readme files for the theme).

Here is a potential way forward, without going through hoops to find the “main” stylesheet: create a minimal style block that can be inserted after all the “purifying”. It is agnostic to the theme in use (which probably does the same) The only thing it does is minimize potential overflow.

Is it possible to wrap the inserted article view into wrapper-div, with id=txp-preview-wrapper (name TBD) ? This would avoid spillover into the main Textpattern admin view.

#txp-preview-wrapper :is(img, picture, audio, video, iframe, pre, table) {max-width: 100%; width: auto; height: auto; }

#txp-preview-wrapper pre { overflow: auto; }

#txp-preview-wrapper  { -webkit-hyphens: auto; hyphens: auto; } /* split (hyphenate) longlong words */
#txp-preview-wrapper  pre > code { -webkit-hyphens: none; hyphens: none; }

iframe is included above for those who insert / embed videos from YT, Rumble, e.a

PS – I just saw that you made some (many?), including, if I read the GH page correctly, a wrapper div. I will check that tomorrow.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#20 2023-12-10 10:13:03

etc
Developer
Registered: 2010-11-11
Posts: 5,053
Website GitHub

Re: How much should we trust other authors?

phiw13 wrote #336081:

The thing you “know” for sure is the $theme_name, you can discrard anything in the plugins ($plugin_path), in the case pf your theme, one stylesheet has a media type of print, you can discard it. Theme can also have one custom stylesheet, “custom.css” by default (users can customise that, check relevant Readme files for the theme).

The only thing we know is the theme path, but not what happens inside it. A theme could use many stylesheets (e.g. common.css, article.css), so guessing which one is (are) ‘main’ without convention is unreliable.

Here is a potential way forward, without going through hoops to find the “main” stylesheet: create a minimal style block that can be inserted after all the “purifying”. It is agnostic to the theme in use (which probably does the same) The only thing it does is minimize potential overflow.

That’s (more or less) how it currently works, indeed. The only rule we are injecting atm is *{max-width:100%}, but if we agree on a theme-agnostic set, it can be done.

Is it possible to wrap the inserted article view into wrapper-div, with id=txp-preview-wrapper (name TBD) ? This would avoid spillover into the main Textpattern admin view.

Here comes the funny part. The preview is already wrapped, but its content is isolated (shadowed) from the main document:

<div id="pane-preview">
<shadow-root>
    <div id="txp-preview-wrapper">
        <!-- content here -->
    </div>
</shadow-root>
</div>

No rule you define outside of shadow-root applies to its content (and vice-versa). Neither #pane-preview * nor #txp-preview-wrapper from the ‘main’ stylesheet will match anything. The only rules that will pass through from html/body are those with inherit default value (color, font- etc).

To style inside the preview we need to inject rules into shadow-root itself via link/style/javascript. The question is: which rules must be injected? Since we have no ‘main’ css file, they have to be defined somewhere, but where?

I was hoping part selector might help, but it does not.

Offline

#21 2023-12-10 10:43:59

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,269
Website GitHub

Re: How much should we trust other authors?

Textpattern traditionally prefers convention over configuration because it makes things easier.

Unfortunately, for theme authors, we define the best practice folder structure but not its contents. So it could be tricky to define a convention for stylesheets.

This is a tough one.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#22 2023-12-10 12:05:40

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,076
Website

Re: How much should we trust other authors?

No rule you define outside of shadow-root applies to its content (and vice-versa). Neither #pane-preview * nor #txp-preview-wrapper from the ‘main’ stylesheet will match anything. The only rules that will pass through from html/body are those with inherit default value (color, font- etc).

Yes, I know all that… Good to see you added the wrapper inside your shadow root (#txp-preview-wrapper). Thus my suggestion for a minimal style-block that Textpattern admin inserts (that this the TXP core PHP/JS code), not added by an admin theme.

(oh, and fwiw, * {max-width:auto} is a bit of wild sledgehammer approach – most HTML element have no need or use for it.)


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#23 2023-12-10 12:09:24

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,076
Website

Re: How much should we trust other authors?

On a related note,

- Do I understand this correctly: if an article is saved in draft status and you view the article by following the “View” link under the Save button (not the Preview link above the textarea) then most styling and any JS is blocked. JS provided by e.g YT/Vimeo, self-hosted webfonts, manifest.webmanifest, self-hosted linked script(s) + plus maybe some conflicts or something (not clear what it was) caused by some CSP rules.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#24 2023-12-10 12:28:14

etc
Developer
Registered: 2010-11-11
Posts: 5,053
Website GitHub

Re: How much should we trust other authors?

phiw13 wrote #336084:

Yes, I know all that… Good to see you added the wrapper inside your shadow root (#txp-preview-wrapper).

Yep, though it should be done more carefully. Leave it with me.

Thus my suggestion for a minimal style-block that Textpattern admin inserts (that this the TXP core PHP/JS code), not added by an admin theme.

I’m fine with it, if all theme authors agree on the rules. We could put them in some core preview.css file.

Do I understand this correctly: if an article is saved in draft status and you view the article by following the “View” link under the Save button (not the Preview link above the textarea) then most styling and any JS is blocked. JS provided by e.g YT/Vimeo, self-hosted webfonts, manifest.webmanifest, self-hosted linked script(s) + plus maybe some conflicts or something (not clear what it was) caused by some CSP rules.

Yes, a CSP sandbox directive is set, though it shouldn’t block styles (must be some other CSP rule). We could remove it for author’s own articles.

Offline

Board footer

Powered by FluxBB