Flexbugs: MS Edge: superior / inferior: automático no funciona correctamente en elementos absolutamente posicionados en un contenedor flexible relativamente posicionado

Creado en 19 nov. 2015  ·  5Comentarios  ·  Fuente: philipwalton/flexbugs

Cuando un elemento absolutamente posicionado usa el valor "auto" con las propiedades "top" o "bottom", la posición vertical del elemento está determinada por su posición en el orden de origen y el flujo natural dentro del offsetParent del elemento.

En MS Edge, sin embargo, top: auto y bottom: auto se renderizan más como si estuvieran explícitamente establecidos en top: 0 si offsetParent también contiene " display: flex "

El siguiente caso de prueba se representa como se esperaba en IE10, IE11, Chrome, Firefox, Safari y Opera: degradado rojo en la parte superior del área desplazable, degradado naranja en la parte inferior. MS Edge coloca ambos degradados desde la parte superior del contenedor exterior:

http://codepen.io/RwwL/pen/rORQVQ

Problema informado a MSFT:
https://connect.microsoft.com/IE/feedbackdetail/view/2035044/top-auto-and-bottom-auto-dont-work-correctly-in-ms-edge-in-relatively-positioned-flexbox-container

Comentario más útil

@gregwhitworth El problema es que hay varias formas de centrar las cosas en css transform: translateX(-50%) translateY(-50%); , margin: auto en un contenedor flexible, márgenes negativos, etc.

Ahora hay exactamente cero formas de colocar un contenido usando su posición flexible calculada, pero fuera del diseño normal. Esto evitará que las personas puedan lograr muchos diseños muy estándar dentro de contenedores flexibles que antes eran posibles.

También es importante darse cuenta de que debido a que no hay forma de determinar si el contenido está dentro de un contenedor flexible, esto introduce un nuevo comportamiento que los elementos no pueden anticipar sin saber de alguna manera si su contenedor principal es flex . Esto dificulta mucho el desarrollo de componentes que funcionen razonablemente en todas las situaciones. (El colapso del margen faltante de los elementos flexibles es otro ejemplo de esto).

Todos 5 comentarios

En realidad, esto es por especificación, la posición estática de un elemento flexible que está absolutamente posicionado debe ser como si fuera el único elemento en el contenedor flexible (en la configuración predeterminada, esto sería 0,0).

The static position of an absolutely-positioned child of a flex container is determined such that the child is positioned as if it were the sole flex item in the flex container, assuming both the child and the flex container were fixed-size boxes of their used size.

La razón por la que está viendo este problema se debe a que somos los únicos en este momento que se han actualizado al último lenguaje de especificaciones.

Ajá, gracias por hacérmelo saber, Greg. ¿Estoy pensando que el nuevo lenguaje de especificaciones es algo contrario a la intuición? No estoy seguro de por qué los desarrolladores no deberían poder suponer que el posicionamiento funcionará de manera similar a otros contextos.

Estoy de acuerdo con usted cuando lo mira por primera vez, pero digamos que desea usar las nuevas propiedades de alineación de la especificación de alineación en un elemento de abspos flex. Debería eliminar el desplazamiento introducido por la posición estática para centrar un elemento, que es desordenado y continúa el viejo adagio de "¿Por qué no puedo centrar algo en CSS?". Cuando introdujimos la cuadrícula, le permitió tener esta capacidad para centrar fácilmente cualquier elemento, ya sea un abspos o no; teniendo en cuenta a sus hermanos, por supuesto, si está en flujo. Para alinear la flexión y la cuadrícula (ya que ambos son diseños modernos) se decidió que tiene sentido permitir que las nuevas capacidades de alineación funcionen en ambos. Por lo tanto, el cambio, si tiene curiosidad por saber qué habilitó esto, vea este caso de prueba (los dos cuadros deben estar en el mismo lugar): http://jsbin.com/xowulasica/edit?html , css, output

Básicamente, la pregunta es esta, ¿retiene los tipos de diseño futuros debido a las limitaciones de los más antiguos para mantener la coherencia, o habilita nuevos tipos de diseño con más capacidades que introducen algunas inconsistencias con otros tipos de diseño? Apostamos por lo último porque, con suerte, a medida que se adoptan estas tecnologías, el diseño de bloques se usa solo donde fue diseñado, documentos, no diseño de aplicaciones. Si tenemos éxito en eso, habrá mucha menos inconsistencia debido a que la mayoría de los casos de uso de abspos son para el diseño de aplicaciones que usarían Grid o Flex y serían consistentes entre sí. No dudes en avisarme si tienes otras preguntas.

Gracias por esa respuesta reflexiva y detallada, Greg, ayuda mucho.

@gregwhitworth El problema es que hay varias formas de centrar las cosas en css transform: translateX(-50%) translateY(-50%); , margin: auto en un contenedor flexible, márgenes negativos, etc.

Ahora hay exactamente cero formas de colocar un contenido usando su posición flexible calculada, pero fuera del diseño normal. Esto evitará que las personas puedan lograr muchos diseños muy estándar dentro de contenedores flexibles que antes eran posibles.

También es importante darse cuenta de que debido a que no hay forma de determinar si el contenido está dentro de un contenedor flexible, esto introduce un nuevo comportamiento que los elementos no pueden anticipar sin saber de alguna manera si su contenedor principal es flex . Esto dificulta mucho el desarrollo de componentes que funcionen razonablemente en todas las situaciones. (El colapso del margen faltante de los elementos flexibles es otro ejemplo de esto).

¿Fue útil esta página
0 / 5 - 0 calificaciones