¿Deberíamos cerrar? | Consejos CSS

En los últimos meses he escrito mucho sobre pseudo-selectores CSS, como ::picker() o ::checkmark. Y, en el proceso, noté que tendía a usar :open En mi caso, y en mi trabajo en general, hay muchos pseudoselectores.

Toma prestadas las palabras de excelentes autores. :open Entradas en el almanaque:

CSS :open Los pseudoselectores apuntan a elementos que admiten estados abiertos y cerrados, p. <details> y <select> elementos – y en su estado abierto.

Entonces, dado esto:

details:open {
  background: lightblue;
  color: darkred;
}

esperamos <details> Cuando el elemento está abierto, aparece un fondo azul claro y texto rojo oscuro (en todas partes menos en Safari mientras escribo esto):

¿Pero qué pasa si queremos seleccionar el estado «apagado»? esto es lo que tenemos:closed Pseudoclase, ¿verdad? es Debe coincidir con el estado cerrado del elemento.. Yo dije, hipótesis Porque aún no se ha especificado.

¿Pero realmente es necesario especificarlo? Solo pregunto porque todavía podemos apuntar al estado cerrado de un elemento sin usar :not():

/* When details is _not_ open, but closed */
details:not(:open) {
  /* ... */
}

Entonces, una vez más: realmente necesitamos una :closed ¿Pseudoclase? ¡La respuesta puede sorprenderte! (Es broma, este no es ese tipo de artículo…)

algunos antecedentes

entorno de conversación :open A partir de mayo de 2022, cuando mason liberado bulto pregunta agregado :open (También se cree que lleva el nombre :top-layer En ese momento) ubique elementos de nivel superior (como ventanas emergentes):

Hoy, lo mismo ocurre con OpenUI WC Resuelto agregar un :top-layer La pseudoclase debería funcionar en (al menos) elementos usando API emergente Actualmente en el último piso. Sin embargo, la intención del nombre y el comportamiento es que esta pseudoclase también sea genérica. Debe coincidir con cualquier tipo de elemento en el nivel superior, incluidos los elementos modales. <dialog>elementos de pantalla completa y ::backdrop Pseudoelemento.

Esto llevó a una discusión sobre si el nombre de un pseudoelemento dirigido al nivel superior de cualquier tipo de elemento (por ejemplo, ventana emergente, selector, etc.) debería serlo. :open o :top-layer. Para mí personalmente, cuando Decisión final del CSSWG :open Agosto de 2022. El nombre tiene más sentido para mí porque «abierto» supone algo encima.

llegar :close o :not(:open)?

¡Pero aguanta! En septiembre de ese año, Mason preguntó si deberíamos tener algo similar. :closed pseudoclase compañera :open. De esta manera, podemos hacer coincidir elementos en el estado «apagado» del mismo modo que hacemos coincidir elementos en el estado «encendido». Esto tiene sentido, al menos superficialmente. Pestaña Atkins Interjección:

Me gusta esta definición porque creo que capta la idea de «abierto», que es coherente con lo que la mayoría de los desarrolladores piensan que significa «abierto». También creo que esto hace que sea relativamente sencillo para HTML conectarlo a un elemento específico.

¿Qué piensa la gente?

¿Deberíamos también discutir la adición de los correspondientes :closed ¿Pseudoclase? De esta manera puedes evitar problemas como este. :not(:open) puede igualar cualquier cosaincluidas las cosas que no se pueden abrir ni cerrar.

¿Adivina qué? Todos parecen estar de acuerdo. ¿Por qué? Porque tenía sentido en ese momento. Quiero decir, porque tenemos una pseudoclase que apunta a los elementos que contienen. :open estado, por supuesto que tiene sentido :closed Apuntar a elementos que están en un estado cerrado, ¿verdad? ¿Correcto? ?

No. Este razonamiento es realmente problemático. Joya Ahal hizo uno comenta sobre esto Octubre del mismo año:

Abrí una nueva pregunta sobre :closed Porque todavía no hay consenso (Capítulo 11039).

Espera, ¿qué pasó con el consenso? Esta es la misma pregunta que hice al principio de esta publicación. de acuerdo a Lucas Warlow:

hacer :closed Se siente extraño coincidir con algo que nunca se puede abrir. y básicamente tendrá éxito :not(:open) ¿Bajo qué circunstancias necesitamos siquiera :closed? como nosotros no :popover-closed porque es todo lo contrario :popover-open.

No :closed… Actualmente

Avance rápido un mes hasta noviembre de 2024. Todos llegaron a un consenso de que desde el principio, solo :open y eliminar :closed Siendo por el momento.

Dang Dang. De todos modos, según QUÉWG y CSSWGesta decisión puede cambiar en el futuro. De hecho, Brahms Justo un mes antes de la decisión del WHATWG, se publicó una nota útil:

Simplemente tomando esto como para su información: :read-only definido como :not(:read-write)y enviado.

¿Cuál te resulta más fácil de entender?

Personalmente estoy de acuerdo :closed —o incluso usar :not(:open) – en la medida en que funcione. De hecho, sigo intercambiando :closed para :not(:open) en mi ::checkmark y ::picker() ejemplo. Por eso son lo que son hoy.

¡pero! Si me preguntaras cuál me resulta más fácil en un día normal, creo que diría :closed. Es más fácil pensar literalmente que negar una afirmación.

¿Pero qué piensas? ¿Estás dispuesto a tener? :closed O simplemente déjalo como :not(:open)?

Si eres como yo y te gusta seguir debates como este, siempre puedes ir a Borrador del CSSWG en GitHub Mira o únete a la diversión.