/* ════════════════════════════════════════════════════════════════════════
 * CONTROLES DE FORMULÁRIO — o que vale nas TRÊS camadas (app, portal, hub)
 *
 * O portal do cliente e o hub NÃO carregam o `app.css`. Regra de controle que
 * mora lá vale só no app — e a mesma tela de filtro (o `rich_filter` cria
 * campo de data nas três camadas) quebra no portal calada. Uma fonte, três
 * `<link>`: `tests/test_o_card_nao_rola_de_lado.py` cobra.
 * ════════════════════════════════════════════════════════════════════════ */

/* ## ⚠️⚠️ NO IPHONE, O CAMPO DE DATA IGNORA A LARGURA — E `min-width:0` NÃO BASTA
 *
 * Chamado #33 da J&M (16/09/2026), no modal do relatório de vendas do dia: o
 * print mostra o campo de data PASSANDO dos botões de baixo, e o modal inteiro
 * rolando de lado. O WebKit do iOS desenha campo de data/hora como `inline-flex`
 * interno e o dimensiona pelo TEXTO FORMATADO ("16 de set. de 2026"), ignorando
 * o `width:100%` da página — e o `min-width:0` global do `app.css` já estava lá.
 *
 * ⚠️ O Chrome — a emulação de celular e a `scripts/medir_largura.mjs` — NÃO
 *   reproduz. Só o aparelho mostra; é por isso que ele voltou três vezes.
 * ⚠️ Vale em TODO campo de data no iPhone, não só no `<input type="date">` do
 *   HTML: o flatpickr, em aparelho de toque, troca o campo por um nativo
 *   (`flatpickr-mobile`). E o `rich_filter`/`card_filter` criam os deles.
 * ⚠️ `appearance:none` é o que tira o campo do dimensionamento próprio; o
 *   seletor nativo continua abrindo no toque. Restrito ao iOS
 *   (`-webkit-touch-callout` só existe lá): o computador não muda nada.
 */
@supports (-webkit-touch-callout: none) {
  input[type="date"], input[type="time"], input[type="month"],
  input[type="week"], input[type="datetime-local"] {
    -webkit-appearance: none;
    appearance: none;
    min-width: 0;
    max-width: 100%;
    overflow: hidden;
  }
  input::-webkit-date-and-time-value { text-align: left; }
}