una todas tipos son principales pagina las etiquetas ejemplos cuales completa codigo basicas atributos html html5

todas - tipos de etiquetas html



¿Está bien usar etiquetas HTML desconocidas? (10)

Corrígeme si me equivoco, pero AFAIK, las etiquetas HTML desconocidas en el marcado (es decir, etiquetas no definidas en la especificación HTML, como por ejemplo, <foobar> ) se tratarán finalmente como un <div> normal en un entorno de navegador HTML 5.

Estoy pensando: ¿cuán sustentable es esta práctica? Quiero decir, si uso etiquetas HTML desconocidas en mi marcado, ¿qué peligros puedo esperar? ¿ Un velociraptor se abalanzará sobre mí en los próximos segundos ?

La razón por la que pregunto es que si estas etiquetas difieren a <div> , potencialmente puedo usar estas etiquetas de una manera más semántica que, por ejemplo, asignando nombres de clase que identifiquen módulos. Eche un vistazo a este artículo, por ejemplo, de una clase .media . Ahora, ¿qué .media si, en lugar de escribir ese CSS para orientar a .media , lo hago objetivo <media> ? En mi opinión, eso hace que el marcado sea mucho más legible y mantenible, pero reconozco que no es HTML "correcto".

EDITAR

Para ser transparente, encontré esta pregunta ASÍ de hace unos años . Se ha cerrado como fuera de tema, pero siento que tengo un punto válido en mi propia redacción. Es un duplicado cercano, lo admito, pero es de hace unos años, por lo que podría haber habido cambios en el entorno general de opiniones entre los desarrolladores web sobre el tema.

¿Qué hay de malo con el uso juicioso de <! - tus cosas aquí ->. Funcionó para guiones atrás de la época del límite Cretácico-Paleógeno. Los dinosaurios dejaron de ser un problema en ese momento, aparte de la variedad voladora y emplumada.

En mi caso, uso muchos de ellos en mi sistema de GUI para juegos con Webkit, y todo funciona.

En su ejemplo, usted está hablando de <media> , podría ser genial, pero si html6 agrega esta etiqueta para otro elemento, su código no será retrocompatible.

Es una mala práctica y no deberías hacerlo. El navegador lo presenta como una solución div como alternativa en la mayoría de los casos, pero no es válido html y, por lo tanto, nunca pasará una prueba de validez.

Generalmente no es recomendable, por ejemplo, IE no aplicará estilos css a etiquetas desconocidas.

Todos los demás navegadores muestran etiquetas desconocidas como -Elementos en inline (lo que causa problemas con la anidación).

Te recomiendo el siguiente artículo: http://diveintohtml5.info/ Hay una sección sobre etiquetas desconocidas.

La regla n. ° 1 de interoperabilidad del navegador es: no tiene errores. No importa cuántos navegadores pruebes, siempre hay navegadores que no puedes probar, por ejemplo porque aún no existen.
Además, los elementos desconocidos serán tratados como <span> , no <div> por la mayoría de los navegadores actualmente.

Si realmente es la legibilidad de la fuente (*) lo que buscas, debes mirar en XML + XSLT.
De esta forma, puede usar todos los nombres de etiquetas que desee y hacer que se comporten de la manera que quiera y no tiene que preocuparse de que <media> sea ​​un elemento real en alguna versión futura de HTML.

Un buen ejemplo del mundo real es el elemento <picture> . Si un sitio web alguna vez usó <picture> y se basó en la noción de que este elemento no tendría estilos o contenido especial por sí mismo, ¡ahora están en problemas!

(*) Con XML + XSLT, la legibilidad estará en la parte XML, no en la parte XSLT, obviamente.

No. Fallarás la validación, obtendrás problemas aleatorios en el navegador y serás comido por dichos dinosaurios. CSS es la respuesta si quieres que tu página se comporte de manera predecible.

Siempre debe acercarse a HTML tal como se define en sus respectivas especificaciones. "Definir" nuevas etiquetas es un enfoque un poco extremo. Puede pasar un control de navegador porque implementa varias soluciones de seguridad, pero no hay garantía de esto. Estás ingresando a la tierra del Comportamiento Indefinido, en el mejor de los casos. Sin mencionar que fallarás las pruebas de validación, pero pareces estar consciente de eso.

Si desea ser más semánticamente expresivo en su marcado, puede usar HTML5 que define un buen número de etiquetas más descriptivas para describir la estructura de su página en lugar de div genéricos que deben agregarse id o class .

Al final, una respuesta corta: No, es una mala práctica, no deberías hacerlo y podría haber problemas imprevistos más adelante en tu desarrollo.

user1309389 tuvo una muy buena respuesta, y estoy de acuerdo con la apelación a la especificación. Pero no estoy de acuerdo con su conclusión, y creo que están equivocados sobre los elementos inventados que conducen a un "comportamiento indefinido". Quiero proponer una forma alternativa de pensar sobre esto, enraizada en cómo las especificaciones y los navegadores realmente manejan los elementos inventados.

Es 2015, estamos al borde de que la especificación CustomElement sea ​​ampliamente adoptada, y los polyfills están disponibles. Ahora es un buen momento para preguntarse sobre "inventar sus propios elementos". En un futuro cercano, podrá crear nuevos elementos con su propia elección de etiqueta y comportamiento de una manera totalmente estándar y compatible que todos puedan amar. Pero hasta que esto llegue a todos los navegadores, y hasta que la mayoría de la gente esté usando navegadores compatibles, puede aprovechar el arduo trabajo de los proyectos Polymer o X-Tags para verificar el futuro de los elementos personalizados de una manera casi estándar y en su mayoría de manera compatible que muchas personas pueden amar. Esto es probablemente lo "correcto" que hacer. Pero no responde su pregunta y, francamente, me parece que "use X" o "do not do X" sean menos útiles que "así es como las especificaciones cubren esto, y esto es lo que hacen los navegadores". Entonces, esto es lo que amo.

En contra de la sincera recomendación (y algunas veces gritando) de gran parte de la comunidad de desarrolladores web, he estado trabajando con elementos "inventados" durante el año pasado, en todos mis proyectos de producción, sin un relleno sintético, y he tenido sin problemas irresolubles (aún), y sin quejas. ¿Cómo? Al confiar en el comportamiento estándar de HTMLUnknownElement , la parte de la especificación W3C que cubre el caso de elementos "inventados". Si un navegador encuentra un elemento HTML no reconocido, existe una forma bien definida e inequívoca de que debería manejarse, y HTMLUnknownElement define ese comportamiento, y usted puede construir sobre eso. HTMLUnknownElement también tiene que ser potente y lo suficientemente correcto como para "no romper la web" al encontrar todas las etiquetas que ahora están obsoletas, como la etiqueta <blink> . No se recomienda el uso de HTMLUnknownElement, pero en teoría y en la práctica, no hay ningún daño al hacerlo, si sabes lo que estás haciendo.

Entonces, ¿cómo funciona HTMLUnknownElement? Es solo una extensión de la interfaz HTMLElement, que es la interfaz estándar que subyace a todos los elementos HTML. Sin embargo, a diferencia de la mayoría de los otros elementos, HTMLUnknownElement no agrega ningún comportamiento especial: obtienes un elemento sin procesar, sin adornos con ningún comportamiento especial ni reglas restrictivas sobre el uso. La interfaz HTMLDivElement funciona casi exactamente de la misma manera, extendiendo HTMLElement y agregando casi ningún comportamiento adicional. En pocas palabras, crear su propio elemento es casi idéntico al uso de un div o span.

Lo que me gusta de los elementos de "maquillar" es el cambio de mentalidad. Debe usar o inventar elementos HTML basados ​​en varios factores, que van desde cuán claro es el marcado, hasta cómo analizan el código los lectores del navegador y de la pantalla y los motores de búsqueda, hasta qué tan probable es que su código sea "correcto" por algunos medida objetiva Utilizo moderadamente elementos inventados, pero los utilizo exactamente de la manera que describió Richard, para hacer que las cosas sean más significativas para el autor del HTML, no solo significativas para un servicio de computadora que extrae metadatos. Cuando se usa de forma consistente en un equipo, puede haber un gran beneficio ya que los elementos inventados pueden expresar de forma concisa para qué sirven.

Particularmente me gusta utilizar elementos inventados para indicar cuándo utilizaré JS para definir el comportamiento adicional de un elemento. Por ejemplo, si tengo un elemento que JS agregará / eliminará niños, usaré un elemento inventado como pista de que este elemento está sujeto a un comportamiento especial. Por la misma razón, no uso un elemento inventado cuando un elemento estándar será suficiente. Verás <dynamic-list> vivo junto a <div> en mi código.

Ahora, sobre esos validarios molestos. Sí, el uso de elementos inventados no es "válido" en el sentido de que no pasará un "validador". Pero muchas características, patrones y sistemas de desarrollo moderno de HTML y JS de uso común fallan en todos los validadores del W3C. Los validadores no son la ley, la especificación es. Y la ley no es vinculante: las implementaciones en todos los navegadores sí lo son. La utilidad de los validadores ha ido disminuyendo durante años, ya que la flexibilidad de HTML ha ido en aumento y los navegadores han cambiado su relación con las especificaciones. Los validadores son excelentes para las personas que no se sienten cómodas con HTML y necesitan orientación. Pero si se siente cómodo tomando su guía de la especificación y de las implementaciones del navegador, no hay razón para preocuparse de ser suspendido por el validador. Ciertamente, si sigue muchas de las pautas ofrecidas por Google, Apple, Microsoft, etc., para implementar cualquier característica experimental, estará trabajando fuera de los límites del validador. Esto es absolutamente correcto, siempre y cuando lo haga deliberadamente y sepa lo suficiente sobre lo que está haciendo.

Por lo tanto, si va a crear sus propios elementos y confiar en HTMLUnknownElement, no lo trate como un salvaje oeste. Debes seguir unas simples reglas.

  1. Tienes que usar un guion en el nombre de tu etiqueta. Si lo hace, se garantiza que nunca colisionará con una edición futura de las especificaciones HTML. Así que nunca diga <wrong> , siempre diga <quite-right> .

  2. Los elementos confeccionados no pueden cerrarse automáticamente; debe cerrarlos con una etiqueta de cierre. No puede decir <wrong> o <still-wrong /> , tiene que decir <totally-good></totally-good> .

  3. Debe definir una propiedad de display para su elemento en CSS, de lo contrario, el comportamiento de representación no está definido.

Eso es todo. Si hace estas cosas, debería ser bueno usar elementos inventados en IE9 y superior, confiando en la red de seguridad del HTMLUnknownElement. Para mí, los beneficios superan con creces los costos, así que he estado usando este patrón en gran medida. Dirijo un sitio de SaaS que atiende a las principales corporaciones industriales, y hasta ahora no he tenido problemas ni quejas. Si tiene que admitir versiones anteriores de IE, es aconsejable mantenerse alejado de cualquier tecnología "2015" o sus aproximaciones crudas, y mantenerse seguro dentro de las partes bien transitadas de la especificación.

Entonces, en resumen, la respuesta a su pregunta es "sí, si sabe lo que está haciendo".