Re: [csswg-drafts] writing-mode propagation from body to document element is annoying (#4357)

The CSS Working Group just discussed `propagation from body to document element is annoying`, and agreed to the following:

* `RESOLVED: Close this issue no change`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: propagation from body to document element is annoying<br>
&lt;dael> github:<br>
&lt;dael> emilio: We resolved hesitantly on prop. the used writing mode from body to document element and to viewport I assume<br>
&lt;dael> emilio: We have an impl but afaict other engines are not ready to impl since don't store value in layout tree<br>
&lt;dael> emilio: Resolution is hacky to impl.<br>
&lt;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<br>
&lt;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<br>
&lt;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<br>
&lt;dael> emilio: This is only thing that prop to document element, right?<br>
&lt;dael> florian: propagation on other things is a bit complicated but less so. Only thing that propagates in this way<br>
&lt;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<br>
&lt;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.<br>
&lt;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.<br>
&lt;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<br>
&lt;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.<br>
&lt;dael> emilio: Intent is same, behavior is different as is impl complexity<br>
&lt;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.<br>
&lt;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<br>
&lt;dael> florian: I suspect that's if you fix bugs related to printing you'll have to do it there as well.<br>
&lt;dael> emilio: Sure, but scrollbar position....that also works if you prop writing mode to viewport<br>
&lt;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.<br>
&lt;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<br>
&lt;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<br>
&lt;dael> florian: If we jsut prop to viewport it's workable but less nice for authors<br>
&lt;dael> Rossen_: That solution will be commonly hit by authors bc most tools set direction on body rather than root element<br>
&lt;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<br>
&lt;dael> Rossen_: Unless explicitly set rules elsewhere that set different writing modes explicitly<br>
&lt;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<br>
&lt;dael> Rossen_: Doens't mean I'm saying I'll def land it in blink, saying not opposed to landing.<br>
&lt;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<br>
&lt;dael> emilio: I'm okay closing no change if this is eventually impl interop<br>
&lt;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<br>
&lt;dael> astearns: Objections?<br>
&lt;dael> RESOLVED: Close this issue no change<br>
&lt;dael> astearns: Thanks emilio for bringing this up<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 9 October 2019 16:18:21 UTC