Is your feature request related to a problem? Please describe.
The edirom-image-viewer web component depended on FontAwesome (resources/css/font-awesome.min.css) for 2 of its annotation category badge glyphs (beschreibung, rasurTektur in annotation-style.css). It also hardcoded that path (and annotation-style.css) as host-relative strings in its shadow-root CSS injection, and separately called a global getPreference() function with an eXist-db-specific /db/ path convention to locate the edition's own CSS — all of which tied the component to Edirom-Online-Frontend's specific app/backend, undermining its stated goal of being reusable in other host applications.
Describe the solution you'd like (current mechanism)
edirom-image-viewer.js: replaced the hardcoded cssFiles array (and the getPreference//db/ lookup) with a generic overlay-stylesheets observed attribute — a JSON array of hrefs/substrings the host supplies. _applyOverlayStylesheets() matches each entry against already-loaded <link rel="stylesheet"> tags in the host <head> (or uses it as a literal href) and clones matching ones into the shadow root. The component no longer has any built-in knowledge of a file path, a preference API, or the eXist-db /db/ convention.edirom-image-viewer.js (_renderOverlays()): each zone in zones-data may carry an optional iconHtml string; if present, the component inserts it verbatim (insertAdjacentHTML) into the badge. The component has zero knowledge of edirom-icon, FontAwesome, Material Symbols, or any icon system — it just mounts whatever markup the host decides to supply per zone, the same convention already used for host-supplied tooltip HTML.OpenSeaDragonViewer.js (bridge, parent repo): now computes the overlay-stylesheets value (annotation-style.css + the resolved additional_css_path edition CSS) and sets it on the component in initSurface — this is where the Edirom-specific preference/path lookup now lives. Still to do: populate iconHtml: '<edirom-icon name="description"></edirom-icon>' / '<edirom-icon name="ink_eraser"></edirom-icon>' for the beschreibung/rasurTektur zones when building zones-data, so the annotation badges actually render an icon again.annotation-style.css: the 2 FontAwesome ::before rules are removed; replaced with centering + --edirom-icon-size/--edirom-icon-color custom-property rules targeting an edirom-icon child element of those 2 badges (this file is host-side, so it's fine for it to know about edirom-icon specifically — only the component itself needed to stay generic).
Describe alternatives you've considered
- A CSS-only swap (
font-family: 'Material Symbols Outlined' + ligature content, reusing the same font edirom-icon loads, but without the component itself) — rejected since it doesn't actually use <edirom-icon>, just its underlying font.
- Having the component construct
<edirom-icon> directly (with a customElements.get('edirom-icon') feature-detection guard) via a hardcoded category→icon-name map — rejected: even a feature-detected reference to the specific tag name edirom-icon re-couples the shared component to one particular icon system/component, and a hardcoded Edirom taxonomy map (beschreibung, rasurTektur, …) bakes domain vocabulary into code meant to be reusable by other host apps.
- Keeping FontAwesome vendored/loaded by the component (rejected — redundant icon-font dependency, and doesn't fix the hardcoded host-path coupling).
Additional context
Affected files:
resources/js/edirom-image-viewer/edirom-image-viewer.js (component, submodule)app/view/window/image/OpenSeaDragonViewer.js (bridge, parent repo — overlay-stylesheets wiring done; iconHtml per-category wiring still pending)resources/css/annotation-style.css (parent repo — done)
Is your feature request related to a problem? Please describe.
The
edirom-image-viewerweb component depended on FontAwesome (resources/css/font-awesome.min.css) for 2 of its annotation category badge glyphs (beschreibung,rasurTekturinannotation-style.css). It also hardcoded that path (andannotation-style.css) as host-relative strings in its shadow-root CSS injection, and separately called a globalgetPreference()function with an eXist-db-specific/db/path convention to locate the edition's own CSS — all of which tied the component to Edirom-Online-Frontend's specific app/backend, undermining its stated goal of being reusable in other host applications.Describe the solution you'd like (current mechanism)
edirom-image-viewer.js: replaced the hardcodedcssFilesarray (and thegetPreference//db/lookup) with a genericoverlay-stylesheetsobserved attribute — a JSON array of hrefs/substrings the host supplies._applyOverlayStylesheets()matches each entry against already-loaded<link rel="stylesheet">tags in the host<head>(or uses it as a literal href) and clones matching ones into the shadow root. The component no longer has any built-in knowledge of a file path, a preference API, or the eXist-db/db/convention.edirom-image-viewer.js(_renderOverlays()): each zone inzones-datamay carry an optionaliconHtmlstring; if present, the component inserts it verbatim (insertAdjacentHTML) into the badge. The component has zero knowledge ofedirom-icon, FontAwesome, Material Symbols, or any icon system — it just mounts whatever markup the host decides to supply per zone, the same convention already used for host-supplied tooltip HTML.OpenSeaDragonViewer.js(bridge, parent repo): now computes theoverlay-stylesheetsvalue (annotation-style.css+ the resolvedadditional_css_pathedition CSS) and sets it on the component ininitSurface— this is where the Edirom-specific preference/path lookup now lives. Still to do: populateiconHtml: '<edirom-icon name="description"></edirom-icon>'/'<edirom-icon name="ink_eraser"></edirom-icon>'for thebeschreibung/rasurTekturzones when buildingzones-data, so the annotation badges actually render an icon again.annotation-style.css: the 2 FontAwesome::beforerules are removed; replaced with centering +--edirom-icon-size/--edirom-icon-colorcustom-property rules targeting anedirom-iconchild element of those 2 badges (this file is host-side, so it's fine for it to know aboutedirom-iconspecifically — only the component itself needed to stay generic).Describe alternatives you've considered
font-family: 'Material Symbols Outlined'+ ligaturecontent, reusing the same fontedirom-iconloads, but without the component itself) — rejected since it doesn't actually use<edirom-icon>, just its underlying font.<edirom-icon>directly (with acustomElements.get('edirom-icon')feature-detection guard) via a hardcoded category→icon-name map — rejected: even a feature-detected reference to the specific tag nameedirom-iconre-couples the shared component to one particular icon system/component, and a hardcoded Edirom taxonomy map (beschreibung,rasurTektur, …) bakes domain vocabulary into code meant to be reusable by other host apps.Additional context
Affected files:
resources/js/edirom-image-viewer/edirom-image-viewer.js(component, submodule)app/view/window/image/OpenSeaDragonViewer.js(bridge, parent repo —overlay-stylesheetswiring done;iconHtmlper-category wiring still pending)resources/css/annotation-style.css(parent repo — done)