¿Por qué funciona CSS con elementos falsos?

438

En mi clase, estaba jugando y descubrí que CSS funciona con elementos inventados.

Ejemplo:

imsocool {
    color:blue;
}
<imsocool>HELLO</imsocool>

Cuando mi profesor me vio usando esto por primera vez, se sorprendió un poco de que los elementos inventados funcionaran y me recomendó que simplemente cambiara todos mis elementos inventados a párrafos con ID.

¿Por qué mi profesor no quiere que use elementos inventados? Ellos trabajan de manera efectiva.

Además, ¿por qué no sabía que los elementos inventados existen y funcionan con CSS? ¿Son poco comunes?

Jordan ChillMcgee Ludgate
fuente
6262
HTML es una forma de proporcionar significado a los datos que pueden ser entendidos por una amplia variedad de medios (incluyendo personas y navegadores). Sus etiquetas inventadas no agregan ningún significado. Esa es una de las muchas razones por las que no quiere que las uses.
punkrockbuddyholly
59
@MrMisterMan en realidad creo que sí. Lo que es más significativo, <p>555-212-2344</p>o <supportPhone> 555-212-2344 </supportPhone>
Yuriy Galanter, el
169
@YuriyGalanter <p class = "supportPhone">; P
punkrockbuddyholly
30
@MrMisterMan Solo recuerda, todas estas reglas y construcciones de programación fueron creadas por personas no más inteligentes que tú, y puedes cambiarlo, puedes influir en él, puedes construir tus propias cosas que otras personas pueden usar.
L_7337
90
Podría señalar que lo que estás haciendo es básicamente XML, no HTML. XML es un lenguaje de marcado más abstracto que le permite representar datos de la manera "útil" que describe, es decir. con significado semántico adjunto. Luego puede usar una transformación XSLT para representar sus datos en HTML
ose

Respuestas:

470

¿Por qué funciona CSS con elementos falsos?

(La mayoría) los navegadores están diseñados para ser (hasta cierto punto) compatibles con futuras adiciones a HTML. Los elementos no reconocidos se analizan en el DOM, pero no tienen semántica o representación predeterminada especializada asociada a ellos.

Cuando se agrega un nuevo elemento a la especificación, a veces se pueden usar CSS, JavaScript y ARIA para proporcionar la misma funcionalidad en navegadores más antiguos (y los elementos deben aparecer en el DOM para esos idiomas para poder manipularlos para agregar esa funcionalidad) )

(Aunque debe tenerse en cuenta que se está trabajando para definir un medio para extender HTML con elementos personalizados , pero este trabajo se encuentra en las primeras etapas de desarrollo en la actualidad, por lo que probablemente debería evitarse hasta que haya madurado).

¿Por qué mi profesor no quiere que use elementos inventados?

  • No están permitidos por la especificación HTML
  • Pueden entrar en conflicto con futuros elementos estándar con el mismo nombre.
  • Probablemente haya un elemento HTML existente que se adapte mejor a la tarea.

También; ¿Por qué no sabía que los elementos inventados existían y funcionaban con CSS? ¿Son poco comunes?

Si. Las personas no los usan porque tienen los problemas anteriores.

Quentin
fuente
30
"No están permitidos por la especificación HTML" No necesariamente es cierto. No se ajustan a la especificación del espacio de nombres HTML, pero la especificación HTML5 es algo mucho más amplio que permite especificaciones personalizadas, y establece explícitamente cómo manejar tales cosas con respecto al manejo de CSS y API (DOM).
Ben Lesh
44
Ya hay bibliotecas, especialmente Angular.js, que le permiten extender HTML con elementos personalizados. Tal vez no en el sentido de que quiere decir que los elementos simplemente son analizados por javascript y traducidos a los reales por lo general, pero si está buscando extender html con etiquetas personalizadas, puede hacerlo con Angular
Charlie Martin
11
+1 Para "Pueden entrar en conflicto con estándares futuros". Recuerde que puede funcionar ahora, pero tiene que funcionar durante 3-4 años después de que haya comenzado.
tim.baker
70
Me gusta tener una etiqueta <ninja> para ocultar elementos dom en lugar de aplicar una visualización de estilo: ninguna, por ejemplo: <ninja> Algunas cosas ocultas </ninja>
kiranvj
18
Otro punto realmente importante: los navegadores especiales para personas ciegas o personas con capacidades limitadas usan los elementos HTML adecuados para diferentes cosas (facilite la navegación en la página siguiendo los encabezados, por ejemplo). Por lo tanto, la semántica faltante + representación predeterminada podría no afectar demasiado a los navegadores normales, pero estos navegadores especiales probablemente se confundirán, reduciendo drásticamente la usabilidad de su sitio web.
Arve Systad
98

TL; DR

  • Las etiquetas personalizadas no son válidas en HTML. Esto puede conducir a problemas de representación.
  • Hace que el desarrollo futuro sea más difícil ya que el código no es portátil.
  • El HTML válido ofrece muchos beneficios, como SEO, velocidad y profesionalismo.

Respuesta larga

Hay algunos argumentos de que el código con etiquetas personalizadas es más útil.

Sin embargo, conduce a HTML no válido. Lo cual no es bueno para su sitio.

El punto de CSS / HTML válido | Desbordamiento de pila

  • Google lo prefiere, por lo que es bueno para el SEO.
  • Hace que su página web sea más probable que funcione en navegadores que no ha probado.
  • Te hace ver más profesional (al menos para algunos desarrolladores)
  • Los navegadores compatibles pueden representar [HTML válido más rápido]
  • Señala un montón de errores oscuros que probablemente haya perdido y que afectan a cosas que probablemente no haya probado, por ejemplo, la página de códigos o el conjunto de idiomas de la página.

Por qué validar | W3C

  • Validación como herramienta de depuración
  • Validación como un control de calidad a prueba de futuro
  • La validación facilita el mantenimiento
  • La validación ayuda a enseñar buenas prácticas.
  • La validación es un signo de profesionalismo.
Dan Grahn
fuente
8
Otro argumento a favor del código válido es que, si necesita entregar a otro desarrollador o si está trabajando en un equipo, los otros miembros o el nuevo desarrollador deben comprender instantáneamente lo que está tratando de lograr. . . Con etiquetas inventadas no válidas, esto puede volverse muy difícil ...
Pat Dobson
99
AKA Desarrollo futuro y mantenimiento fácil.
Dan Grahn
68

YADA (otra respuesta (diferente))

Editar: consulte el comentario de BoltClock a continuación sobre el tipo vs etiqueta vs elemento. Por lo general, no me preocupo por la semántica, pero su comentario es muy apropiado e informativo.

Aunque ya hay un montón de buenas respuestas, indicó que su profesor le solicitó que publicara esta pregunta, por lo que parece que está (formalmente) en la escuela . Pensé en exponer un poco más en profundidad no solo sobre CSS sino también sobre la mecánica de los navegadores web. Según Wikipedia , "CSS es un lenguaje de hoja de estilo utilizado para describir ... un documento escrito en un lenguaje de marcado". (Agregué el énfasis en "a") Tenga en cuenta que no dice "escrito en HTML" y mucho menos una versión específica de HTML. CSS se puede usar en HTML, XHTML, XML, SGML, XAML, etc. Por supuesto, necesita algo que representecada uno de estos tipos de documentos que también aplicarán estilos. Por definición, CSS no sabe / entiende / se preocupa por las etiquetas específicas del lenguaje de marcado. Por lo tanto, las etiquetas pueden ser "inválidas" en lo que respecta a HTML, pero no hay un concepto de etiqueta / elemento / tipo "válido" en CSS.

Los navegadores visuales modernos no son programas monolíticos. Son una amalgama de diferentes "motores" que tienen trabajos específicos que hacer. Como mínimo , puedo pensar en 3 motores, el motor de renderizado, el motor CSS y el motor javascript / VM. No estoy seguro si el analizador es parte del motor de renderizado (o viceversa) o si es un motor separado, pero se entiende la idea.

Si un navegador visual ( otros ya han abordado el hecho de que los lectores de pantalla pueden tener otros desafíos relacionados con las etiquetas inválidas ) aplica el formato depende de si el analizador deja la etiqueta "inválida" en el documento y luego si el motor de renderizado aplica estilos a esa etiqueta Dado que dificultaría el desarrollo / mantenimiento, los motores CSS no están escritos para comprender que "este es un documento HTML, así que aquí está la lista de etiquetas / elementos / tipos válidos". Los motores CSS simplemente encuentran etiquetas / elementos / tipos y luego le dicen al motor de representación: "Aquí están los estilos que debe aplicar". Si el motor de renderizado decide aplicar los estilos o no, depende de ello.

Aquí hay una manera fácil de pensar en el flujo básico de motor a motor: analizador -> CSS -> representación. En realidad es mucho más complicado pero esto es lo suficientemente bueno para empezar.

Esta respuesta ya es demasiado larga, así que terminaré allí.

Andrew Steitz
fuente
10
Aunque ha mencionado que "etiquetas" se ha convertido en un término común para elementos, con lo que no puedo y no estoy en desacuerdo, eso no cambia el hecho de que el término correcto para ellos sigue siendo "elementos". Una etiqueta es específicamente una función de sintaxis de HTML y XML, y puede no existir en otros lenguajes de documentos que sean compatibles con CSS. Entonces, decir que los estilos CSS "etiquetas" como las personas a menudo los llaman no está haciendo mucha justicia al agnosticismo del lenguaje de documentos de CSS.
BoltClock
53

Los elementos desconocidos son tratados como divs por los navegadores modernos. Por eso trabajan. Esto es parte del estándar HTML5 inminente que introduce una estructura modular a la que se pueden agregar nuevos elementos.

En navegadores más antiguos (creo que IE7-) puedes aplicar un truco Javascript después del cual también funcionarán.

Aquí hay una pregunta relacionada que encontré al buscar un ejemplo.

Aquí hay una pregunta sobre la corrección de Javascript . Resulta que, de hecho, IE7 no es compatible con estos elementos de fábrica.

También; ¿Por qué no sabía que las etiquetas inventadas existían y funcionaban con CSS? ¿Son poco comunes?

Si bastante. Pero especialmente: no tienen un propósito adicional. Y son nuevos en html5. En versiones anteriores de HTML, una etiqueta desconocida no era válida.

Además, los maestros parecen tener lagunas en su conocimiento, a veces. Esto podría deberse al hecho de que necesitan enseñar a los estudiantes los conceptos básicos sobre un tema determinado, y realmente no vale la pena conocer todos los entresijos y estar realmente actualizados. Una vez recibí detención porque un maestro pensó que había programado un virus, solo porque podía hacer que una computadora playreprodujera música usando el comando en GWBasic. (Historia verdadera, y sí, hace mucho tiempo). Pero sea cual sea el motivo, creo que el consejo de no utilizar elementos personalizados es acertado.

GolezTrol
fuente
3
@OnoSendai Me hiciste dudar, pero realmente creo que se representan como 'elementos de bloque sin marcado adicional', básicamente como divs.
GolezTrol
66
@OnoSendai Un elemento de bloque puede tener la propiedad de visualización de bloque , pero no es obligatorio. Por ejemplo, las etiquetas de anclaje se promocionaron para bloquear el estado (lo que significa que puede colocar elementos de bloque como divs dentro de ellas), pero aún tienen la propiedad de visualización en línea.
cimmanon
8
El valor inicial de displayes inline, por lo que el comentario de @ OnoSendai es correcto.
BoltClock
2
@cimmanon: los aelementos tienen un modelo de contenido transparente ahora, por lo que si son en bloque o en línea depende de si su antepasado es en bloque o en línea. Esta respuesta está hablando de elementos desconocidos, para los cuales HTML no define un modelo de contenido. En lo que respecta a CSS, si no hay un displayvalor predeterminado del navegador , utiliza el valor inicial.
BoltClock
1
@ BoltClock'saUnicorn Entonces, ¿eso significa que <div> <a> foo </a> <a> bar </a> </div> representará las dos etiquetas <a> como bloques? Eso parece un poco sospechoso ...
esponjosa
27

En realidad puedes usar elementos personalizados. Aquí está la especificación W3C sobre este tema:

http://w3c.github.io/webcomponents/spec/custom/

Y aquí hay un tutorial que explica cómo usarlos:

http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

Como señaló @Quentin: esta es una especificación preliminar en los primeros días de desarrollo, y que impone restricciones sobre los nombres de los elementos.

Bas van Dijk
fuente
77
Cabe señalar que esa es una especificación preliminar en los primeros días de desarrollo, y que impone restricciones sobre los nombres de los elementos.
Quentin
2
+1 No sabía los usos del W3C, githubpero sí los usan.
Vitor Canova
22

Hay algunas cosas sobre las otras respuestas que están mal redactadas o tal vez un poco incorrectas.

FALSO (ish): los elementos HTML no estándar son "no permitidos", "ilegales" o "inválidos".

No necesariamente. Son "no conformes" . ¿Cual es la diferencia? Algo puede "no conformarse" y aún así ser "permitido". El W3C no enviará a la policía HTML a su hogar y lo llevará lejos.

El W3C dejó las cosas de esta manera por una razón. La conformidad y las especificaciones están definidas por una comunidad. Si tiene una comunidad más pequeña que consume HTML para fines más específicos y todos acuerdan algunos Elementos nuevos que necesitan para facilitar las cosas, pueden tener lo que el W3C denomina "otras especificaciones aplicables" . (Obviamente, esto es una gran simplificación, pero se entiende la idea)

Dicho esto, los validadores estrictos declararán que sus elementos no estándar son "inválidos". pero eso se debe a que el trabajo del validador es garantizar el cumplimiento de las especificaciones para las que está validando, no garantizar la "legalidad" para el navegador o para su uso .

FALSO (más o menos): elementos HTML no estándar serán dar lugar a problemas de representación

Posiblemente, pero poco probable. (reemplace "will" con "might"). La única forma en que esto debería dar lugar a un problema de representación es si su elemento personalizado entra en conflicto con otra especificación, como un cambio en la especificación HTML u otra especificación respetada dentro del mismo sistema (como SVG, Matemáticas o algo personalizado).

De hecho, la razón por la que CSS puede diseñar etiquetas no estándar es porque la especificación HTML establece claramente que:

Los agentes de usuario deben tratar los elementos y atributos que no entienden como semánticamente neutros; dejándolos en el DOM (para procesadores DOM) y diseñándolos de acuerdo con CSS (para procesadores CSS), pero sin inferir ningún significado de ellos

Nota: si desea usar una etiqueta personalizada, solo recuerde que un cambio en la especificación HTML en un momento posterior podría volar su estilo, así que prepárese. Sin <imsocool>embargo, es realmente poco probable que el W3C implemente la etiqueta.

Etiquetas no estándar y JavaScript (a través del DOM)

La razón por la que puede acceder y modificar elementos personalizados usando JavaScript es porque la especificación incluso habla de cómo deben manejarse en el DOM , que es la API (realmente horrible) que le permite manipular los elementos en su página.

La interfaz HTMLUnknownElement debe usarse para elementos HTML que no están definidos por esta especificación (u otras especificaciones aplicables).

TL; DR: La conformidad con la especificación se realiza con fines de comunicación y seguridad. La no conformidad todavía está permitida por todo excepto un validador , cuyo único propósito es hacer cumplir la conformidad, pero cuyo uso es opcional.

Por ejemplo:

var wee = document.createElement('wee');
console.log(wee.toString()); //[object HTMLUnknownElement]

(Estoy seguro de que esto atraerá llamas, pero ahí están mis 2 centavos)

Ben Lesh
fuente
3
El HTML no solo especifica cómo deben tratarse los elementos con CSS, sino que la especificación de CSS es, en su mayor parte, un documento independiente del lenguaje por diseño también (esto ya está implícito en algunas otras respuestas, pero lo anoto aquí para conveniencia). Si hay algún comportamiento específico de HTML y / o XHTML, siempre se indica , incluso en texto informativo (por ejemplo, "el idatributo especifica un ID de elemento HTML "), no solo texto normativo (consulte Fondos y bordes 3 para obtener un ejemplo).
BoltClock
18

De acuerdo con las especificaciones:

CSS

Un selector de tipo es el nombre de un tipo de elemento de lenguaje de documento escrito usando la sintaxis de nombres calificados CSS

Pensé que esto se llamaba el selector de elementos , pero aparentemente es en realidad el selector de tipo . La especificación continúa para hablar sobre lo CSS qualified namesque no restringe cuáles son realmente los nombres. Es decir, siempre que el selector de tipo coincida con la sintaxis de nombre calificado por CSS, es técnicamente correcto y coincidirá con el elemento en el documento. No existe una restricción específica de CSS en elementos que no existen en una especificación particular: HTML u otros.

HTML

No hay restricciones oficiales para incluir etiquetas en el documento que desee. Sin embargo, la documentación dice

Los autores no deben usar elementos, atributos o valores de atributos para fines distintos de su propósito semántico previsto, ya que esto impide que el software procese correctamente la página.

Y luego dice

Los autores no deben usar elementos, atributos o valores de atributos que no estén permitidos por esta especificación u otras especificaciones aplicables, ya que hacerlo dificulta significativamente la extensión del lenguaje en el futuro.

No estoy seguro específicamente dónde o si la especificación dice que los elementos desconocidos están permitidos , pero habla sobre la interfaz HTMLUnknownElement para elementos no reconocidos. Algunos navegadores pueden incluso no reconocer elementos que están en la especificación actual (IE8 viene a la mente).

Sin embargo, hay un borrador para elementos personalizados , pero dudo que se implemente en cualquier lugar todavía.

Píldoras de explosión
fuente
Creo que la mayoría de nosotros los consideramos como selectores de elementos , pero tiene sentido que sean selectores de tipo "oficialmente" .
Andrew Steitz
@ Andrew Steitz: Piénsalo de esta manera: elemento: tipo :: persona: nombre. Puede tener muchos elementos de diferentes tipos, cada elemento es de un solo tipo, y de la misma manera puede tener muchas personas, cada una con un nombre. Los selectores funcionan en un árbol de documentos, y cada selector puede coincidir con cierto número de elementos del árbol de documentos, que puede reducir con un selector de clase, un selector de ID, un selector de atributos ... o un selector de tipo. Independientemente de lo que use, sigue combinando elementos. Por lo tanto, "selector de elementos" no tendría sentido en este caso, todas estas cosas serían selectores de elementos.
BoltClock
@ BoltClock'saUnicorn: es cierto, pero la clase, el ID y el atributo son todos, uh, atributos (LOL) de un "elemento", es decir, la "cosita" dentro de los corchetes angulares. Describen el "elemento" en cuya etiqueta de apertura residen. Sí, <a> y <div> son "tipos" específicos de elementos, pero dudo que alguien llame a la clase, ID y atributos "elementos". TOTALMENTE estoy de acuerdo en que todos los selectores son realmente selectores de "elementos", pero en el USO COMÚN, las personas generalmente se refieren a los selectores de "tipo" como selectores de "elementos". Ese fue el punto de mi comentario anterior. Lo siento, no estaba claro. :-)
Andrew Steitz
@ExplosionPills: las especificaciones HTML no dicen que los elementos desconocidos están prohibidos, pero dado que cada elemento tiene una lista enumerada de nombres de elementos que están permitidos como elementos secundarios (es decir, su modelo de contenido), no es necesario. Simplemente no hay ningún lugar donde se permita un elemento desconocido como hijo de un elemento permitido. La aplicación de HTMLUnknownElement a dichos elementos es parte de la especificación de precesión, es decir, lo que los consumidores de HTML deben hacer con documentos válidos o no, y no parte de lo que los autores deben hacer para que sus documentos sean válidos.
Alohci
@Alohci, quiero decir, no está permitido en el sentido de que serían descartados del DOM en lugar de ser semánticamente inválidos
Píldoras de explosión
13

Esto es posible con html5 pero debe tener en cuenta los navegadores más antiguos.

¡Si decides usarlos, asegúrate de COMENTAR tu html! Algunas personas pueden tener problemas para descubrir qué es, por lo que un comentario podría ahorrarles un montón de tiempo.

Algo como esto,

<!-- Custom tags in use, refer to their CSS for aid -->

Cuando crea su propia etiqueta / elementos personalizados, los navegadores más antiguos no tendrán idea de cómo son los elementos html5 como nav/ section.

Si está interesado en este concepto, le recomiendo que lo haga de la manera correcta.

Empezando

Los elementos personalizados permiten a los desarrolladores web definir nuevos tipos de elementos HTML. La especificación es una de varias primitivas API nuevas que aterrizan bajo el paraguas de Web Components, pero posiblemente sea la más importante. Los componentes web no existen sin las funciones desbloqueadas por elementos personalizados:

Defina nuevos elementos HTML / DOM Cree elementos que se extiendan desde otros elementos Combine lógicamente funcionalidades personalizadas en una sola etiqueta Extienda la API de elementos DOM existentes

Hay mucho que puedes hacer con él y hace que tu guión sea hermoso, ya que a este artículo le gusta decirlo. Elementos personalizados que definen nuevos elementos en HTML .

Así que recapitulemos,

Pros

  • Muy elegante y fácil de leer.

  • Es bueno no ver tantos divs. :pags

  • Permite una sensación única del código

Contras

  • La compatibilidad con navegadores antiguos es algo muy importante a tener en cuenta.

  • Otros desarrolladores pueden no tener idea de qué hacer si no conocen las etiquetas personalizadas. (Explíqueles o agregue comentarios para informarles)

  • Por último, una cosa a tener en cuenta, pero no estoy seguro, es el bloque y los elementos en línea. Al usar etiquetas personalizadas, terminarás escribiendo más CSS porque la etiqueta personalizada no tendrá un lado predeterminado.

La elección es totalmente suya y debe basarla en lo que está pidiendo el proyecto.

Actualización 1/2/2014

Aquí hay un artículo muy útil que encontré y pensé que compartiría, Elementos personalizados .

Aprenda la tecnología ¿Por qué elementos personalizados? Los elementos personalizados permiten a los autores definir sus propios elementos. Los autores asocian el código JavaScript con nombres de etiquetas personalizadas y luego usan esos nombres de etiquetas personalizadas como lo harían con cualquier etiqueta estándar.

Por ejemplo, después de registrar un tipo especial de botón llamado súper botón, use el botón súper así:

Los elementos personalizados siguen siendo elementos. Podemos crearlos, usarlos, manipularlos y componerlos con la misma facilidad que cualquier estándar o hoy.

Parece una biblioteca muy buena para usar, pero noté que no pasó el estado de compilación de Windows. Esto también está en un pre-alfa, creo, así que lo vigilaría mientras se desarrolla.

Josh Powell
fuente
3
" Other developers may have no clue what to do if they don't know about custom tags." Odio ese argumento. Se supone que otros desarrolladores también deben aprender cosas nuevas y si no entienden las técnicas utilizadas en su código, deberían estar agradecidos por señalar las deficiencias en su conocimiento. Tal vez eso sea un poco injusto en este caso, porque las etiquetas personalizadas solo existen como borrador, pero he escuchado el mismo argumento cuando se utilizan técnicas estandarizadas adecuadas.
GolezTrol
1
No digo que lo respalde, pero muchos desarrolladores no continúan aprendiendo. Casi no hay razón para no comentar algo si es un poco complejo o nuevo. Todos comentamos nuestros guiones ¿correcto? Para mostrar lo que estamos ejecutando y cómo, lo mismo con las etiquetas personalizadas.
Josh Powell
1
Por supuesto, si solo se trata de agregar comentarios. Pensé que querías decir que no deberías usar elementos personalizados en absoluto porque otras personas no lo entenderían. Agregar un pequeño comentario cuando agrega una técnica menos utilizada es algo bueno. Sin embargo, tenga cuidado con los comentarios en HTML. Pueden terminar en el cliente, consumiendo ancho de banda y posiblemente revelando detalles de implementación que no desea que sus visitantes conozcan. Pero, alternativamente, puede agregar comentarios como comentarios PHP / ASP, por lo que todavía están en la plantilla, pero permanecen en el servidor.
GolezTrol
1
@GolezTroi, no es que nunca debas hacer cosas que desafíen a otros desarrolladores, es una cuestión de costo-beneficio. Si hacer algo de una manera que sea más difícil para el próximo desarrollador legítimamente hace que su código sea mejor y más limpio, hágalo. Pero no hagas cosas retorcidas solo por diversión.
BostonJohn
1
@JoshPowell Los comentarios no deberían ser sobre qué y cómo (el código ya lo dice, y si no es lo suficientemente claro, vuelva a escribir el código hasta que lo esté), pero debería decirme por qué . Hay pocas cosas peores que un montón de comentarios que simplemente dicen que la sendmailfunción envía correo o algo así. Me interesaría más saber por qué envías correo, y si el nombre de la función lo hace obvio, ¡genial! Entonces no necesito un comentario, que es el caso ideal. Leeré el código de todos modos.
Christopher Creutzig
4

¿Por qué no quiere que los uses? No son comunes ni forman parte del estándar HTML5. Técnicamente, no están permitidos. Son un hack.

Sin embargo, me gustan. Te puede interesar XHTML5. Le permite definir sus propias etiquetas y usarlas como parte del estándar.

Además, como otros han señalado, no son válidos y, por lo tanto, no son portátiles.

¿Por qué no sabía que existían? No lo sé, excepto que no son comunes. Posiblemente no era consciente de que pudieras.

tjons
fuente
2
No hay XHTML5: había un grupo de trabajo que intentaba crear XHTML 2, pero fracasó hace años.
max
1
@papirtiger: XHTML5 es HTML5 servido como XML, pero tiene razón en que no hay un estándar XHTML independiente más allá de XHTML 1.1.
BoltClock
1
Así que no es XHTML5, pero parece diferir poco de HTML 5 con respecto a este tema de las etiquetas personalizadas. Por lo tanto, creo que la declaración sobre XHTML5 que le permite definir etiquetas adicionales en contraste con HTML5 es incorrecta, lo que podría explicar el voto negativo, a pesar de que no estoy lo suficientemente seguro sobre XHTML5 para votar a favor o rechazar esta respuesta.
GolezTrol
1
Según el borrador HTML5 del W3C, HTML y XHTML son (ahora) "sintaxis concretas" que representan el mismo "lenguaje abstracto". Tienen las mismas características fundamentales, excepto aquellas que solo tienen sentido en una sintaxis (espacios de nombres XML, conmutador de analizador de noscript HTML): w3.org/TR/html5/introduction.html#html-vs-xhtml
IMSoP
2

Las etiquetas inventadas casi nunca se usan, porque es poco probable que funcionen de manera confiable en cada navegador actual y en cada navegador futuro.

Un navegador tiene que analizar el código HTML en elementos que conoce, y las etiquetas inventadas se convertirán en algo más para que quepa en el modelo de objetos del documento (DOM). Como los estándares web no cubren cómo manejar todo lo que está fuera de los estándares, los navegadores web tienden a manejar el código no estándar de diferentes maneras.

El desarrollo web es bastante complicado con un montón de navegadores diferentes que tienen sus propias peculiaridades, sin agregar otro elemento de incertidumbre. La mejor apuesta es seguir con las cosas que realmente están en los estándares, eso es lo que los proveedores de navegadores intentan seguir, para que tenga la mejor oportunidad de funcionar.

Guffa
fuente
2

Creo que las etiquetas inventadas son potencialmente más confusas o confusas que las p con ID (generalmente un bloque de texto). Todos sabemos que ap con una ID es un párrafo, pero ¿quién sabe para qué están hechas las etiquetas inventadas? Al menos ese es mi pensamiento. :) Por lo tanto, se trata más de un problema de estilo / claridad que de funcionalidad.

runelynx
fuente
3
Gracias gramática de hadas :)
runelynx 03 de
2

Otros han hecho excelentes puntos, pero vale la pena señalar que si observa un marco como AngularJS , hay un caso muy válido para los elementos y atributos personalizados. Estos transmiten no solo un mejor significado semántico al xml, sino que también pueden proporcionar comportamiento, apariencia para la página web.

drew_w
fuente
2

CSS es un lenguaje de hoja de estilo que se puede utilizar para presentar documentos XML, no solo documentos (X) HTML. Su fragmento con las etiquetas inventadas podría ser parte de un documento XML legal; sería uno si lo incluye en un solo elemento raíz. Probablemente ya tienes un <html> ...</html>alrededor? Cualquier navegador actual puede mostrar documentos XML.

Por supuesto, no es un documento XML muy bueno, carece de una gramática y una declaración XML. Si utiliza un encabezado de declaración HTML en su lugar (y probablemente una configuración de servidor que envía el tipo MIME correcto), sería HTML ilegal.

(X) HTML tiene ventajas sobre XML simple ya que los elementos tienen un significado semántico que es útil en el contexto de una presentación de página web. Las herramientas pueden funcionar con esta semántica, otros desarrolladores conocen el significado, es menos propenso a errores y es mejor leerlo.

Pero en otros contextos es mejor usar CSS con XML y / o XSLT para hacer la presentación. Esto es lo que hiciste. Como esta no era tu tarea, no sabías lo que estabas haciendo, y HTML / CSS es la mejor manera de hacerlo la mayor parte del tiempo que debes seguir en tu escenario.

Debe agregar un encabezado HTML (X) a su documento para que las herramientas puedan darle mensajes de error significativos.

Hauke ​​Ingmar Schmidt
fuente
2
No, no es XML legal (bien formado) en absoluto. Hay un <style>elemento, y luego ... un <body>elemento. Un documento XML debe tener solo un elemento raíz; en este caso, o bien el <style>elemento es el elemento raíz pero <body>está interfiriendo, o es necesario agregar un elemento raíz que convierta a ambos elementos en hijos. A menos que reemplace el <style>elemento con una referencia de hoja de estilo (incluso un URI de datos <?xml-stylesheet href="data:text/css,imsocool { color: blue; }"?>funcionaría bien) de modo que el elemento raíz se convierta <body>.
BoltClock
2

... Simplemente cambio todas mis etiquetas inventadas a párrafos con ID.

De hecho, estoy en desacuerdo con su sugerencia de cómo hacerlo correctamente.

  1. Una <p>etiqueta es para párrafos. Veo personas que lo usan todo el tiempo en lugar de un div, simplemente con fines de espacio o porque parece más suave. Si no es un párrafo, no lo use.

  2. No necesita o desea pegar ID en todo, a menos que necesite apuntarlo específicamente (por ejemplo, con Javascript). Use clases o simplemente un div directo.

dennisbest
fuente
2

Desde sus inicios, CSS fue diseñado para ser independiente del marcado, por lo que puede usarse con cualquier lenguaje de marcado que produzca estructuras DOM similares a los árboles (SVG, por ejemplo). Cualquier etiqueta que cumpla con la name tokenproducción es perfectamente válida en CSS. Entonces, su pregunta es más sobre HTML que CSS en sí.

Los elementos con etiquetas personalizadas son compatibles con la especificación HTML5. HTML5 estandariza la forma en que los elementos desconocidos deben analizarse en el DOM. Entonces HTML5 es la primera especificación HTML que permite elementos personalizados estrictamente hablando. Solo necesita usar doctype HTML5 <!DOCTYPE html>en su documento.

A partir de los nombres de etiquetas personalizadas ...

Este documento http://www.w3.org/TR/custom-elements/ recomienda etiquetas personalizadas que elija contener al menos un símbolo '-' (guión). De esta manera no entrarán en conflicto con futuros elementos HTML. Por lo tanto, será mejor que cambies tu documento a algo como esto:

<style>
so-cool {
    color:blue;
}
</style>

<body>
    <so-cool>HELLO</so-cool>
</body> 
c-smile
fuente
2

Aparentemente nadie lo mencionó, así que lo haré.

Este es un subproducto de las guerras del navegador .

Ya en la década de 1990, cuando Internet comenzaba a generalizarse, la competencia aumentó en el mercado de los navegadores. Para seguir siendo competitivos y atraer a los usuarios, algunos navegadores (especialmente Internet Explorer) intentaron ser útiles y "amigables para el usuario" al tratar de descubrir qué significaban los diseñadores de páginas y, por lo tanto, permitieron marcas incorrectas (por ejemplo, se <b><i>foobar</b></i>mostrarían correctamente en negrita) cursiva).

Esto tenía sentido hasta cierto punto porque si un navegador seguía quejándose de errores de sintaxis mientras otro comía algo que le arrojaste y escupía un resultado correcto (más o menos), entonces la gente naturalmente acudiría a este último.

Si bien muchos pensaron que la guerra de los navegadores había terminado, una nueva guerra entre los proveedores de navegadores se ha vuelto a encender en los últimos años desde que se lanzó Chrome, Apple comenzó a crecer nuevamente y empujó a Safari, e IE perdió su dominio. (Podría llamarse una "guerra fría" debido a la cooperación y el apoyo percibido de los estándares por parte de los proveedores de navegadores.) Por lo tanto, no es sorprendente que incluso los navegadores contemporáneos que supuestamente se ajustan estrictamente a los estándares web realmente intenten ser "inteligentes" y permita un comportamiento de ruptura de estándares como este para intentar obtener una ventaja como antes.

Desafortunadamente, este comportamiento permisivo condujo a un crecimiento masivo ( algunos incluso podrían decir canceroso) de páginas web mal marcadas. Debido a que IE era el navegador más indulgente y popular, y debido al continuo incumplimiento de los estándares de Microsoft, IE se hizo infame por alentar y promover un mal diseño y propagar y perpetuar páginas rotas.

Es posible que pueda evitar el uso de peculiaridades y exploits como ese en algunos navegadores por ahora, pero aparte del rompecabezas o juego ocasional o algo así, siempre debe atenerse a los estándares web al crear páginas web y sitios para asegurarse de que se muestren correctamente y evite que se rompan (posiblemente completamente ignorados) con una actualización del navegador.

Synetech
fuente
Yo diría que culpar a este particular capricho de IE es un poco fuera de lugar, porque cuando se agregaron oficialmente un montón de nuevas etiquetas (para HTML5), IE fue el único navegador importante que requirió una "cuña" específica para que fueran estilizables. . Esto se debió en parte a los regímenes de actualización más agresivos de otros navegadores (lo que significa que las versiones antiguas de IE se mantienen más tiempo que las versiones antiguas de Chrome de Firefox), pero es todo lo contrario de que IE sea "el más indulgente".
IMSoP
HTML5? ¿Eh? <imsocool>no es una nueva etiqueta en HTML5. Esto no tiene nada que ver con HTML5 o IE 8, 9, etc. Este tipo de comportamiento no es una peculiaridad nueva ; que es un subproducto de años de edad navegador guerras. Incluso si IE no es responsable de las ofensas estándar actuales (aunque por ira de los desarrolladores web, aún se niegan a conformarse adecuadamente), ciertamente fueron notorios por promover prácticas de codificación deficientes durante años. Más específicamente, los navegadores indulgentes (IE es el peor delincuente) llegaron en el peor momento, justo cuando Internet comenzaba a despegar y los desarrolladores web comenzaron a aprender HTML ... incorrectamente.
Synetech
No dije que esto tuviera nada que ver con HTML5, pero tiene que ver con etiquetas no estándar (como lo <header>fue, por ejemplo , hasta que HTML5 se convirtió en el estándar objetivo) que las versiones antiguas de IE ciertamente no son "tolerantes". La indulgencia tampoco es lo mismo que el incumplimiento: HTML5 es un estándar extremadamente pragmático que acepta que existirá HTML mal formado, a diferencia del idealismo de las especificaciones anteriores del W3C, y esta "clemencia" podría decirse que beneficia el crecimiento democrático de la web.
IMSoP
Nuevamente, no estoy hablando de ningún navegador o versión específica. Estoy explicando que la indulgencia en general es un efecto secundario de las guerras de navegador. IE toleró un comportamiento roto no estándar e incluso rotundo, como etiquetas faltantes, etiquetas y atributos no válidos y etiquetas que no coinciden ( <b><i>foobar</b></i>). Esto no es secreto e incluso es un tema muy criticado y muy difamado. Como dije, IE no fue el único navegador que permitió un marcado deficiente, pero debido a que tenía una participación de mercado tan grande y apareció en el momento correcto (o incorrecto), contribuyó en gran medida al marcado deficiente en general .
Synetech
1

Si bien los navegadores generalmente relacionan CSS con etiquetas HTML, independientemente de si son válidas o no, usted NO debería hacer esto ABSOLUTAMENTE.

Técnicamente, no hay nada de malo en esto desde una perspectiva CSS. Sin embargo, el uso de etiquetas inventadas es algo que NUNCA debe hacer en HTML.

HTML es un lenguaje de marcado, lo que significa que cada etiqueta corresponde a un tipo específico de información.

Sus etiquetas inventadas no corresponden a ningún tipo de información. Esto creará problemas de los rastreadores web, como Google.

Lea más información sobre la importancia del marcado correcto .

Editar

Divs se refieren a grupos de múltiples elementos relacionados, destinados a mostrarse en forma de bloque y pueden ser manipulados como tales.

Los espacios se refieren a elementos que deben tener un estilo diferente al contexto en el que se encuentran actualmente y deben mostrarse en línea, no como un bloque. Un ejemplo es si algunas palabras en una oración deben ser mayúsculas.

Las etiquetas personalizadas no se correlacionan con ningún estándar y, por lo tanto, span / div debe usarse con propiedades de clase / ID.

Hay excepciones muy específicas para esto, como Angular JS

Dan Green-Leipciger
fuente
3
"Nunca" nunca es la respuesta correcta - parece que te has olvidado de XHTML;)
Izkata
divs y spanns tampoco corresponden a ningún tipo de información. Google y los lectores de pantalla parecen manejarlos bien. Es importante usar marcado semántico, pero no es un argumento en contra del uso de etiquetas personalizadas.
GolezTrol
2
Divs se refieren a grupos de múltiples elementos relacionados, destinados a mostrarse en forma de bloque y ser manipulados como tales. Los espacios se refieren a elementos que deben tener un estilo similar y deben mostrarse en línea, no como un bloque. Las etiquetas personalizadas no se correlacionan con ningún estándar y, por lo tanto, span / div debe usarse con propiedades de clase / ID.
Dan Green-Leipciger
Eliminé tu comentario sobre los lectores de pantalla porque es incorrecto. La tecnología de asistencia se leerá <imsocool>some awesome text</imsocool>bien porque se interpretará como <>...</>. Lo que no sucederá es que no podrán saltar a ese fragmento de texto de forma independiente como si fuera un <p>. Por supuesto, si usted escribió su propia DOCTYPE y se asigna imsocoola p, que funcionaría.
Ryan B
0

Aunque CSS tiene una cosa llamada "selector de etiquetas", en realidad no sabe qué es una etiqueta. Eso queda para que el idioma del documento lo defina. CSS fue diseñado para usarse no solo con HTML, sino también con XML, donde (suponiendo que no esté usando un DTD u otro esquema de validación) las etiquetas pueden ser casi cualquier cosa. También podría usarlo con otros idiomas, aunque necesitaría crear su propia semántica para saber exactamente a qué corresponden las cosas como "etiquetas" y "atributos".

Los navegadores generalmente aplican CSS a etiquetas desconocidas en HTML, porque esto se considera mejor que romperse por completo: al menos pueden mostrar algo. Pero es una muy mala práctica usar etiquetas "falsas" deliberadamente. Una razón para esto es que las nuevas etiquetas se definen de vez en cuando, y si se define una que se parece a su etiqueta falsa pero no funciona de la misma manera, eso puede causar problemas con su sitio en los nuevos navegadores.

El más cuchara
fuente
0

¿Por qué funciona CSS con elementos falsos? Porque no hace daño a nadie porque se supone que no debes usarlos de todos modos.

¿Por qué mi profesor no quiere que use elementos inventados? Porque si ese elemento está definido por una especificación en el futuro, su elemento tendrá un comportamiento impredecible.

Además, ¿por qué no sabía que los elementos inventados existen y funcionan con CSS? ¿Son poco comunes? Porque él, como la mayoría de los otros desarrolladores web, entiende que no debemos usar cosas que puedan romperse al azar en el futuro.

ADJenks
fuente