Fundamentally these seem like reasonable things for measureText to return.

While I'm not sure feedback here is the best way to get issues back to the editors, a few comments/questions:

• how do actualBoundingBoxLeft and actualBoundingBoxRight deal with vertical text? (Even if the answer is "this API doesn't currently support vertical text" (which seems to be the case since CanvasTextDrawingStyles has direction but not writingMode)... the names seem bad for when it's likely to be extended to do so in the future.)
• how do the definitions of "positive numbers" for all the *Ascent and *Descent values deal with vertical text?
• there are multiple references to a "line box", yet I don't see anything that says what this line box is. Do these mean "inline box" instead?
• it seems like hangingBaseline, alphabeticBaseline, and ideographicBaseline should define the behavior when multiple fonts are present. Is it the first available font what should be used?
• the API methods don't say anything about what rounding is performed. Is the expectation that the results be round numbers of CSS pixels, round numbers of device pixels, or unrounded?
• all of the "positive numbers indicating that the given baseline is (below/above) the X" seem confusing to me, and seem like they'd be clearer if they were swapped to "positive numbers indicating that X is (above/below) the given baseline" (note that the order is swapped and the above/below are swapped so that the statement is still true). That's probably just preference, though. (But it does make them more consistent with the preceding 4 definitions.)
• the definitions of emHeightAscent and emHeightDescent should probably have wording that repeats the "of all the fonts used to render the text" used in defining fontBoundingBoxAscent etc., assuming that is what is intended (which I think it is given the "highest top" and "lowest bottom" wording); otherwise it's not clear what it's the "highest" or "lowest" of. (For example, it's important that it's all fonts used to render the actual text rather than all fonts that could have been used given any possible text.)
• the "half the font size if the given baseline is the middle of that em square" comment only seems true if there's only a single font or if the em squares of all fonts used line up (at least assuming my previous assumption was correct)

At first glance it looks like some useful metrics are missing, specifically ex height and cap height (also mathematical baseline?).

My primary concern here is coordination with the Houdini Font Metrics API, first that I don't want to have multiple (and different) ways of getting font metric data, second that the Houdini Font Metrics API work seems to have stalled. One of the issues there was discovering that the problem was more complex than originally thought and a lack of relevant expertise.

We do need a good font metrics API for the platform and I'm glad to see this is getting worked on.

Last week we left this open so that I could file issues against HTML for the feedback above; I was hoping to do that for this week, but didn't.

Note that @domenic and I reverted the changes made to HTML for now, due to implementer and internationalization feedback (linked from the commit message): https://github.com/whatwg/html/commit/31c0db30a74534f56359e4187d32e824f7d5d9f6. There might not be much overlap with your comments though and it's definitely still worth it to raise them as this feature will be further developed.

I think what I reviewed was actually post-revert. I'll file some issues, though.

The 4 issues I filed above cover all of the points in my https://github.com/w3ctag/design-reviews/issues/302#issuecomment-422999075 . Perhaps @plinss wants to file issues on his comment following it?

Tagging for discussion at Paris f2f to figure out what remains before the TAG closes this issue.

We discussed briefly in today's TAG meeting -- given that (a) the spec changes got reverted and (b) I filed some feedback anyway, we don't think there needs to be more happening in this review right now.

That said, we're interested in:

• progress on the above filed issues against HTML
• future work related to re-making the original changes, Houdini work in this space, and the relation between them.

So if there is future work in that area, we'd be interested in seeing another review request... ideally pointing back to this one so we don't lose all the context (although hopefully we'd be able to find it ourselves).

Thanks for reaching out to the TAG for review.