css - posicionar - posiciones en html
CSS: posiciĆ³n: fija dentro de posiciĆ³n: absoluta (5)
Me estoy topando con algunos comportamientos extremadamente extraños y no consistentes en todos los navegadores que he probado.
Tengo un diseño bastante complejo, pero el problema principal radica aquí:
<div id="drop">
<div id="header"></div>
</div>
#drop
tiene position:absolute
e z-index:100
#header
tiene position:fixed; top:60px;
position:fixed; top:60px;
Cuando comienzo a desplazarme hacia abajo, Chrome ignora la position:fixed
regla position:fixed
. Si #drop
cualquiera de los dos estilos anteriores de #drop
, Chrome comienza a respetar la position:fixed
regla position:fixed
.
no puedo hacerlo funcionar en Ubuntu Chrome 23.0.1271.97 y ver el mismo comportamiento en Mac Chrome 25.0.1364.99. Mi amigo usa Ubuntu Chrome 25.0.1364.68 beta y funciona correctamente para él. Lo he probado en Firefox y funciona un poco (con otros síntomas)
¿Alguien ha oído hablar de este error? ¿O alguien puede incluso reproducirlo?
editar
Estoy usando el mapa de openlayers como otro div con position:fixed
si elimino esa capa o al menos la cambio para display:none
entonces este extraño error desaparece.
editar
Noté que durante la presencia de este error, si cambio el nivel de zoom hacia adelante y hacia atrás, entonces la posición se ajusta al comportamiento adecuado. Para mí, esto indica un problema de webkit que no puede ejecutar alguna función de devolución de llamada interna en el desplazamiento.
Otra cosa extremadamente extraña es que tengo algunos enlaces dentro de #header
y funcionan si hago clic en la ubicación esperada, a pesar de que el div no aparece allí. En general , he notado que solo se ha roto la representación . Si en algún momento obligo al navegador a volver a renderizar cambiando el tamaño de la ventana o cambiando el zoom, o simplemente haciendo Select-All, la barra de encabezado salta a la posición correcta, pero no permanece fija.
Como dice la respuesta aceptada, este es el comportamiento deseado y cumple con las especificaciones. Otro componente importante de esto es lo que significa usar transformaciones CSS.
En su caso, se debió a OpenLayers, pero esto se aplica a cualquier persona que use will-change: transform
también (probablemente muchas de las personas que visitan esta pregunta). Esto se ha incluido en el rastreador de errores de Chromium here , y se ha marcado como WontFix
, porque (como dije) es el comportamiento previsto. El comentario oficial es este:
Este comportamiento es requerido por la especificación ( http://dev.w3.org/csswg/css-will-change/ ): "Si cualquier valor no inicial de una propiedad causara que el elemento genere un bloque contenedor para posicionar elementos, especificando que la propiedad en will-change debe hacer que el elemento genere un bloque contenedor para elementos de posición fija ".
La idea es que, una vez que se va a cambiar: se especifique la transformación, debería poder agregar / eliminar / cambiar las transformaciones a bajo costo, sin necesidad de que los descendientes de posición fija se vuelvan a desplegar.
Tenga en cuenta que el uso de otros valores de cambio de voluntad (por ejemplo, opacidad, arriba) no cambiará la posición de los descendientes de posición fija.
Que yo sepa, la única solución es hacer que el hijo del elemento will-change
un hermano , para evitar que el atributo caiga en cascada.
Como nota al margen, en mi caso específico, pude arreglarlo siendo más específico con el atributo de will-change
. En lugar de usarlo en la div
contiene el elemento de rendimiento que requirió la descarga de la GPU, lo usé directamente en el elemento ofensivo. Sin embargo, esto se debió a mi código erróneo original, por lo que no funcionará en la mayoría de los casos.
En primer lugar, pon algo en tu div
ya que los vacíos se comportan realmente raros. Entonces, ¿qué esperas al poner un fixed
en un absolute
? Obviamente, nadie sabe cuál es el punto de referencia de su div fixed
. ¿Debería ser la posición de sus padres? ¿Qué no cambia con el desplazamiento o la posición de la página que cambia? Trate de usar cosas que sean completamente significativas y tenga una definición clara porque si lo arregla en Chrome, ¿qué pasaría con otro navegador? ¿Realmente prefieres probar está en todos ellos?
Supongo que hay un pequeño cambio en sus div
s para que saque el div fixed
del absolute
o mueva el div absolute
otro lugar.
Quiero agregar otra solución posible porque estaba luchando con la posición de ignorar el cromo: corregida por bastante tiempo hasta que finalmente encontré al culpable:
-webkit-perspective: 1000;
Procedía de un complemento que estaba usando y hace que TODAS las posiciones: los elementos fijos se ignoren. Espero que ayude a alguien.
Tendrá que colocar el header
fuera del contenedor primario para que funcione.
Tuve problemas ligeramente similares días atrás. Por ejemplo, si establece el índice z del header
, se alcanzará el índice z del contenedor principal de la drop
. El índice z del header
será inútil porque ya está dentro de un contenedor que tiene otro índice z
La misma lógica del índice z se aplica a la posición.
Usted mencionó en los comentarios que OpenLayers usa transformaciones CSS. Siendo ese el caso:
el elemento con posicionamiento fijo se convertirá en relativo al elemento con la transformación, no en relación con la ventana gráfica
Eche un vistazo a la especificación: el modelo de procesamiento de transformación
Al especificar un valor distinto de ''ninguno'' para la propiedad ''transformar'' se establece un nuevo sistema de coordenadas local en el elemento al que se aplica.
Mire este FIDDLE en un navegador webkit para ver esto en acción.
<div class="wpr">
<div class="fixed"></div>
</div>
.wpr
{
width: 200px;
height:1000px;
background: pink;
position:relative;
margin: 0 200px;
-webkit-transform: translateX(0);
transform: translateX(0);
}
.fixed
{
width: 200px;
height:200px;
margin: 50px;
position: fixed;
top:0;
left:0;
background: aqua;
}