- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Apr 2017 08:18:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed , and agreed to the following resolutions: ``` RESOLVED: WONTFIX this level, explain why ``` ``` RESOLVED: Update WD of css-contain with edits for issues we resolved today ``` <details><summary>The full IRC log of that discussion</summary> ``` <Florian> topic: <Florian> https://github.com/w3c/csswg-drafts/issues/1043 <Florian> github topic: https://github.com/w3c/csswg-drafts/issues/1043 <fantasai> Florian: Probably better in 1D context, but still applies to 2D <fantasai> Florian: Imagine you have long FB page, infinite scroller, 37 screns down <fantasai> Florian: because everything is dynamic, ppl will update stories above where you are, which will change your size, which will make you scroll <fantasai> Florian: Things that are off-screen should have their size frozen, and when they enter the screen you should unfreeze them <fantasai> Florian: So want a variant of size containment that only applies offscreen <fantasai> Florian: And then when you scroll in it solves <fantasai> plinss: Sounds like a giant hack that should be solved by scroll anchroing <fantasai> iank_: FB can also use intersection observer to do this <fantasai> Florian: That ends up being just slow enough that they do resizing on-screen (rather than just off-screen) <fantasai> Florian: My take is that once we get scroll anchoring a large part will be solved, combine with fact that you can do manual freezing if you want <fantasai> Florian: But I think this is not something to solve with magic freezing and unfreezing <fantasai> fantasai: I agree with the last statement <fantasai> flackr: If you were to drag the scrollbar, we will rpobably put up a frame before we run any script in response to the scroll position, so you will see unresized content <fantasai> Florian: which is why I'd suggest there was some UI indication (like graing out) that indicates out-of-date-ness <fantasai> Florian: Not as good as magic, but dunno how to make that happen <fantasai> Florian: So proposed wontfix <fantasai> astearns: Objections? <fantasai> iank_: We should also said that we'll keep use case in mind for future stuff <fantasai> TabAtkins: But right now solution is use JS intersection observer <fantasai> Florian: And various upcoming feaures will make it better (though not perfect) soon <fantasai> astearns: Can someone add a comment summarizing these conclusions? <fantasai> RESOLVED: WONTFIX this level, explain why <fantasai> Florian: That takes us to zero open issues on css-contain <fantasai> Florian: Modulo DoC, go to CR? <fantasai> ChrisL: Changes section? <fantasai> Florian: No, should I do that first? <fantasai> ChrisL: If you can do it in a rasonable time. Just want to avoid "CR pending edits" which takes 9 months <fantasai> tantek: Could update a WD now, and the resolve on CR once you have DoC <fantasai> Florian: Question about DoC... <fantasai> Florian: Not much happened between FPWD and now, do we need a DoC covering comments from earlier <fantasai> ChrisL: Assumption in the Process is that FPWD is actually the first *public* working draft <fantasai> Florian: okay, I'll do DoC over old issues <fantasai> tantek: Is that needed? <fantasai> Florian: need to demonstrate wide review <fantasai> ChrisL: We also need to show usual sec/a11y/i18n reviews <fantasai> Florian: Will show non-tivial DoC, not necessarily comprehensive to first ED <fantasai> RESOLVED: Update WD of css-contain with edits for issues we resolved today ``` </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1043#issuecomment-295157661 using your GitHub account
Received on Wednesday, 19 April 2017 08:18:45 UTC