Thanks, I'll look over it and probably merge it.
(hope this doesn't count as necroposting)
I'm working on an e-book that uses Snap! code, and I was hoping to use snapblocks in the markup to embed the blocks.
I'm using Github Pages' built-in Jekyll actions (i.e. making markdown files and leaving the configuration at default).
How would I embed snapblocks? Is there a JS file I can <Script SRC=>?
Don't worry, this isn't necroposting.
You can indeed just stivk the snapblocks.min.js file in a <script src="snapblocks.min.js" /> tag, but then at the bottom (or using defer I think) just add something like
snapblocks.renderMatching('pre.blocks', {
style: 'snap', // Optional, defaults to 'snap'.
languages: ['en'], // Optional, defaults to ['en'].
scale: 1, // Optional, defaults to 1
wrap: true, // Optional, defaults to false. This enabled block wrapping
zebraColoring: true, // Optional, defaults to false. Enabled zebra coloring
showSpaces: true, // Optional, defaults to false. Shows spaces in inputs
});
The first argument in renderMatching is a css selector for all the elements that would contain snapblocks code. In this example, it would match
<pre class="blocks">
move (10) steps
</pre>
If you want to use snapblocks inline, just add a second renderMatching but with a different selector, and add the option inline: true. You can do
The <code class="blocks">move (10) steps </code> moves 10 steps
Unfortunately I don't know for sure whether snapblocks works with Jekyll, so I don't know if it takes more steps.
Thank you! It works fine (except for when I tested it on Firefox/Fedora, for some reason. Even webkit works.) I'll attach photographs in a second.
| Firefox/Fedora | Chrome/ChromeOS |
Snap! itself looks more or less the same on both systems. IDK.
The rendering issues on firefox is something that I already know about, and @sarpnt has made a fix for it in this pull request. However, I haven't merged it yet, because I've noticed that it looks worse in both browsers when I have my display scale set to 125%, and both looks the same (and almost identical to snap) if I set my display scalr to 100% (on windows), and I'm not sure if I want to deal with that.
Baseline is, firefox is really annoying when it comes to niche details (like svg rendering).
Okay, nevermind. I forgot.
hmm i still can't quote snapblocks (i'm a bit late to the party but eh)
also () () turns into an operator. (this is because of farsi/persian/wahtever you call it.)
(accidentally clicked reply sorry satvikrias)
Also to fix the define blocks turning into cap blocks, couldn't we just remove the Japanese translation for the stop block? I doubt anyone is going to use it anyways, and if they do, they can just add ::control cap
Or we could ask the Japanese Scratch translators to change the Japanese translation for the stop block to not just be a dropdown (although as someone who doesn't speak Japanese I am not sure if they would be able to properly form a sentence), and then we could change the translation in Snapblocks.
I already fixed the issue in the next version by prioritizing the define block over other detected blocks (translations). I just haven't released it yet.
Suggestion: Add serrated blocks
These blocks have zigzag edges to look like it's part of a block snipped from.
The input dialog when creating a custom block has the inputs in serrated blocks.
It can be reporter (left and right serrated), or command (either top or bottom serrated based on the position, or even both).
?
I don't think I'm going to add that, as that's not part of the actual snap language. And plus, I don't see any practical use case for it.
@mr_owlssssnap2 they're talking about this
oh
Bug: default icon color is not affected by zebra coloring
($brush ($brush::grey)) // what it looks like right now ($brush ($brush-1.2-255-255-255::grey)) // bug ($brush ($brush-1.2-0-0-0::grey)) // intended
Oh I see, thanks for the report.