Join GitHub today
Recent TextMetrics baseline changes may have jumped the gun #3995
#3931 removed the attributes
At the time we merged this, I did not realize that Safari had already shipped the previous properties to their stable channel. (I thought this was part of the still-evolving new-ish canvas APIs which nobody had yet shipped.) As such, I don't think landing that pull request without Safari's participation was the right thing to do.
Which are reasonable arguments for this change. But I don't think we fully considered all the options. To my mind our options are:
We chose option (3), but I want to make sure that implementers are on board with that choice---in particular Safari, since they already ship the old API.
Of note, if we choose (2), the current blink-dev intent to ship should be put on hold. So if someone prefers that option we should say so ASAP.
We don't set the metrics from the font:
So I'm not sure who is actually relying on this data.
It's a good idea to make these values optional.
Does anyone have data on whether existing content makes use of either API?
I think we have an implementation of the various baselines for completeness rather than because of any specific demand, so we are likely mostly indifferent to the shape of the API, unless there is important content depending on it. I am not aware of any.
In general, it seems to me that a possibly-null property is a more elegant way to represent optionality than a get method returning a dictionary. Dictionaries seem better used in the case where the set of optional values is large or open-ended, or as parameters to methods to avoid the need for null placeholders. In a case like this, it makes access less convenient and less efficient. That said, I am not sure what the precedent is for this sort of thing in other web APIs, and it seems reasonable to follow the normal precedent.
The CSS Houdini API is still under heavy discussion, and I didn't see strong arguments there against this. The argument as I remember was that most of those values are unused/unavailable.
I don't mind using null instead of the dictionary. I agree with @othermaciej's and @annevk's argument. It addresses the compatibility issue with the already launched version, and it's easier to access.
But just for the record, let's clarify that we are doing this understanding that some of those baselines are rarely/never available. But since they are limited in number, having those null values hanging there is a good tradeoff.
In the interest of bringing up possible future changes, would it be possible to expand the scope of this to more than just Canvases; for example SVG, or even plain HTML text? It also feels like there could be some integration with the Font Loading API. If these changes sound reasonable I thought it would be good to start thinking about them now before it gets even more set in stone.
added a commit
Sep 14, 2018
referenced this issue
Sep 14, 2018
I've opened #4037 to revert #3931 for now. I'm glad that we've got such a detailed and spirited discussion going around how to create a better spec for these APIs, and I'm sorry that we editors didn't do our part in appropriately fostering that discussion before merging the PR.
It looks like there are a lot of threads already listing issues we'd need to resolve before reintroducing the API changes there: #3994, #4023, #4030, #4033, #4034. When the revert PR (#4037) is merged, this issue will close, so let's be sure to migrate any additional concerns and proposals from this thread into their own dedicated issues. From my understanding those would be:
Thanks all, and apologies again for the premature merging.