27993 2015-02-10 07:28:38 +0000 <canvas>: influence of computed style or bidi text direction on CanvasRenderingContext2D text rendering 2017-07-21 10:47:37 +0000 1 1 1 Unclassified WHATWG HTML unspecified All All RESOLVED WONTFIX P3 normal Unsorted 1 vivekg ian annevk eae ian mike philipj contributor oldest_to_newest 117787 0 vivekg 2015-02-10 07:28:38 +0000 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 117788 1 philipj 2015-02-10 07:48:12 +0000 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. 117794 2 vivekg 2015-02-10 09:07:26 +0000 (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 117796 3 philipj 2015-02-10 09:39:14 +0000 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. 118298 4 ian 2015-03-04 19:37:26 +0000 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? 118339 5 philipj 2015-03-05 05:09:56 +0000 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. 119082 6 ian 2015-03-30 20:44:04 +0000 (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? 128748 7 annevk 2017-07-21 10:47:37 +0000 Please file a new issue at https://github.com/whatwg/html/issues/new if you still think this needs changing.