27359 2014-11-18 14:57:55 +0000 [Shadow]: Need to define interaction with directionality 2015-04-15 05:41:07 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 14978 1 bzbarsky kojiishi felash hayato jackalmage kenjibaheux mike public-webapps public-webapps-bugzilla oldest_to_newest 115056 0 bzbarsky 2014-11-18 14:57:55 +0000 Consider this testcase: <div dir="rtl"></div> <script> var div = document.querySelector("div"); var root = div.createShadowRoot(); root.innerHTML = "<p>aaa</p>"; </script> It seems like in at least Chrome and Firefox the directionality of the inner div is "rtl". But per HTML spec at https://html.spec.whatwg.org/multipage/dom.html#the-directionality in this case the <p> is a "root element" and hence its directionality is expected to be "ltr". It's not clear to me whether we want directionality to leak across the shadow DOM boundary by default or not, by the way, and whether it should be explicitly controllable by the component or not. 115057 1 bzbarsky 2014-11-18 15:04:47 +0000 > It seems like in at least Chrome and Firefox the directionality of the inner > div is "rtl" Based on the rendering, that is. :-moz-dir matching in Firefox thinks it's "ltr", and I'd be interested in other ways of poking at that state in Chrome if there are any. 115065 2 jackalmage 2014-11-18 18:16:32 +0000 I'd base the decision on whether to inherit directionality on whether styles inherit; directionality isn't quite a style (the 'direction' property notwithstanding), but it's similar in effect. 115084 3 hayato 2014-11-19 01:48:52 +0000 The relevant issue: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27222 From the view of the spec, if we are to make 'rtl' *inheritable* across the shadow DOM boundary, we should update the spec, using the term of parent/child relationship in the composed tree (maybe). See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26365#c23 115087 4 bzbarsky 2014-11-19 03:35:06 +0000 This bug has nothing to do with bug 27222. The title behavior (which is purely about event targeting, afaict) and the directionality issue are very different. 115089 5 hayato 2014-11-19 03:45:53 +0000 Yeah, it's not directly related. I just meant that the current spec doesn't provide a good term for handling this kind of 'attribute' inheritance. I agree that each should be handled differently. 115090 6 bzbarsky 2014-11-19 03:59:29 +0000 Ah, there's some interesting subtlety here. There's the inherent element directionality, but also the CSS directionality. They both, separately, inherit. The element directionality can affect the CSS directionality. So it's possible that what's going on in terms of layout in Gecko and Blink is that the CSS directionality inherits. That would explain the layout behavior. But that leaves the question of element directionality open, of course. I'd be interested in a way to directly query that in Blink. 115109 7 hayato 2014-11-19 09:40:24 +0000 (In reply to Boris Zbarsky from comment #6) > Ah, there's some interesting subtlety here. > > There's the inherent element directionality, but also the CSS > directionality. They both, separately, inherit. The element directionality > can affect the CSS directionality. > > So it's possible that what's going on in terms of layout in Gecko and Blink > is that the CSS directionality inherits. That would explain the layout > behavior. But that leaves the question of element directionality open, of > course. I'd be interested in a way to directly query that in Blink. I'm afraid that I don't have any idea how we should resolve this potential conflict situation. That reminds me of the similar issue I've encountered, 'contenteditable' attribute in blink. WebKit has a CSS property that is similar to contentEditable: `-webkit-user-modify`. WebKit/Blink treats contenteditable attribute to something like as if the element had 'user-modify' css property so that contenteditable were processed as if it were css property. To avoid the complex situation, I hope that we should treat both worlds, 'element attribute' and 'css property' in the same way as possible as we can. My initial thought is that we should use a composed tree based tree walking for both worlds, which would explain the layout behavior and match the parent/child relationship which is used by a style inheritance. 115119 8 bzbarsky 2014-11-19 14:34:06 +0000 I don't think there's a conflict at all. What needs to be defined is what happens with HTML directionality. CSS computed "dir" values are already well-defined. > I hope that we should treat both worlds, 'element attribute' and 'css property' > in the same way as possible as we can That's what comment 2 suggested. That makes some sense for the "dir" attribute (but not at all for "title", note). 116561 9 felash 2014-12-19 17:05:46 +0000 Hey, I'm trying to understand how this could work if we don't inherit directionality inside the shadow DOM. How could a component change his internal layout if we don't inherit? If you decide that both use cases can make sense, then maybe we need "something" so that the component author can decide whether his component will inherit directionality. `:root { direction: inherit }` ? 116607 10 hayato 2014-12-20 10:46:35 +0000 Yeah, it'd be nice that component author can have a way to inherit explicitly. However, I'm not sure what is the best solution here yet. You might want to see the discussion on https://www.w3.org/Bugs/Public/show_bug.cgi?id=27222. It'd be nice that we have a general solution for this kind of 'attribute inheritance'. 116636 11 felash 2014-12-22 07:56:01 +0000 It would be simpler if the dir= attribute was expressed in terms of CSS only, at least for agents supporting CSS. 116644 12 bzbarsky 2014-12-22 19:28:45 +0000 It can't be expressed in terms of CSS only, because for example CSS doesn't have an equivalent of the "auto" value. 116646 13 jackalmage 2014-12-22 19:50:56 +0000 And we (the CSSWG) don't really intend to extend it to include that. Directionality is not a matter of style, but of content. It's as much a part of the host document as the text itself is, and belongs in the host document for the same reason. The CSS 'direction' property is a hack, intended solely for use in styling arbitrary host languages that may not have a built-in way to indicate directionality. For HTML it shouldn't really be used, as HTML has such a method - the dir attribute. (Note, for example, that the 'all' shorthand does not expand into 'direction' <http://dev.w3.org/csswg/css-cascade/#all-shorthand>, because 'direction' isn't a styling property in the same way as everything else, it's a host-document property that's encoded in CSS for convenience.) 116875 14 kojiishi 2015-01-07 06:32:45 +0000 (In reply to Boris Zbarsky from comment #6) > Ah, there's some interesting subtlety here. > > There's the inherent element directionality, but also the CSS > directionality. They both, separately, inherit. The element directionality > can affect the CSS directionality. > > So it's possible that what's going on in terms of layout in Gecko and Blink > is that the CSS directionality inherits. That would explain the layout > behavior. But that leaves the question of element directionality open, of > course. I'd be interested in a way to directly query that in Blink. Unfortunately, no, there's no way to directly query that in Blink. I agree with Hayato and Tab that "dir" should be behave the same way as CSS inheritance. The "dir" attribute and CSS unicode-bidi/direction properties work together under the assumption of CSS inheritance works along with DOM tree traversal, so inheriting CSS without inheriting "dir" is likely to cause a problem. Regarding the bug 27222, Hayato and I discussed when the bug came in, and rather than having one bug for each attribute, it must be better to review all attributes and update the spec at once, and then handle whatever we missed if any. Since it wasn't clearly communicated to you all, I've changed the summary of the bug. I can read Hayato and Tab prefer "dir" to be handled the same way as CSS inherits. Are we all in consensus? 117394 15 kojiishi 2015-01-21 16:11:22 +0000 In addition to inheriting "dir" and CSS properties, we'll also need to use the composed tree to "find the first character in tree order". Blink currently: - Inherits dir - Inherits CSS direction and unicode-bidi but: - the behavior around dir=auto is a little flaky around shadow boundaries - does not use the composed tree to "find the first character in tree order" I'll look into these two. 119510 16 hayato 2015-04-15 05:41:07 +0000 I think we can close this issue now. kojiishii@, if you have any remaining issue, please reopen this.