This is frustrating when making certain kinds of plugins. For example, you want to pass in some HTML, but you can’t because perchance decides the block isn’t code anymore.
Ideally, all code within a [] would be ignored until its final ].
Oh while I’m on the topic… Please ignore any [] or {} inside of <script> tags or in things like onclick="" attributes. Would make life a lot easier ;p
Can you give an example of what you are using the
[]in the HTML panel for? It might be easier to write the script that you want to execute on the List Editor instead of writing the whole thing inside the[]in the HTML editor.Someone on Reddit wanted to use a spoiler plugin (for the sake of example…)
[]with an image tag[]which would be just fine, and it’s nothing complicated. But perchance says “Oh look a tag, I guess there’s no code here after all.”Some things are just better to be done in-place in the HTML, know what I mean? Rather than using a list item just because perchance works differently for the HTML stuff to the list stuff. I’d say it would be more consistent to work the same in both, know what I mean?
I guess that is just how the plugin works. Mostly caters only to spoiler texts.
Here is a simple one I made that allows HTML as an input.: https://perchance.org/9xaiky68ni
No, you’re missing the point, sorry.
This bit:
[]. That in the HTML pane means the code block is entirely ignored. Your example doesn’t have such a code block, which is why it works.Ah, I see it now. I never really used it like that.
You can, however, use
<as the<for the HTML, to essentially escape it from being understood as HTML directly like so:[spoiler(`<h1>A Spoiler Function</h1> <img style\="aspect-ratio: 768/512; height: 200px;" src\="https://user-uploads.perchance.org/file/c3e7005097f3fdad94bb003c300e6865.webp"> <p>Lorem Ipsum</p> <button onclick\="event.stopPropagation(), update(minimalOut)">randomize</button>`)]And you would be able to use it as an HTML. I’ve updated the demo generator to showcase it.
Wow okay that’s bizarre! So it turns < etc. into regular characters before passing it to the function or something? Where is any of this documented?! 😂
That is not how these things work normally; < will show just that character in the HTML document. The fact it doesn’t do that if you use it in code to pass as a string to a function which then returns it… just to get around this breaking-code-blocks behaviour is… just out of this world 😅
There’s so much going on with this engine under the hood that if you actually have any understanding of real, regular JS… it drives you insane 🥴
Okay at least that’s a workaround. But seriously… it should just ignore stuff in
[]entirely so you don’t have to have all this deep knowledge and you don’t have to go insane trying to understand it.if you actually have any understanding of real, regular JS… it drives you insane […] But seriously… it should just ignore stuff in [code blocks] entirely so you don’t have to have all this deep knowledge and you don’t have to go insane trying to understand it.
I agree 100% - at some point I’ll fix all these issues. I’d like it to be a very thin/robust/predictable layer on top of raw web platform stuff.
Where is any of this documented?!
https://perchance.org/known-bugs which is linked from https://perchance.org/resources but I agree it’s not very easy to find, and these issues obviously ideally wouldn’t exist in the first place.
So it turns < etc. into regular characters before passing it to the function or something?
The problem here (and the way to mentally model this - CC @[email protected]) is that the output HTML is fully rendered without any Perchance-specific stuff first (i.e. just setting
innerHTML), and then the square blocks are evaluated in any text nodes on the page. So the underlying issue is the same for your original request, and this question about<and<. I’ll add this explanation to the existing item for this on /known-bugs page. I guess the simple way of explaining it is “HTML parsing gets priority”.But I agree it shouldn’t. So yeah it’s a silly bug, and the only reason I haven’t fixed it is because it’d be a breaking change, and so requires a manifest/versioning type thing to be added as a header HTML comment to existing generators which are relying on this ~bug.
Thanks for bringing up the issue though - it’s nice to have fresh eyes on this stuff, and hearing complaints helps me prioritize.
Oh, I see… I guess that’s why it works out like that. Thanks for explaining.
I kind of enjoy this stuff. For a number of years I was part of a somewhat niche community for another user-creation platform for video games called Dreams. I taught, helped, answered questions, and wrote my own documentation just through reverse-engineering stuff within the engine.
I’ve already started on one for perchance, just explaining the methods/properties on list nodes. thinking of doing more, but some of this stuff is quite hard to figure out by myself–and a lot of it just isn’t explicitly explained anywhere.
Dreams had the same issue: great software with really deep features that no one but the devs understood or knew existed. So I’d scour their streams for clues to such features, then explore them fully in the engine to get as accurate a picture of it as I could–then added it to my documentation.
Hard work, but I seem to just enjoy stuff like that. ;p
