/* ============================================================================ EN CORTO — La capa del teléfono ---------------------------------------------------------------------------- Va la última de todas, después de app.css, app-v2.css y app-v3.css, porque su trabajo es ganar. Todo lo que hay aquí vive bajo 760 px de ancho: en un escritorio ninguna de estas reglas existe. El problema que resuelve ---------------------------------------------------------------------------- Se midió con una sonda que abre cada pantalla en un iPhone de 390×844 y cuenta. En «Datos de tu negocio» había que recorrer PANTALLA Y MEDIA antes de ver el primer campo: cabecera de 66, tarjeta de migas, título grande, subtítulo de dos renglones, botón de vista previa, fila de pasos, un aviso azul de siete renglones y el pie del asistente. Cincuenta y siete campos en el formulario, cuatro a la vista. Y con el teclado abierto —que es cuando la persona está escribiendo y más necesita saber qué sigue— quedan 390 px de alto. En dieciséis de los veintitrés formularios de la aplicación, el botón que continúa el trámite estaba fuera de la pantalla. Las cuatro reglas que ordenan esta hoja ---------------------------------------------------------------------------- 1. El adorno paga renta. Cada píxel de cromo se le quita a un campo. 2. Lo que sigue SIEMPRE se ve. La acción que avanza el trámite vive en una barra fija abajo, por encima del teclado, y nunca se va de la pantalla. 3. Una barra abajo, no dos. Mientras se llena un formulario, la barra de pestañas se retira: un trámite es un trámite, no un sitio por donde navegar. Es lo que hace iOS con una hoja modal. 4. Nada que se toque mide menos de 44 px, y ningún campo menos de 16 px de letra —con menos, Safari hace zoom al enfocar y descoloca la página. ============================================================================ */ /* ============================================================ 0 · Constantes ============================================================ */ :root { /* El alto que el teclado del sistema le está quitando a la ventana. Lo escribe movil.js con visualViewport; sin guion vale cero y todo lo que depende de él se comporta como antes. */ --teclado-h: 0px; /* El alto de la barra de acción del formulario, cuando la hay. */ --barra-accion-h: 0px; } @media (max-width: 760px) { /* ============================================================ 0 bis · Que el campo enfocado no quede debajo de la barra ------------------------------------------------------------ Esto es lo que rompía TODOS los formularios en un teléfono, y no se veía mirando la pantalla quieta: se veía al escribir. Al tocar un campo, el sistema abre el teclado y el navegador desplaza la página para traerlo a la vista. Pero el navegador cree que la ventana llega hasta abajo del todo, y abajo del todo hay dos barras fijas —la de acción del formulario y la de pestañas— que suman unos 130 px. El campo acaba colocado justo detrás de ellas: la persona escribe y no ve lo que escribe. Medido antes de arreglarlo: en «Códigos de registro» los 7 campos quedaban tapados; en «Patrullas», los 12; en el formulario del negocio, los 4. `scroll-padding` es la forma que tiene el navegador de saber que los bordes de la ventana no son los bordes útiles. No hace falta un guion ni escuchar el foco: se le dice una vez cuánto sobra por arriba y por abajo, y a partir de ahí acomoda solo —al enfocar, al saltar a un ancla y al recorrer con el teclado—. Las tres variables ya existían y las mantiene `movil.js`: el teclado, la barra de acción y la de pestañas. Sin guion todas valen cero y esto se comporta como antes. Los 16 px de más no son estética: pegar el campo al borde exacto de la barra deja el mensaje de error —que se pinta DEBAJO— otra vez escondido. */ html { scroll-padding-top: calc(var(--anclaje, 84px) + 8px); scroll-padding-bottom: calc( var(--barra-accion-h, 0px) + var(--nav-movil-h, 0px) + var(--teclado-h, 0px) + 16px); } /* ============================================================ 1 · Los campos, a 16 px ------------------------------------------------------------ Safari en iOS hace zoom sobre cualquier campo con menos de 16 px al enfocarlo, y al hacerlo mueve la página entera: la persona toca «Nombre» y la pantalla salta, se sale de sitio y ya no encuentra el botón. No es una preferencia tipográfica, es la diferencia entre que el formulario se quede quieto o no. Eran 188 campos en 72 pantallas: la hoja base los tenía a 15.5, los selectores a 15.5 y las cajas de texto a 15.5. ============================================================ */ .input, .select, .textarea, .input-sm, .input.input-sm, .toolbar .input, .toolbar .select, .zona-fila .input, .busca input, .busca input[type="search"], input[type="text"], input[type="email"], input[type="tel"], input[type="url"], input[type="password"], input[type="number"], input[type="search"], input[type="date"], input[type="time"], input[type="datetime-local"], select, textarea { font-size: 16px; } /* Y los que ya tenían dueño con más peso en la cascada. La sonda los encuentra uno a uno: cada vez que aparezca uno nuevo, sale en el informe como «zoom». `.lugar-buscar` es el buscador de colonias del formulario de alta, y era el peor de todos: se enfoca justo cuando hay que escribir una dirección. */ .searchbar select, .searchbar input, .toolbar .input, .toolbar .select, .zona-fila .input, .lugar-buscar, input.input, select.select, textarea.textarea { font-size: 16px; } /* El campo del código de acceso y los de un solo dígito siguen siendo más grandes: son los que se dictan en voz alta y se teclean mirando un papel. */ .input.mono { font-size: 17px; } /* Un campo no puede medir menos que un dedo. */ .input, .select, .textarea { min-height: var(--toque, 44px); } .textarea { min-height: 96px; } /* ============================================================ 2 · El cromo paga renta ------------------------------------------------------------ Lo de arriba se encoge para que quepa lo de en medio, que es a lo que se vino. Nada desaparece: se aprieta. ============================================================ */ /* La cabecera: 66 → 52. El nombre se queda, el subtítulo «NEZA · DIRECTORIO» se va: en el teléfono ya se sabe en qué sitio se está, y ese renglón sólo estaba ahí para llenar el hueco que dejaba el logotipo grande. */ .site-header .inner { height: 52px; gap: 12px; } .brand svg, .brand-mark { width: 30px; height: 30px; } .brand-text { font-size: 18px; } .brand-tag { display: none; } /* Lo que se pega debajo de la cabecera tiene que pegarse a la cabecera de AHORA, que en el teléfono mide 52 y no 66. Con los 66 de antes quedaba una rendija de catorce píxeles por la que se veía pasar el contenido, justo encima del buscador de la pantalla de búsqueda. */ .buscador-fijo { top: 52px; } /* El aire de sección, a la mitad. En un escritorio 44 px arriba y abajo dan respiro; en 390 px de ancho son un octavo de la pantalla en blanco. */ .section { padding: 18px 0 24px; } .container { --pad-cont: 16px; } /* Los títulos. `clamp(28px, …)` deja 28 px en el teléfono, que con la tipografía de la casa ocupa dos renglones para cualquier título de más de tres palabras. A 24 px cabe en uno y sigue mandando. */ h1 { font-size: 24px; letter-spacing: -.03em; } h2 { font-size: 20px; } /* La entrada de las pantallas de registro: icono, título y una explicación de tres renglones a 16 px, todo centrado. Son 330 px —cuarenta por ciento de la pantalla— antes del primer campo, para decir algo que ya dice el título. La explicación se queda, en el cuerpo de texto que le toca. */ .reg-entrada { margin-bottom: 14px; } .reg-entrada p { font-size: 14px; line-height: 1.45; } .reg-entrada > div:first-child { display: none; } /* el icono grande */ /* El relleno de las tarjetas: 24 px por lado en una pantalla de 390 se come el 12 % del ancho útil. */ .card-pad, .card-body { padding: 16px; } .card-head { padding: 14px 16px; } /* La tarjeta de migas del panel y de administración era una tarjeta con sombra, dos renglones y una flecha: 78 px de alto para decir dónde estás, cuando la barra de abajo ya lo dice. Pasa a ser una fila de 44. */ .nav-abrir { min-height: var(--toque, 44px); padding: 8px 12px; border-radius: var(--r, 14px); box-shadow: none; margin-bottom: 10px; } .nav-abrir b { font-size: 14px; } .nav-abrir .hint { font-size: 12px; margin-top: 0; } /* ============================================================ 3 · La barra de acción del formulario ------------------------------------------------------------ El pie del asistente por pasos («Paso 1 de 7 · Continuar ›») estaba declarado `position: sticky`, y un sticky se pega SÓLO cuando su sitio natural ya salió de la pantalla. Como el guion lo inserta antes del último paso, su sitio natural estaba a media página: se veía flotando en medio del formulario, encima de los campos, con el primero cortado debajo. Aquí pasa a `fixed`: es una barra, no un párrafo. ============================================================ */ .pasos-pie, .barra-accion { position: fixed; left: 0; right: 0; z-index: 55; /* Sube lo que mida el teclado, y se apoya encima de la barra de pestañas cuando la hay. Con el teclado cerrado y sin pestañas, las dos variables valen cero y la barra se apoya en el borde de abajo. */ bottom: calc(var(--teclado-h, 0px) + var(--nav-movil-h, 0px)); margin: 0; border-radius: 0; border: 0; border-top: 1px solid var(--line); background: var(--card); padding: 10px 16px calc(10px + env(safe-area-inset-bottom, 0px)); box-shadow: 0 -6px 22px rgba(0, 0, 0, .09); transition: bottom .18s ease; } /* Con el teclado abierto el borde de seguridad de abajo lo tapa el teclado. */ body.teclado .pasos-pie, body.teclado .barra-accion { padding-bottom: 10px; } .pasos-pie .row-between, .barra-accion .fila { display: flex; align-items: center; gap: 10px; flex-wrap: nowrap; margin-top: 8px; } .barra-accion .fila { margin-top: 0; } .barra-accion .grow, .pasos-pie .grow { flex: 1; justify-content: center; } .pasos-pie .btn, .barra-accion .btn { min-height: var(--toque, 44px); } /* Un botón escondido tiene que esconderse. ----------------------------------------------------------------- `[hidden]` es una regla del navegador con la misma especificidad que `.btn`, y como la del navegador va primero, `.btn { display: inline-flex }` la pisaba: los botones de paso que nacen con `hidden` —para que sin JavaScript el formulario se vea de corrido— salían igual, y quien entraba sin guion veía tres «Continuar» que no hacían nada. Con la barra de acción el mismo fallo dejaba dos «Continuar» a la vez, uno a media página y otro abajo. Se arregla de raíz y no botón por botón: `.row`, `.field` y `.card` tienen el mismo problema, y el segundo turno de los horarios —un `.row` con `hidden` puesto— salía igualmente vacío en los siete días de la semana. */ [hidden] { display: none !important; } /* El botón que avanza manda: ocupa lo que sobra. Los de volver y guardar, lo justo, y sin gritar. */ .pasos-pie [data-paso-sig] { flex: 1; justify-content: center; } .pasos-pie [data-paso-prev], .pasos-pie [data-pasos-enviar] { flex: 0 0 auto; padding-inline: 14px; } .pasos-pie .hint { display: none; } /* el número de paso ya está en la barra de arriba */ .pasos-progreso { height: 5px; } /* El sitio que la barra ocupa se le devuelve al documento por abajo, o el último campo del formulario queda debajo de ella para siempre. (La regla vive en el apartado 8, con las demás de relleno inferior: aquí perdía contra `body.no-legal-bar`, que tiene el mismo peso y se declara después, y el resultado eran 86 px de hueco donde hacían falta 135.) */ /* En un asistente, una barra abajo y no dos. ----------------------------------------------------------------- Un formulario suelto conserva la barra de pestañas: quitarla por escribir dos campos deja a la persona encerrada en la pantalla. Un asistente por pasos es otra cosa: es un trámite con principio y final, y salirse a media captura pierde lo escrito. Ahí las dos barras apiladas son 130 px —un tercio de lo que queda con el teclado abierto— y además dicen cosas que se contradicen: una pregunta a dónde quieres ir y la otra pide terminar lo que empezaste. iOS resuelve esto igual: en una hoja modal no hay barra de pestañas. Se sale por la cabecera, que sigue ahí. */ body.con-asistente .nav-movil { display: none; } body.con-asistente { --nav-movil-h: 0px; } /* La barra pasó de cuatro sitios a cinco. A 390 px tocan a 78 por botón y la etiqueta más larga mide 57, así que caben; por debajo de 370 se aprieta la letra antes que recortar la palabra, porque «Mi negoc…» no dice nada. */ @media (max-width: 400px) { .nav-movil a, .nav-movil .nav-toggle { font-size: 9.8px; padding-inline: 1px; } .nav-movil svg { width: 22px; height: 22px; } } /* ============================================================ 4 · El teclado ------------------------------------------------------------ Cuando el teclado sube, la ventana pasa de 844 a ~390 px de alto. Lo que sobra en esos 390 px se retira solo. ============================================================ */ /* La barra de pestañas se va. Es navegación: mientras se escribe no se navega, y son 58 px que valen dos campos. */ body.teclado .nav-movil { transform: translateY(110%); pointer-events: none; } .nav-movil { transition: transform .18s ease; } /* Y el hueco que dejaba se le devuelve a quien lo estaba sorteando: sin esto la barra de acción se quedaba flotando 58 px por encima del borde, con campos asomando por debajo, que es peor que no moverla. */ body.teclado { --nav-movil-h: 0px; } /* Los flotantes también. Un corazón y un icono de WhatsApp encima del campo que se está llenando no son una ayuda, son un obstáculo: se midió que tapaban el campo de horario del martes y el botón de guardar. */ body.teclado .apoyo-widget, body.teclado .wa-widget, body.con-formulario .apoyo-widget, body.con-formulario .wa-widget { display: none; } /* El aviso legal de la ficha tampoco compite con el teclado. */ body.teclado .legal-bar { display: none; } /* La cabecera pegada se va con el teclado: son 52 px más de formulario, y nadie usa el logotipo mientras escribe su dirección. */ body.teclado .site-header { position: static; } /* ============================================================ 5 · Los pasos, dentro del formulario ============================================================ */ /* La fila de pastillas de paso: en el teléfono sólo se lee la del paso actual, las demás son puntos. Ya lo hacía app.css; aquí se le da el área de toque y se deja recorrer de lado sin cortar. */ .pasos-barra { display: flex; gap: 6px; overflow-x: auto; scrollbar-width: none; padding: 2px 0 8px; margin: 0 0 10px; scroll-snap-type: x proximity; } .pasos-barra::-webkit-scrollbar { display: none; } .paso-chip { min-height: var(--toque, 44px); scroll-snap-align: center; flex: none; } /* El aviso que explica el formulario, plegado. ----------------------------------------------------------------- «Solo tres datos son obligatorios» ocupaba siete renglones —155 px— encima del primer campo. Es una buena explicación y se queda; lo que cambia es que se lee cuando se busca, no cuando estorba. Lo pliega movil.js. */ .aviso-plegable { padding: 0; } .aviso-plegable > summary { display: flex; align-items: center; gap: 10px; cursor: pointer; list-style: none; padding: 11px 14px; min-height: var(--toque, 44px); font-weight: 700; font-size: 14px; } .aviso-plegable > summary::-webkit-details-marker { display: none; } .aviso-plegable > summary::after { content: ''; margin-left: auto; width: 9px; height: 9px; flex: none; border-right: 2.2px solid currentColor; border-bottom: 2.2px solid currentColor; transform: rotate(45deg) translate(-2px, -2px); transition: transform .18s; } .aviso-plegable[open] > summary::after { transform: rotate(-135deg) translate(-3px, -3px); } .aviso-plegable > .cuerpo { padding: 0 14px 13px; } /* ============================================================ 6 · Blancos de toque ------------------------------------------------------------ La regla de los 44 px, aplicada a los controles que la sonda encontró por debajo y que las hojas anteriores no cubrían —o cubrían sólo en el diseño v3, dejando fuera a v1 y v2. ============================================================ */ .btn { min-height: var(--toque, 44px); } .btn-icon { min-width: var(--toque, 44px); min-height: var(--toque, 44px); } .btn-sm { min-height: var(--toque, 44px); padding-block: 8px; } .chip, .chg { min-height: 36px; position: relative; } /* El área llega a 44 sin que la pastilla mida 44: se estira por arriba y por abajo con una capa invisible, que es lo que ya hacía v3 y aquí se generaliza a los tres diseños. */ .chip::after, .chg::after { content: ''; position: absolute; left: 0; right: 0; top: 50%; height: var(--toque, 44px); transform: translateY(-50%); } /* El ojo que enseña la contraseña medía 35. Es el control que más se usa de un formulario de acceso después del propio campo. */ .pw-toggle { min-width: var(--toque, 44px); min-height: var(--toque, 44px); } /* Las casillas y los redondeles: el cuadrito mide 20 y no va a crecer —a 44 parecería un botón—, así que crece la etiqueta que lo envuelve, que es lo que de verdad se toca. */ label.check { min-height: var(--toque, 44px); align-items: center; padding: 8px 0; } .check input[type="checkbox"], .check input[type="radio"] { margin-top: 0; } /* Los resúmenes de un plegable son botones: la flecha sola no basta. */ summary { min-height: var(--toque, 44px); } /* Los enlaces de una tabla y de un índice. ----------------------------------------------------------------- En las pantallas de administración —negocios, actividad, cortesías— y en el índice del manual, los enlaces son texto suelto de 18 a 41 px de alto. En un escritorio con ratón dan igual; en un teléfono son la única forma de entrar a la ficha de un negocio, y hay diez por renglón. No se agranda el dibujo, se agranda el blanco: el renglón de la tabla mide lo mismo y el texto también. */ .table td a, .table th a, td a, .toc a, .grupo-pleg a, .rese-negocio { display: inline-flex; align-items: center; min-height: var(--toque, 44px); } /* Una casilla de 13 px en una tabla de selección múltiple es un blanco imposible: se marca la fila equivocada y se le regala un mes de plan a quien no era. ----------------------------------------------------------------- El truco del ::after estirado —el que usa el resto de la hoja— aquí NO sirve: una casilla es un elemento reemplazado y los navegadores no le pintan pseudoelementos. Se midió creyendo que sí, y las casillas seguían midiendo 22 px con la regla puesta. Lo que sí funciona es envolverla en una etiqueta, que además la marca al tocarla por definición. La envoltura la pone movil.js, que es donde se puede comprobar que no tenga ya una. */ td input[type="checkbox"], td input[type="radio"], .table input[type="checkbox"], .table input[type="radio"] { width: 22px; height: 22px; } .toque-envoltura { display: inline-flex; align-items: center; justify-content: center; min-width: var(--toque, 44px); min-height: var(--toque, 44px); margin: -11px; /* el blanco crece, el renglón no */ cursor: pointer; } /* Los enlaces sueltos de un renglón —«¿La olvidaste?»— tenían 19 px de alto. Se les da el área sin cambiar el dibujo. */ .lnk { position: relative; } .lnk::after { content: ''; position: absolute; left: -6px; right: -6px; top: 50%; height: var(--toque, 44px); transform: translateY(-50%); } /* «¿La olvidaste?», encima del campo de contraseña, es la excepción: ahí la capa invisible no vale. ----------------------------------------------------------------- Se probó, y el campo la tapaba por abajo: viene después en el documento, se pinta encima, y de los cinco puntos del blanco de toque el de abajo caía en el campo. Ponerle z-index lo arregla al revés —entonces el enlace se come el borde de arriba del campo de contraseña, y quien va a escribir su contraseña acaba en «recuperar»—. Así que aquí el renglón crece de verdad: veinticinco píxeles una vez por formulario, a cambio de que el enlace se pueda tocar. */ .row-between > .f-xs { padding-block: 12px; } .field > .row-between { align-items: center; } /* El carril de giros recorta lo que se sale por arriba y por abajo —es un `overflow-x: auto`, y eso recorta en los dos ejes—, así que se comía los cuatro píxeles que le sobresalen al blanco de toque de cada pastilla. Se le da el aire para que quepan los 44. */ .chips-giro { padding-block: 5px; } /* ============================================================ 7 · Densidad: dos columnas donde caben dos ------------------------------------------------------------ `app.css` derrumba TODA rejilla de dos columnas a una bajo 760 px. Para un nombre y un correo está bien. Para «de las 9:00 a las 21:00» no: son dos datos de cuatro caracteres que caben de sobra al lado, y apilarlos duplicó el largo de la pantalla de horarios —5 261 px, seis pantallas y media para siete días de la semana. ============================================================ */ .par-corto, .grid-2.corta { display: grid; grid-template-columns: 1fr 1fr; gap: 10px; } .par-corto .field, .grid-2.corta .field { margin-bottom: 0; } /* Los horarios: un día por bloque, no cuatro renglones sueltos. ----------------------------------------------------------------- Eran 5 148 px —seis pantallas y media— para siete días. El nombre del día arriba, las dos horas en su renglón, y el segundo turno plegado si está vacío, que es el caso de casi todos: la mayoría de los negocios del barrio no cierran a mediodía, y a los que sí lo hacen les sigue apareciendo. */ .switch-row[data-day-row] { display: block; padding: 12px 0; } .switch-row[data-day-row] > .check { min-width: 0 !important; margin: 0 0 8px !important; font-weight: 700; } .switch-row[data-day-row] > .row { display: flex; gap: 8px; align-items: center; flex-wrap: nowrap; margin: 0; } .switch-row[data-day-row] > .row + .row { margin-top: 8px; } .switch-row[data-day-row] .input[type="time"] { width: auto !important; flex: 1; min-width: 0; text-align: center; } .switch-row[data-day-row] .hint { flex: none; font-size: 12px; } /* El botón que despliega el segundo turno, cuando está vacío. */ .turno2-abrir { background: none; border: 0; padding: 6px 0; margin-top: 6px; color: var(--brand); font-weight: 700; font-size: 13px; min-height: var(--toque, 44px); cursor: pointer; } /* ============================================================ 8 · Lo que ya no cabe abajo ------------------------------------------------------------ La sonda encontró enlaces del pie y fichas de negocio que quedaban debajo de la barra de pestañas al llegar al final del documento: ahí ya no hay a dónde recorrer, así que quedaban inalcanzables. ============================================================ */ body { padding-bottom: calc(var(--legal-h) + var(--nav-movil-h) + env(safe-area-inset-bottom, 0px)); } body.no-legal-bar { padding-bottom: calc(28px + var(--nav-movil-h) + env(safe-area-inset-bottom, 0px)); } /* Y cuando hay barra de acción, manda la barra: es la más alta de las tres cosas que pueden estar pegadas abajo. Va la última a propósito —tiene el mismo peso que las dos de arriba y en un empate gana la que se declara después—, y con los dos selectores porque `body.no-legal-bar.con-barra-accion` sí le gana a `body.con-barra-accion` a secas. */ body.con-barra-accion, body.no-legal-bar.con-barra-accion { padding-bottom: calc(var(--barra-accion-h, 76px) + var(--nav-movil-h, 0px) + env(safe-area-inset-bottom, 0px) + 14px); } } /* fin de @media (max-width: 760px) */ /* En escritorio el aviso plegable no se pliega: se ve entero, como siempre. El guion sólo le quita el `open` en el teléfono. */ @media (min-width: 761px) { .aviso-plegable > summary { list-style: none; font-weight: 700; } .aviso-plegable > summary::-webkit-details-marker { display: none; } } /* Los avisos largos, plegados. Ver el bloque del mismo nombre en `movil.js`. */ @media (max-width: 760px) { .aviso-plegado { margin: 0 0 12px; border: 1px solid var(--line); border-radius: var(--r, 14px); background: var(--card); overflow: hidden; } .aviso-plegado > summary { display: flex; align-items: center; gap: 10px; min-height: var(--toque, 44px); padding: 10px 14px; cursor: pointer; list-style: none; font-size: 14px; font-weight: 700; color: var(--ink); } .aviso-plegado > summary::-webkit-details-marker { display: none; } .aviso-plegado > summary::marker { content: ''; } .aviso-plegado .ap-t { flex: 1; min-width: 0; overflow: hidden; text-overflow: ellipsis; white-space: nowrap; } .aviso-plegado .ap-mas { flex: none; font-size: 12.5px; font-weight: 600; color: var(--brand-txt); } /* El aviso de dentro pierde su propio marco: ya lo pone el desplegable, y dos marcos concéntricos es lo que hace que una tarjeta parezca un error. */ .aviso-plegado > .alert, .aviso-plegado > .aviso-largo { margin: 0; border: 0; border-top: 1px solid var(--line); border-radius: 0; } } /* ============================================================ La presentación de la página, en un renglón ------------------------------------------------------------ Medido en «Datos de tu negocio»: 397 px entre la barra de menú y el primer campo, y ni un dato pedido dentro. Son el título a 27 px, un subtítulo de dos renglones explicando que lo que guardes se refleja en tu ficha, un botón secundario de vista previa y las fichas de los pasos. Todo eso es cierto y ninguna palabra sobra en un escritorio. En un teléfono de 844 px —390 con el teclado abierto— es la diferencia entre ver lo que te están pidiendo y tener que buscarlo. Lo que se hace, y lo que NO: · El título baja a 21 px. Sigue estando: dice en qué pantalla estás. · El subtítulo se recorta a dos renglones. No se esconde: se recorta, y si cabe entero no se nota nada. · Los botones secundarios de la cabecera se encogen. No se quitan: un botón que desaparece en el teléfono es una función que no existe para quien sólo tiene teléfono. ============================================================ */ @media (max-width: 760px) { .admin-layout h1, .container > .stack > .row-between h1 { font-size: 21px !important; line-height: 1.2; margin-bottom: 2px; } /* El subtítulo que va pegado al título de la página. `-webkit-line-clamp` sigue siendo la forma que entienden todos los navegadores de teléfono; `line-clamp` a secas todavía no. */ .admin-layout h1 + p.muted, .admin-layout h1 + p.f-sm, .admin-layout h1 + .muted { display: -webkit-box; -webkit-box-orient: vertical; -webkit-line-clamp: 2; overflow: hidden; font-size: 13px; line-height: 1.4; margin-bottom: 0; } /* La fila de «título + botón secundario» se aprieta: el botón deja de pedir su propio renglón. */ .admin-layout .row-between:has(h1) { gap: 10px; align-items: flex-start; } .admin-layout .row-between:has(h1) > .btn { flex: none; padding: 6px 12px; font-size: 13px; } .admin-layout .row-between.mb-3:has(h1) { margin-bottom: 10px; } } /* La presentación se aprieta; el título se queda. ------------------------------------------------------------ Primer intento: esconder el `

` en el teléfono, con el argumento de que la barra de arriba ya dice dónde estás. Lo tumbó `recorrido.js`, y con razón: comprueba que al llegar a una pantalla se vea su título, y en «Guardados» o «Mi cuenta» ese `

` es el ÚNICO título que hay. La barra de arriba lo repite en letra pequeña dentro de un botón de menú, que no es lo mismo que un título: nadie llega a una pantalla y lee el botón. Lo que sí sobra en un teléfono es el subtítulo. «Todo lo que aquí guardes se refleja al instante en tu ficha y en tu tarjeta QR» son dos renglones que explican algo que no hay que decidir ahora. Se va sólo cuando la pantalla lleva formulario: ahí el espacio es la diferencia entre ver dos campos o cuatro. En una pantalla de lectura se queda, porque ahí no estorba y a veces es lo único que orienta. ------------------------------------------------------------ */ @media (max-width: 760px) { .admin-layout:has(form) .row-between:has(> div > h1) > div > p.muted, .admin-layout:has(form) .row-between:has(> div > h1) > div > p.f-sm { display: none; } .admin-layout .row-between:has(h1) { gap: 10px; align-items: center; } .admin-layout .row-between:has(h1) > .btn { flex: none; padding: 6px 12px; font-size: 13px; } .admin-layout .row-between.mb-3:has(h1) { margin-bottom: 10px; } }