- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Sep 2022 17:09:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `@image rule for manipulating images`, and agreed to the following: * `RESOLVED: Accept @image and add it to css-images-5` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: @image rule for manipulating images<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/6807<br> <heycam> TabAtkins: this is a request for feedback and possible WD, precised details are being discussed on the thread<br> <heycam> ... this is a request for a way to manipulate images directly in CSS<br> <heycam> ... right now you can do a handful of things directly in CSS<br> <heycam> ... certain repetitions with background properties<br> <heycam> ... but anything more complex, running a filter on it, opacity, etc. your only choice is to use a separate image, or to put it on a declarative element and then apply CSS properties to that element<br> <heycam> ... this is trying to split the different, and allow existing existing effecfts (transforms, filters), directly in a CSS image<br> <heycam> ... rough approach is an @image rule, which provides a doubel dashed name<br> <heycam> ... a bunch of descriptors, which takes a src image, then others which are copies of other CSS properites that do useful things<br> <heycam> ... currently only supporting things you can already do to elements<br> <heycam> ... once defined, you could use this image in CSS<br> <heycam> ... image(--foo)<br> <Rossen_> q?<br> <heycam> q+<br> <Rossen_> ack heycam<br> <fantasai> heycam: Alternative approach is to slam all of these filtering and transforms into the image() function itself<br> <fantasai> heycam: if you need to re-use that, put it all into a custom property<br> <fantasai> heycam: have you thought about that?<br> <heycam> TabAtkins: I don't believe there's a great reason to go one way or the other<br> <heycam> ... back in the day, using it in an image() function you'd need to repeat it<br> <heycam> ... but with variables it's not a huge deal now<br> <heycam> ... some bits of functionality like image layering have been discussed, but more widely as pulling in SVG's filter capabilities via nested at rules<br> <heycam> ... having them be consistent in approach would be nice<br> <heycam> ... but now that I bring that up, it could still be done using CSS functions<br> <heycam> ... it would be a matter of what we find more convenient to do, or more natural<br> <JakeA> q+<br> <heycam> ... don't think there's a huge way to go one way or the other<br> <Rossen_> ack dbaron<br> <heycam> dbaron: could you talk briefly about how sizing of these images works?<br> <heycam> ... looks like there's some sizing related properties in there<br> <heycam> ... transforms and filters which might have sizing implementations<br> <heycam> TabAtkins: you have a width/height property<br> <heycam> ... that's the natural width/heihgt of the produced image<br> <heycam> ... scaling etc. would be purely visual effects<br> <andreubotella> q+<br> <heycam> ... it would scale it within the bounds of the width/height that's already been provided<br> <Rossen_> ack JakeA<br> <heycam> JakeA: for blurring a low quality image as a placeholder<br> <heycam> ... that's difficult with filters now, because it blurs the edge as well<br> <heycam> ... here you want to recognize the edge and not blur the transparency into it<br> <heycam> ... so it works a bit more like backdrop-filter<br> <Rossen_> ack andreubotella<br> <heycam> andreubotella: could you use such an @image rule in the src property?<br> <heycam> ... if you already have declared an image, then you want to apply some further transformations to that?<br> <heycam> ... and for the current properties, it seems like you could apply a set of properties to multiple images<br> <heycam> TabAtkins: the exact answer to that depends on what we want to define<br> <heycam> ... being able to put a generated image in as the source of a new generated image is reasoanble<br> <ydaniv> q+<br> <heycam> ... whether that gets rasterized then transformed, as if it's an independent image, or these transformations are additively appended to the list of existing transformations in some intelligent fashion? no opinion<br> <heycam> ... both have pros/cons. simplicity on one side, understandability<br> <heycam> ... avoiding rasterization effects<br> <heycam> ... both seems potentially reasonable<br> <heycam> ... can discuss those<br> <heycam> andreubotella: thinking also maybe not having it rasterized, that might limit the properties we could add to @image rules<br> <heycam> TabAtkins: I think everythign we've discssed so far in the thread is compatible with just holding it as a scene graph<br> <heycam> ydaniv: might be some advantage to have this rasterized beforehand<br> <Rossen_> ack ydaniv<br> <heycam> ... if you're just setting the properties outside the at rule, you could have them animated<br> <heycam> ... then if you want to do further animations on the element, then have the browser apply all of these at the same time every frame, could be heavy for the browser to handle<br> <heycam> ... so maybe this could be some sort of performance boost<br> <heycam> ... another thing that might be way off, if you're thinking about syntax, having this for replaced images, object manipulation, that could be useful<br> <heycam> ... so not just for background-image, <image> values, but use the same manipulations on replaced elements like straight on an <img> element<br> <heycam> TabAtkins: right now you can take any replaced element and put properties on it<br> <heycam> ... but you want to be able to run these on the underlying image itself, and still be displayed in the bounds of the image element? so apply a rotate to the source image?<br> <heycam> ydaniv: I want to optimize for having the src already rasterized, then if I'm rotating the image outside, then the browser doesn't have to handle rasterizing every frame<br> <heycam> ... what you're saying is another use case which is also valuable<br> <Rossen_> ack dbaron<br> <Zakim> dbaron, you wanted to talk about ordering<br> <heycam> dbaron: Andreu's comment made me think about another set of questions about the ordering of these operations<br> <heycam> ... in CSS, a bunch of these things are properties where the order that they apply in is defined by our processing model<br> <heycam> ... the relative ordering we apply opactiy, filter, transform, etc. on a single element is defined by CSS's processing model<br> <heycam> ... one thought is that re being able to nest the output of one of these as the source of another, that's probably quite useful, since sometimes you want to apply these things in a differetn order than how CSS's processing model works<br> <heycam> TabAtkins: os the same descriptor multiple times in different fashions<br> <heycam> s/os/or/<br> <heycam> dbaron: maybe falling back to that processing model isn't the right thing here? for this rule, the graphical operations maybe shouldn't be order independent?<br> <heycam> ... so the order of the descriptors matters<br> <heycam> TabAtkins: if you have them in an order, that implies you should be able to repeat: rotate, blur, rotate<br> <heycam> ... first, object model issues<br> <heycam> ... also, that would run into our forward compat fallback ability<br> <heycam> ... where you can say something twice and ignore the first, unsupported value<br> <heycam> ... but I like the way you are thinking<br> <heycam> ... having this order be controllable is probably a great idea<br> <Rossen_> q?<br> <emilio> q+<br> <Rossen_> ack emilio<br> <heycam> emilio: that kind of issue disappears if you add the operations in the image() function<br> <heycam> TabAtkins: yes, it removes the fact taht ordering and repetition is ap roblem<br> <heycam> ... now support is an all or nothing for the entire graph<br> <heycam> ... on the other hand, if an image transform isn't supported, and you are trying to rely upon it, you probably do want the whole thing to fail<br> <heycam> ... so that is an argument in favor of a function<br> <heycam> q+<br> <emilio> heycam: I realized that there might be a semantic difference between image() and the at rule<br> <Rossen_> ack heycam<br> <emilio> ... each of those are a different image<br> <emilio> ... is there any situation where having the image defined in the at-rule lets you have a single place where you can do image manipulations, where with image() you'd need to apply the transform to all uses of the image() function<br> <emilio> ... it's probably not an issue, I don't think they can express different things<br> <emilio> TabAtkins: being able to say that one in an at-rule there's an efficiency arg to be made there<br> <heycam> TabAtkins: how to animate an at rule is an open question<br> <heycam> ... how to animate a function is already a reasonably solved problem<br> <heycam> ... match up lists, animate individual parameters<br> <heycam> TabAtkins: does the WG feel this is OK, or objectiosn to the approach in general?<br> <heycam> fantasai: my main concern is prioritization wrt other things we're doing<br> <heycam> ... other than that doesn't seem terrible<br> <heycam> Rossen: from a use case approach, it's fine<br> <heycam> fantasai: definitely needs a lot more work<br> <heycam> Rossen: that's like most other work we take on<br> <heycam> fantasai: this is not a small task<br> <heycam> Rossen: assuming Mia and others will be contributing to this?<br> <heycam> TabAtkins: I'm shepherding this<br> <andreubotella> /s/Mia/Lea/<br> <heycam> Rossen: acknowledge this adds more work to the group, but I'm hearing support for the use case and approach<br> <heycam> ... so I'm personally OK with this<br> <fantasai> s/Mia/Lea/<br> <heycam> TabAtkins: do we want this added to images 5, or is it larger enough to be split out?<br> <heycam> fantasai: what else is in images 5?<br> <heycam> Rossen: almost nothing<br> <heycam> fantasai: current images is images-4. images-5 is just an ED, don't think there's anything even in it<br> <heycam> TabAtkins: just want to know if it should be merged into the totality of the images spec<br> <heycam> RESOLVED: Accept @image and add it to css-images-5<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6807#issuecomment-1248380039 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 September 2022 17:09:19 UTC