Intent to Ship: Full TextMetrics object

[Alexis Hétu]

Contact emails

su...@google.com

Spec

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-measuretext

Summary

Currently, the TextMetrics object returned by the measureText() method only contains the "width" measurement. This change will add all other measurements mentioned in the spec. This change does not add any new methods or classes, it only adds more members to the TextMetric structure. The change is fairly small and straightforward, so I made a sample implementation which is available here:

https://codereview.chromium.org/141433026/

Compatibility Risk

This change should work wherever measureText() already worked prior to this change. No new platform dependent code will be added.

OWP launch tracking bug?

crbug.com/277215

Link to entry on the feature dashboard

This change is very small, so an entry has not yet been created in the Chromium Dashboard.

[Eric Seidel]

Do any other engines ship this? Are you working with a customer? I
can forsee this being very useful for the Web, but someone actually
using our implemented-behind-a-flag version first tends to shake out
more bugs than any spec-work or list-discussion can. :)

LGTM to Implement, but I'd rather we put this behind a flag for a
while first if no one else is shipping it yet.

[Alexis Hétu]

I'm not currently working with a customer and AFAIK, we'd be the first to ship this, so a behind a flag version could be created at first.

[Eric Seidel]

http://www.chromium.org/blink/runtime-enabled-features should give you
the information you need. If it gives you any trouble, let me know.

Once you update your patch to be runtime-guarded, then I'll happily
LGTM it (or anyone else can).

[Rik Cabanier]

On Tue, Feb 18, 2014 at 10:28 AM, Alexis Hétu <su...@google.com> wrote:

I'm not currently working with a customer and AFAIK, we'd be the first to ship this, so a behind a flag version could be created at first.

When this API was first introduced, Alan Stearns had some concerns about the API. His questions were never addressed so in response to your intent to implement, he opened 2 bugs:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24717

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24723

Since you are the first one to ship this, you can help fix the spec (since implementing it gives you good insight into the feature) and land this very useful feature.

At the last SVG F2F, some people found it unfortunate that this method is on a canvas object. They thought it was an API that was generally useful and it was a bit strange that you need to create a canvas context.

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

On Tue, Feb 18, 2014 at 8:17 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Tue, Feb 18, 2014 at 10:28 AM, Alexis Hétu <su...@google.com> wrote:

I'm not currently working with a customer and AFAIK, we'd be the first to ship this, so a behind a flag version could be created at first.

When this API was first introduced, Alan Stearns had some concerns about the API. His questions were never addressed so in response to your intent to implement, he opened 2 bugs:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24717

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24723

Since you are the first one to ship this, you can help fix the spec (since implementing it gives you good insight into the feature) and land this very useful feature.

At the last SVG F2F, some people found it unfortunate that this method is on a canvas object. They thought it was an API that was generally useful and it was a bit strange that you need to create a canvas context.

I agree with this in general but don't see harm in adding it to canvas contexts first. We can extract/expand a more general API out of it over time.

[Elliott Sprehn]

On Tue, Feb 18, 2014 at 8:32 PM, Alex Russell <sligh...@google.com> wrote:

On Tue, Feb 18, 2014 at 8:17 PM, Rik Cabanier <caba...@gmail.com> wrote:

On Tue, Feb 18, 2014 at 10:28 AM, Alexis Hétu <su...@google.com> wrote:

I'm not currently working with a customer and AFAIK, we'd be the first to ship this, so a behind a flag version could be created at first.

When this API was first introduced, Alan Stearns had some concerns about the API. His questions were never addressed so in response to your intent to implement, he opened 2 bugs:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24717

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24723

Since you are the first one to ship this, you can help fix the spec (since implementing it gives you good insight into the feature) and land this very useful feature.

At the last SVG F2F, some people found it unfortunate that this method is on a canvas object. They thought it was an API that was generally useful and it was a bit strange that you need to create a canvas context.

I agree with this in general but don't see harm in adding it to canvas contexts first. We can extract/expand a more general API out of it over time.

I agree, this gets us one step closer to explaining the text measurement that goes on inside layout and makes it easier for developers to measure text without stuffing a span into the document to call getClientRects() and then remove it.

- E

[Alex Russell]

Also, LGTM. Apologies for omitting that from my previous message.

[Rik Cabanier]

On Tue, Feb 18, 2014 at 8:56 PM, Alex Russell <sligh...@google.com> wrote:

Also, LGTM. Apologies for omitting that from my previous message.

That's to implement, correct? (Title indicates shipping)

Not being an owner, fwiw it's LGTM for me as well.

[Alexis Hétu]

Yes, no worries, it will be put behind a flag for now.

[Eric Seidel]

To close this thread, it was resolved to implement at this time and
re-raise for shipping at a later date.

[Alexis Hétu]

Hi all,

  Sorry for simply reviving this dead thread 3 months later, but since it's already appropriately titled, all the information is in it, and since all the appropriate people are in it also, I was wondering if you guys thought it was okay to actually ship this feature now (just remove it from the experimental canvas features and make it available by default).

  Now, in 3 months, I haven't received any issues/problems related to this, which could indicate that it's not really been used much (I don't know how much coverage we usually get from our experimental canvas features). I'll let you guys decide if it's time to ship this or not.

Thanks

Alexis

[Alexis Hétu]

Friendly ping.

I haven't heard back from anyone yet. If you prefer that I start a new thread rather than reusing this old one, I can do that, no problem, but I would like the have the owners' opinion on this.

Thanks

Alexis

[Eric Seidel]

Do you have a customer?  What factors help us believe we've found the right api? (Not doubting we have, just seeking to understand.)

[Alexis Hétu]

I don't have a customer, but apparently, some people did notice the new feature:

http://www.rgraph.net/blog/2014/march/new-text-metrics-for-canvas.html

A sample use case provided by the spec is that this feature would be "useful when drawing a bounding box around specific text". This is basically providing a way to do manual text decorations.

Now, about the API, I can see that it can be very useful to have all the font metrics in the same object from an ECMAScript/Javascript developer's standpoint, the only thing I see that you could find debatable is that both metrics that are computed from a given string and metrics that are constant for the given font are in the same object. This is how the spec was made and I still think it's ok, but whether or not this is an issue is for you guys to decide.

Thanks

[Bem Jones-Bey]

I don't know if this is the right API in the grand scheme of things, but it looks like it could be used to implement a polyfill for CSS Line Grid (http://dev.w3.org/csswg/css-line-grid/). The general concept of aligning to a baseline grid is used around the web, but people usually just use line height as an approximation because it is hard to get proper font metrics in JS.

[Ian Hickson]

On Wed, 28 May 2014, 'Alexis Hétu' via blink-dev wrote:
>
> Now, about the API, I can see that it can be very useful to have all the
> font metrics in the same object from an ECMAScript/Javascript
> developer's standpoint, the only thing I see that you could find
> debatable is that both metrics that are computed from a given string and
> metrics that are constant for the given font are in the same object.
> This is how the spec was made and I still think it's ok, but whether or
> not this is an issue is for you guys to decide.

The precise contents of the string decides what fonts are used, so
actually all the metrics depend on the string.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

[Alan Stearns]

We're currently working on some JavaScript that would correctly align and size a drop cap as in http://dev.w3.org/csswg/css-inline/#Initial

The baseline metrics in this API are required to make the script really bulletproof, but we'd also need to get the cap height (I'm assuming emHeightAscent gives you the ascent, which varies a bit from cap height depending on the font)