Scratch-blocks: Class attributes to distinguish blocks

[mrjacobbloom]

This is a feature request. When people start to create themes for Scratch 3 they'll want a way to distinguish the inputs from the blocks themselves with CSS styles. It'd be nice if there was a class-name on the paths to separate the two.

[tmickel]

Sounds like a nice idea to me so Scratchers could customize how things look with user-styles :)

We should definitely wait until we play out #238, since that would restructure how things are arranged.

[mrjacobbloom]

Whenever y'all revisit this, consider adding classes to distinguish block shape and category as well. That'll make creating themes/skins significantly easier.

[rachel-fenichel]

On a deeply nested stack of blocks, adding the class to each block may be
an expensive operation.

On Fri, Jun 10, 2016 at 8:26 PM Airhogs777 [email protected] wrote:

Whenever y'all revisit this, consider adding classes to distinguish block
shape and category as well. That'll make creating themes/skins
significantly easier.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-blocks/issues/365#issuecomment-225334184,
or mute the thread
https://github.com/notifications/unsubscribe/ANDWfy5HRjFdU-CAcbHkc9OTy3qKusxkks5qKirWgaJpZM4IuBtE
.

[mrjacobbloom]

I've been thinking about how to do this. Shape classes could be added on the fly during rendering/initialization based on connections.

Category isn't as easy to determine. I see a few options:

• The easiest way is to use the substring of block.type before the first underscore
  
  
  
  • The problem with this option is that it depends on a naming convention and is therefore susceptible to human error
  
  
• Compare the block's color[s] to Blockly.Colours
  
  
  
  • There are some edge cases where this would fail. For example, if two categories shared the same color.
  
  
  • It'll also involve a for-loop since we're searching for values instead of keys, and that could be kind of expensive.
  
  
  • The for-loop could be avoided by generating a reversed colors database. For example {"#FFFFFF": "categoryName"}. But that seems like overkill...
  
  
• Add category names to the block definitions
  
  
  
  • This would involve an overhaul of the block definitions but I think it's the cleanest solution. Down the line, this could also simplify how we set block colors.
  
  

Sometime down the line, would you guys be willing to accept a PR that adds this functionality?

[tmickel]

Regarding category: I would personally lean toward option 3 (adding category names to block definitions) for exactly the reason you say. The color-boilerplate reduction would possibly be worth the addition regardless of making it easier to user-style the blocks. In fact, if we went this route, we could set the colors of blocks entirely through CSS on the category name and throw out the Blockly.Colours dictionary for blocks. That's not how Blockly approaches the color problem right now, but I think we could entertain it.

[mrjacobbloom]

Have you guys discussed #238 at all? I'd be willing to get started on a pull request to add the block shape class code.

[tmickel]

Hey @Airhogs777! We have discussed it. It's looking like it might happen, but might take some time. So it might be best to wait before adding the class code.

[mrjacobbloom]

Those were all the changes I was hoping for. Thanks for being so open to my contributions! :)