Ipywidgets: Change in default Label placement/alignment and deprecate
In 7.0.0, labels are placed at the far right of the output area, where as most other widgets are placed at the far left. In 6, labels were placed on the left (though also truncated).
On master, from the Widget Events notebook:
v6, same cell:
mwcraig
All 21 comments
Yes, we made this change so that the label widget could be used to make descriptions for controls (descriptions are right-aligned). For text that stands alone, it would be better to use the HTML widget (or HTMLMath if you want math rendering).
jasongrout
on 22 Jun 2017
This is noted as the first item in the Changelog: https://github.com/jupyter-widgets/ipywidgets/blob/master/docs/source/changelog.md
jasongrout
on 22 Jun 2017
One other option is to make a Description widget mimic control descriptions, and just deprecate Label (replace with HTML, HTMLMath, or Description...). That would be more backwards compatible. I think Label never really had a clear semantic meaning, and it was confusing where it should be used.
jasongrout
on 22 Jun 2017
And thanks again for auditing these notebooks. That is really valuable!
jasongrout
on 22 Jun 2017
One other option is to make a Description widget mimic control descriptions, and just deprecate Label (replace with HTML, HTMLMath, or Description...). That would be more backwards compatible. I think Label never really had a clear semantic meaning, and it was confusing where it should be used.
The more I think about it, the more I like that idea. It bothered me that we said to use the Label in all sorts of situations, so I'd like to not break compatibility too much with 5.0 or 6.0.
The plan would be to
(a) rename the current Label to Description
(b) reinstate the Label from 5.0, essentially, by copying the current Label and changing the styling to more resemble the 5.0 Label
(c) making a deprecation warning on the Label directing people to use Description, HTML, or HTMLMath, slating it for removal in a year or so.
Thoughts? @SylvainCorlay, @maartenbreddels too?
jasongrout
on 22 Jun 2017
That seems reasonable as long as the lead time for addressing the deprecation will be long. To go a step further, is a Description widget really necessary now that the the description_width and the width of the control can be changed?
Why is there a different class for HTML and HTMLMath? That strikes me as being like the old Label and Latex widgets, which eventually merged into one.
mwcraig
on 22 Jun 2017
This is noted as the first item in the Changelog: https://github.com/jupyter-widgets/ipywidgets/blob/master/docs/source/changelog.md
D'oh! Never occurred to me to look there :)
mwcraig
on 22 Jun 2017
is a Description widget really necessary now that the the description_width and the width of the control can be changed?
Maybe not. Should we just deprecate the Label widget without a replacement description widget? That sounds reasonable to me too.
Why is there a different class for HTML and HTMLMath?
Because they serve two different usecases. Most people probably will not want math, and will be annoyed by not being able to write dollar signs. However, some do, and will really want to have math auto-interpreted.
jasongrout
on 22 Jun 2017
Most people probably will not want math, and will be annoyed by not being able to write dollar signs.
The difference between business and science users of python in a nutshell? 馃榾
One of the things I like about scipy is that it brings both together.
mwcraig
on 22 Jun 2017
In any event, I'll change up the tutorial a bit to emphasize using HTML/HTMLMath rather than Label. I've always used the latter any time I need generic text.
mwcraig
on 22 Jun 2017
So the decision was to deprecate the Label (and change it back to being left aligned for backwards compatibility)?
jasongrout
on 28 Jun 2017
I think so, yes. Then, for people who want to do minimal changes to existing code they could import HTML as Label and things would work the same way.
mwcraig
on 28 Jun 2017
On the other hand, there is another difference between Label and HTML/HTMLMath - the Label interprets math, but does not interpret HTML. Some might consider this a bug, but others might consider it a feature. For example, Label('hi &') actually prints out hi &.
So really, we should have 4 widgets (or one with creation options?): It prints a string, and recognizes HTML or not, and renders math or not. I'm happy to consolidate Label, HTML, and HTMLMath into this new widget. But what should we call it?
jasongrout
on 28 Jun 2017
Right, forgot about that again. The first thing that springs to mind, Text, obviously doesn't work, and doesn't capture that the HTML widget can really do much more than just display words.
The difference is large enough that I wonder whether it is worth keeping Label around after all. It is always a representation of words (including math) and words alone.
If an HTML widget has keywords on initialization or traits/keys that can be set later that determine how the content is displayed that seems complicated/fragile, because then an HTML widget might mean "display the html in this widget" or "display only literal text". The latter meaning is confusing to me because it essentially says the HTML widget doesn't display HTML.
Sliders have something like that, in that the orientation can be changed on the fly or at instantiation, but this seems like a much different thing.
I guess my other reason for thinking that keeping them separate may be a better idea is that if I am laying out a widget and I have a piece that I want to display text that I expose users but use an HTML widget for it, I can't really prevent them from display html content instead. Maybe that's an edge case that doesn't need to be worried about.
But I'm coming around to the view that the semantic meaning of Label is that it always display the content of its value as words on the screen. HTML can, of course, do that, and one could imagine implementing Label as a convenient interface to HTML limited to displaying words.
mwcraig
on 29 Jun 2017
But I'm coming around to the view that the semantic meaning of Label is that it always display the content of its value as words on the screen. HTML can, of course, do that, and one could imagine implementing Label as a convenient interface to HTML limited to displaying words.
And math. Which begs the question of the fourth widget - Label without math support...
jasongrout
on 29 Jun 2017
Which begs the question of the fourth widget - Label without math support...
The case I keep forgetting. Math or no feels more to me like a vertical or horizontal slider question, i.e. appropriate to set on initialization/with a trait. If math were separate, then Label and LabelNoMath (not a good name) would be better for backwards compatibility.
Of course that minimizes consistency with HTML...
Thinking out loud here [and not seriously proposing markdown this week]:
Label has a property like render_style
This would be like the orientation property for sliders, with value like math (default) and plain and perhaps even down the road markdown.
Advantage: flexible, backwards compatible, allows for future expansion without new classes.
Disadvantage: a user who doesn't know about render_style may not be likely to discover it, though perhaps that can be done in the documentation.
Helper classes, analogous to VBox and HBox for containers
Like Box has some default orientation, Label would default to current behavior. TextLabel or PlainLabel does no latex interpreting, down the road MarkdownLabel does that, etc. Maybe even have a MathLabel which is the same as Label, just like HBox is essentially the same as Box.
Advantage: Explicit, easy enough to add additional example down the road.
Disadvantage: More verbose; potentially still hard to discover the right thing to do if you don't want math.
Make Label not do math but LabelMath does math
Advantage: consistency with HTML, conceivably also tab-completion discoverable. Just as extensible as the previous option.
Disadvantage: Backwards compatibility, which is big. Plus, I like the magic of Label($\mu$) working just like I would expect, but that is not really a strong argument.
Add documentation on how to avoid math in Label
It looks like (based on a couple of quick tests) using a backslash to escape the $ keeps it interpreted as a literal. So Label('$\mu$') produces 碌 but Label('\$\mu\$') produces $\mu$.
The other ways of getting math, e.g. \(\mu\), seem unlikely to happen unless a user intends for there to be math, so $ may be the only character that needs special treatment for non-math users.
Advantage: Doc fixes are easier than code changes, preserves backwards-compatibility.
Disadvantage: The $ requires special handling.
mwcraig
on 29 Jun 2017
One other thought -- simply making Label left-aligned for 7.0.0 would address the original issue. A larger reorganization could be punted for now...
mwcraig
on 29 Jun 2017
One other thought -- simply making Label left-aligned for 7.0.0 would address the original issue. A larger reorganization could be punted for now...
Do you want to put in a PR? I think it's probably just deleting one line of CSS.
jasongrout
on 29 Jun 2017
Sure, will do.
For more options, visit https://groups.google.com/d/optout.
mwcraig
on 29 Jun 2017
For more options, visit https://groups.google.com/d/optout.
Was that the link you planned to post?
jasongrout
on 29 Jun 2017
sigh Spark used to be so nice...meaning that whole line wasn't supposed to be there.
mwcraig
on 29 Jun 2017
Related issues
andymcarter
路
6Comments
drafter250
路
4Comments
hangyao
路
6Comments
pbugnion
路
4Comments
aidanheerdegen
路
4Comments
Most helpful comment
Maybe not. Should we just deprecate the Label widget without a replacement description widget? That sounds reasonable to me too.
Because they serve two different usecases. Most people probably will not want math, and will be annoyed by not being able to write dollar signs. However, some do, and will really want to have math auto-interpreted.