Initialize patterns on <pre> containers

[thet]

The following commit prevents patterns from being initialized on <pre> containers:

8f4b14b

While working on a pat-codeeditor for Plone I found that limiting.
It would be nice, if a code editor could be initialized like

<pre><code class="pat-codeeditor">
</code></pre>

Do we need to have patterns not initialized on <pre> elements?

If yes, can we add a functionality to initialize it when the element has a class like .do-touch-this, similar to the .cant-touch-this which also prevents elements from being initialized?

[cornae]

I cannot imagine why Patterns would not be allowed to be initialised on or inside pre elements. Actually, we initialise pat-markdown usually on a pre tag.

Please use 'pat-code-editor' because code editor is two words in English.

What does this pattern do? Making it possible to design editors for code? Where are you using it?

[thet]

I have to correct me: patterns are not initialized, when one of the parent tags is a <pre> element.

So you think we can remove this limitation?

Thanks for the feedback, I will change the name!

It's for Plone - I did not coordinate with @pilz or you, @cornae as this is a quick shot to replace the pat-texteditor Mockup pattern. It is used in Plone for the theme editor where Plone integrators can directly edit HTML, CSS and JavaScript in the browser to change the theme.

[cornae]

Sounds exiting :).

I think it can be removed, but I'm probably not the right person to judge this. There might have been an technical reason. But from an interaction point of view I can neither see a reason nor a problem to have patterns inside a pre tag.

[ale-rt]

I suspect the reason why that rule was added is to actually write documentation for patternslib.
Immagine you want to document an hypothetical pat-destroy-me:

<pre>
  <div class="pat-destroy-me">This element will be removed when the page is loaded</div>
</pre>

If the pattern is enabled inside the pre, you will not read it at all.

Apologies in advance if I have not been clear or if I misunderstood the topic.

[cornae]

Ahhh that makes a lot of sense! I think that’s exactly the case. But it would be more correct in that case to look for a pat-markdown context instead of a <pre> context. Even if pat-markdown is typically used on a pre tag.

…

Op 5 feb. 2021, om 15:07 heeft Alessandro Pisa ***@***.***> het volgende geschreven: I suspect the reason why there rule was added is to actually write documentation for patternslib. Immagine you want to document an hypothetical pat-destroy-me: <pre> <div class="pat-destroy-me">This element will be removed when the page is loaded</div> </pre> If the pattern is enabled inside the pre, you will not read it at all. Apologies in advance if I have not been clear or if I misunderstood the topic. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#805 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFUKKKZDQDVJOQSFTEY26LS5P3QPANCNFSM4XEXP6KA>.

[cornae]

I think this can be closed now, right?