Context
Follow-up from #2, which made bare literals on the pure positional aesthetics (x, y, xend, yend, xmin, xmax, ymin, ymax) train the position scale instead of being dropped as style params.
That fix deliberately left width (and any future height) out of scope.
Current behaviour
mark_bar(width = 0.5) flows through params, and the emitter reads it via a %||% band fallback (e.g. w <- rep_len(L$values$width %||% band, n) in .emit_*). So a constant width works today, but through a different path than the coordinate channels — it does not go through values/scale training.
Question to decide
Should width/height constants be unified with the positional-literal path (.POSITION_AES), or is the current params + %||% band fallback the intended design?
Not a bug — tracking so the inconsistency isn't forgotten.
Context
Follow-up from #2, which made bare literals on the pure positional aesthetics (
x,y,xend,yend,xmin,xmax,ymin,ymax) train the position scale instead of being dropped as style params.That fix deliberately left
width(and any futureheight) out of scope.Current behaviour
mark_bar(width = 0.5)flows throughparams, and the emitter reads it via a%||% bandfallback (e.g.w <- rep_len(L$values$width %||% band, n)in.emit_*). So a constantwidthworks today, but through a different path than the coordinate channels — it does not go throughvalues/scale training.Question to decide
Should
width/heightconstants be unified with the positional-literal path (.POSITION_AES), or is the currentparams+%||% bandfallback the intended design?Not a bug — tracking so the inconsistency isn't forgotten.