- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Feb 2021 00:47:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-conditional] [css-contain] `srcset` and `sizes` interaction with container queries``. <details><summary>The full IRC log of that discussion</summary> <astearns> topic: [css-conditional] [css-contain] `srcset` and `sizes` interaction with container queries<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/5889<br> <dlibby> una: next issue is related - how to deal with responsive images in container queries<br> <dlibby> una: would like to explore the solution space, since it seems like it'll be pretty common<br> <dlibby> una: adding a ??? to srcset, setting images on each compute, since they come from server<br> <bkardell_> q+<br> <dlibby> una: how should container queries interact, and background images are also a consideration<br> <bkardell_> how would this work with preloading? https://web.dev/preload-responsive-images/<br> <dlibby> s/???/new syntax/<br> <dlibby> una: do something simliar to media queries but seems important to consider for container queries<br> <astearns> ack bkardell_<br> <dlibby> bkardell: preloading - see linked article. you can't know what to load until later<br> <dlibby> una: yes, tricky because working at compute time, not sure how this works for viewport size<br> <dlibby> emilio: you can estimate what your viewport is<br> <dlibby> emilio: you can make a decent guess in iframes<br> <dlibby> emilio: you can't really do this in containers<br> <dlibby> iank: relatively sure that gecko and chromium reference image via background: url(foo), but can have multiple decls<br> <dlibby> iank: UA load images after computed value time so you don't load lots of things in the background<br> <dlibby> iank: it's a performance tradeoff<br> <dlibby> emilio: <img> tags are a little more important as user wants to immediatly see it<br> <dlibby> florian: worried that this could make slow connections slower<br> <dlibby> florian: you normally don't get all resources at the first request, progressive modification, which happens more on slow networks. as this happens container can change, possible to congest/thrash network<br> <dlibby> florian: that sounds unfortunate side effect<br> <dlibby> una: if youre using container queries and there's a hero, or in a card, or sidebar, those are different<br> <dlibby> una: if container queries allow for composable styles in components, I can't imagine that we can't have different image sizes based on the size<br> <bkardell_> not just image sizes maybe different art direction too?<br> <dlibby> una: not sure if it is slower to load a bunch of images first, or layout first then download other images<br> <bkardell_> I suggest we send this to RICG :)<br> <dlibby> florian: use case makes sense - should and can are different questions<br> <dlibby> florian: if you have multiple small parts, many changes could be happening, and as the stylesheet comes in over network, you might end up loading all the images<br> <dlibby> florian: ending up there sounds bad, but perhaps there's another approach<br> <dlibby> myles: problem appears endemic to container queries<br> <dlibby> florian: most thrashing doesn't hit the network for each change<br> <dlibby> una: perhaps we can scope to initial load to avoid this problem - maybe solves the majority use cases<br> <dlibby> emilio: not sure - if you resize the window, you'd bet stuck in possible suboptimal state<br> <fantasai> I was about to say the same thing also<br> <dlibby> myles: I don't think visual layout should be permanently affected based on network speed<br> <dlibby> myles: CSS shouldn't be sensitive to timing of bytes on the wire<br> <dlibby> una: might be misunderstanding. when we figure out the layout size keep that image<br> <dlibby> una: refresh page would get different images<br> <dlibby> emilio: layout while stylesheets are outstanding is common. stylesheet in body can affect the page layout, this should be taken into account<br> <dlibby> iank: the place where this functionality may make sense is html layout. some components are already stateful, but this should be carefully considered<br> <dlibby> e.g. a oneshot load - how does this affect the html layout, something to consider<br> <nicole> a balance btw not requesting unnecessary images and not waiting to load images until css is done parsing<br> <dlibby> myles: maybe specify behavior, UAs can use different heuristics<br> <dlibby> myles: CSSWG doesn't have to specify when loads are triggered<br> <dlibby> iank: option for this would be adding to Image specificiation (perhaps additional data on <img>) once this has been laid out and it reaches 'stable' state, then UA can fire off request<br> <dlibby> ???: problem with containment in general?<br> <fantasai> s/????/nicole/<br> <fantasai> s/???/nicole/<br> <dlibby> emilio: perhaps one approach is to define what the behavior should be (lazy or something). just a gneeral problem with containment.<br> <dlibby> s/containment/container queries/<br> <dlibby> iank: reasonably easy to polyfill, prototype, iterate to discover 'good behavior'<br> <dlibby> iank: don't have to nail down spec text right now, we can try to find optimal via prototyping<br> <dlibby> bkardell: might be good to ask folks on ??? CG<br> <jensimmo_> yes, do ask Mat.<br> <dlibby> bkardell: to the point of wanting different size, you might want different art directives(?)<br> <dlibby> astearns: is it possible to load different images?<br> <dlibby> iank: yes this is possible to get different urls<br> <dlibby> astearns: that is for separate declarations, but this is for a single declaration<br> <dlibby> iank: i was referring to img tag attribute, there's nothing in CSS currently that allows for this<br> <dlibby> nicole: having it in CSS should be the same problem as having this specified in the html itself. likely has same characteristics<br> <dlibby> una: i recognize that this is probably for specification in HTML<br> <dlibby> una: glad bkardell brought up different images - third party service could provide different crops<br> <dlibby> bkardell: precisely, that's what I wanted to be recognized<br> <dlibby> astearns: what else would you like to get from the group?<br> <dlibby> una: this conversation basically<br> <dlibby> astearns: perhaps prototyping per iank is the way forward, thanks for bringing it up<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5889#issuecomment-777893985 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 February 2021 00:47:38 UTC