/*
  Makes Flutter web's hidden text-editing DOM elements stay invisible.

  Flutter web does not type into the canvas: for every focused TextField the
  engine puts a real <input>/<textarea> (class `flt-text-editing`, inside
  <flt-text-editing-host>) on top of the field so that the browser's IME,
  keyboard and clipboard work. That element carries the same text as the
  Flutter-painted one, at a slightly different baseline, and is hidden only by
  `color: transparent` (inline style, engine text_editing.dart) plus two rules
  in the stylesheet the engine injects at runtime
  (`StyleManager.applyGlobalCssRulesToSheet`):

      flutter-view input::selection      { background-color: transparent; }
      flutter-view .flt-text-editing::placeholder { opacity: 0; }

  Those two rules are the only thing hiding the DOM copy in two states, and
  `color: transparent` does not cover either of them, because both states are
  painted with UA colours that win over the element's own `color`:

  * Selected text - the engine only clears the selection *background*, so the
    browser still repaints the glyphs in its highlight foreground colour. The
    DOM copy of the value becomes visible a few pixels below the canvas text
    ("marked text moves down a little").
  * Placeholder - `::placeholder` has its own UA colour (grey). The placeholder
    text exists because Material's TextField always sends an autofill
    configuration (`TextField.autofillHints` defaults to `const <String>[]`,
    not null, see material/text_field.dart), and the engine copies
    `InputDecoration.hintText` from it into the DOM element's `placeholder`
    attribute. On focusing an empty field the browser draws it slightly below
    Flutter's own hint ("the placeholder duplicates").

  So whenever that injected stylesheet does not apply - a `style-src` CSP
  without `'unsafe-inline'`/nonce on the hosting CloudFront distribution is the
  usual reason, which is why this only shows up on the deployed build and never
  under `flutter run` on localhost - both symptoms appear while everything else
  still looks correct, since all the engine's other hiding is inline style.

  This file is an *external* stylesheet on purpose: a <style> block in
  index.html would be blocked by the very CSP that breaks the engine's own
  injected <style>. `!important` is needed to beat the UA rules for these
  pseudo-elements.

  Scoped to Flutter's own editing/semantics elements, so real DOM inputs on the
  page keep their placeholders.
*/

/*
  The decisive rule. Blink refuses to paint selected text with a fully
  transparent foreground - it falls back to its own highlight colour so that
  selected text can never be invisible - so the `color: transparent` in the
  ::selection rules below is silently dropped and the hidden input's glyphs
  still show up under the selection, a few pixels below the canvas text
  ("marked characters move down"). `opacity` is not part of that highlight
  colour resolution and cannot be overridden by the UA, so it is the only
  reliable way to hide the element in every state.

  The engine sets `opacity: 1` inline (text_editing.dart), hence `!important`.

  Trade-off: browsers skip autofill for zero-opacity fields. That is fine here
  because nothing in lib/ passes `autofillHints`, so no field opts into
  autofill in the first place - revisit this rule if one ever does.

  Focus, key events, IME composition and the mobile keyboard are unaffected:
  the element keeps its box and stays focusable, unlike `visibility: hidden`
  or `display: none`.
*/
input.flt-text-editing,
textarea.flt-text-editing,
flt-text-editing-host input,
flt-text-editing-host textarea,
flt-semantics input,
flt-semantics textarea {
  opacity: 0 !important;
}

input.flt-text-editing::selection,
textarea.flt-text-editing::selection,
flt-text-editing-host input::selection,
flt-text-editing-host textarea::selection,
flt-semantics input::selection,
flt-semantics textarea::selection {
  background-color: transparent !important;
  color: transparent !important;
  -webkit-text-fill-color: transparent !important;
}

/* Separate rule: an unknown pseudo-element invalidates the whole selector
   list, so Firefox's prefixed spelling cannot share the rule above. */
input.flt-text-editing::-moz-selection,
textarea.flt-text-editing::-moz-selection,
flt-text-editing-host input::-moz-selection,
flt-text-editing-host textarea::-moz-selection,
flt-semantics input::-moz-selection,
flt-semantics textarea::-moz-selection {
  background-color: transparent !important;
  color: transparent !important;
}

input.flt-text-editing::placeholder,
textarea.flt-text-editing::placeholder,
flt-text-editing-host input::placeholder,
flt-text-editing-host textarea::placeholder,
flt-semantics input::placeholder,
flt-semantics textarea::placeholder {
  opacity: 0 !important;
  color: transparent !important;
  -webkit-text-fill-color: transparent !important;
}

/* Same failure mode, third symptom: Blink/WebKit paint a yellow autofill
   overlay over the hidden input, which would then sit on top of the
   Flutter-rendered field. The engine's equivalent rule lives in the same
   injected stylesheet (flutter/flutter#118337). */
.transparentTextEditing:-webkit-autofill,
.transparentTextEditing:-webkit-autofill:hover,
.transparentTextEditing:-webkit-autofill:focus,
.transparentTextEditing:-webkit-autofill:active {
  opacity: 0 !important;
}