Some XF values have fixed data and we now display them as gray cells where the user cannot edit them. However, the user should be able to remove the data. Ashley let me correct that. The user should not be able to remove the chip. But I wanna uh change the great out sales design by a chip design where you have a chip with the value in it. And you shouldn't be able to remove the chip, but clicking on the chip should inform you that it is this information is in the active data. removing this chip will not remove it from the exiv data and that remove it from the exiv data the file should be uploaded again without the exive data the user wants to remove. And now that I think of it, they can still remove it and it will say that it will only remove it in the Search your data on commas, but not from the XF data. Well no that doesn't make sense because a pot will come by and do it anyway so they should not be able to remove the chip with the exive data When clicking on the chip, it should also show all the other exif data that is available and that will automatically be published.
So this chip design should completely replace the uneditable fields in the table. Only one value is accepted in that cell, in those cells of exif data. So it's also not possible to add a different value. Turn ascent. It is fixed because you cannot remove the chip and you cannot add a different value or chip. However, the user is better informed and visually it's more coherent **Scope:** replace the muted "uneditable" rendering of read-only EXIF cells with a fixed (non-removable, non-editable) chip pill, and surface the file's full embedded EXIF in a click-to-open info popover so the user is informed about what the file actually carries.
== What's broken ==
Today the EXIF columns **camera, lens, focal, iso, aperture, shutter** (`src/table.jsx:97-102`, `tone: "exif"` + `editable: false` + `immutable: true`) render as muted disabled cells (`.tbl__td--immutable`, see `src/app.css:2360-2382` and `:3088-3109`). They look greyed-out, the cell click does nothing useful (`src/table.jsx:1573` short-circuits, then bubbles to the row's open-detail handler), and the user has no in-app way to discover what other EXIF data the file is actually carrying — even though that other EXIF travels with the file the moment it's published, with no opt-out.
== Wanted ==
Each of those six cells should render the value (when present) as a **fixed chip pill**:
- shape & spacing match the chip primitive introduced by [[ https://phabricator.wikimedia.org/T425887 | T425887 ]] / !54 (so the table's chip family stays visually coherent),
- distinct **subtle / neutral** tone (NOT progressive blue) — the user can't act on it, the colour shouldn't promise an action,
- inline lock indicator (or equivalent), no remove (`×`) control,
- `cursor: help`,
- click opens an **info popover** anchored to the chip.
The popover (uses the existing `PillInfoPopover` infrastructure at `src/table.jsx:4438`, kind `"exif"`):
- name and value of the field this chip represents,
- explainer copy: "Read from the file's embedded EXIF. The workbench can't suppress it on publish — Commons indexes EXIF and bots may transcribe parts of it to Structured Data later.",
- a scrollable list of every **other** EXIF tag/value the API returned for this file (so the user can see the full picture beyond the columns visible in the table).
When the EXIF field has no value, the cell shows the existing `—` placeholder — no chip, no popover.
== Where in the code ==
| File | Change |
|---|---|
| `src/api/normalize.js:158-249` | Add a `rawExif` array on the normalized item (every `{name, value}` from `info.metadata + info.commonmetadata`, post-flattenMetaValue, dropping null/empty/`_type`). Derived-runtime only — never persisted to user-store. |
| `src/table.jsx:1877-1882` (CellView for camera/lens/focal/iso/aperture/shutter) | Render value as `<span className="chip-pill chip-pill--fixed">…</span>` with inline lock icon. Click → `setPillInfo({ kind: "exif", value: { col, item }, anchorEl: e.currentTarget })`. |
| `src/table.jsx:4438` (PillInfoPopover) | New branch for `info.kind === "exif"` → renders `<ExifChipPopover>` analogous to the existing `DepictsPopover` / `CategoryPopover`. |
| `src/app.css` (near `:6683` — the `.chip-pill` block from T425887) | Add `.chip-pill--fixed` modifier (subtle/neutral colour family, `cursor: help`). Define a minimal `.chip-pill` base inline if T425887 hasn't merged yet — same selector / same shape, so the cross-MR merge collapses to a no-op. |
== Cells in scope ==
`camera`, `lens`, `focal`, `iso`, `aperture`, `shutter` (the six `tone:"exif"` + `editable:false` + `immutable:true` cells).
== Cells NOT in scope ==
- `dateTaken`, `cameraLocation` — `tone:"exif"` but `editable:true` (EXIF default, user-overridable); keep the inline editor.
- `size`, `dimensions`, `status` — immutable but **not** EXIF (computed from upload state); keep their existing rendering.
- `wikitext` — immutable launcher cell that opens a modal; unchanged.
== Acceptance criteria ==
1. The six EXIF cells render as a chip pill with the value, when the value exists; `—` placeholder when not.
2. The chip cannot be removed and cannot be edited (no `×`, no inline editor opens on click).
3. Clicking the chip opens an info popover; clicking outside / pressing Esc closes it.
4. The popover names the field, shows the value, includes the EXIF-stays-in-the-file explainer, and lists every other raw EXIF entry the API returned for the file.
5. The chip uses the same shape primitive as T425887's chips but a distinct neutral tone.
6. `npm run build` (incl. the `scripts/check-undefined-refs.mjs` scanner) passes.
== Notes ==
- What actually auto-publishes from this app (`src/api/publish.js:270-308` `buildSdcClaims`): depicts (P180), coordinates (P625), location-of-creation (P1071), date-taken (P571), self-author (P170). Camera/lens/ISO/aperture/shutter/focal are **NOT** written as SDC by this tool, and **not** referenced in the wikitext template (`buildWikitext`); they stay only inside the file's binary EXIF block. The popover copy reflects this accurately ("baked into the file", not "auto-published as SDC by this tool").
- Co-existence with T425887 (in flight as !54): the `.chip-pill` base class is shared. If T425887 hasn't merged when this MR lands, this MR defines a minimal compatible base. If it has, this MR only adds the `.chip-pill--fixed` modifier. No version bump (per merger's-job rule).