- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jan 2022 00:53:47 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom][css-break] getComputedStyle and fragmentation`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [cssom][css-break] getComputedStyle and fragmentation<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/6513<br> <dael> florian: A while ago looking at def of gCS and it does not mention fragmentation. problem b/c element frag gives multiple answer to value of property. What to do?<br> <dael> florian: GH suggestion which is roughly okay with commentors is other APIs are fragment aware so people who want per frag should use those. This API we should do simpliest with tweak for compat<br> <dael> florian: Simpliest is return first fragment. Might need to tweak based on historic impl. Assuming hoz writing mode, height of the block chrome returns sum, though FF returns first. Probably not compat porblem there, but might have it elsewhere<br> <dael> florian: Suggestion is doc that gCS returns based on first fragment and we document compat issues sep<br> <dael> florian: Suggestion from fremy to make it a little smarter and answer on last for other writing modes. I think I would suggest not taking the suggestion. This will not be smart enough to describe everything so you need frag away APIs<br> <dael> florian: If compat dictates smarter this could be one of the things, but would rather not if we can keep it simple<br> <dael> TabAtkins: I think I agree. Don't think we can get smarter without being complex. Going with simple answer of first frag is easier<br> <dael> iank_: Not wild about first fragment. Larger set of problems about client width and height and how they interact<br> <Rossen_> q?<br> <dael> iank_: In a lot of libraries they compute to witdh and height and used interchangably. Someone using this naively they would get unexpected results when printing. If you sum as I suggest in the issue you get broadly expected<br> <dael> iank_: I don't expect a large compat issue, but it's a little unintuitive<br> <dael> florian: Can we say unless documented we go with first fragment but with block dimensions we sum up. And maybe for padding, border, margin we take last for inline-end and block-end. Maybe that's enough of an excpetion?<br> <dael> iank_: What properties return funcy used? width height padding border margin?<br> <dael> florian: More. Offsets as well<br> <dael> florian: width height margin padding, top left bottom right<br> <Rossen_> q+<br> <dael> florian: Another complication is we're baking selectors that let you style different fragments differntly and then any property could have a different answer. Not exposed, but might be coming<br> <dael> iank_: With that we would start not to return...you can't really...a lot will break if you set different margin-top per fragment. Skeptical we'll need to do something for that case<br> <dael> florian: Even if we don't get that. for margin-bottom return the first, last, depend on box-decoration-break? If compat dictates we should take that<br> <dael> iank_: Rathr then applying general rule would be good to go through cases individually and come up with answers. I suspect I agree with amrgina nd padding for first/last fragment but width and height we want different.<br> <dael> iank_: It would be better to do case by case<br> <astearns> ack Rossen_<br> <dael> Rossen_: I'm more closely aligned with iank_ then the simplicity. Generally I'm all for simplier and more definitive answer. I believe there will be unfortunate compat breakage we'll see for apps building pagination-ish presentations<br> <florian> q+<br> <dael> Rossen_: I've seen a number of apps using multicol to drive book-like experiences. For them, back in the time this is why we into getClientRects and go down patch of fragment aware things. Zooming out, not being able ot know where a box starts which is what you will run into if you only give results on first frag which could give you a result under the 2nd, that would be unfortunate<br> <dael> Rossen_: I'm closer aligned with iank_ 's point<br> <astearns> ack florian<br> <dael> florian: Strongly agree we need something that's fragment aware. But gCS isn't fragment aware. As to breaking interop, we don't have interop.<br> <dael> florian: Another thing I forgot to mention is we don't need to get to fancy APIs to get into troble. We could sum heights, but what to do with width when frag have different width? Or an inline that breaks 2 lines? Block that's across 2 pages? No answer in the spec<br> <dael> florian: We can go property by property as iank_ said. Having done that for height there's no interop<br> <dael> astearns: Not that we break interop but that we break compat. There are likely sites that rely on Blink's behavior. Risk breaking them if we spec differently<br> <dael> florian: But if it's engine specific should we also not change FF?<br> <dael> Rossen_: If they don't have bugs they're either not used for these presentations or they've coded to adapt. I want to udnerscore the point about compat vs interop. I'd be more concerned about compat at this point<br> <dael> astearns: If concerned about compat and there isn't anything that we can spec as safe, perhaps we explicitly say gCS is not frag aware, different enginres return different and we don't spec what to do<br> <dael> florian: Not terribly helpful<br> <dael> astearns: It's not. but going through what to do with every layout property with interesting frag when we can't spec something interop, is that a wild goose chase?<br> <dael> Rossen_: Sounds more academic than applicable. Do we have use cases for alignment? These properties have existed for quite some time so people work around it<br> <dael> florian: Confsed how it can be true simultaniously that this is sufficently used that we can't change but unused that we don't have to answer. If people aren't using this spec simple or say undefined. If it is used would be good to haev a known behavior for interop<br> <dael> smfr: Might have legacy content on each browser relying on the behavior<br> <dael> Rossen_: epub viewers are built against 1 engine and for these apllications they have very specific code with very specific behavior for the engine. Whatever that engine does is what they'll get<br> <dael> florian: Not so sure. Paginators are frequent cross-engine.<br> <dael> iank_: Specific example, a lot of people run chrome in headless to generate pdfs. A lot of people doing that<br> <dael> iank_: To my previous point, only properties we'd use layout dependent is margin, padding, width, height, and the insets<br> <dael> florian: Also borders. Sizes don't change but box-decoration-break might or might not have<br> <dael> florian: But yes, it's those<br> <chrishtr> q+<br> <dael> iank_: I wonder if we can go through these and pick what is reasonable. for example, for the edge type things, border padding margin and insets I'll agree picking first or last will be pretty compat. not huge burden on engines to sum on block and take max on inline<br> <dael> iank_: I think blink and wk do that already. Would be interested to hear for gecko<br> <dael> florian: Not particuarly hard. But in viviostyle there is a measure of lazy rendering for a many 1000 book and having a blocking call that forces you to layout isn't great. Maybe no way around<br> <dael> iank_: I can come up with examples that will render incorrect due to that<br> <dael> florian: Yeah. For block maybe no way around. For inline maybe we can just do first?<br> <dael> iank_: Yeah. I'd like this consistent with client height. A bit of precedence with inline element fragmentation. might be wrong there<br> <astearns> ack chrishtr<br> <dael> chrishtr: No strong opinion, but maybe take this offline for specific proposals?<br> <dael> chrishtr: There is #6588 on the agenda which we need for progress<br> <dael> astearns: Okay, will go back to GH on this issue and get a list of properties we want to consider fully<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6513#issuecomment-1006197072 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 6 January 2022 00:53:49 UTC