13:56:55 RRSAgent has joined #css 13:56:55 logging to https://www.w3.org/2021/04/06-css-irc 13:56:57 RRSAgent, make logs Public 13:56:58 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 13:57:55 jensimmons has joined #css 13:57:58 GameMaker has joined #css 14:00:05 fremy has joined #css 14:00:13 present+ 14:00:20 jfkthame has joined #css 14:00:28 present+ 14:02:00 present+ 14:02:10 alisonmaher has joined #css 14:02:29 Present 14:02:32 present+ 14:02:47 present+ 14:02:53 present+ 14:02:54 present+ 14:03:10 Morgan has joined #css 14:03:13 present+ 14:03:14 present+ 14:03:18 present+ 14:03:22 present+ 14:03:28 present+ 14:03:53 futhark has joined #css 14:04:15 present+ 14:04:41 ScribeNick: fremy 14:04:43 myles has joined #css 14:04:57 Loving the project boards! 14:04:59 present+ myles 14:05:36 present+ 14:05:43 astearns: we are skipping introductions today, because it seems the people are about the same as the last time 14:05:56 present+ 14:06:01 astearns: if people have comments about the order, now is the time 14:06:23 Topic: [css-fonts] Computed value of font stretch 14:06:35 github: https://github.com/w3c/csswg-drafts/issues/6171 14:07:16 emilio: the spec has a note that says that for compat reasons, computation of font-stretch should stay a keyword if it was one, instead of the percentage 14:07:22 emilio: webkit doesn't do that 14:07:37 emilio: tests either require one or the other, there is no concensus 14:07:48 emilio: I would like to remove this note 14:08:00 myles: there is no known issue I was working around 14:08:15 dbaron: usually, we try to stick to the most compatible representation for compat 14:08:39 emilio: returning the keyword makes it difficult for authors because they need to reverse compute the keywords 14:08:50 emilio: font-3 used to report the keyword all the times 14:08:52 jensimmons has joined #css 14:08:55 jensimmo_ has joined #css 14:09:08 myles: at least in webkit, we implemented font-stretch at the same time as the numerical values 14:09:20 myles: so the span of time where we didn't support numbers for it was short 14:09:26 myles: possibly not even a release 14:09:37 dbaron: given that, I think it's fine to break the general principle 14:10:02 astearns: ok, so the proposed resolution is to not used the font-stretch keywords in serialization 14:10:07 emilio: and return a percentage 14:10:14 astearns: ok, any objection to this? 14:10:34 RESOLVED: font-stretch should serialize to a number/percentage, not a keyword 14:10:38 topic: [css-fonts] extent font-size-adjust to take a pair of values: 14:10:45 github: https://github.com/w3c/csswg-drafts/issues/6160 14:11:26 jfkthame: this was prompted by the discussion about size adjust descriptor 14:11:40 jfkthame: we want to harmonize when we have mixtures of fonts 14:12:02 jfkthame: font-size-adjust allows you to use the x-height of the font to size things 14:12:10 jfkthame: this is very latin-centric however 14:12:25 jfkthame: for exemple you might want to harmonize the ascent/descent of the font instead 14:12:39 jfkthame: because x-height might be meaningless to my language 14:12:52 jfkthame: this sounds like a natural extension to me, but I wanted feedback 14:13:01 fantasai: this makes sense to me 14:13:07 fantasai: I support the proposal 14:13:12 florian: same 14:13:14 sanketj has joined #css 14:13:32 florian: I would like to note that the ascent+descent combination is problematic 14:13:41 florian: because it depends on the baseline 14:13:59 florian: it's easier to stick to things that are distances from the baseline 14:14:12 florian: otherwise you are adding a feature to realign 14:14:22 s/are/adding/need to add/ 14:14:23 jfkthame: I don't propose to adjust the alignment 14:14:27 jfkthame: just the font size 14:14:44 fantasai: yes, you would need to use ideographic alignement in some cases 14:14:52 florian: ok, that sounds convincing 14:15:11 myles: did we consider IC-height? 14:15:26 [IC = Ideographic Character] 14:15:32 fantasai: we probably want to have logical variants of these as well 14:15:41 myles: philosophically this proposal makes sense 14:15:53 myles: but to change the spec, I will need a list of tokens to consider for the first argument 14:16:04 myles: I might have some opinions on the set 14:16:10 myles: descent doesn't seem useful for example 14:16:19 astearns: how often do people use font-size-adjust? 14:16:39 fantasai: it's not cross-browser so it might be lower than we think 14:16:50 jfkthame: I found a lot more uses that I expected actually 14:16:59 s/ok, that sounds convincing/ok, that sounds convincing, you can use vertical-align to deal with any alignement problem/ 14:17:07 jfkthame: but however it often as no effect since it only applies if font don't load 14:17:21 astearns: are we sure we don't complexify too much? 14:17:34 fantasai: I think it's fair to support asian languages better 14:17:54 fantasai: some languages don't even have opentype metrics, but at least this would add support for languages for which we have metrics 14:17:59 jensimm__ has joined #css 14:18:05 s/non-european/ 14:18:07 fantasai: and we have a mechanism to add new metrics if they are created later 14:18:10 s/asian/non-european/ 14:18:10 present+ 14:18:23 present+ 14:18:47 astearns: which browsers support this right now? 14:18:51 s/we have a mechanism/it provides a design which works/ 14:18:51 present+ 14:18:52 myles: probably just firefox? 14:19:17 jfkthame: and behind a flag in chrome 14:19:34 myles: and webkit would implement when we add the overrides in the font description block 14:19:47 myles: no objection to add, we can discuss the set later 14:19:58 astearns: sounds like we have a consensus 14:20:02 astearns: any objection? 14:20:28 RESOLVED: add new metrics that can be used to harmonize the font size of fonts used in fallback 14:20:43 florian: btw we need to find a way to work with the opentype people 14:20:48 florian: so we can provide feedback 14:21:06 florian: I don't have a plan to propose, but maybe we can create a community group 14:21:22 florian: maybe that is not necessary, but it would be nice to figure it out 14:21:51 s/maybe we can create a community group/there is a community group created recently/ 14:21:52 astearns: indeed, the set of metrics can be a good think to ask to the opentype people 14:22:12 astearns: let's make sure that we don't ping them about bad fonts though 14:22:20 s/maybe that is not necessary/I don't know for sure how to engage with the fonts people/ 14:22:21 astearns: there are lots of fonts that are reporting wrong metrics 14:22:31 astearns: and it's not the fault of the committee 14:22:48 https://github.com/w3c/font-text-cg/ 14:22:56 topic: [css-fonts-5] vertical metrics overrides 14:23:07 github: https://github.com/w3c/csswg-drafts/issues/6152 14:23:42 fantasai: these overrides are useful if you rotate the font (?) 14:24:03 fantasai: for example ascent and descent are given differently depending on the axis 14:24:20 fantasai: but we probably need to add values that would override things in vertical writing mode 14:24:40 fantasai: because using the horizontal values in vertical writing mode doesn't work well 14:24:53 s/work well/make any sense/ 14:25:00 myles: in upright vertical text, the ascent would be horizontal? 14:25:05 fantasai: yes, horizontal 14:25:22 (some pondering) 14:25:36 astearns: do we need to support both or a switch? 14:25:47 fantasai: I think both might be needed at the same time 14:25:59 s/needed/required to be specified/ 14:26:00 myles: this proposal would require a different implementation 14:26:20 myles: this is fine, but this something worth noting 14:26:35 fantasai: but the font has y values, you just need to override them 14:26:49 bkardell_ has joined #css 14:26:58 myles: possibly? but the problems that this solves are less important that the horizontal writing mode 14:27:07 fantasai: I would agree that this is less severe in most cases 14:27:28 fantasai: because in vertical writing mode the baseline is often the middle, and it is fine 14:27:29 present+ 14:27:47 myles: and the CJK scripts don't have diacritics so they usually fit in the 1em box 14:28:09 fantasai: some cases might still exist 14:28:20 astearns: are there arguments to not complexify? 14:28:29 astearns: if we add this, I would like to view examples 14:28:37 astearns: because I don't have an idea in mind of what this would do 14:29:01 astearns: any objection to add this to the spec at this time? 14:29:34 jfkthame: line-gap override could be useful too 14:29:45 jfkthame: no reason this should be left out 14:29:55 astearns: ok, any objection? 14:30:10 RESOLVED: add font-face descriptor overrides for vertical writing modes 14:30:30 topic: [css-fonts-5] How do font-size-adjust property and size-adjust descriptor work together? 14:30:38 github: https://github.com/w3c/csswg-drafts/issues/6128 14:31:17 jfkthame: the question came up about the interaction between these two properties 14:31:28 jfkthame: the proposed solution in the issue 14:31:43 jfkthame: is that the font-size-adjust takes precedence in a given element 14:31:55 jfkthame: that does erase the changes in the descriptor 14:32:05 jfkthame: I think this makes sense 14:32:38 myles: one way of looking at it is that they both occur, but font-size-adjust changes things to the same solution regardless 14:32:50 myles: when writing the spec text, I would go with this 14:33:00 jfkthame: I think that is true 14:33:07 (Myles's description makes sense to me.) 14:33:22 jfkthame: basically the calculations of font-size-adjust cancel out any previous adjustment 14:33:32 astearns: sounds like we have a general agreement 14:33:45 astearns: any objection to this clarification? 14:33:49 +1 to jfkthame's proposal 14:34:19 RESOLVED: clarify that font-size-adjust computations will effect things in such a way that the descriptor overrides have no effect 14:35:47 topic: [css-flexbox] [css-sizing-4] Interaction of flexbox minimum height and aspect-ratio minimum height 14:35:55 github: https://github.com/w3c/csswg-drafts/issues/6069 14:36:28 cbiesinger: the aspect ratio spec says that min-height auto and you compute it using the aspect ratio, you expand to the content height 14:36:57 cbiesinger: but in a column flex box, the height is the minimum of the transferred height and the content height 14:37:06 cbiesinger: it's not clear to me which one should win 14:37:22 cbiesinger: fantasai clarified the aspect ratio version should win 14:37:28 cbiesinger: but does the working group agree to this? 14:37:41 fantasai: this is different for replaced and non-replaced elements 14:37:59 fantasai: because the intrinsic size of replaced elements is not as strict 14:38:11 fantasai: so we need to keep that behavior for them 14:38:27 fantasai: but for non-replaced elements, the intrinsic size is more meaningful 14:38:47 florian: I'm not sure about what the alternative is? 14:39:21 cbiesinger: width:100px + aspect ratio 1:1 but intrinsic-height:200px 14:39:28 florian: ah ok, got it 14:39:36 cbiesinger: because it used to be the minimum 14:39:57 jensimmo_: the default of flexbox is that it's shrink then grow 14:40:18 jensimmo_: but the proposal is that for replaced elements, we make aspect ratio "work" 14:40:32 fantasai: yes, that is the heart of the issue 14:40:43 dholbert has joined #css 14:40:59 (some discussion about magic css jokes) 14:41:10 astearns: last week there was more contention 14:41:11 [jen's explanation was that if there's a bunch of elements you want to be squares, unless too much content want to grow, that's the behavior we specced for block boxes with aspect-ratio; and the issue is making sure it works the same for flexbox] 14:41:16 iank_: that was me last week 14:41:20 iank_: I am now fine with this 14:41:29 astearns: is the spec edit correct for what we discussed 14:41:37 fantasai: I think it is correct 14:41:47 fantasai: but we need to update the spec 14:42:45 fantasai: proposal is non-replaced elements with an aspect ratio honor the intrinsic size in flexbox 14:43:11 for min-height:auto 14:43:13 jensimmo_: I am seeing a lot of tutorials about aspect ratio on replaced elements 14:43:31 jensimmo_: in particular content-size fit etc 14:43:40 fantasai: that should continue to work 14:43:52 s/content-size fit/object-fit/ I think? 14:43:53 fantasai: that is why we don't do this for replaced elements 14:44:07 dholbert has joined #css 14:44:17 fantasai: non-replaced elements have an intrinsic size that depends on content, that might not be easy to resize 14:44:32 jensimmo_: the previous text for images would still apply then? 14:44:35 fantasai: yes 14:44:45 astearns: any objection to keep fantasai's edit in the ED? 14:45:05 RESOLVED: non-replaced elements with an aspect ratio honor the intrinsic size in flexbox for min-height:auto 14:45:34
14:52:06 leaverou_ has joined #css 14:52:15 present+ 14:52:33 present+ 14:53:20 dholbert has joined #css 14:53:24 smfr has joined #css 14:54:20 Partial regrets for Chris, he's having a migraine. May join later 14:54:47 present+ 14:56:31 present+ 14:58:28 TabAtkins: might be a dwarf propaganda map, hiding their continent from the view of others then! that would be smart of them... 14:59:44 House Sivis is gnomish, not dwarvish 15:00:58 ScribeNick: fantasai 15:01:25 topic: [css-sizing] Auto-resize iframes based on content 15:01:31 https://github.com/w3c/csswg-drafts/issues/1771 15:01:35 github: https://github.com/w3c/csswg-drafts/issues/1771 15:01:51 TabAtkins: Fairly old issue, #1171 15:02:06 TabAtkins: originated in HTML in the form of 'seamless' attribute on iframes 15:02:24 TabAtkins: meant to allow isolating parts of a page, but still lay them out as if in the page 15:02:31 TabAtkins: there were a bunch of issues, dropped from HTML 15:02:43 TabAtkins: core ideas still requested by people, in various variants 15:02:52 TabAtkins: We believe there's a useful and safe set of resizing behavior that we could expose now 15:02:59 TabAtkins: that would solve some of the use cases 15:03:09 https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925 15:03:33 TabAtkins: Core idea is that just the resizing portion of seamless is value 15:03:41 TabAtkins: But security issues around being able to tell the size of 3rd-party content 15:03:50 TabAtkins: bare minimum, different sizes of content depending on logged in or not 15:04:00 TabAtkins: So should only be allowed to take size of 3rd-party content if it wants to allow that 15:04:31 TabAtkins: Another problem, if 3rd-party page can trigger resizing without consent of containing page, can create problems as well 15:04:37 TabAtkins: So 2-way agreement on sizing 15:04:48 TabAtkins: First, outer page needs to opt into resizing based on iframe content 15:05:04 present+ 15:05:04 TabAtkins: Suggestion is to use new 'resize' value in 'allow' attribute 15:05:24 TabAtkins: Then for 3rd-party content, there's a window.resizeTo() method which is a no-op in iframes 15:05:31 TabAtkins: Inner page can request such sizes 15:05:39 TabAtkins: using this API 15:05:59 TabAtkins: Whenever inner page wants a resize, triggers an event on iframe which bubbles up 15:06:07 dlibby has joined #css 15:06:10 TabAtkins: if not prevetnDefault, then the iframe changes it's size 15:06:20 TabAtkins: if cancelled, doesn't change size 15:06:28 TabAtkins: This allows control over layout behavior across the page 15:06:54 astearns: Possible scripts using resizeTo() and relying on the fact that it does nothing? 15:07:02 TabAtkins: it's a no-op currently, so don't think so 15:07:09 TabAtkins: ... [ missed ] 15:07:26 astearns: Making page decide to allow event or not, already in place due to opt-in to resize behavior 15:07:44 cbiesinger: Nothing sounds like CSS thing 15:07:47 TabAtkins: kinda sorta 15:07:48 q+ to ask at which level of sizing this works. natural size of the iframe? something else? 15:07:58 TabAtkins: it's a cross-spec thing, does interact with CSS by adjusting intrinsic size of iframe 15:08:04 q+ 15:08:04 TabAtkins: gets into issue of same-origin content 15:08:18 fantasai: YOu wanted a 2-way handshake for security 15:08:26 fantasai: resizeTo() gives you 2-way for page consenting 15:08:41 fantasai: If that page is already firing resizeTo() and expecting it not to ahve sec implications 15:09:02 fantasai: I don't think paying attention to resizeTo() would break the framed page... 15:09:23 fantasai: But if they're asking for it and it's currently not changing size, the outer page probably isn't expecting a problem. 15:10:08 q-- 15:10:12 ack gregwhitworth 15:10:20 fantasai: [clarifying] the issue isn't an attack due to sizing, it's a possibly unexpected info leak from the frame'd page, leaking the size it wants to size to 15:10:22 ack fantasai 15:11:04 florian: currently, calling resizeTo() doesn't leak information 15:11:28 TabAtkins: could check if stuff in iframes do this currently... 15:11:43 fremy: It's not about stuff currently in iframes, but a page could put *anything* into an iframe 15:12:12 fremy: which would leak information from that page, which was not intended to be in an iframe 15:12:42 florian: resizeTo() doesn't have an effect on pages that are loaded into a window with multiple tabs 15:12:55 florian: for exactly this reason: it would leak information about that page to other pages in the same window 15:13:04 ack florian 15:13:04 florian, you wanted to ask at which level of sizing this works. natural size of the iframe? something else? 15:13:06 florian: opening up this leak through iframes is similarly bad (worse maybe) 15:13:18 another path would be an additional dictionary argument to resizeTo, e.g. window.resizeTo(100, 100, {something: true}); 15:13:18 TabAtkins: Yeah, OK, we need to think about that more. Maybe needs a new API 15:13:32 +1 iank_ 15:13:46 florian: In the case where resize does work, thing it affects is the natural size, right? 15:14:08 TabAtkins: Yes. Right now iframes have natural size of 300x150, and this would change that 15:14:19 TabAtkins: totally controllable, it's the weakest size input possible 15:14:27 fremy: [missed] 15:14:35 TabAtkins: currently iframes do not have an aspect ratio 15:14:47 TabAtkins: Ability to infer an aspect ratio is an interesting possibility 15:14:53 q+ 15:15:01 florian: As long as we're there, should we specify min size and max size separately 15:15:02 s/[missed]/do iframes have an aspect-ratio applied to that intrinsic size? 15:15:15 TabAtkins: Interesting. Not unreasonable to consider. 15:15:29 q+ 15:15:33 ack jensimmo_ 15:15:40 q+ 15:15:43 jensimmo_: Curious about use cases 15:15:57 jensimmo_: All I can think of is what ad networks will do, and I don't like those thoughts. 15:16:13 TabAtkins: There's another proposal for 1st-party content, which addresses more use cases 15:16:37 TabAtkins: but even within 3rd-party stuff, currently they do this resizing already, just with postMessage back and forth 15:16:41 TabAtkins: This would standardize that 15:16:59 TabAtkins: There's also things like Disqus, which does such special-case postMessage things 15:17:10 TabAtkins: which is complicated and no standardized way to handle across multiple systems 15:17:11 q+ 15:17:35 TabAtkins: YouTube player, e.g., might want to do this. CodePen might want to ask for sizes on its examples. Anything that wants to embed, has a reasonable use case for wanting to request a particular size and have it potentially honored by containing page 15:17:50 jensimmo_: If goal is to reduce jankiness of ad network... 15:17:55 TabAtkins: that is one goal, but not all of it! 15:17:57 need to drop off briefly for another call, but I'm very supportive of this, and I hope we can find a way to implement it in a privacy and security preserving way. 15:18:03 ack emilio 15:18:18 emilio: How do you react to resize in parent page when using the API? 15:18:37 emilio: User shrinks the page, need to somehow coordinate between both. No auto size, only fixed intrinsic size 15:18:48 TabAtkins: I don't think there's a reasonable direct analog to block auto-sizing .. 15:19:11 emilio: I guess at that point... You don't really need JS on the parent page to get auto height 15:19:23 emilio: If you require JS on the parent page then it's not great 15:19:47 emilio: So inner page can send resizeTo() whenever it gets Resize event 15:19:57 emilio: and then containing page doesn't need to do anything ... 15:20:07 emilio: [missed] 15:20:14 TabAtkins: possible this makes it easy enough that it's a concern 15:20:22 emilio: resize event ... your own resize event 15:20:40 TabAtkins: I suspect that's something that would show up fairly quickly 15:21:06 emilio: It only consumes CPU, not while:true. I send a message, it resizes me, sends a message back. Code keeps working, just uses a ton of CPU 15:21:18 emilio: It's a bug in the page, but. 15:21:34 TabAtkins: no-op loops can't happen because if the iframe's resizeTo() doesn't change its size, won't get an event because size didn't change. 15:21:50 TabAtkins: Either it'll grow or shrink infinitely, or will jiggle, which should be noticeable 15:22:00 emilio: Concerned about e.g. floating point issues, and rounding errors 15:22:07 emilio: I've seen that kind of stuff happen 15:22:12 we also already have the "jiggle" problem today with frame by frame resize-observers. 15:22:31 if not causing change in size, then shouldn't cause a problem 15:22:39 dholbert has joined #css 15:23:00 fremy: can't put a breakpoint in the main page to figure it out because no JS 15:23:07 fremy: Already have these kinds of bugs today 15:23:12 ack fremy 15:23:36 smfr: The HTML5 event loop spec is very specific about when resize steps happen 15:23:44 smfr: when we spec this, we need to spec it in terms of that event loop spec 15:23:50 smfr: Nobody mentioned resizeobserver yet 15:23:55 smfr: it's designed to avoid infinite recursion 15:24:08 smfr: we might need something here with nested iframes, so don't get into crazy infinite resizing 15:24:11 q+ 15:24:24 TabAtkins: yes, want to handle events in descending order like resizeobserver does 15:24:34 TabAtkins: need some thought to ensure not creating bad cross-tree resizing behaior 15:24:56 TabAtkins: Not too concerned about page vs iframe vibration, but much worse if grandparent grandchild interactions cause problem, because then nobody knows what's going on 15:25:13 Francis_Storr has joined #css 15:25:13 fremy: Main question here was, I guess point of allow attribute is to allow resize 15:25:19 fremy: External page wants to allow iframe to resize 15:25:24 fremy: Not sure I understand point of resize function 15:25:35 q- 15:25:38 fremy: why not some CSS value that allows resizing by containing page 15:25:57 fremy: reason I think about htat is that resize takes 2 arguments, width and height. 15:26:06 fremy: not that interesting to change intrinsic width of iframe 15:26:14 +1 to fremy 15:26:24 fremy: why not say that "I'm fine with my scrollHeight to be reported to the containing page" 15:26:30 iank_: scrollHeight isn't always what you want 15:26:37 fremy: could be something smarter, max-content maybe 15:26:47 q? 15:26:50 TabAtkins: Second part of proposal also, about same-origin content and no-JS solution 15:27:29 smfr: Other point, iframe calls resizeTo() and has to provide a size. What size should it provide? does it doe getBoundingClientRect() on the body or what? 15:27:36 smfr: Is there some convenient way to get the height of the content? 15:27:55 TabAtkins: For 1st-party content, making it easy. But for 3rd-party content wanted to be more explicit 15:28:05 TabAtkins: But maybe we can reduce that restriction 15:28:23 TabAtkins: 2nd part of proposal is about same-origin content 15:28:38 TabAtkins: right now, minimum solution still requires some JS on the framed page (not containing page) 15:28:48 TabAtkins: but for same-origin content, there's a certain degree of implicit trust we can rely on 15:28:52 TabAtkins: and might not require auditing 15:29:11 TabAtkins: for this, I propose that on a 1st-party iframe, or something that's srcdoc 15:29:17 emilio: srcdoc is not ? 15:29:20 emilio: data URIs are 15:29:24 TabAtkins: sorry, I'm thinking about sandbox 15:29:47 q+ 15:29:54 TabAtkins: In my original proposal, I had a new property that could be set on the root element to set the requested intrinsic size for each axis (auto | ) 15:29:57 q+ 15:30:15 TabAtkins: page could opt into ? via 'from-element' keyword, providing fallback length 15:30:27 TabAtkins: fantasai later suggested the page could just set an explicit width/height on the HTML element 15:30:40 TabAtkins: Possibly we don't need to mint a new property, can just take from the root element 15:30:53 TabAtkins: if that's problematic from existing, maybe mint something new 15:31:03 TabAtkins: but either way, that'll allow getting the size without JS 15:31:16 TabAtkins: Just set allow=resize, and inner page does whatever it needs to do 15:31:24 TabAtkins: and those sizes automatically communicate back and forth 15:31:29 TabAtkins: acts like an element, no JS required 15:31:39 https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-805117925 15:31:54 fremy: that only works in 1D, right? you can't do both dimensions 15:31:59 fremy: then you wouldn't get the resize 15:32:10 fremy: if you get width + height, wouldn't know you need more space 15:32:22 TabAtkins: If you set both to auto, you'll need to rely on outer page to set your width... 15:32:26 fremy: ah, ok, make sense 15:32:41 iank_: I don't think that width/height on HTML will work, because people do set an explicit width on HTML and use e.g. auto margins to center 15:32:59 iank_: HTML is not the root, bit of disconnect 15:33:13 iank_: likely for auto behavior, might want something like scrollWidth/scrollHeight as was discussed 15:33:23 iank_: There's a little bit of danger here 15:33:29 +1 to scrollWidth/scrollHeight (adjusted if necessary) 15:33:50 iank_: you might get content that, if you have a fixed-position content that rises to ICB, and has height 120%, could create an infinitely-growing iframe that way? 15:33:57 iank_: I'm not too concerned about that 15:34:17 TabAtkins: Yeah, need to think about loop detection... 15:34:46 fremy: we can set a threshold, if you fire too many resize events in a certain amount of time don't allow it or whateer 15:35:09 iank_: That might block some valid use cases. E.g. comment expansion might want to animate growing 15:35:10 resizeObserver has the same error handling 15:35:29 ack gregwhitworth 15:35:52 gregwhitworth: Effectively what you just outlined is something we wanted at Salesforce. All over the web ppl using Salesforce but not aware of it. 15:35:57 gregwhitworth: would like to see ??? 15:36:03 gregwhitworth: enable this auto behavior for cross-origin 15:36:14 gregwhitworth: if a grid with min/max content, how can I lay out my content and pass back my height 15:36:25 s/???/network headers/ 15:36:25 gregwhitworth: I can work it out in JS, but want it automatic 15:36:39 TabAtkins: Reason restricted right now is trying to be cautious 15:36:52 gregwhitworth: we could write blog posts about how to do it, but would rather not 15:37:03 TabAtkins: I would want to have more security eyes on it 15:37:06