I’m using the selectedItem.moveInParentCoordinates() and when I pass in fractional values they are being rounded to whole pixels. The API says they are numbers.
Example:
var selectedItem = selection.items[0];
selectedItem.moveInParentCoordinates(10.234, 10.3);
Position is set to 10.234 x 10.3
Position is set to 10, 10
Unfortunately, anything not supported on the XD side is also not supported on the extensibility side.
Curious what the use case here is for fractional positions? Usually you want to be aligned to a pixel boundary so that any exported and rendered results are sharp rather than blurry.
I can give you a few reasons.
My first use case was when I was creating a close icon where you have an X inside of a circle. The icon was a total of 16 pixels. When I drew the lines they were not perfectly centered. But interestingly they were already positioned at half pixel positions.
When I used the center alignment tool and the center command I noticed it was not accepting half pixel values but I could set the position with fractions through the properties panel. If you use the line tool now you’ll see it positions on fractional points.
You also have the option to set the position of the stroke (inner, outer or center) so you won’t avoid sub pixel values or positioning.
With hi dpi devices sub pixel values are not blurry anymore since on 2x devices there are 2 dots for 1 pixel (144 / 72). So .5 value lands on one of those pixels.
Finally, if a graphic is on a half pixel when exporting renditions and scaling up the graphic will be placed accurately on full pixel.
The example code you gave works fine for me – do you have a more specific example that demonstrates the problem?
The properties panel in XD will round X/Y/W/H values to the nearest 100th, so in the UI you’ll only see 10.23 instead of the full 10.234 – but the value is there in the scenegraph and it is taken into account by the renderer.
@kerrishotts – there are other use cases for fractional pixels too. E.g. if you’re working with centered strokes whose weight is an odd number, it’s actually more correct to have coordinates ending in 0.5 than to be integers, if you want the strokes to align crisply with the pixel grid. And for bezier paths, the coordinates of anchor points and control points can be all over the place since curves aren’t really pixel-aligned at all anyway. (I’ve been meaning for a while now to write up docs or a blog about how pixel-aligned != integers, since this is a question we get often… maybe some day 
).
+1 for a write up on this. 
@Velara revisiting this topic, we are unable to replicate this behavior. Do you have an example document where you see the fractional values are not respected when move APIs are used?