writing-mode propagation from body to document element is annoying #4357
Comments
|
cc @jfkthame too |
|
So talked offline with @frivoal and noticed that Gecko does some (code) of the propagation to the viewport, kinda, only for scrollbar directionality. This was introduced by @dbaron in bug 192767. So I guess the constraints are:
Both current Gecko behavior and the resolution in #3066 achieve (1) and (3). So if any of those are implementable by other engines I'm fine with either (not terribly happy about #3066, but...). Gecko can also pretty easily I'd think just propagate the whole writing-mode to the viewport. That gives us (1) and (2) but not (3). |
|
The Gecko code is pretty weird, too, it looks at the body even if the scrollbars come from the |
|
Similar to |
|
Direction and overflow are not propagated to the root. Overflow is only propagated to the viewport, and direction in Gecko isn't propagated at all as far as I can tell, modulo the quirk I described above about scrollbar directionality. |
|
Ugh, old habits - we have an element (hidden) for the viewport that we call "Root" in IE/Edge... hence I was confirming our behavior that matches Blink/Webkit and achieves 1 and 2 but not 3. I'll try to see what an implementation in Blink looks like before dismissing the possibility of it being landed there. |
|
Reworded the title (s/root/document element/) to avoid confusion. |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: propagation from body to document element is annoying<dael> github: https://github.com//issues/4357 <dael> Rossen_: dbaron do you want to talk now or wait for emilio next week? <dael> Rossen_: I'm happy to defer <dael> dbaron: I think better to defer to next week with emilio <dael> Rossen_: One thing I would point out is we're in PR and he's raising issue against PR <dbaron> unless heycam or dholbert want to cover it <dael> florian: One brief comment for everyone else to prepare, this is how we prop. writing modes and related properties up. Changed it recently and it's either impl or on its was to impl in Gecko. emilio thinks Gecko can do but he's skeptical other browsers will do it <dael> florian: Please do some reflection. If we resolved against what people want to do that's annoying. For next time please not-Mozilla people know if you have intention of implementing |
|
Blink is storing the writing-mode on its ComputedStyle. We discussed this in a Taxi in Fukuoka, and I think a feasible solution (avoiding a lot of if-branching in the code) was to add a used writing-mode value to the ComputedStyle object which would have the same value as the computed value in all cases but for the root element in the case where writing-mode for body differs from the root element. After updating styles for body, we would check if the body and root element differ in their computed styles, and if so clone the root ComputedStyle and set the used writing-mode to that of the body. It doesn't sound all that crazy, but not all that great either. |
|
For what is worth, Gecko's used |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: propagation from body to document element is annoying<dael> github: https://github.com//issues/4357 <dael> emilio: We resolved hesitantly on prop. the used writing mode from body to document element and to viewport I assume <dael> emilio: We have an impl but afaict other engines are not ready to impl since don't store value in layout tree <dael> emilio: Resolution is hacky to impl. <dael> emilio: Should we implement this? Do what other engine impl which is just prop to viewport? And tell people if they want orthogonal set on document element <dael> florian: Discussion on GH is this looks hacky but doable in Blink as well. Given we resolved there is some willingness to do this. If not, I wonder why we resolved. We can reopen but it's unplesent. If can do in blink and FF and we're moving the spec forward and it's nicest for author I would hope keep as is <dael> florian: If people not going to do it you're right it's not helpful for spec to say one thing and do another <dael> emilio: This is only thing that prop to document element, right? <dael> florian: propagation on other things is a bit complicated but less so. Only thing that propagates in this way <dael> emilio: AS gecko dev I'm not in lovewith hack. Easier to propagate to viewport. Happy to impl if other engines will do it <dael> fantasai: In WM we wanted ot make sure it's prop in same way as direction. Means spec was not quite correct in way direction prop. <dael> fantasai: Adding writing modes and direction need to prop together. Iunderstand how hacky it is, Blink solution sounds pretty crazy. I think prop was a mistake, but it happens so have to address. Doens't have to be perfect. <dael> emilio: Direction in gecko does not prop at all, only have hack for scrollbar directionality and that would not be needed if both prop to viewport <dael> emilio: Blink prop to the viewport is to fix the same case and the hack for look up body style from scrollbox is doing. <dael> emilio: Intent is same, behavior is different as is impl complexity <dael> florian: Would like to hear from blink. WE can investigate ideal. It's hacky but doable in gecko. If blink will do we don'th ave to revist. We have discussed preferable behavior. <dael> emilio: But it was on assumption direction was prop somehow. But in blinka nd webkit it is prop with writing mode to viewport. In gecko there'sno prop, just lookup a box for this style <dael> florian: I suspect that's if you fix bugs related to printing you'll have to do it there as well. <dael> emilio: Sure, but scrollbar position....that also works if you prop writing mode to viewport <dael> florian: Direction only not prop to document element is fine. But direction if you don't go through element you create horizontal flow and tha'ts not nice. Ideally for authors we prop the whole thing properly. If can't do that there are intermediate solutions. <dael> fantasai: I think important point that page progression direction and frag direction needs to be consistant with how modify scrollers. That doens't require us to change the root element <dael> fantasai: Means content will overflow root, but in a direction we've choosen. Similar to how the root element in the scrolling case doesn't grow to accomodate the content. Solveable but important to solve <dael> florian: If we jsut prop to viewport it's workable but less nice for authors <dael> Rossen_: That solution will be commonly hit by authors bc most tools set direction on body rather than root element <dael> Rossen_: When orginally disc I was in full support as documented in spec and that's the behavior in Edge where we prop from body to root and all the way to viewport. Allows us to avoid all these corner cases of root element and body element differing by writing mode and causing scrollbars <dael> Rossen_: Unless explicitly set rules elsewhere that set different writing modes explicitly <dael> Rossen_: In our impl it wasn't crazy to impl given we're kinda sorta doing it in overflow. I looked at blink and what I desc is impl there. I don't know if we have resources right now, but wouldn't be opposed to giving that a go and having better results for authors as we have desc <dael> Rossen_: Doens't mean I'm saying I'll def land it in blink, saying not opposed to landing. <dael> Rossen_: Looking at rune's comments on GH he's not crazy about it but doens't sound against. Don't want to speak for him/chrome, but looking through what's needed and what we spec that matches what as an author I would expect to see happen <dael> emilio: I'm okay closing no change if this is eventually impl interop <dael> astearns: sounds to me that yes impl is hacky but people are willing to change. Given author benefit I think we close no change and wait on impl <dael> astearns: Objections? <dael> RESOLVED: Close this issue no change <dael> astearns: Thanks emilio for bringing this up |
|
Found a more sensible way of doing it in Blink. Taking a stab at it now. |
|
Landed on Chromium master. The change made these tests pass: css/css-writing-modes/wm-propagation-002.html I had to modify these tests (upstreamed to wpt) which were relying on the direction being different on the html and body elements: css/css-writing-modes/normal-flow-overconstrained-vlr-005.xht |
|
Fixes in Blink and Gecko have landed. Thanks to all involved. Closing. |
So in #3066 we resolved (hesitantly) that we'd propagate the
writing-modefrom the<body>element to the<html>element, at used value time.As far as I can tell, WebKit and Blink propagate the writing-mode to the viewport, but not to the root, and the actual propagation to the root would be hard for them to implement it.
@aethanyc has an implementation of this in Firefox (https://phabricator.services.mozilla.com/D45481, https://bugzilla.mozilla.org/show_bug.cgi?id=1102175).
Handling correctly the edge cases like:
<body>element before the existing primary body.<body>element.<html>element, if it hasdisplay: table, for example.Takes quite a bit of pretty unfortunate special-casing that in my (personal) opinion is not worth it.
Given that that resolution doesn't point to a clear path path to interop (since WebKit / Blink are quite unlikely to adopt it from what I can tell, since they don't store the writing mode separately from the style), can we instead not do any propagation (i.e., do what Gecko does right now), and maybe add warnings to the console when the
<body>s writing-mode / direction / text-orientation differs from the<html>?The text was updated successfully, but these errors were encountered: