It looks like we need to have auto dflt and value in respect to src/components/shapes/defaults.js logic.

@archmoj What would be the use case for an auto value for textposition?

@archmoj What would be the use case for an auto value for textposition?

Hmm.. that's a good idea. But as far as I recall we don't have such an option for textposition in other places. So perhaps we could keep this part as is.

Are these start|end really necessary?
If so, let's describe them in the description please.

Definitely open to suggestions here, but my thought was that corner-based positions like top right, top left etc. don't really make sense for lines because imagine e.g. a downward sloping line -- top right of the bounding box would place the label at a far-off point in space nowhere close to the line.

Even if the line started out sloping upward and so top right made sense, it could be dragged by the user into a downward-sloping position.

I agree that mixing start|end positions with top|middle|bottom is a little convoluted though. One thought I had was that maybe lines should only support 4 specific label positions: top, bottom, start and end (or potentially, top, bottom, left and right). Not sure if that would be more or less confusing.

Maybe @alexcjohnson has thoughts here as well?

My thinking about these attributes is that position refers to a single point on the shape, and [xanchor, yanchor] (plus padding) refers to a single point on the text element, and you position the text so that those two points are in the same place.

So for lines, the only position values that make sense are start|middle|end. We can set smart defaults for xanchor based on those ({start: 'left', middle: 'center', end: 'right'} so that by default for position: start|end the start or end of the text aligns with the start or end of the line, and for position: middle the text is centered on the line. Then yanchor: bottom puts the text on top of the line (ie the bottom of the text is on the line), yanchor: top puts the text under the line, and yanchor: 'middle' puts the text on top of the line. You can get other cool effects then like text preceding the line (position: start, xanchor: right, yanchor: middle) or following the line (position: end, xanchor: left, yanchor: middle)

For other shapes the first nine positions you have are good, and in those cases we can set smart defaults for both xanchor and yanchor to match, ie [xanchorDefault, yanchorDefault] = position.split(' ') so (for rects anyway) by default the text is drawn just inside whatever corner or side you specify with position. Default for all these shapes should be middle center though.

Yeah I think this makes sense @alexcjohnson , thanks!

@alexcjohnson I've implemented these changes to the position property for lines

@alexcjohnson Oh, I realized I skimmed over this part of your comment before:

For other shapes the first nine positions you have are good, and in those cases we can set smart defaults for both xanchor and yanchor to match, ie [xanchorDefault, yanchorDefault] = position.split(' ') so (for rects anyway) by default the text is drawn just inside whatever corner or side you specify with position.

I've implemented the exact opposite -- by default the text is drawn outside the corner, if xanchor and yanchor are not specified. That feels more intuitive to me, and I think it generally looks better, so wanted to verify that that's okay. If it needs to be the other way for consistency with other parts of the API, I can change it.

I guess it depends what we consider the default or most common use case for labels on shapes. I feel like if I was using a shape to label a particular region of a graph - an important x or y range, typically - I'd likely want the label within that region, but off in a corner so it avoids most of the data in that region.

I guess that really only applies to rectangles, for circles or paths being outside the region would be better as otherwise the label would often overlap the edge of the shape, and there are other use cases even for rects where an outside label would make more sense. Perhaps though even then it would make sense for xanchor to be within the bounds and just yanchor to be outside? So for example textposition="top left" would default to xanchor="left", yanchor="bottom"?

Also: can we handle this logic at the defaults stage instead of the draw stage? If we do that, the choices we made show up in fullLayout which can help some users understand and fix unwanted behavior. And at that point I don't see a use for "auto" in these attributes (which in turn means they can probably stop inheriting from annotations)

Oh I guess xanchor on lines with textposition='start'|'end' still needs 'auto' because it depends whether the start is toward the left or right, and we can't know that unless we also know the axis range it's on. That doesn't apply to yanchor though, I still don't see a reason to let that be 'auto'.

But a little more logic around this perhaps, just for lines: If textangle='auto' I would expect the text to be along the line by default, rather than extending off the end. Whereas for any other textangle I'd expect the text to extend off the end, since if it tried to go along the line it would often overlap the line.

@alexcjohnson I've updated xanchor and yanchor defaults so they reflect the following behavior:

• yanchor:
  • Default for lines is bottom
  • Default for all other shapes is such that the label is positioned inside the shape bounding box (e.g. if textposition is top right, yanchor is top.
  • auto is not a supported value for yanchor
• xanchor default is always auto. This has the following behavior at render:
  • For lines:
    • If textangle is auto (parallel to line) xanchor is set so that text is inside the line bounding box
    • If textangle is anything else, xanchor is set in the opposite direction, so that text is outside the line bounding box
  • For other shapes: xanchor is set such that the label is positioned inside the shape bounding box (e.g. if textposition is top right, xanchor is right

This mostly works pretty nicely. The only cases that are not ideal are circles and paths -- since the text is positioned inside the bounding box, it overlaps the circle/path in an odd way for any position besides middle center.

We could potentially position the text outside the bounding box by default for circles and paths... but not sure whether that's worth the additional complexity.