/* PIA — MIS MENSAJES A LA DERECHA, LOS DE LOS DEMÁS A LA IZQUIERDA.
 *
 * Nodo 6f95dc3b, 18-ago-2026. Reportado por Zey por moca: «en el chat no
 * distingo cuáles mensajes son míos y cuáles de otros; todos se ven igual».
 *
 * =============================================================================
 * ESTO NO ERA UNA REGRESIÓN, Y LA DIFERENCIA IMPORTA
 * =============================================================================
 *
 * El nodo nació sospechando del rediseño móvil de esa misma noche (3c1a9f62,
 * pia-chat-movil.css, commit 65290d5). NO LO ERA, y se descartó por dos vías
 * independientes antes de escribir una línea:
 *
 *   1 · POR HISTORIA. `git log -S EventTile --all -- element/brand/` no
 *       devuelve NINGÚN commit. Ninguna hoja de PIA ha tocado jamás una regla
 *       de mensajes: no hay nada que se pudiera haber roto.
 *
 *   2 · POR MEDICIÓN, que es la que cierra. Con Synapse vivo, sesión real
 *       (@root) y una sala con dos remitentes de verdad —la de gestión del
 *       puente de WhatsApp, donde @root y @whatsappbot se alternan— se midió
 *       la geometría de un mensaje propio y uno ajeno DESACTIVANDO
 *       pia-chat-movil.css en la página (`link.disabled = true`):
 *
 *           con la hoja      propio  x=18  w=350   ajeno  x=18  w=350
 *           SIN la hoja      propio  x=100 w=268   ajeno  x=100 w=268
 *
 *       Idénticos en los dos casos. Quitar el rediseño mueve la COLUMNA
 *       entera (ése es justo el fallo que aquel fichero arregla) y no mueve ni
 *       un píxel la diferencia entre propio y ajeno, porque no había ninguna.
 *       Y a 900px de ancho —donde ninguna media query de PIA aplica— pasa lo
 *       mismo: propio y ajeno en x=458, w=420 los dos.
 *
 * Lo que pasa es que Element Web arranca en su disposición «moderna» (grupo),
 * que alinea A TODO EL MUNDO a la izquierda y distingue al autor sólo por el
 * nombre y el avatar. Es correcto en un escritorio con una columna ancha; en un
 * teléfono, donde no hay más pantalla que la conversación, deja de serlo.
 *
 * =============================================================================
 * EL ARREGLO DE VERDAD NO ESTÁ EN ESTE FICHERO
 * =============================================================================
 *
 * Está en `element/config.json`:
 *
 *     "setting_defaults": { "layout": "bubble" }
 *
 * y eso NO es un atajo: es la única forma correcta. La alineación de mensajes
 * en Element es un AJUSTE, no una hoja de estilo — se llama `layout` y se
 * resuelve en JavaScript al montar cada tile, que escribe `data-layout` en el
 * DOM. Se comprobó que `config` es un nivel admitido para ese ajuste leyendo la
 * definición dentro del bundle servido (no la documentación):
 *
 *     layout:{supportedLevels:X,…}   con   X=[DEVICE, ACCOUNT, CONFIG]
 *
 * INTENTAR HACERLO EN CSS HABRÍA SIDO EL ERROR CARO. En la disposición de grupo
 * el avatar va en un canalón absoluto a la izquierda, el nombre encima, la marca
 * de tiempo absoluta, la barra de acciones al vuelo y los recibos de lectura en
 * un raíl a la derecha: darle la vuelta a un mensaje con `margin-left:auto`
 * habría dejado seis piezas colocadas para el lado contrario. La disposición de
 * burbujas ya resuelve las seis, y la resuelve Element, que es quien las pinta.
 *
 * Lo que se consigue, medido a 390px en la sala de dos remitentes:
 *
 *                    antes (grupo)          después (burbuja)
 *     ajeno          x=18   sin fondo       x=58..300   fondo #F0F2F5 (gris)
 *     PROPIO         x=18   sin fondo       x=222..324  fondo #E3F7ED (verde)
 *
 * O sea: lado distinto Y fondo distinto, que es exactamente lo que se pidió.
 *
 * =============================================================================
 * ENTONCES ¿QUÉ HACE ESTE FICHERO? PAGAR LA FACTURA DE ESE AJUSTE EN UN MÓVIL
 * =============================================================================
 *
 * La disposición de burbujas de Element está dimensionada para una columna de
 * escritorio, y en un teléfono se cobra el cambio en ANCHO DE LECTURA. Medido a
 * 390px, el texto de un mensaje ajeno mide:
 *
 *     disposición de grupo ....... 270px   (69% de la pantalla)
 *     burbujas, sin este fichero . 170px   (44%)
 *     burbujas, con este fichero . 194px   (50%)
 *
 * Dónde se va: 49px de canalón izquierdo (el avatar), 60px de canalón derecho
 * (el raíl de recibos de lectura), 70px de relleno DENTRO de la burbuja y un
 * `max-width: 70%` encima de todo eso.
 *
 * ⚠️ ESTE FICHERO NO RECUPERA LOS 270px Y NO PRETENDE HABERLO HECHO. Recupera
 * 24px de los 100 que costó el cambio. Los otros 76 están medidos y con dueño
 * conocido, y están escritos abajo en «LO QUE QUEDA ABIERTO» para que nadie los
 * lea como resueltos.
 */

@media (max-width: 480px) {

  /* 1 · LA BURBUJA LLEGA HASTA EL BORDE DE SU CAJA.
   *
   * Element la corta en `max-width: 70%`. Ese 70% se resuelve contra la caja de
   * CONTENIDO del tile, y encima el relleno (70px) se suma por fuera, así que la
   * burbuja acaba midiendo 0,70·W + 70 — a 390px eso son 241px dentro de un
   * hueco de 266: sobran 24px de aire que nadie usa.
   *
   * SE SUBE A 92% Y NO A 100%, Y EL NÚMERO NO ES DE GUSTO: por encima de ~95%
   * la burbuja se mete debajo del raíl de recibos de lectura, que vive en
   * absoluto a la derecha del tile. Se midió: con el tile ensanchado hasta 16px
   * de margen, `.mx_ReadReceiptGroup` se iba a x=426..434 en una pantalla de
   * 390 — fuera de cuadro, o sea un dato que deja de verse sin que nada avise
   * (scrollWidth 434 contra innerWidth 390). 92% es el último valor que deja el
   * raíl dentro a 320, 390 y 430.
   *
   * NO LLEVA `!important` a propósito, y eso es comprobable, no una esperanza:
   * el CSS de Element vive dentro de `@layer app-web` —se verificó en el bundle
   * servido, que declara `@layer compound-tokens, compound-web,
   * shared-components, app-web`— y una hoja SIN capa gana a cualquier hoja EN
   * capa, pase lo que pase con la especificidad. Aquí no hay nada escrito en
   * línea por JavaScript, que es lo único que obligaría a `!important` (el
   * motivo que pia-chat-movil.css sí tiene y explica en su §11bis). */
  .mx_EventTile[data-layout="bubble"] .mx_EventTile_line {
    max-width: 92%;
  }

  /* 2 · UN MENSAJE MÍO NO NECESITA CANALÓN PARA EL AVATAR DE OTRO.
   *
   * Element reserva los DOS canalones en TODOS los tiles: 49px a la izquierda y
   * 60px a la derecha, sea de quien sea el mensaje. En un escritorio eso es
   * simetría barata; en un teléfono de 320px son 109px —el 34% de la pantalla—
   * y la mitad está siempre vacía, porque un mensaje sólo tiene avatar en SU
   * lado.
   *
   * Se recorta el canalón que le sobra al mensaje propio, y SÓLO ése. El de la
   * derecha se deja intacto en los dos casos y no es tacañería: ahí no está sólo
   * el avatar propio, está el raíl de recibos de lectura, que Element coloca en
   * absoluto con un `left` calculado a partir del ancho del tile. Ensanchar el
   * tile por la derecha empuja el raíl fuera de la pantalla — medido, ver arriba.
   *
   * EL SELECTOR ES `[data-self]` Y ESTÁ MEDIDO EN EL DOM VIVO, NO SUPUESTO. El
   * nodo pedía buscar `mx_EventTile_isOursMessage` / `mx_EventTile_out`, que son
   * los nombres que se citan por ahí: EN ESTA VERSIÓN NO EXISTEN. Se enumeraron
   * todas las clases de todos los tiles de la sala filtrando por
   * /our|self|mine|sent|own/ y el resultado fue la lista vacía. Lo que sí hay es
   * un atributo, `data-self="true|false"`, escrito por Element en cada tile.
   * Viene del código fuente y no del compilador: no lleva hash y no caduca con
   * la imagen. Por eso tampoco hay ningún `nth-child` aquí. */
  .mx_EventTile[data-layout="bubble"][data-self="true"] {
    margin-left: 16px;
  }
}

/* =============================================================================
 * LO QUE QUEDA ABIERTO, MEDIDO Y CON DUEÑO — no es una lista de deseos
 * =============================================================================
 *
 * · 70px DE RELLENO DENTRO DE LA BURBUJA (10px izq + 60px der). Los 60 de la
 *   derecha existen para la marca de tiempo, que Element pinta en absoluto con
 *   `right: 0` sobre la ÚLTIMA línea del texto (medida: x=256..300, 44px de
 *   ancho, con el cuerpo acabando en 239). Recortarlos sin más deja la hora
 *   encima del final del texto. Tiene solución —reservar el hueco sólo en la
 *   última línea, con un `float` o una forma— pero es un trabajo de tipografía,
 *   no un override de dos líneas, y mezclarlo aquí habría hecho imposible saber
 *   cuál de los dos cambios rompió qué. Es el siguiente nodo de esta superficie.
 *
 * · EL RAÍL DE RECIBOS DE LECTURA se lleva ~30px de ancho en cada fila para
 *   decir algo que en una conversación de dos apenas cambia. Element lo coloca
 *   con un `left` derivado del ancho del tile, así que moverlo es re-anclarlo
 *   (`left:auto; right:…`), y eso choca con el avatar propio: se probó y el
 *   recibo caía en x=344..352 con el avatar en 323..361. Hay que decidir antes
 *   qué pasa con el avatar en un teléfono, y eso es una decisión de producto.
 *
 * · EL COLOR NO ES EL QUE DISTINGUE, Y ESO HAY QUE SABERLO ANTES DE TOCAR NADA.
 *   Los dos fondos son los de Element (#E3F7ED el mío, #F0F2F5 el ajeno) y este
 *   fichero no los toca. Se midió el contraste entre ellos:
 *
 *       entre las dos burbujas ............ 1.00:1
 *       cada una contra el blanco ......... 1.12:1
 *       tinta de PIA encima de cada una ... 16.5:1 y 16.4:1
 *
 *   1.00:1 ENTRE ELLAS quiere decir que tienen la MISMA luminancia y sólo se
 *   diferencian en el tono. Para quien no separa el verde del gris —en torno al
 *   8% de los hombres— o para una pantalla mala al sol, las dos burbujas son la
 *   misma. O sea: EL COLOR AQUÍ ES DECORACIÓN; EL QUE DISTINGUE ES EL LADO.
 *
 *   No se repinta, y la razón no es pereza: un par de luminancias iguales es lo
 *   que hacen también WhatsApp y Telegram, porque en un chat el lado es un canal
 *   más fuerte que cualquier color y no se agota. Forzar una separación de
 *   luminancia obligaría a un gris oscuro (el mejor candidato de pia-tokens.css
 *   es #CFCFCF, y aun así se queda en 1.39:1) que pelearía con la paleta de
 *   tinta y grises de PIA para reforzar un canal que no está haciendo el
 *   trabajo.
 *
 *   LO QUE SÍ SE PROHÍBE, Y ES EL MOTIVO DE ESCRIBIR ESTO: nadie puede quitar el
 *   lado y quedarse con el color. Si algún día en una tableta o en escritorio se
 *   plantea «con el fondo distinto ya se ve», la respuesta está medida y es no:
 *   sin el lado no queda ninguna señal para quien no ve ese tono.
 *
 * · POR ENCIMA DE 480px este fichero no hace NADA, y el ajuste de burbujas SÍ
 *   aplica. Es deliberado: la disposición es un ajuste global y no se puede
 *   cambiar por media query, y en una columna ancha las medidas de Element ya
 *   son las suyas. Lo que no se ha medido es PIA en una tableta, y este fichero
 *   no finge haberlo hecho.
 */