Are thesestart|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 liketop 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 sotop right made sense, it could be dragged by the user into a downward-sloping position.

I agree that mixingstart|end positions withtop|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 andend (or potentially,top,bottom,left andright). Not sure if that would be more or less confusing.

Maybe@alexcjohnson has thoughts here as well?

My thinking about these attributes is thatposition refers to a single point on the shape, and[xanchor, yanchor] (pluspadding) 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 onlyposition values that make sense arestart|middle|end. We can set smart defaults forxanchor based on those ({start: 'left', middle: 'center', end: 'right'} so that by default forposition: start|end the start or end of the text aligns with the start or end of the line, and forposition: middle the text is centered on the line. Thenyanchor: 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, andyanchor: '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 bothxanchor andyanchor 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 withposition. Default for all these shapes should bemiddle center though.

Yeah I think this makes sense@alexcjohnson , thanks!

@alexcjohnson I've implemented these changes to theposition 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 drawnoutside the corner, ifxanchor andyanchor 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 forxanchor to be within the bounds and justyanchor to be outside? So for exampletextposition="top left" would default toxanchor="left", yanchor="bottom"?

Also: can we handle this logic at thedefaults stage instead of thedraw stage? If we do that, the choices we made show up infullLayout 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 guessxanchor on lines withtextposition='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 toyanchor though, I still don't see a reason to let that be'auto'.

But a little more logic around this perhaps, just for lines: Iftextangle='auto' I would expect the text to be along the line by default, rather than extending off the end. Whereas for any othertextangle 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 updatedxanchor andyanchor defaults so they reflect the following behavior:

• yanchor:
  • Default for lines isbottom
  • Default for all other shapes is such that the label is positionedinside the shape bounding box (e.g. iftextposition istop right,yanchor istop.
  • auto is not a supported value foryanchor
• xanchor default is alwaysauto. This has the following behavior at render:
  • For lines:
    • Iftextangle isauto (parallel to line)xanchor is set so that text is inside the line bounding box
    • Iftextangle 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 positionedinside the shape bounding box (e.g. iftextposition istop right,xanchor isright

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 besidesmiddle center.

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

It looks like we need to haveautodflt andvalue in respect tosrc/components/shapes/defaults.js logic.

@archmoj What would be the use case for anauto value fortextposition?

@archmoj What would be the use case for anauto value fortextposition?

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

Please note that back quotes are used around attribute names not the values.
In all the new documentation, please place values inside* instead.
This line for example would become:

'*top left*, *top center*, *top right*, *middle left*,',