Small active area when selecting number fields on blocks

[drigz]

To change the number "1" on the block above, you have to click inside the text area of the "1" - clicking in the surrounding white area does nothing. The active area is highlighted in the image above. This is especially hard to hit on touchscreens.

Two possible fixes:

• Blockly.Field.init() could install the mouseup handler on block.getSvgRoot()
• or field.borderRect_ could be larger (what it's current purpose? It has width="0" for me)

What do you think is the right approach to improving this?

[tmickel]

I think the actual block here is being drawn to look like the field. Fix number one makes sense to me, but would make the field incompatible with the vertical text field? If we make borderRect_ larger, can it fill the whole space of the shadow block?

Another possible way to approach it might be to install the handler in the horizontal rendering of the shadow?

[drigz]

Is there a way I can test the vertical rendering at the moment? If I open vertical_playground.html I get broken blocks:

I've looked into the borderRect_ option, which is a little weird. The image below shows a classic Blockly block - the borderRect_ is the lighter green background for the text, which also provides a nice click target. Its width is calculated by Field.render_ to give SEP_SPACE_X/2 margin either side of the text. Field.render_ is normally called by field.getSize(), which the horizontal renderer doesn't use, so the rect never gets a width and is invisible.

As FieldTextInput.resizeEditor_() uses the borderRect_ size (from Field.getAbsoluteXY_()) to determine how to size the <input>, this bug means that the text doesn't quite line up when editing (see below), so I think fixing the borderRect_ rendering is worth it regardless. Doing this will increase the size of the click target, although it won't quite fill the shadow block. The misalignment was introduced by a change I made, the text is properly aligned with vanilla code.

To make the whole shadow block active, I think we'd need to install the handler differently in horizontal/vertical rendering, although I don't have a feeling for how vertical rendering is meant to work.

Let me know if you have any thoughts - unless you say otherwise, I'll try to fix the borderRect_ rendering (but make it invisible) to see if it fixes the alignment as well as this.

[rachel-fenichel]

iirc vertical rendering is broken in a fairly trivial way (something is
undefined and that's making svg sad).

On Wed, Mar 30, 2016 at 8:44 AM Rodrigo Queiro [email protected]
wrote:

Is there a way I can test the vertical rendering at the moment? If I open
vertical_playground.html I get broken blocks:

[image: broken vertical rendering]
https://cloud.githubusercontent.com/assets/632207/14146781/2956ce62-f699-11e5-988b-a30a97e18860.png

I've looked into the borderRect_ option, which is a little weird. The
image below shows a classic Blockly block - the borderRect_ is the lighter
green background for the text, which also provides a nice click target. Its
width is calculated by Field.render_ (never called as the horizontal
rendered doesn't call field.getSize()) to give SEP_SPACE_X/2 margin either
side of the text.

[image: blockly classic]
https://cloud.githubusercontent.com/assets/632207/14147924/bb823d40-f69d-11e5-81e8-9df3f18fcc2f.png

As FieldTextInput.resizeEditor_() uses the borderRect_ size (from
Field.getAbsoluteXY_()) to determine how to size the , this bug means that
the text doesn't quite line up when editing, so I think fixing the
borderRect_ rendering is worth it regardless. Doing this will increase the
size of the click target, although it won't quite fill the shadow block.

To make the whole shadow block active, I think we'd need to install the
handler differently in horizontal/vertical rendering, although I don't have
a feeling for how vertical rendering is meant to work.

Let me know if you have any thoughts - unless you say otherwise, I'll try
to fix the borderRect_ rendering (but make it invisible) to see if it fixes
the alignment as well as this.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#132 (comment)

[drigz]

I've gone for the first approach, with a check that the block only has one field (true for these shadow blocks and a few others). Given the change from using Field.borderRect_ as a text background to using only BlockSvg.svgPath_, this makes sense to me. Do you think this will cause an issue with vertical rendering?

As a side-note, it seems like borderRect_ is now only used by the subclasses of Field via Field.getAbsoluteXY_ and Field.getScaledBBox_ in order to position their editors over the field. Are you planning on restoring the concept of a field that implements its own chrome, or are you going to use shadow blocks for all fields? I quite like the latter idea, as it can be very hard to decide if you want a field or an inline input.

If fields don't need their own chrome, removing Field.borderRect_ might make the layout code simpler and more direct.

[RoboErikG]

Another approach would be to make shadow blocks transparently wrap their field (height and width are height and width of their only field and they don't draw anything) and style the field to draw the oval..

[tmickel]

@drigz By the way, not sure about this, we should discuss. Having the block render the chrome is nice also because we will usually render fields differently in horizontal vs. vertical...

So I would lean toward rendering the fields in the appropriate block rendering code.