Intent to ship: CanvasRenderingContext2D 'direction' attribute

[Vivek Galatage]

Contact emails

vivek.vg@samsung.com

 

Spec

http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting.html#dom-context-2d-direction

Summary

The attribute, 'direction', represents the text directionality.

This is an important attribute for the bi-directional text within the CanvasRenderingContext2D.

The allowed set of values are 'rtl', 'ltr' and 'inherit'.

This is currently supported behind the ExperimentalCanvasFeatures added in https://codereview.chromium.org/468483003

 

Compatibility Risk

Low.

 

Ongoing technical constraints

None.

 

Will this feature be supported on all five Blink platforms?

Yes.

 

OWP launch tracking bug?

http://code.google.com/p/chromium/issues/detail?id=277209

 

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5100084685438976

 

[PhistucK]

Who else supports this?

☆PhistucK

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

[Philip Jägenstedt]

The CanvasRenderingContext2D::direction() implementation looks wrong to me, as it never returns the default value "inherit" but rather "ltr" or "rtl". Simply returning the current value per spec should also remove the need for updateRenderTreeIfNeeded(), right?

It also looks like the way the attribute value is used isn't quite per spec:
https://html.spec.whatwg.org/multipage/scripting.html#text-preparation-algorithm

That algorithm uses the directionality of the canvas element or document.documentElement, but in CanvasRenderingContext2d.cpp I see use of the canvas element's computed style and the bidi determineDirectionality() algorithm on the text being rendered, which doesn't seem equivalent. I think that per spec neither CSS nor the text being rendered should have any influence. The latter seems a bit odd if true, so perhaps there's a spec bug?

Unless I'm wrong on all points, it would be good to sync the implementation with the spec before shipping.

An example of when you would want to use this attribute would also be useful for those of us who only know LTR languages.

Support in other browsers
You added CanvasRenderingContext2D.direction to WebKit in https://bugs.webkit.org/show_bug.cgi?id=135878 but that doesn't seem to have reached stable Safari yet. Neither Firefox Nightly nor IE11 appears to support it. That seems fine to me.

Philip

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

[Dimitri Glazkov]

Looks like we're waiting on Vivek's response here.

:DG<

[Vivek Galatage]

Hi Philip,

Sorry about the delay in replying as I was on a medical leave. Please find my comments inline.

On Jan 26, 2015 10:40 AM, "Philip Jägenstedt" <phi...@opera.com> wrote:
>
> The CanvasRenderingContext2D::direction() implementation looks wrong to me, as it never returns the default value "inherit" but rather "ltr" or "rtl". Simply returning the current value per spec should also remove the need for updateRenderTreeIfNeeded(), right?
>

Yes you are right. This was done considering the usage of computedStyle and determine directionality.
We need to have a sync between the specification and the implementation.

> It also looks like the way the attribute value is used isn't quite per spec:
> https://html.spec.whatwg.org/multipage/scripting.html#text-preparation-algorithm
>
> That algorithm uses the directionality of the canvas element or document.documentElement, but in CanvasRenderingContext2d.cpp I see use of the canvas element's computed style and the bidi determineDirectionality() algorithm on the text being rendered, which doesn't seem equivalent. I think that per spec neither CSS nor the text being rendered should have any influence. The latter seems a bit odd if true, so perhaps there's a spec bug?
>

I am not sure if the spec having a bug. We should discuss this on whatwg. I will post there soonish.

> Unless I'm wrong on all points, it would be good to sync the implementation with the spec before shipping.
>

Agreed.

[Philip Jägenstedt]

Thanks for the update, Vivek.

It looks like small changes to both spec and implementation will be
needed. If you file a bug at https://whatwg.org/newbug or post to the
WHATWG list, consider pointing out that shipping in Blink is blocked
on resolving the issues so that they don't sit untouched for months.

Philip

[Vivek Galatage]

Raised the bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27993

[Anne van Kesteren]

On Tue, Feb 10, 2015 at 8:34 AM, Vivek Galatage <viv...@chromium.org> wrote:
> Raised the bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27993

Sorry for reviving such an old thread, but I was wondering if someone
could update the bug with the current status. Last comment was asking
for justification a little less than a year ago.


--
https://annevankesteren.nl/