/*
 * Custom-block chip styling for the mail template rich editor.
 *
 * Filament renders each inserted custom block as a bare
 * `div[data-type=customBlock]` with no class of its own (see the
 * fi-fo-rich-editor-custom-block-* classes on its children), so these
 * overrides target Filament's own compiled classes rather than anything
 * this app controls directly.
 */

/*
 * The template content editor is given a large min-height (see
 * TemplateFormSchema's extraInputAttributes on `template_content`) so its
 * live preview can show the whole email at once - which means the page,
 * not an internal box, does the scrolling. Without this, the toolbar and
 * the "Add block" panel scroll away with the content, forcing a scroll
 * back to the top just to insert another block.
 *
 * Scoped to `.mail-template-content-editor` (set via ->extraAttributes() on
 * that one field) rather than every `.fi-fo-rich-editor` - this used to be
 * global, which put a z-index on every small nested RichEditor too (Section/
 * Columns block content) and made their toolbar render on top of unrelated
 * Select dropdowns opened further down the same modal.
 */
.mail-template-content-editor .fi-fo-rich-editor-toolbar {
    position: sticky !important;
    top: 0 !important;
    /* Filament's own overlays (Select dropdowns, etc.) use z-index 20+ -
       this only needs to clear plain scrolling content, not compete with
       them, or it renders on top of a dropdown opened anywhere below it. */
    z-index: 1;
    /*
     * Transparent rather than a solid colour: the toolbar sits directly on
     * the Page Background Colour Group wrapping this whole field (see
     * TemplateFormSchema), which is dynamic per template/theme - a fixed
     * grey bar would clash with darker backgrounds instead of blending in.
     * Icon legibility on dark backgrounds is handled by .mail-canvas-dark
     * below rather than by giving the toolbar its own opaque colour.
     */
    background-color: transparent;
    /*
     * Filament's default border-bottom (a light grey line) is meant to
     * separate the toolbar from a plain white canvas - now that the toolbar
     * is transparent over the Page Background Colour instead, that line just
     * reads as a stray pale bar across a dark theme rather than a
     * deliberate divider, breaking the preview's flow into the canvas below.
     */
    border-bottom: none;
}

.mail-template-content-editor .fi-fo-rich-editor-panels {
    position: sticky !important;
    inset: auto !important;
    top: 2.75rem !important;
    max-height: calc(100vh - 4rem);
    overflow-y: auto;
}

/*
 * Filament's own `.fi-input-wrp` class (the field's outermost card
 * wrapper, one level further out than .fi-fo-rich-editor-main) carries a
 * default solid white background. That sits between the Page Background
 * Colour Group wrapping this whole field (in TemplateFormSchema) and the
 * editor's inner elements, hiding that colour everywhere except the inset
 * canvas itself. Force it transparent for this field only so the Group's
 * colour actually shows through in the surrounding margin.
 */
.mail-template-content-editor.fi-input-wrp {
    background-color: transparent !important;
}

/*
 * Inset the actual editable content to the canvas width instead of letting
 * it fill the whole box edge-to-edge, and give it its own Canvas Colour
 * (an adopted theme's own colour, or plain white otherwise) distinct from
 * the surrounding Page Background Colour applied to the Group wrapping
 * this whole field in TemplateFormSchema. Both custom properties are set
 * inline by the same extraInputAttributes closure.
 */
.mail-template-content-editor .fi-fo-rich-editor-content {
    max-width: var(--mail-canvas-width, 100%);
    margin-inline: auto;
    background-color: var(--mail-canvas-background, #fff);
    /* --mail-canvas-gradient is "none" when the theme has no Canvas
       Gradient colour set, so this simply has no effect over the solid
       background-color above. */
    background-image: var(--mail-canvas-gradient, none);
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.12);
}

/*
 * The Page Background Colour Group (see TemplateFormSchema) adds this class
 * when EmailColorClasses::isDarkHex() judges its own background colour too
 * dark for the toolbar's normal grey icons to stay legible against - the
 * toolbar itself has no opaque background of its own (see above), so its
 * icons sit directly on whatever colour the Group is. Targets the RichEditor
 * toolbar's own dedicated classes (.fi-fo-rich-editor-tool and the dropdown
 * tool trigger/chevron for things like the heading-level picker) - NOT the
 * generic .fi-icon-btn, which is a different, unrelated Filament component
 * this toolbar doesn't actually use.
 */
.mail-canvas-dark .fi-fo-rich-editor-toolbar .fi-fo-rich-editor-tool,
.mail-canvas-dark .fi-fo-rich-editor-toolbar .fi-fo-rich-editor-dropdown-tool-trigger,
.mail-canvas-dark .fi-fo-rich-editor-toolbar .fi-fo-rich-editor-dropdown-tool-chevron {
    /*
     * Filament's own compiled CSS always references these custom properties
     * bare (e.g. `color:var(--gray-300)`), never wrapped in `rgb()` - they
     * hold complete, ready-to-use colour values (not raw RGB channel
     * triplets), so wrapping one in rgb() as done previously produced an
     * invalid declaration the browser silently drops.
     */
    color: var(--gray-300);
}

/*
 * Filament's own hover state (.fi-fo-rich-editor-tool:hover) always gives the
 * button a light background-color:var(--gray-50), regardless of this dark
 * canvas class - so the hovered icon needs to switch back to a dark colour
 * here, not a lighter one, or it disappears against its own light hover
 * background.
 */
.mail-canvas-dark .fi-fo-rich-editor-toolbar .fi-fo-rich-editor-tool:hover,
.mail-canvas-dark .fi-fo-rich-editor-toolbar .fi-fo-rich-editor-dropdown-tool-trigger:hover {
    color: var(--gray-700);
}

/*
 * Filament's Section component clips its content wrapper with
 * `overflow: hidden` (for the rounded-corner/shadow effect), which silently
 * defeats `position: sticky` on anything nested inside it - the toolbar
 * above would compute a sticky position but never visibly "stick" because
 * its containing block clips before it ever reaches the edge. Only lift the
 * clip on the section that actually holds the template content editor, so
 * other sections (including modals) keep their rounded-corner clipping.
 */
.fi-section-content-ctn:has(.mail-template-content-editor) {
    overflow: visible !important;
}

/*
 * NOTE: a previous attempt fixed here also disabled container-type on
 * .fi-section-content and .fi-fo-rich-editor (Filament's container-query
 * mechanism for its own responsive layouts) to unblock position: sticky.
 * That broke Filament's own container-query-based responsive layout for
 * the custom-blocks panel (it started always rendering full-width under
 * the toolbar instead of as a side panel) without actually fixing
 * stickiness either, so it's been reverted. Sticky toolbar/panel
 * positioning for this editor remains an open problem.
 */

.fi-fo-rich-editor .tiptap div[data-type='customBlock'] {
    position: relative;
    box-shadow: none;
    outline: 1px solid transparent;
    transition: outline-color 75ms ease-in-out;
}

.fi-fo-rich-editor .tiptap div[data-type='customBlock']:hover {
    outline: 1px dashed #31708f;
}

/*
 * The header (with its edit/delete buttons) still exists and still works -
 * it's just not permanently visible, and no longer spans the full block
 * width. Shrunk to a small top-left badge showing just the block name and
 * its buttons, floating it out of the flow and fading it in on hover keeps
 * both buttons reachable without reserving a grey banner's worth of space
 * on every block all the time.
 */
.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-header {
    position: absolute;
    inset-inline-start: 0.375rem;
    inset-inline-end: auto;
    top: 0.375rem;
    z-index: 10;
    width: auto;
    max-width: calc(100% - 0.75rem);
    gap: 0.375rem;
    border-radius: 0.375rem;
    padding-inline: 0.5rem;
    padding-block: 0.25rem;
    box-shadow: 0 1px 3px rgba(0, 0, 0, 0.15);
    opacity: 0;
    pointer-events: none;
    transition: opacity 75ms ease-in-out;
}

.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-header .fi-fo-rich-editor-custom-block-heading {
    flex: 0 1 auto;
    overflow: hidden;
    white-space: nowrap;
    text-overflow: ellipsis;
    font-size: 0.75rem;
}

.fi-fo-rich-editor .tiptap div[data-type='customBlock']:hover .fi-fo-rich-editor-custom-block-header,
.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-header:focus-within {
    opacity: 1;
    pointer-events: auto;
}

/*
 * A custom block's own preview HTML (e.g. the Columns block's nested
 * RichEditor body) is rendered inside Filament's own `fi-not-prose`
 * wrapper, which deliberately excludes it from Filament's `.fi-prose`
 * typography rules - so headings created via the nested editor's H1-H6
 * options otherwise all render at the same flat size. Restore standard
 * heading sizing within that preview specifically.
 */
.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview h1 {
    font-size: 1.875rem;
    line-height: 1.2;
    font-weight: 700;
}

.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview h2 {
    font-size: 1.5rem;
    line-height: 1.33333;
    font-weight: 700;
}

.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview h3 {
    font-size: 1.25rem;
    line-height: 1.4;
    font-weight: 700;
}

.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview h4 {
    font-size: 1.125rem;
    line-height: 1.55556;
    font-weight: 700;
}

.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview h5 {
    font-size: 1rem;
    line-height: 1.5;
    font-weight: 700;
}

.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview h6 {
    font-size: 0.875rem;
    line-height: 1.42857;
    font-weight: 700;
}

/*
 * That same `fi-not-prose` wrapper (see above) also excludes the preview
 * from `.fi-prose`'s "lobotomized owl" rule - `:where(* not fi-not-prose) +
 * :where(* not fi-not-prose) { margin-top: 1rem }` - which is what gives
 * every element vertical spacing from the one before it everywhere else in
 * the editor. Without it, consecutive paragraphs inside a block's preview
 * (Section, Columns/Row column bodies, Content, etc.) render pressed
 * together with no gap, even though the same text shows correctly spaced
 * while actively being edited in that block's own `.fi-prose`-wrapped
 * RichEditor. Scoped to `p + p` only, rather than reintroducing the whole
 * owl selector, so it doesn't also add unwanted margin between flex/table
 * layout siblings (e.g. the Columns block's own column divs) that this
 * preview markup relies on `gap`/explicit spacing classes for instead.
 */
.fi-fo-rich-editor .tiptap .fi-fo-rich-editor-custom-block-preview p + p {
    margin-top: 1rem;
}

/*
 * Full screen mode for the "Email Content" section (toggled by the button
 * in content-fullscreen-toggle.blade.php, which flips the `fullScreen`
 * Alpine state set on this Section's own extraAttributes in
 * TemplateFormSchema). Lifts the whole section - heading, footer actions,
 * and the content editor together - out of the page flow to cover the
 * viewport, so the editor gets the full window instead of a card-width
 * column.
 *
 * z-index: 40 clears Filament's topbar/sidebar (z-20) but stays below its
 * modals (z-50) - the Preview/Send Test actions on this same section still
 * need to open on top of it.
 */
.mail-template-content-section--fullscreen {
    position: fixed !important;
    inset: 0.75rem;
    z-index: 40;
    overflow-y: auto;
    background-color: var(--gray-50, #f9fafb);
}

:is(.dark .mail-template-content-section--fullscreen) {
    background-color: var(--gray-900, #101828);
}

/*
 * Full screen only makes sense for the email RichEditor - the SMS/WhatsApp
 * Textarea beside it is already a small, fixed box. `data-content-type` is
 * set on the same Section wrapper from TemplateFormSchema's extraAttributes
 * (a plain Get() closure, which resolves reliably there, unlike inside the
 * afterHeader sub-schema the toggle button itself renders in - see that
 * file for why this isn't a Filament ->visible() check instead).
 */
.mail-template-content-section:not([data-content-type='email']) .content-fullscreen-toggle {
    display: none;
}

/* Stops the page itself from also scrolling behind the fixed section. */
body:has(.mail-template-content-section--fullscreen) {
    overflow: hidden;
}