- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Fri, 15 Dec 2023 18:50:24 +0000
- To: public-css-archive@w3.org
A few more thoughts. ## Scaling Thinking about this a bit more, I don’t think we should restrict ourselves to descriptors that correspond to CSS properties. Obviously when concepts match we should re-use CSS property names as much as possible, but there are many concepts that are useful for manipulating images, but do not have a corresponding CSS property. It seems to me that `@image` can be a big win for things like sizing or repeat: Rather than adding properties for these in everything that can accept an image, *bake* them into the image. For 9-slice scaling, there is no corresponding CSS property that would make sense, but it seems pretty straightforward to add a descriptor like: ``` fit: fill | none | scale-down | scale-up | contain | cover | sliced(<length>#{1,4}) | <repeat-style> ``` or two separate descriptors (`fit` and `repeat`). Do note that since `src` refers to any `<image>`, `@image` rules can be chained to produce more complex effects. We also need to be able to optionally decouple the source bounding box from the output bounding box. The original proposal includes size properties as overriding the image’s intrinsic dimensions, but assumes these will also be the intrinsic dimensions of the output. ## Using `@image` for manipulations? I think we could have our cake and eat it too, with an optional `src` descriptor. `image(--foo)` just uses what is specified in the `src` descriptor if one exists, or is IACVT if one does not exist, and `image(--foo, url("foo.png"))` overrides it. We could even specify it so that in the latter uses the image in `src` as a fallback. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6807#issuecomment-1858344250 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 15 December 2023 18:50:25 UTC