RFC: A plan for a core image story #500
Conversation
proposals/0030-core-image-story.md
Outdated
| In tandem with the `src/assets` folder, we'd like to introduce a way for users to specify that a specific property needs to refer to a valid asset from the `src/assets` folder: | ||
|
|
||
| ```ts | ||
| import { asset, defineCollection, z } from "astro:content"; |
There was a problem hiding this comment.
(bikeshed comment, not blocking my approval on this RFC)
Any thoughts on matching asset naming? My brain says that import {asset} is too generic, but I see that you're trying to match the format of z.asset() which makes sense. import {assetSchema} is less generic, but now feels so different from z.asset().
What about import {a} from 'astro:content';? Then this snippet would look like:
import { defineCollection, a, z } from "astro:content";
const blogCollection = defineCollection({
schema: z.object({
title: z.string(),
image: a.asset({ width: 1120, height: 1120 }),
}),
});Or, another idea that's probably less controversial:
import { defineCollection, schemas, z } from "astro:content";
const blogCollection = defineCollection({
schema: z.object({
title: z.string(),
image: schemas.asset({ width: 1120, height: 1120 }),
}),
});IDK, maybe too early to be thinking about this since it's the first custom schema we're shipping. Like I said, no need to block on this, and also happy to revisit when we add our second or third custom schema.
There was a problem hiding this comment.
I can't say I have any particular thoughts on this. I like the schemas.asset one though, but maybe schema is a bit too foreign for users not used to Zod?
|
I had spoken with @Princesseuh about how cool it would be to store blog images in the Super happy to see this feature could be landed on Astro, especially with all the optimization and resizing tools... I'm testing this immediately! Thanks for the excellent work 😊 |
| ```html | ||
| <!-- Remote images are not optimized or resized. Nonetheless, you still benefit from the enforced attributes and the guarantee of no CLS, albeit manually. --> | ||
| <img | ||
| src="https://example.com/image.png" | ||
| decoding="async" | ||
| loading="lazy" | ||
| width="1280" | ||
| height="720" | ||
| alt="..." | ||
| /> | ||
| ``` |
There was a problem hiding this comment.
Do you think pixel-density is within scope of this API?
The output would look something like this:
<img
srcset="
/_astro/my_image.dp1hash.webp 1600w,
/_astro/my_image.dp2hash.webp 3200w
"
sizes="(min-width: 3200px) 3200px, 100vw"
src="/_astro/my_image.dp1hash.webp"
/>I'm not quite sure what the inputs should be. Currently the @astrojs/image Picture component accepts a widths: number[]. But sizes and srcset are available on <img> without a <picture>, so I would expect Image to support them as well.
At a minimum, I think there should be some way to tell Image to generate image files for a list of widths.
Could it be calculated from srcset? From sizes? Is widths required? I'm not sure about these details.
See also Responsive images with srcset and sizes and Optimal Images in HTML.
There was a problem hiding this comment.
This is considered out of scope for this current proposal (see the non-goals section, it's part of it)
You can achieve this with the APIs shipped in 2.1 technically, but in the future we aim to have official support, just not in this version.
There was a problem hiding this comment.
This is considered out of scope for this current proposal
As long as the APIs proposed here don't preclude it being added in the future, I'm hugely supportive of shipping one thing at a time 😄👍
|
@Princesseuh I tried the relative asset in Markdown as described in RFC here https://github.com/withastro/roadmap/blob/feat/core-image-story/proposals/0030-core-image-story.md#image-in-markdown I was also wondering if SVG could profit of colocation without necessarily enduring any optimization or is it rather just excluded for the moment ? |
Relative images in Markdown are still part of the plan, as you can see on this page: https://docs.astro.build/en/guides/assets/ They're currently supported in the experimental feature, although people have been reporting issues getting it working (that I'm hoping to fix next week!) SVGs are out of scope for this specific feature at the moment, but could certainly be included in the feature in the future (specifically meaning relative assets, not optimization) |
|
We are now entering the final comment period of this RFC. If there are no objections it will be merged later this week. Thanks! |
|
An emphatic +1 on this RFC! Thank you for all of your hard work on this @Princesseuh! |
Summary
This RFC aims to outline a plan to simplify the usage, optimization and resizing of images in Astro without the need of an integration.
Links