Patternslib / Patterns

Library for quickly applying rich interaction patterns without the need to write any JavaScript.
http://patternslib.com
Other
104 stars 43 forks source link

Initialize patterns on <pre> containers #805

Open thet opened 3 years ago

thet commented 3 years ago

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

https://github.com/Patternslib/Patterns/commit/8f4b14bc9644c5cac57be4cdb520eec2b5bbb3d1

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

 context. Even if pat-markdown is typically used on a pre tag.

Op 5 feb. 2021, om 15:07 heeft Alessandro Pisa notifications@github.com 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:

  
This element will be removed when the page is loaded

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 https://github.com/Patternslib/Patterns/issues/805#issuecomment-774053310, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFUKKKZDQDVJOQSFTEY26LS5P3QPANCNFSM4XEXP6KA.

cornae commented 3 years ago

I think this can be closed now, right?