Saltar enlaces

Puede aparecer en el navegador: near() You

Justo antes de que termine 2025, veo Esta propuesta apunta :near()una pseudoclase que coincidirá si el indicador está cerca del elemento. ¿Cuántos? Bueno, eso depende de lo que valga. <length> Argumentos aportados. Thomas Valicevicquien propuso :near()mostrando cómo funciona de la siguiente manera:

button:near(3rem) {
  /* Pointer is within 3rem of the button */
}

Para aquellos que se preguntan, sí podemos usar el teorema de Pitágoras. Mida la distancia en línea recta entre dos elementos usando JavaScript (“Distancia euclidiana” es un término matemático), así que supongo que esa es la distancia que se utiliza aquí detrás de escena. Tengo algunos casos de uso para compartir con ustedes, pero las demostraciones son solo simulaciones. :near() Porque aparentemente no es compatible con ningún navegador web. ¿Vamos a profundizar?

efectos visuales

No hay duda de que :near() Se puede utilizar para una cantidad casi infinita (lo siento) de efectos visuales:

div {
  /* Div is wow */

  &:near(3rem) {
    /* Div be wowzer */
  }

  &:near(1rem) {
    /* Div be woahhhh */
  }
}

Atenúe el elemento hasta :near()

Para reducir el desorden visual, es posible que desees atenuar ciertos componentes hasta que los usuarios se acerquen a ellos. :near() probablemente mejor que :hover En este caso, dado que los usuarios pueden tener problemas para interactuar con los componentes si tienen una visibilidad limitada, poder activarlos “temprano” puede compensar de alguna manera esto. Sin embargo, tenemos que garantizar un contraste de color accesible, por lo que no estoy seguro de lo útil que sea. :near() puede estar en esta situación.

button:not(:near(3rem)) {
  opacity: 70%; /* Or...something */
}

esconder elementos hasta :near()

Además de atenuar componentes, también podemos ocultar componentes (siempre que no sean importantes). Creo que este es un mejor caso de uso. :near()ya que no tenemos que preocuparnos por el contraste de colores, aunque sí presenta diferentes retos de accesibilidad.

Bueno, ¿sabías que el botón de compartir aparece cuando pasas el mouse sobre una imagen? Tiene sentido, ¿verdad? Como no queremos que la imagen se oscurezca, la ocultamos inicialmente. No es el mejor en términos de experiencia de usuario, pero sigue siendo un patrón familiar, por ejemplo en Pinterest.

El método es el siguiente. :near() Se puede mejorar. La gente sabe o sospecha que el botón está ahí, ¿verdad? Debería estar en la esquina inferior derecha, ¿verdad? Saben aproximadamente dónde hacer clic, pero no exactamente dónde, porque no conocen el tamaño o el desplazamiento del botón. Bueno, cuando se muestra el botón :near() Lo que significa que no tienen que desplazarse con tanta precisión para que aparezca el botón. Esta situación es muy similar a la anterior, pero el motivo de la visibilidad reducida puede ser diferente.

Sin embargo, necesitamos que este botón sea accesible (se pueda desplazar, enfocar y paginar). Para esto no podemos usar:

  • display: hidden (No se puede desplazar, enfocar ni encontrar en la página)
  • visibility: hidden (Tampoco se puede desplazar, enfocar ni buscar dentro de la página)
  • opacity: 0 (Una vez encontrado a través de buscar en la página, no se puede mostrar)

Esto nos deja con content-visibility: hiddenpero el problema con el uso de contenido oculto content-visibility: hidden (o elemento con display: none) es que en realidad desaparecen y no puedes acercarte a algo que no existe en absoluto. Esto significa que debemos reservar espacio para ello, incluso si no lo sabemos. Cuántos espacio.

Ahora, :near() Esto no es compatible con ningún navegador web, por lo que en la siguiente demostración envuelvo el botón en un contenedor. 3rem de paddingcuando el contenedor está siendo :hovered para mostrar el botón. Esto aumenta el tamaño del área sobre la que se puede pasar el cursor (la puse en rojo para que puedas verla) en lugar del tamaño del botón real. Es esencialmente una simulación. button:near(3rem).

Reserva de inserción de CodePen

Pero, ¿cómo ocultamos algo preservando el espacio?

Primero, declaramos contain-intrinsic-size: auto none sobre objetivos ocultos. Esto asegura que mantenga un tamaño específico incluso si cambia (en este caso, incluso si su contenido está oculto). Puedes especificar un <length> para cualquier valor, pero en este caso auto Es decir, cualquiera que sea el tamaño de renderizado. noneque es un valor de reserva requerido o puede ser <length>pero no lo necesitamos en absoluto, entonces “none“.

El problema es que el tamaño renderizado no hace “nada” porque el botón está content-visibility: hidden¿recordar? Esto significa que sólo tenemos que renderizar durante un milisegundo, que es lo que hace esta animación:

<div id="image">
  <div id="simulate-near">
    <button hidden="until-found">Share</button>
  </div>
</div>
@keyframes show-content {
  from {
    content-visibility: visible;
  }
}

button {
  /* Hide it by default */
  &:not((hidden="until-found")) {
    content-visibility: hidden;
  }

  /* But make it visible for 1ms */
  animation: 1ms show-content;

  /* Save the size while visible */
  contain-intrinsic-size: auto none;
}

Tenga en cuenta que si el botón tiene hidden=until-found valor del atributo, que lo hace enfocable y localizable en la página, content-visibility: hidden No hay ninguna declaración porque hidden=until-found Haga esto automáticamente. De todos modos, declaración de animación. content-visibility: visible para 1ms a pesar de contain-intrinsic-size: auto none Capta su tamaño y preserva el espacio, permitiéndonos desplazarlo incluso si no es visible.

Ahora que entiendes cómo funciona, aquí tienes el código completo (nuevamente, está simulado porque :near() Aún no compatible):

<div id="image">
  <div id="simulate-near">
    <button hidden="until-found">Share</button>
  </div>
</div>
@keyframes show-content {
  from {
    content-visibility: visible;
  }
}

#simulate-near {
  /* Instead of :near(3rem) */
  padding: 3rem;

  button {
    /* Unset any styles */
    border: unset;
    background: unset;

    /* But include size-related styles */
    padding: 1rem;

    /* Hide it by default */
    &:not((hidden="until-found")) {
      content-visibility: hidden;
    }

    /* But make it visible for 1ms */
    animation: 1ms show-content;

    /* Save the size while visible */
    contain-intrinsic-size: auto none;
  }

  &:where(:hover, :has(:focus-visible)) button {
    color: white;
    background: black;
    content-visibility: visible;
  }
}

Si te preguntas por qué desarmamos border y backgroundesto es porque content-visibility: hidden Sólo se oculta el contenido, no el elemento en sí, pero lo hemos incluido. padding Aquí, debido a que esto afectará el tamaño que intentamos renderizar, téngalo en cuenta. Entonces solo necesitamos aplicar estos estilos. content-visibility: visible al botón cuando se abre el envoltorio :hovereditar o :has(:focus-visible).

Esto es lo mismo pero no es compatible. :near():

<div id="image">
  <button hidden="until-found">Share</button>
</div>
@keyframes show-content {
  from {
    content-visibility: visible;
  }
}

button {
  /* Unset any styles */
  border: unset;
  background: unset;

  /* But include size-related styles */
  padding: 1rem;

  /* Hide it by default */
  &:not((hidden="until-found")) {
    content-visibility: hidden;
  }

  /* But make it visible for 1ms */
  animation: 1ms show-content;

  /* Save the size while visible */
  contain-intrinsic-size: auto none;

  &:where(:near(3rem), :hover, :focus-visible) {
    color: white;
    background: black;
    content-visibility: visible;
  }
}

en breve, :near() Nos permite hacer lo que hace la tecnología simulada, pero sin el marcado adicional y los selectores creativos, si tenemos alguna necesidad de accesibilidad. animation/contain-intrinsic-size truco.

Precargar/prepresentar cuando esté cerca

No estoy sugiriendo que haya una manera de usar :near() Incluso :near() debería ampliarse, sino más bien API de reglas de especulación Aproveche su funcionalidad subyacente. Se utiliza la API de reglas de especulación. mousedown, touchstartla dirección y velocidad del puntero, la presencia de la ventana gráfica y la pausa de desplazamiento como señales para comenzar a precargar/prepresentar recursos vinculados, así que ¿por qué no estar cerca?

De hecho, creo que el concepto de “proximidad” se puede aplicar a mucho más que :near()y debería Considerando el uso de pruebas de acierto personalizadas pointermove Tiene un mayor costo de rendimiento y complejidad de implementación (como señaló Thomas). Veamos otro ejemplo.

Mejorar la interacción de las personas que llaman con intereses

Al interactuar con una superposición activada por desplazamiento, existe el riesgo de alejar accidentalmente el indicador del disparador o del objetivo. este API de llamada de interésque facilita las interacciones activadas por el cursor, utilice interest-show-delay y interest-hide-delay Las propiedades CSS evitan la activación y desactivación accidental respectivamente, pero desde la perspectiva de la experiencia del usuario, cualquier cosa que implique latencia y sensibilidad temporal no es divertida.

Por poner algunos ejemplos:

  • El puntero se sitúa en el espacio entre un activador de interés (como un enlace o botón) y un objeto de interés (como una ventana emergente).
  • Las métricas excedieron los límites del objetivo de interés al intentar interactuar con un elemento cerca del borde del objetivo de interés.

Por lo tanto, en lugar de (o además de) mostrar y ocultar retrasos, la API de llamada de interés puede aprovechar el concepto de “cerca” para garantizar que la superposición no desaparezca debido a interacciones erróneas. Esto se puede configurar a través de propiedades CSS (por ejemplo, near-radius: 3rem o simplemente near: 3rem), que está relacionado con :near() llamará a la función (interest y loseinterest Eventos de JavaScript, en este caso).

Otro caso de uso que Thomas propuso en su propuesta: mostrar un mensaje de “arrastrar para reordenar” al pasar el cursor cerca de un elemento que se puede arrastrar. Este es un excelente caso de uso porque mostrar la información sobre herramientas incluso unos milisegundos antes puede reducir el tiempo de la tarea.

Desafortunadamente, sería difícil (¿creo?) emularlos con HTML válido, principalmente porque <a>arena <button>s sólo puede contener ciertos elementos.

defecto :near()

Una posible desventaja es :near() En situaciones en las que un mejor diseño de la interfaz de usuario es la opción correcta, puede generar un aumento significativo en el número de desarrolladores que ocultan contenido perezosamente para reducir el desorden visual, o Aumentar Desorden visual (por ejemplo, con ilustraciones innecesarias) porque Se puede ocultar condicionalmente.

Otros posibles abusos incluyen mapas de calor, huellas dactilares y modelos publicitarios agresivos. La forma en que se utiliza también puede tener un impacto negativo en el rendimiento. La propuesta de Tomás. Excelente trabajo al señalar estos abusos y las formas de corregirlos. :near() se pueden implementar medidas para detenerlos.

:near() Problemas de accesibilidad

:near() no debe implicar :hover o :focus/:focus-visible. Creo que es obvio cuando realmente lo piensas, pero aún puedo ver que se cruzan líneas. Una buena pregunta para hacer antes de usar. :near() Sí: “¿Atacamos primero o atacamos primero?” Los ataques preventivos pueden ser buenos, pero Presunto Siempre es malo porque nunca queremos que el usuario piense que está flotando o concentrándose en un elemento interactivo cuando en realidad no lo está (o no lo ha hecho). Esto se menciona en varias secciones de las Pautas de accesibilidad al contenido web, pero más notablemente Criterio de éxito 2.4.7: Enfoque visible (Nivel AA).

Similarmente, Criterio de éxito 2.5.8: Escala objetivo (Nivel AA) Indica que los elementos interactivos son más pequeños que 24x24px Debe haber un espacio adicional alrededor de ellos, calculado de la siguiente manera 24px - target width/24px - target heightpero independientemente de si el valor :near() Es un poco ambiguo considerar esto.

En resumen

Hay mucho que considerar aquí, pero en última instancia, me encantaría verlo implementado como propone Thomas. Dicho esto, las Directrices WCAG debe Ser sólidos como una roca antes de que comience cualquier implementación, especialmente teniendo en cuenta lo que ya podemos lograr. :near() servirá (aunque con más marcado y tal vez algunos trucos de CSS).

Nuevamente, creo que deberíamos pensar en “próximo” como un concepto, donde la funcionalidad subyacente puede ser proporcionada por la API de reglas especulativas y la API de llamadas de interés (esta última tiene propiedades CSS, p. ej. near-radius).

¡Por favor danos tu opinión!


Puede aparecer en el navegador: near() You Publicado originalmente en Consejos CSS,Esto es océano digital familia. debería Recibe el boletín.

Home
Account
Cart
Search
¡Hola! ¡Pregúntame lo que quieras!
Explore
Drag