TextMetrics baselines may not be compatible with internally-used browser metrics

[litherum]

https://html.spec.whatwg.org/multipage/canvas.html#dom-textmetrics-getbaselines

In WebKit, we synthesize these baselines. I don't think it's clear about whether or not synthesized values should be present in the dictionary (or non-null, if we use that mechanism).

Is this API meant to be compatible with text that the browser draws? Or is it meant to be a faithful as possible to the font file?

Or, are we required to stop synthesizing these baselines in order to implement this API? (Thus potentially changing how the entire Web looks for some users)

If it's meant to be compatible with the text that the browser draws, should baselines present in the font but unused by the browser be present?

@domenic @kojiishi @jfkthame

[annevk]

cc @whatwg/canvas

[litherum]

The answer to this question probably has ramifications on what data structure is used to expose this information. If the API is supposed to be faithful to what the browser uses to draw native text, there will be a set of well-known baselines (perhaps the values for the CSS dominant-baseline property) and these can be attributes in an interface.

However, if the API is supposed to be faithful to whatever the font file happens to have in it, an open dictionary makes more sense, because we don’t want to tie ourselves to a particular font format. This is because the tags used by OpenType are a different set of tags than the ones used by AAT TrueType.