Expected behaviour when using measureText on input with leading/trailing whitespace

[rwlbuis]

What is the issue with the HTML Standard?

I wonder what the behaviour should be for measureText on leading/trailing whitespace on actualBoundingBoxLeft/actualBoundingBoxRight:

1. tm = ctx.measureText("D");
2. tm = ctx.measureText("D ");

In Chrome and gecko the values would be the same for 1) and 2), whereas right now WebKit would have actualBoundingBoxRight be larger in 2) than 1), accounting for the trailing whitespace.

I personally think discarding the leading/trailing whitespace makes sense, but I wonder if all implementations agree and whether the canvas specification text is clear enough in this regard.

[rwlbuis]

Note that I added tests for this in:
html/canvas/element/text/2d.text.measure.actualBoundingBox.whitespace.html

[annevk]

cc @whatwg/canvas

[annevk]

I had a look at the specification and it seems to suggest that white-space is set to pre so I think WebKit is correct here. The only somewhat ambiguous whitespace processing is this step:

Replace all ASCII whitespace in text with U+0020 SPACE characters.

But that does not trim leading or trailing ASCII whitespace (and does not touch non-ASCII whitespace).

I'm not sure what the intent for that step was exactly, especially when combined withwhite-space: pre. Avoiding newlines I suppose? But should \r\n become two spaces or one? (This text dates back to 97c4d63 and appears to have not been questioned since.)

[Kaiido]

It's not entirely my area of expertise, but it seems to me the actualBoudingBox[Left|Right] properties are supposed to read the rendered glyphs xMin and xMax values. In most fonts these are undefined for U+0020 so it makes sense leading and trailing spaces aren't part of the bounding box.
Every browser agrees that they are part of the advance width however, the one reported by TextMetrics.width, since they do have an advanceWidth defined.

In this fiddle I created a small font where the glyph for U+0020 has an actual box defined, and we can see that neither Chrome nor Firefox do trim the input.

As for the \r\n case it seems all do agree it should become two spaces: https://jsfiddle.net/4wm8defc/