- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 20:43:24 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `aspect-ratio via width/height doesn't work for <video>`, and agreed to the following: * `RESOLVED: Clarify that aspect-ratio:auto doesn't pull aspect ratio from the default object size, it can only pull from an actual loaded resource` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: aspect-ratio via width/height doesn't work for <video><br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/7524<br> <fantasai> scribe+ bramus<br> <bramus> TabAtkins: so, the aaspect ratio property has the auto keyword and it will take the ar from the resource otherwise use the other one as the fallback<br> <bramus> TabAtkins: this works great, expect for video<br> <bramus> TabAtkins: bc video does not communicate the ar<br> <bramus> TabAtkins: instead the size is 300 by 150<br> <bramus> TabAtkins: and the algo will say cool i have an ar<br> <bramus> TabAtkins: needs a small fix, suggested by jaffathecake<br> <emilio> q+<br> <bramus> TabAtkins:<br> <bramus> TabAtkins: new concept of pending your first resoruce size instead of "do you have an ar" ask "have you ever received an ar from you rcontent?"<br> <bramus> TabAtkins: if not use the fallback from the ar property<br> <bramus> TabAtkins: this would fix the problem so taht img and videos ar enot considered to have an r until they load their resource<br> <bramus> TabAtkins: it is flipped when they obtain the ar<br> <bramus> TabAtkins: other reason for a f2f bc the relevant algos are in images-3<br> <bramus> s/an r/an ar/<br> <bramus> fantasai:<br> <bramus> fantasai: why do we ignore wdth and height in favor of the 300 by 150?<br> <bramus> fantasai: if we have better info shoulndt we us that instead?<br> <bramus> TabAtkins: correct<br> <bramus> emilio: to clarify, thi sonly changes behavior before the video loads<br> <bramus> TabAtkins: correct<br> <iank_> there is also some special behaviour for video image placeholders i think.<br> <bramus> emilio: i htink images are a bit special ?? when there is mapped ar<br> <emilio> https://searchfox.org/mozilla-central/rev/417eb46de41c31c3223d7b84c275ba56fc7d4343/layout/generic/nsImageFrame.cpp#659-661<br> <bramus> emilio: so why dont we do the same for video?<br> <bramus> emilio: here is the gecko code for image intrinsic sizing<br> <bramus> emilio: fallback has a lot of stuff<br> <bramus> emilio: but basically intrinsic size is 0 if broken<br> <bramus> emilio: ???<br> <bramus> emilio: why cant we do same for video<br> <iank_> q+<br> <Rossen_> ack emilio<br> <bramus> emilio: that function does a lot of stuff … once you get to th ebottom the intrinsic size of a broken img is 0x0<br> <bramus> emilio: instead of that, have it check if you have an ar then return no intrinsic size and use the ar instead<br> <bramus> emilio: i dont see how that is gonna work for video<br> <fantasai> s/is/isn't/<br> <bramus> emilio: i think we need just the same check also for video<br> <bramus> iank_: i wnat to point out that videos are more complicated<br> <bramus> iank_: they define a ??? and we get the ar from there<br> <bramus> emilio: we also do that<br> <Rossen_> s/???/poster image/<br> <bramus> emilio: check the actual video, check the poster, and then the fallback<br> <Rossen_> ack iank_<br> <bramus> TabAtkins: in the html spec, images do not have a fallback size<br> <bramus> emilio: yes, 0x0<br> <bramus> TabAtkins: so we do not want that for video<br> <bramus> fantasai: ??? if you have an ar use that and not the default object size<br> <bramus> TabAtkins: where would this change be? html?<br> <bramus> emilio: possibly<br> <bramus> emilio: if the fallback is defined in html<br> <bramus> fantasai: it is fine to say the fallback size is what it is<br> <bramus> fantasai: we should make it clear if the ar is set, you do not need that fallback size<br> <bramus> TabAtkins: yes, you are saying what i suggested<br> <florian> q+<br> <bramus> Rossen: everyone is agreein, which is great<br> <bramus> Rossen_: other opinions?<br> <bramus> florian: given that videos have controls, how realistic is that w ecan nkow the ar wihtout the size?<br> <bramus> TabAtkins: controls are overlaid<br> <bramus> Rossen_: tab, can you verify?<br> <bramus> TabAtkins: if a video or any replaced element has not yet loaded, then we do not consider it to have an ar to come from its fallback size<br> <iank_> q+<br> <emilio> q+<br> <florian> q-<br> <bramus> fantasai: the default object size should not ???<br> <TabAtkins> s/???/provide an aspect ratio/<br> <bramus> Rossen_: no, this is not the case.<br> <fantasai> s/not ???/never provide an aspect ratio, it's just a width+height/<br> <bramus> Rossen_: if we have a defined ar, we do not have a prob?<br> <bramus> Rossen_: we need to figure out in case of auto to fallback to 350<br> <bramus> TabAtkins: you should not be doing that, that is the point<br> <Rossen_> q?<br> <bramus> TabAtkins: if your default sizes are used, do not consider that to provide an aspect-ratio but us the auto<br> <bramus> Rossen_: auto by default?<br> <bramus> fantasai: 16/9 set … use that inti loaded<br> <bramus> fantasai: what tab is trying to say that auto is not giving the aspect ratio, until the resource is loaded<br> <bramus> TabAtkins: it is what we intended for images, but a clear error we need to fix (in images-3)<br> <bramus> fantasai: images-3 does not define that<br> <bramus> TabAtkins: it does ?? with size<br> <bramus> TabAtkins: the default object size is defined in 2.1<br> <fantasai> fantasai: sizing rules for replaced elements is not in css-images-3<br> <fantasai> fantasai: css-images-3 defines sizing algorithms, but not for replaced elements<br> <Rossen_> q?<br> <fantasai> fantasai: it covers things like list-style-image and background-image<br> <Rossen_> ack iank_<br> <bramus> iank_: we may only want to do this for video and ?? elements because ther eis some funky stuff with object elements<br> <bramus> Rossen_: object and embed have similar proble which you do not want to change<br> <bramus> fantasai: we are not gonna run into probs here<br> <bramus> iank_: any other elems?<br> <bramus> TabAtkins: not sure<br> <bramus> iank_: canvas?<br> <bramus> TabAtkins: maybe<br> <bramus> emilio: input type image, video, image, canvas<br> <bramus> florian: svg?<br> <bramus> emilio: no<br> <bramus> iank_: it might take us a while to do bc the way our intrinsic logic handles it historically<br> <bramus> Rossen_: ok, ty<br> <bramus> Rossen_: but shouldt prevent us from resolving<br> <Rossen_> ack emilio<br> <bramus> emilio: i dont know if saying getting the ar from the fallback size or not, or if you hav ean ar make sure you do not have a falback intrinsic size to being with<br> <bramus> iank_: you mean the natural size?<br> <bramus> emilio: yeah<br> <bramus> emilio: i need to check how it works<br> <bramus> emilio: but we are in agreement<br> <bramus> emilio: i think you may not want an intrinsic size to begin with<br> <bramus> iank_: (thinks)<br> <TabAtkins> q+ to finish this up without requiring us to nail down all details right there<br> <bramus> iank_: thi swill lose the natural fallback sizing as well?<br> <bramus> emilio: i htink it should<br> <bramus> emilio: i need to check where tha tmakes a diff<br> <bramus> iank_: that will make the diff when you do sth like width fit-content<br> <bramus> iank_: in certain circusstances<br> <bramus> emilio: maybe yes<br> <bramus> TabAtkins: can i interrupt<br> <bramus> TabAtkins: suggestion is to resolve to fix it, without detailing it<br> <bramus> fantasai: mayb e more precise<br> <bramus> fantasai: that the auto part does not provide an aspect ratio<br> <bramus> fantasai: that you do no get it from the fallback size<br> <bramus> TabAtkins: sure<br> <bramus> fantasai: the spec was never intended to pull the ar from the fallback size<br> <bramus> fantasai: we should clarify that it doesnt<br> <bramus> fantasai: it always fall back to the provide aspect ratio<br> <bramus> emilio: for iframes?<br> <bramus> fantasai: no<br> <bramus> fantasai: they dont get one automagically<br> <bramus> fantasai: same with svg, until you load it<br> <bramus> Rossen_: back to resolution<br> <bramus> fantasai: 2 resolutions<br> <fantasai> Proposed: aspect-ratio:auto doesn't pull aspect ratio from the default object size, it can only pull from an actual loaded resource<br> <fantasai> Proposed: Clarify that aspect-ratio:auto doesn't pull aspect ratio from the default object size, it can only pull from an actual loaded resource<br> <bramus> fantasai: when providing the ar through the property then yo u no longer have a naturla size tha tis a default size<br> <bramus> Rossen_: so ar overrides default<br> <bramus> fantasai: yeah<br> <bramus> TabAtkins: would like to address in separate issue if needed<br> <bramus> Rossen_: first one is easy to resolve one<br> <bramus> s/one/on/<br> <bramus> emilio: poster image?<br> <bramus> fantasai: that is a loaded resource<br> <bramus> emilio: but not a video<br> <bramus> florian: proposed resol says a resource<br> <bramus> fantasai: if video is 16 by 9 and poster 1x1, then loaded poster will give 1 by 1 aspect ratio<br> <bramus> emilio: ok<br> <bramus> we agree on behavior<br> <bramus> emilio: we agree on behavior<br> <bramus> Rossen_: anyone objecting?<br> <fantasai> RESOLVED: Clarify that aspect-ratio:auto doesn't pull aspect ratio from the default object size, it can only pull from an actual loaded resource<br> <bramus> Rossen_: no, ok<br> <bramus> fantasai: second one when providing ar via aspect-ratio property then dont fallback to default object size<br> <bramus> iank_: unsure about that<br> <bramus> fantasai: if you want to hang on to the ar, you have to at least hang on to one of the sizes<br> <fantasai> s/hang on to one/let go of one/<br> <bramus> iank_: (missed)<br> <bramus> iank_: i think the behavior today you will still size at width 300 and take into account the new ar, so you wont end up with 150 height<br> <bramus> iank_: and i think that might be fine<br> <bramus> emilio: not sure<br> <bramus> emilio: images may want to overrride that<br> <bramus> emilio: bc their intrinsic size is 0x0<br> <bramus> emilio: but video maybe we do not need to change intrinsic size<br> <bramus> emilio: consistency would b egood though<br> <bramus> Rossen_: so?<br> <bramus> Rossen_: we have resolution for original post<br> <bramus> Rossen_: suggest to open new issue for the 2nd thing<br> <bramus> Rossen_: we can record info there and give iank_ and emilio time to discuss<br> <bramus> Rossen_: we can come back to this later<br> <bramus> Rossen_: everyone ok with that?<br> <bramus> fantasai: ok<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7524#issuecomment-1204462924 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 20:43:26 UTC