This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
> 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.
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.
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
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.
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.
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.
(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.
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).
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 }` ?
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'.
It would be simpler if the dir= attribute was expressed in terms of CSS only, at least for agents supporting CSS.
It can't be expressed in terms of CSS only, because for example CSS doesn't have an equivalent of the "auto" value.
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.)
(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?
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.
I think we can close this issue now. kojiishii@, if you have any remaining issue, please reopen this.