- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Dec 2021 17:47:04 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Auto-resize iframes based on content`, and agreed to the following: * `RESOLVED: Use HTML mechanism (either attributes or meta) to express the intrinsic size of the child` * ``RESOLVED: Add `contain-intrinsic-size: from-element` with a note that it needs further discussion on the name`` <details><summary>The full IRC log of that discussion</summary> <emilio> topic: [css-sizing] Auto-resize iframes based on content<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/1771<br> <fantasai> scribe+<br> <Domenic> https://github.com/domenic/cooperatively-sized-iframes<br> <emilio> Domenic: This is a widely-desired feature for devs, I've worked with tab, iank and chrishtr on how a solution could look like<br> <emilio> ... I've got the explainer (^) but basically content inside iframe requests content size, and the page can use css to decide to honor it<br> <emilio> ... which resizes the iframe element and in turn the viewport in the inner iframe and so on<br> <emilio> ... you can restrict it to honor only height / width, or using max/min-width to constraint<br> <emilio> ... there's also some discussion to try avoiding shifts<br> <emilio> ... what devs really want is auto-sizing<br> <emilio> ... and the iframe will auto-resize its content<br> <emilio> ... we were not able to figure out how to best do this<br> <emilio> ... biggest problem is resize loops<br> <emilio> ... like 100vh inside the iframe which would change the element size, which would change the viewport, etc...<br> <chrishtr> q+<br> <emilio> ... so MVP is just allowing devs to request exact sizes<br> <emilio> ... there's also some ideas about snapshotting stuff at the load event<br> <emilio> ... or special layout modes that make vh behave differently to avoid the loops<br> <emilio> ... but the discussions about it are on the issue tracker<br> <emilio> ... there's some discussion of the alternatives and so on<br> <astearns> would be unhappy with modes that change how things behave<br> <bkardell_> is there something here we could borrow from how image sizing works maybe?<br> <emilio> ... I think from the CSSWG we should get some expertise... Should the sizes be communicated via css? should we use contain-intrinsic-size to opt-into this from the iframe?<br> <emilio> q?<br> <astearns> ack chrishtr<br> <emilio> q+<br> <bkardell_> like, you could set px values or fit-like things?<br> <emilio> chrishtr: it seems the main thing we should focus on is the mechanism for communicating the intrinsic sizing<br> <bkardell_> feels like those two options would cover most kinds of cases I can think of<br> <emilio> ... so the specific proposal is that it'd be a keyword on the `contain-intrinsic-size` property<br> <Domenic> `contain-intrinsic-size: from-element 500px 500px`where 500px 500px is the initial/fallback size<br> <emilio> ... I think that one makes sense<br> <emilio> ... The other bit is whether on the child we should use a css property vs. attributes<br> <smfr> q+<br> <emilio> ... and whether it could be `contain-intrinsic-size` or other thing<br> <astearns> ack emilio<br> <fantasai> emilio: Wanted to ask why is 'contain-intrinsic-size' the right property for this<br> <fantasai> emilio: I thought it mostly only worked on contained stuff<br> <fantasai> emilio: It communicates a size, but...<br> <fantasai> iank_: It could work a lot of different ways, but contain-intrinsic-size allows ...<br> <fantasai> iank_: It's the mechanism at the moment that we have for changing the intrinsic size of an element<br> <fantasai> iank_: Did you have something else in mind?<br> <fantasai> emilio: I wasn't aware of that overriding replaced element intrinsic size already<br> <fantasai> iank_: If you set c-i-s: 100px 100px on an image element, it will override the image's size<br> <florian> q?<br> <florian> q+<br> <fantasai> iank_: we could explore a different mechanism, but as a first shot seems reasonable<br> <fantasai> emilio: With this proposal, would you need to use 'contain: size' on the iframe?<br> <florian> q-<br> <fantasai> iank_: I believe ???<br> <fantasai> s/???/that is true/<br> <fantasai> iank_: I may be wrong<br> <Domenic> Interesting, I did not know that. I kind of assumed replaced elements were size-contained by default.<br> <fantasai> iank_: Other nice thing about this is that it provides a fallback size<br> <fantasai> iank_: if you can't get that size, it'll back<br> <fantasai> emilio: OK<br> <chrishtr> (we could also define replaced elements to be implicitly contain:size)<br> <fantasai> emilio: Didn't want to use for something totally unrelated<br> <smfr> q-<br> <fantasai> <fantasai> Domenic, that might be a reasonable thing to do<br> <fantasai> <fantasai> Maybe should be considered<br> <Domenic> https://github.com/domenic/cooperatively-sized-iframes/issues/6 to track updating the explainer<br> <Domenic> Oh cool, thanks fantasai<br> <emilio> chrishtr: probably not right? Otherwise you break intrinsic-sizing of images by default<br> <fantasai> astearns: Borrow something from image sizing, e.g. setting px values or fit-like things?<br> <bkardell_> yes right iank_<br> <florian> q+<br> <fantasai> iank_: like to get letterboxing?<br> <emilio> iank_: we've discussed this previously<br> <emilio> ... there's an argument to be made about object-fit applying to iframes<br> <emilio> ... but I think that's orthogonal to this issue<br> <emilio> Domenic: It's orthogonal in the sense that the size would be used as the viewport but on the parent document it'd be letterboxed<br> <emilio> iank_: There's another issue about an iframe not wanting to change size but not wanting to overflow either but it's orthogonal to this<br> <emilio> Domenic: I think it layers well with this proposal<br> <astearns> ack florian<br> <emilio> astearns: is there an issue already on object-fit for iframes? if not may be worth filing one bkardell_<br> <emilio> florian: so contain-intrinsic-size is conditional on contain:size but afaict that's a no-op on `<iframe>`<br> <emilio> ... should we add it by default on a UA sheet?<br> <Domenic> +1 if possible<br> <emilio> iank_: I'd have to try the existing behavior<br> <emilio> florian: Spec says contain-intrinsic-size applies to elements with size containment so it doesn't kick in automatically<br> <emilio> iank_: right, so adding it to iframes in the ua sheet might make stuff suddenly kick in<br> <emilio> ... I need to refresh my memory on how iframe intrinsic sizing works<br> <chrishtr> q+<br> <emilio> ... because if we make contain:size by default on element we might stop respecting width/height<br> <emilio> florian: I suspect it would work but there might be a reason it doesn't<br> <emilio> iank_: makes sense<br> <astearns> ack chrishtr<br> <emilio> chrishtr: so sounds like contain-intrinsic-size is fine but need to make sure ergonomics are fine<br> <emilio> ... what about the child document sizes?<br> <dholbert> We'd need to be sure this is well-defined for <iframe style="contain:initial"> (presumably then contain-intrinsic-size would be ignored?)<br> <emilio> Domenic: currently from the outside you can do this by combining max-width / height with 'contain-intrinsic-size: from-element'<br> <emilio> ... with the current proposal that's not really possible from the child iframe<br> <dholbert> (Even in the presence of UA stylesheet `contain:size` defaults for iframe)<br> <emilio> ... It'd be nice to allow doing this for the child, and I feel CSS has a lot more tools<br> <emilio> iank_: the initial reaction I had about css vs. attribute is that this only applies to one element (the `<html>` element)<br> <emilio> ... there are already some things we use the CSS parser for on attributes<br> <emilio> ... the min() / max() functions can't have 'auto'<br> <emilio> ... so we'd need separate syntax<br> <emilio> smfr: is this about the iframe content expressing its desired for sizing on a given range?<br> <emilio> iank_: yeah, so the iframe would say "size me as 500x500" but the additional layer on top would be something like...<br> <emilio> ... this is more interesting on the snapshotting approach where it'd read the offsetHeight/offsetWidth of the document<br> <emilio> ... and the additional layer would be to limit that size<br> <emilio> ... so not go below 100px or above 1000px<br> <Domenic> The additional layer on top would be something like: "if the parent is currently set to anything between 400px-600px height, then don't resize me. Otherwise, resize me to 432px".<br> <emilio> ... not so useful when we set a single size but it's more useful when setting multiple<br> <Domenic> E.g. `min-requested-height: 400px; max-requested-height: 600px; if-outside-requested-size-range: 432px;`???<br> <emilio> ... so you'd send a message to the parent and so on...<br> <emilio> smfr: seems similar to viewport meta tag / @viewport for iframe<br> <emilio> smfr: it's nice if these features could work with JS disabled<br> <emilio> iank_: These things are only needed if we go for the one-shot behavior<br> <emilio> smfr: would that be default or an opt-in?<br> <bkardell_> are there popular libraries using some postMessage concept to negotiate this already somehow<br> <Domenic> But you could also do `requestedheight="432 if not in 400 to 600"` or some other new microsyntax... or even just three separate HTML attributes.<br> <emilio> iank_: it'd be an opt-in, you'd do a 'requested-intrinsic-size: auto'<br> <emilio> ... can't auto-opt-in<br> <Domenic> bkardell_: yes, see https://github.com/domenic/cooperatively-sized-iframes#continue-to-do-this-through-ad-hoc-custom-protocols<br> <fantasai> scribe-<br> <emilio> ... so on the load event that'd read the scroll width/height and send it<br> <chrishtr> Yes there are libraries, but it requires postMessage stuff and JS on both ends, and there is also the issue of both frames having to use the same protocol<br> <emilio> ... so if you want to add floor/ceil to that how would that work?<br> <emilio> as an html attribute?<br> <fantasai> Domenic, I feel like it's unlikely to have "432 unless I'm between 400 and 600", seems more likely to request "make me between 400 and 600, I prefer 432"<br> <fantasai> scribe+<br> <fantasai> emilio: [missed]<br> <emilio> emilio: has a meta tag been considered? it may be more flexible than attributes<br> <fantasai> Domenic: If we did end up creating a microsyntax, might be more natural that way<br> <Domenic> fantasai: yes, that is exactly right, I phrased it very confusingly. Thanks.<br> <emilio> iank_: we'd need to find a new CSS syntax for this anyway because min()/max()/clamp() doesn't support auto, so if we go to the CSS property we'd need to invent a new syntax anyways<br> <emilio> iank_: so for this use-case we'd need to define a new syntax for a one-line attribute or property<br> <emilio> Domenic: I was thinking multiple css properties like `min-`/`max-`/`preferred-`...<br> <TabAtkins> scribe-<br> <TabAtkins> I'm fine with element-specific CSS properties when warranted, fwiw...<br> <emilio> ... though that may be another argument for less properties than apply to one element<br> <lea> Is supporting auto in min()/max()/clamp() out of the question? That would be very useful in general<br> <emilio> fantasai: tantek was wondering whether we'd want to implement a new variant of @viewport for this<br> <Domenic> https://developer.mozilla.org/en-US/docs/Web/CSS/@viewport<br> <emilio> iank_ and fantasai: [explain @viewport]<br> <tantek> found it https://web.archive.org/web/20160404172306/http://people.opera.com/rune/TR/ED-css-viewport-20100806/<br> <futhark> +q<br> <emilio> iank_: could you nest @viewport inside @media?<br> <emilio> ... that could be bad<br> <emilio> smfr: we deprecated @viewport because making viewport depending on CSS loading was pretty bad behavior<br> <tantek> point being, the problem/use-case is *very* similar to what @viewport was trying to solve, so there's at least some syntax there that could be re-used<br> <astearns> ack futhark<br> <emilio> Domenic: You need to allow adjusting it but I agree that meta / attributes get the info to the browser as soon as possible<br> <emilio> futhark: you could nest @viewport inside @media but it'd cause a circular dependencies so it was specified to resolve against the initial viewport when you collected viewport rules<br> <emilio> astearns: it seems there's more consensus towards expressing these sizes on HTML rather than CSS<br> <tantek> seems reasonable to experiment with attributes in HTML<br> <emilio> smfr: either attribute or meta tag right?<br> <emilio> astearns: yeah<br> <emilio> Domenic: can we read the temperature on that?<br> <emilio> ... seems like leaning towards meta-tag if we need a micro-syntax<br> <emilio> ... but I don't know how complicated that would end up being<br> <emilio> astearns: I expect we won't have a strong opinion on it...<br> <fantasai> emilio: Attributes can trigger restyling, but not if they don't trigger changes in styls<br> <fantasai> smfr: but you'd have to write code to detect that ...<br> <emilio> Domenic: can't you write rules against the meta?<br> <emilio> iank_: I think we can leave the attributes vs. meta as an open question for now<br> <TabAtkins> Due to the particulars of HTML, it's not very targetable; it shows up in the <head> but you want to style things in <body><br> <TabAtkins> But that is an accidental restriction.<br> <emilio> RESOLVED: Use HTML mechanism (either attributes or meta) to express the intrinsic size of the child<br> <emilio> emilio: I'd expect contain-intrinsic-size:from-element to do stuff on other replaced elements<br> <emilio> ... like undoing what `contain:size` does<br> <emilio> astearns: putting it into an ED doesn't mean we're fully behind on it<br> <emilio> fantasai: we can add some placeholder-name on it<br> <emilio> chrishtr: what about putting from-element in an ED committing that we're not shipping it yet<br> <emilio> fantasai: yeah... please do from-iframe? :-)<br> <emilio> Domenic: what about `<object>` / `<embed>`?<br> <emilio> chrishtr: we can put from-element as a placeholder and bikeshed with the editors<br> <fantasai> Domenic, intentionally, it's bad and needs renaming<br> <tantek> the object element is more interesting because you're also styling the fallback content inside<br> <emilio> RESOLVED: Add `contain-intrinsic-size: from-element` with a note that it needs further discussion on the name<br> <Domenic> Not sure if I'm serious about object/embed, I kinda want those elements to die in a fire and so starving them of new features might be my preference...<br> <Domenic> Thanks all!<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1771#issuecomment-989034819 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 December 2021 17:47:07 UTC