Prism for html preview in write tab

sacripant · 2016-02-27 10:29:22

Hello,

It’s about last commit: add prism.js for a syntax highlight for html preview in write tab.
It’s a good improvment.

But, I wonder if it’s a good idea to add it to the core.

Because :

it adds a new js library on all pages of the back office.
it’s not switched off for those who don’t want

There’s there a way to add it otherwise?
Through an official plugin that is already there when installing or updating textpattern : It adds the js library only on pages where it’s necessary and it’s switched off for those who want a lighter interface and does not need.

I don’t like how the back office gain weight (Jquery UI + prism).

Pat64 · 2016-02-27 10:51:51

I like so this new UX improvment!

Why don’t you add it to other textareas? i.e. “Page” and “Form”.

sacripant · 2016-02-27 12:48:30

Prism.js is a script for highlight block of code <code> <pre> tags, not for <textarea>.
For that you can install spf_codemirror plugin

phiw13 · 2016-02-28 05:59:25

I’m actually not unhappy with this addition. The code colouring part is certainly welcome, it makes reviewing articles on the HTML sub panel of the Write panel easier on the eyes.That would also be beneficial for (plugin) help files.

The additional line-numbering though: meh. That part makes the already mentioned HTML sub panel (the only place so far where Prism.js actually does something, so far) very —and I mean very — hard to use: that JS code forces the use of white-space:pre on the pre element, with as result: terribly long lines. For my own admin theme, I’ve hidden the generated line numbering for that panel, and set the code block to wrap…

.html code[class*="language-"] {
	white-space: pre-wrap;
}

PS – I do sympathise with sacripant above, re- code bloat though; we’ve talked about it before.

philwareham · 2016-02-29 11:19:20

If you want a user-friendly user interface then features need to be added as and when they make sense. That means jQuery, jQuery UI, and now Prism. The amount of code I’ve saved by not supporting IE8-10 more than negates the code bloat added by this plugin, plus we ditched Modernizr a while back too. If we can get Textile updated then Prism can also be used by plugin authors in their docs.

I will think about the line numbers – I guess they are not essential and if causing issues I could remove that part of Prism – which is a plugin anyway (that also reduces the aforementioned code bloat).

Bloke · 2016-02-29 12:00:25

phiw13 wrote #298045:

That would also be beneficial for (plugin) help files.

I tried that on the plugin install page as soon as Phil added this to core, but couldn’t get it to render reliably. It’d be nice if the help rendered as HTML instead of just showed you the HTML code, but maybe that’s a security risk, in case there’s inline JS or something?

With regards plugin help docs, in theory it’s just a case of adding an appropriate language- hint to some parent element on the page and then any code blocks would get highlighted for free. Authors could override this on a block-by-block basis.

I tried it, but it didn’t work very well. I suppose the question is: which language do we go for as fallback? The most prevalent type of code block in my plugins is some <txp:smd_*>... </txp:smd_*> example. Does the language-markup cater for our txp tags using some xml-style markup scheme? Seemed more miss than hit in my (limited) tests. Presumably because of the Textile issue that Phil mentioned.

The additional line-numbering though: meh.

Yes, not really necessary imo. Nobody really cares about line numbers in the preview pane, do they? Does it help with debugging? And if so, perhaps a toggle option would be better that refreshed the page with them on and remembered the setting.

I do sympathise with sacripant above, re- code bloat

This addition wasn’t something I’d envisaged for core exactly. Perhaps if it was more widely useful as a back-end syntax highlighter on the Pages/Forms/Styles/etc panels (like codemirror, but… not codemirror as it sucks imo) then it’d be better.

Dunno, on first glance it sort of felt pluginish to me: not of major benefit to the user base at large, although relying on a plugin would preclude its use for plugin help highlighting. If it gets added there and is satisfactory (assuming Textile can be fixed somehow), then it’s a more-than acceptable enhancement imo.

Last edited by Bloke (2016-02-29 12:02:28)

philwareham · 2016-02-29 12:31:53

The reason it doesn’t render on the plugin install page is because of the PHP built-in highlighter which is already used there. Although as discussed last week that whole install process is horrible UX anyway.

It makes no sense to provide an automatic fallback for code highlighting because how can we assume the code is markup, not CSS or PHP or whatever. We can’t.

The real issue here is Textile’s inability to allow a class on the inner <code> tag of a <pre><code> pairing. That should be fixed.

sacripant · 2016-02-29 12:36:30

Hello Phil,

I think I misspoke.
I love the work and improvements you make to textpattern. The project progresses.

My question was more about the strategy you decide to make these improvements :

1/ Impose improvements to all by placing them in the core
OR
2/ Add some improvments via core plugins to enable greater scalability and more freedom : switch on/off, change CSS of prism theme, activate line number or not, …

It’s just a throught.

phiw13 · 2016-02-29 12:41:04

Bloke wrote #298061:

It’d be nice if the help rendered as HTML instead of just showed you the HTML code, but maybe that’s a security risk, in case there’s inline JS or something?

To be honest, I’d prefer if that panel remain as raw as possible, for the reason you mention. Some plugin authors seems to add some kind of code-colouring on their own in the plugin-install step (at least for the PHP part).
I was more thinking the plugin help files.

… The most prevalent type of code block in my plugins is some <txp:smd_*>... </txp:smd_*> example. Does the language-markup cater for our txp tags using some xml-style markup scheme?

I would think XML-type language; that is how I treat my .txp files in my code editor

Nobody really cares about line numbers in the preview pane, do they? Does it help with debugging? And if so, perhaps a toggle option would be better that refreshed the page with them on and remembered the setting.

Personally they’re no help at all in the article preview sub panel – as I noted above, it creates a (serious) usability issue there; I can see it as a nice touch when giving out code snippets (help files again), but certainly not a must-have.

This addition wasn’t something I’d envisaged for core exactly.…

The code-colouring is welcome. And yeah, the Pages & Forms panel. I won’t cry if the line-numbering disappears tomorrow *-)

PS – Prism.js is very fast, compared to the google-prettify.js that Phil used previously on his design pattern page

philwareham · 2016-02-29 12:42:00

We can limit Prism script loading to the article write/edit panel and plugin (help?) panels since those is the most likely places it would be used. That is also how the zxcvbn script is handled.

sacripant · 2016-02-29 13:08:22

Hi,

I don’t understand your problem with Textile? Prism.Js work well with bc(language-*).. I use it in my website. No problem.

philwareham · 2016-02-29 13:11:12

sacripant wrote #298066:

Hi,

I don’t understand your problem with Textile? Prism.Js work well with bc(language-*).. I use it in my website. No problem.

But doesn’t that render as?…

<pre class="language-markup"><code>

…and the <code> is the tag that Prism requires to have the class on it in order to work? Can you show me a working example?

Textpattern CMS

Textpattern CMS support forum

#1 2016-02-27 10:29:22