-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Text width measuring does not respect CSS. #5871
Comments
Technically is mentioned in the docs :P "The label field takes in an optional value, and an optional css class string." But yeeee you're right, it should probably be in the example code, as well as in the description. Also I think this is a dupe of #2694 ? Not sure which is better to close though. |
I think #2694 is a superset of this issue, not a duplicate. Its problem is mainly a complete lack of height info, whereas this issue only deals with incorrect width info. Obtaining height info is nearly impossible, whereas correcting the width info appears to be feasible. Thus I expect we can quickly resolve this issue, while leaving #2694 open. |
This extends our blockly monkey patch to use the slower, more accurate way of figuring out how big the comment text field should be, as detailed in google/blockly#5871.
Is this still being looked at? |
This seems to have been fixed by #8572. |
FieldLabels have an optional class parameter (which interestingly is not mentioned in the docs, but is listed in the reference). This allows one to change the font/size/colour and other attributes of the text.
However, changes made by a class to the label does not affect the computed width. Blockly.utils.dom.getTextWidth does a perfectly good job, but it has largely been replaced by Blockly.utils.dom.getFastTextWidth. Whereas the former measures the actual onscreen text using the built-in
getComputedTextLength
function, the latter draws the text onto a canvas and measures the result. Nothing drawn on a canvas is affected by CSS class rules.The result is that (for example) if one adds some monotype text to a block, the text spills off the edge of the block:
Changing text colour is about the only safe action one can perform using a CSS class.
This bug surfaced as a result of PR #5868, but it's been lurking in the shadows for years ever since
getFastTextWidth
was created.The text was updated successfully, but these errors were encountered: