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)

Change #1091815 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex@main] [WIP] Image: Add Image component

https://gerrit.wikimedia.org/r/1091815

Change #1091840 had a related patch set uploaded (by Abaris; author: Abaris):

[design/codex@main] [WIP] ImageContainer: Add ImageContainer component

https://gerrit.wikimedia.org/r/1091840

In the task specifications for the ImageContainer component, there is no explicit mention of how the container’s width and height should be handled. While implementing the component, I used container-specific width (380px) and height (230px) to define the dimensions.

It would be helpful to clarify whether the container’s width and height should:

1. Be inherited from the Image dimensions,
2. Be set explicitly through ImageContainer props (as I have done in my implementation), or
3. Be fully customizable through user-defined styles.

Could this be addressed in the design spec or during development? Thank you! You can see my current work in the video below.

{F57721910}

@bmartinezcalvo I'd like to add an example to the Image demo page of an illustration that's different in RTL and LTR. Could you please export images that we can use for this, like the ones you used in the Figma spec?

El T314514#10376294, @AnneT escribió:

@bmartinezcalvo I'd like to add an example to the Image demo page of an illustration that's different in RTL and LTR. Could you please export images that we can use for this, like the ones you used in the Figma spec?

The idea is that we should create the LTR and RTL version for those illustrations communicating any of the mirroring recommendations from the Bidirectionallity guidelines (e.g. when communicating direction, horizontal orientation, or navigation).

LTR	RTL

So I've included illustrations examples for both cases:

• Map: it should not be mirrored, so the same illustration is used for both LTR and RTL.
• Article: it should include the mirror version since the reading direction is different in LRT and RTL.

@bmartinezcalvo this is perfect, thank you!

Change #1091815 merged by jenkins-bot:

[design/codex@main] Image: Add WIP Image and component

https://gerrit.wikimedia.org/r/1091815

Thank you for working on this @Anne. Listing here some feedback collected from yesterdays DST design sync in case we want to apply this feedback in future versions of Image:

• When the Image is loading, a skeleton would be more appropriate than the placeholder.We could complete this once the Skeleton is implemented in T311874.
• Evaluate the need of an error state. In case we need an error in Image, the error state should always provide an error message explaining how to fix that.
• We will need to define how width, height, and aspect ratios should interact.
• We will need to evaluate if we want to use the border-radius-base (2px) to style the images radios as in other components.
• We will need to include some of the decisions applied in Thumbnail:
  • Probably use a subtle border to avoid white images to merge with the background of the page
  • Set background-color-base-fixed so PNG images are visible in dark mode.
• Evaluate if we want to tokenize available options for objectFit and objectPosition to avoid unnecessary complexity.

Change #1101943 had a related patch set uploaded (by LWatson; author: LWatson):

[mediawiki/core@master] Update Codex from v1.17.0 to v1.18.0

https://gerrit.wikimedia.org/r/1101943

Change #1101943 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.17.0 to v1.18.0

https://gerrit.wikimedia.org/r/1101943