FWIW, Codex thumbnails use background image styles, not actual <img> elements. If we want Thumbnail to use the Image component internally, we would either need to change that in the Thumbnail or support use of background images in the Image component.

I wanted to add a few implementation-specific notes which might impact design of this component as well.

• I'd recommend limiting the initial MVP version of this component to <img> elements (no CSS background-image use yet). The img element provides onload and onerror events that we can use to implement lazy-loading and fallback behavior; images loaded via CSS don't provide the same interface (though we may be able to figure out workarounds later).
• Modern CSS already provides pretty sophisticated controls for control of image aspect ratio, cropping, and positioning. Rather than duplicating a lot of this functionality ourselves within the component, I think we should just expect the user to style image components using these CSS properties. We could still provide design tokens or LESS mixins for commonly used image styles (including pre-defined aspect ratios).
• I think that this v-lazy-image component on GitHub is a good example of the kind of thing we'll want to build in Codex – this component is very simple and style-free; the component controls the loading and fallback behavior but not much else, with the expectation that styling should come from the user.

So maybe we need to build two different things here:

• A basic CdxImage component similar to v-lazy-image that manages loading/fallback state for images using the IntersectionObserver API (where the user provides a src or srcset, a fallback src, and intersection observer options); this component would have very little additional styling on its own
• Some tokens and mixins to provide consistent values for one or more style properties – aspect ratio, border, CSS transitions/animations, background color during fallback state, etc.

In the future we could build more specific components on top of the base Image component that are more opinionated in terms of appearance & behavior.

During the last Eng/Design sync we decided that aspect ratios will not be defined as tokens but they will be included in the Image component as component's property. So I've created the Figma spec sheet accordingly with this and adding the following:

1. Aspect ratios (16:9, 3:2, 4:3, etc.) have been added as component's property
2. Image component will have 2 states: default and loading (using the Skeleton once it's implemented in T311874)
3. If Image component doesn't have an image uploaded, it will display the placeholder
4. Placeholder icon will scale from a minimum size (12px) to a maximum size (40px). More details in the spec.
5. RTL behavior: the image component will not be mirrored but the assets for the image component will be created/exported in both LTR/RTL in some cases (e.g. illustrations)

Apart from the image component, we will create an ImageContainer or Figure in the future, where we will implement the image position within a container, the image's container borders and caption (image text). This will be done in a separate task. I've defined some of the aspects in this other spec to grab the differences between Image and ImageContainer.

Let me know your feedback about all this.

There is one open question to solve in the task before implementing the Image component: Do we want an option to provide a specific px size in the image? (use case from VE image settings)