Create custom block but hide 1st label name

I'd like to be able to create custom blocks that don't have a visible label at the start of them

like these
I don't think its currently possible
Could it be done?
maybe use $myblockname like the image prefixes but just display nothing?


If I understand correctly, it is possible. You just need to create a custom block which has the text you want to have in the middle and use the plus button for adding inputs.

your right of course - I used some wrong examples to illustrate my request :slight_smile:

I'm wanting this feature so I can produce reporters likes this


but without the image prefix (and the ability to have similar looking blocks that are functionally different hence the need for invisible label)

I see. Yes, that is currently impossible, to my knowledge.

It's not impossible! First you do this:
untitled script pic (8)
Then you click the words "some" and "thing" to turn them into inputs!
untitled script pic (10)

Works excellent for 1st of them

but I can't then make another one without it adding a suffix


so I still think I need to have invisible labels

Do it with a zero-width space

Could you show how to use that?

Go to the Wikipedia article, copy the character (between the brackets) and paste it somewhere in the blocks title

Got there :slight_smile:
To anyone trying this - I ended up copying from last letter of Lorum to first letter of Ipsum - pasting then deleting the m - moving to end and backspacing the I

Its best work-around so far :slight_smile:

But not very editing friendly as I've not managed to edit (or even delete) a text field with one in

hmm... What am I misunderstanding?


I made a project that lets you copy the zero-width space so you don't need to do all that editing.

Sorry - My first post was wrong - see 2nd one for clarification :slight_smile:

I'm after two reporter blocks that look the same but are functionality different.

I want to create them to return possible values using pulldown options

e.g one provides a list of possible common LED colours (red,green,blue,white,orange) and another one that provides a list of Pi pin numbers (pin3, pin5,pin7 etc)


Then I just want a programmer to drop whichever custom reporter they need to use inside another blocks slot.

But I don't want (need is too strong a word) to "clutter" up the reporter with a prefix or suffix - hence the FR to have invisible labels

e.g left one is great - its obvious that its a colour on/off reporter - doesn't need a suffix/prefix
The pin one one the right is also obvious and doesn't need a visible label but has to have one otherwise Snap! can't tell the difference

Thanks :slight_smile:

I'm finding its very weird (after 45 years of programming) to be copying and pasting an invisible character

Luckily the cursor knows about it and lets me move back and forth across it as if it was visible otherwise I'd be completely lost :slight_smile:

Ah, I see, thanks. It's funny, Snap doesn't technically need unique block labels for global custom blocks, this is a user-interface requirement only :slight_smile:

So that's good news - no need for invisible labels then

And, for most cases, that is obviously a very good idea - two blocks with no labels would cause an awful amount of problems

by using different pulldown menus - the UI confusion is negated :slight_smile:

So, what can you offer me to square this circle? :slight_smile:

I really don't want to go down @fridolinux zero-width space route if I can avoid it as once I've added one in - its impossible AFAICT, to edit/delete one once created. (Which makes it difficult to play-around with it)

One possible idea: If $zeroWidthSpace was available as a symbol - then at least editing a block header with them in would become possible, as I could stick 2, 3 or 4 of them in-between the two input fields without the visuals looking too bad


Oh, my advice is easy: Just give your blocks expressive labels! :slight_smile:

Look - I've not asked for anything in AGES :slight_smile:
Throw me a crumb :slight_smile:

Well, seriously, then, another idea would be to collapse it all into a single block with nested submenus.

Oh, my advice is easy

My serious reply to this is that I'm basically trying to provide a custom 2 parameter join block where the inputs are menu dropdowns

So, in true Scratch/Snap! philosophy, I should just prefix them with the label join

Which is fine for the 1st block - but we are back to the same problem for the 2nd block - I can't re-use join (wihout adding a zero-width space to the label)

And I can't use same concept with single field blocks of this type as I wouldn't have a join prefix (well I could but I think we'd both agree it looks silly)