This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27993 - <canvas>: influence of computed style or bidi text direction on CanvasRenderingContext2D text rendering
Summary: <canvas>: influence of computed style or bidi text direction on CanvasRenderi...
Status: RESOLVED WONTFIX
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-10 07:28 UTC by Vivek Galatage
Modified: 2017-07-21 10:47 UTC (History)
5 users (show)

See Also:

Attachments

Description Vivek Galatage 2015-02-10 07:28:38 UTC 
There is a concern on how the directionality should be determined when the 'direction' attribute is not specified on a <canvas> element explicitly. 

The blink implementation determines the direction as:
* If the target object's direction attribute has the value "ltr" 
    Let direction be 'ltr'
* If the target object's direction attribute has the value "rtl" 
    Let direction be 'rtl'
* Update the computed style of the document 
* Run bidi directionality detection algorithm on the given text to compute the direction value

As per the specification [1], neither CSS nor the text being rendered should have any influence on directionality.

In blink, currently this feature is available behind --enable-experimental-canvas-features (can be activated in chrome://flags).
In order to ship the support for 'direction' attribute on a CanvasRenderingContext2D, there is an ongoing discussion [1], for the above concern. 

Which is the correct approach to sync the implementation and the specification?

[1] https://html.spec.whatwg.org/multipage/scripting.html#text-preparation-algorithm
[2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/h7hfD3yOCfA
Comment 1 Philip Jägenstedt 2015-02-10 07:48:12 UTC 
Vivek, do you think what is implemented in Blink is better than what the spec says? The spec seems simpler to me, but I don't know why the Blink code ended up this way.
Comment 2 Vivek Galatage 2015-02-10 09:07:26 UTC 
(In reply to Philip Jägenstedt from comment #1)
> Vivek, do you think what is implemented in Blink is better than what the
> spec says? The spec seems simpler to me, but I don't know why the Blink code
> ended up this way.

IMHO utilizing the bidi directionality based on the input text seems a better approach when the default direction is inherit. If its explicitly mentioned we do override it anyways. This was added here [1] for fixing the measureText on RTL text.

[1] https://code.google.com/p/chromium/issues/detail?id=439850
Comment 3 Philip Jägenstedt 2015-02-10 09:39:14 UTC 
Was the problem with measureText that it didn't match the bounds of what would actually be rendered, or that what was actually rendered looked bad? From http://jsfiddle.net/behdad/cjy5jhby/1/ it looks like it's a mismatch problem, but if the rendering isn't a problem I'm not sure why we need to take CSS into account here.

Using the BiDi algorithm seems sensible, since that's simply a property of the input.
Comment 4 Ian 'Hixie' Hickson 2015-03-04 19:37:26 UTC 
As far as I can tell the spec is very precise about this. I don't understand the issue with what the spec says. Can you elaborate?
Comment 5 Philip Jägenstedt 2015-03-05 05:09:56 UTC 
The spec is clear, I think the problem is that it looks only at the direction attribute. How about falling back to the bidi algorithm?

CC Emil from the Chromium bug.
Comment 6 Ian 'Hixie' Hickson 2015-03-30 20:44:04 UTC 
(In reply to Vivek Galatage from comment #2)
> 
> IMHO utilizing the bidi directionality based on the input text seems a
> better approach when the default direction is inherit. 

Why?
Comment 7 Anne 2017-07-21 10:47:37 UTC 
Please file a new issue at https://github.com/whatwg/html/issues/new if you still think this needs changing.