/* system/apps/fullscreen-editor/styles.css
 *
 * Split out of index.html's shared <style> block (Sept 2026) -- see
 * start-here.md's "Each app owns its own styles.css" note for why.
 *
 * Identical treatment to apps/notes's .notes-textarea on purpose
 * (fills the shell's own card directly, no border/radius of its
 * own) -- both now use the shared .text-input-base + .text-input-fill
 * classes (system/lib/shared-app-styles/styles.css) for that part. A
 * distinct class rather than reusing .notes-textarea directly since
 * the two are owned by different apps and have no reason to be
 * coupled just because they currently look the same.
 *
 * background IS set explicitly here, unlike apps/notes/apps/chat --
 * this is the fix for Ron's "huge flicker, goes black for a fraction
 * of a second" report on focus. A textarea with no background of its
 * own relies on its parent's showing through, which is fine normally,
 * but iOS Safari can briefly promote a focused field inside a
 * position:fixed ancestor (#appMainContent, via body.app-mode) to its
 * own compositor layer while the keyboard animates in -- a
 * well-documented WebKit quirk where that layer's own background
 * renders as opaque BLACK for a frame or two before the real
 * (transparent, parent-inherited) background takes over, rather than
 * just showing the parent through it like the CSS says it should. An
 * explicit, non-transparent background-color on the layer itself
 * sidesteps the bug outright since there's then no gap between what
 * the hastily-created layer shows and what the field is actually
 * supposed to look like.
 */
.fullscreen-editor-textarea {
  flex: 1 1 0;
  min-height: 0;
  width: 100%;
  min-width: 0; /* see apps/notes's styles.css comment -- same fix, same reasoning */
  resize: none;
  padding: 10px 12px;
  background: var(--card);
}