/**
 * @file
 * CKEditor 5 edit-page rendering corrections.
 *
 * Two related fixes for how the editor behaves against the fixed admin toolbar
 * while scrolling. See also the sticky-toolbar viewport-offset fix in
 * js/ckeditor5-viewport-offset.js.
 */

/**
 * 1. Stop the page scroll from getting "stuck" while an image is selected.
 *
 * A selected image pins a balloon toolbar that repositions on every scroll,
 * flipping above/below the image as it crosses the viewport. Near the top (where
 * the admin toolbar sets an ~80px offset) those repositions shift layout just
 * enough that the browser's scroll-anchoring snaps the scroll position back,
 * trapping the user: scrolling slowly bounces in place, while scrolling fast
 * jumps clean past it. Disabling scroll anchoring on the scroll container removes
 * the snap-back; the balloon still repositions, the scroll just no longer fights
 * it. Scoped with :has() to pages that actually contain an editor, so front-end
 * scroll anchoring is untouched. `html` and `body` are both listed because which
 * one is the scroll root varies by theme.
 */
html:has(.ck-editor),
body:has(.ck-editor) {
  overflow-anchor: none;
}

/**
 * 2. Keep the sticky editor toolbar *under* the admin toolbar.
 *
 * CKEditor's sticky toolbar (`.ck-sticky-panel__content`, made position:fixed
 * while pinned, then position:absolute as it scrolls out) carries z-index 1000,
 * well above the Drupal admin toolbar's 502. While pinned flush below the admin
 * toolbar that is invisible, but as the editor scrolls out of view the toolbar
 * passes up through the admin toolbar and — winning on z-index — renders on top
 * of it until it is gone. Dropping it below the admin toolbar makes it slide
 * under, as expected. 400 sits below the admin toolbar (502) and above page
 * content.
 *
 * CKEditor sets the 1000 with `.ck.ck-sticky-panel .ck-sticky-panel__content_sticky
 * { z-index: var(--ck-z-panel) }` from a runtime-injected <style> that loads
 * after this file, so an equal-specificity rule would lose on source order. We
 * repeat the `_sticky` modifier class to raise specificity above CKEditor's and
 * win regardless of order. The element only exists (and only carries z-index)
 * while sticky, so no extra scoping is needed.
 */
.ck.ck-sticky-panel .ck-sticky-panel__content.ck-sticky-panel__content_sticky {
  z-index: 400;
}

/**
 * 3. Breathing room inside the editing area.
 *
 * CKEditor 5 gives the inline editable `padding: 0 var(--ck-spacing-standard)`,
 * which computes to `0 9.6px` here: no vertical padding at all, so the first and
 * last blocks sit flush against the field's border, and a template's own border
 * lands directly on top of it. Authors read that as the content being clipped.
 *
 * The selector repeats `ck-editor__editable` to outrank CKEditor's own
 * two-class `.ck.ck-editor__editable_inline` rule, which is injected at runtime
 * and therefore wins any equal-specificity contest on source order. Same
 * reasoning as the sticky-panel rule above.
 *
 * This is the editing surface only. It is not `.ck-content`, so it does not
 * follow the markup out to the rendered page.
 */
.ck.ck-editor__editable.ck-editor__editable_inline {
  padding: 1rem 1.25rem;
}