register - ¿Los elementos personalizados son válidos para HTML5?
w3c custom elements (11)
Elementos personalizados básicos y atributos
Los elementos y atributos personalizados son válidos en HTML, siempre que:
- Los nombres de los elementos son minúsculos y comienzan con
x- - Los nombres de atributos son minúsculos y comienzan con
data-
Por ejemplo, <x-foo data-bar="gaz"/> o <br data-bar="gaz"/> .
Una convención común para los elementos es x-foo ; x-vendor-feature es recomendado.
Esto maneja la mayoría de los casos, ya que es discutible que un desarrollador necesite todo el poder que conlleva registrar sus elementos. La sintaxis también es adecuadamente válida y estable. Una explicación más detallada está debajo.
Elementos personalizados avanzados y atributos
A partir de 2014, existe una forma nueva y muy mejorada de registrar elementos y atributos personalizados. No funcionará en navegadores más antiguos como IE 9 o Chrome / Firefox 20. Pero le permite usar la interfaz HTMLElement estándar, evitar colisiones, usar nombres que no sean x-* y no- data-* , y definir un comportamiento personalizado y sintaxis para que el navegador respete. Requiere un poco de JavaScript elegante, como se detalla en los enlaces a continuación.
html5rocks.com/en/tutorials/webcomponents/customelements
WebComponents.org - Introducción a elementos personalizados
W3C - Componentes web: elementos personalizados
Respecto a la validez de la sintaxis básica
El uso de data-* para nombres de atributos personalizados ha sido perfectamente válido por algún tiempo, e incluso funciona con versiones anteriores de HTML.
En cuanto a los nombres de elementos personalizados (no registrados), el W3C recomienda encarecidamente que no los incluya y los considera no conformes. Pero se requiere que los navegadores los admitan, y los identificadores x-* no entrarán en conflicto con las futuras especificaciones de HTML y los identificadores de x-vendor-feature no entrarán en conflicto con otros desarrolladores. Se puede usar una DTD personalizada para evitar cualquier navegador minucioso.
Aquí hay algunos extractos relevantes de los documentos oficiales:
"Las especificaciones aplicables PUEDEN definir contenido de documentos nuevos (por ejemplo, un elemento foobar) [...]. Si la sintaxis y la semántica de un determinado documento conforme no se modifican mediante el uso de las especificaciones aplicables, entonces ese documento sigue siendo un HTML5 conforme. documento."
"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 pegándolos según CSS (para procesadores CSS), pero sin inferir ningún significado de ellos".
"Los agentes de usuario no son libres de manejar documentos no conformes como quieran, el modelo de procesamiento descrito en esta especificación se aplica a las implementaciones independientemente de la conformidad de los documentos de entrada".
"La interfaz HTMLUnknownElement debe usarse para elementos HTML que no están definidos por esta especificación".
W3C - HTML5: documentos conformes
WhatWG - HTML Standard: elementos DOM
No he podido encontrar una respuesta definitiva a si las etiquetas personalizadas son válidas en HTML5, como esta:
<greeting>Hello!</greeting>
No he encontrado nada en la especificación de una forma u otra:
http://dev.w3.org/html5/spec/single-page.html
Y las etiquetas personalizadas no parecen validar con el validador W3C.
Citando de la sección Extensibilidad de la especificación HTML5 :
Para las características de nivel de marcado que pueden limitarse a la serialización XML y no necesitan soporte en la serialización de HTML, los proveedores deben usar el mecanismo del espacio de nombres para definir espacios de nombres personalizados en los que se admiten los elementos y atributos no estándar.
Entonces, si está utilizando la serialización XML de HTML5, es legal que haga algo como esto:
<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>
Sin embargo, si usa la sintaxis HTML, está mucho más limitado en lo que puede hacer.
Para las características de nivel de marcado que se utilizan con la sintaxis HTML, las extensiones deben limitarse a los nuevos atributos de la forma "x-vendor-feature" [...] No se deben crear nuevos nombres de elemento.
Pero esas instrucciones se dirigen principalmente a los proveedores de navegadores, que supuestamente proporcionarían un diseño visual y funcionalidad para los elementos personalizados que elijan crear.
Sin embargo, para un autor, aunque puede ser legal incluir un elemento personalizado en la página (al menos en la serialización XML), no obtendrá nada más que un nodo en el DOM. Si desea que su elemento personalizado realmente haga algo o se represente de alguna manera especial, debería mirar la dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/… .
Para obtener una introducción más cuidadosa sobre el tema, lea la Introducción a los componentes web , que también incluye información acerca de Shadow DOM y otras especificaciones relacionadas. Estas especificaciones todavía están trabajando borradores en este momento, puede ver el estado actual here , pero se están desarrollando activamente.
Como ejemplo, una definición simple para un elemento de greeting podría verse más o menos así:
<element name="greeting">
<template>
<style scoped>
span { color:gray; }
</style>
<span>Simon says:</span>
<q><content/></q>
</template>
</element>
Esto le dice al navegador que represente el contenido del elemento entre comillas, y el prefijo "Simon dice:" que tiene el estilo del color gris. Normalmente, una definición de elemento personalizada como esta se almacena en un archivo html separado que se importaría con un enlace.
<link rel="import" href="greeting-definition.html" />
Aunque también puede incluirlo en línea si lo desea.
He creado una demostración de trabajo de la definición anterior usando la biblioteca Polymer polyfill que puedes ver here . Tenga en cuenta que esto está utilizando una versión anterior de la biblioteca Polymer; las versiones más recientes funcionan de manera bastante diferente. Sin embargo, con las especificaciones todavía en desarrollo, esto no es algo que recomendaría usar en el código de producción de todos modos.
Es posible y permitido:
Los agentes de usuario deben tratar los elementos y atributos que no entienden como semánticamente neutrales; dejándolos en el DOM (para procesadores DOM), y diseñándolos según CSS (para procesadores CSS), pero sin inferir ningún significado de ellos.
http://www.w3.org/TR/html5/infrastructure.html#extensibility-0
Pero, si tiene la intención de agregar interactividad, tendrá que hacer que su documento sea inválido (pero aún completamente funcional) para acomodar los 7 y 8 de IE.
Ver http://blog.svidgen.com/2012/10/building-custom-xhtml5-tags.html (mi blog)
Esto es en realidad una consecuencia de la acumulación del modelo de contenido de los elementos.
Por ejemplo, el elemento raíz debe ser un elemento html .
El elemento html solo puede contener un elemento de encabezado A seguido de un elemento de cuerpo.
El elemento del body solo puede contener contenido de flujo donde el contenido de flujo se define como los elementos: a, abbr, dirección, área (si es un descendiente de un elemento de mapa), artículo, aparte, audio, b, bdi, bdo, blockquote, br, botón, lienzo, citar, código, comando, datalist, del, detalles, dfn, div dl, em, insertar, fieldset, figura, pie de página, formulario, h1, h2, h3, h4, h5, h6, encabezado, hgroup , hr, i, iframe, img, entrada, ins, kbd, keygen, etiqueta, mapa, marca, matemática, menú, medidor, nav, noscript, objeto, ol, salida, p, pre, progreso, q, ruby, s , samp, script, section, select, small, span, strong, style (si el atributo de ámbito está presente), sub, sup, svg, table, textarea, time, u, ul, var, video, wbr y Text
y así.
En ningún momento el modelo de contenido dice "puedes poner los elementos que te gusten en este", lo que sería necesario para los elementos / etiquetas personalizados.
La especificación de Elementos personalizados está disponible en Chrome y Opera, y está disponible en otros navegadores . Proporciona un medio para registrar elementos personalizados de manera formal.
Los elementos personalizados son nuevos tipos de elementos DOM que pueden ser definidos por los autores. A diferencia de los decorators , que son sin estado y efímeros, los elementos personalizados pueden encapsular el estado y proporcionar interfaces de scripts.
Los elementos personalizados forman parte de una especificación W3 más grande llamada Componentes web , junto con Plantillas, Importaciones HTML y DOM sombra.
Los componentes web permiten a los autores de aplicaciones web definir widgets con un nivel de riqueza visual e interactividad que no son posibles solo con CSS, y la facilidad de composición y reutilización no es posible con las librerías de scripts actuales.
Sin embargo, de este excelente recorrido por el artículo sobre Google Developers sobre Custom Elements v1:
El nombre de un elemento personalizado debe contener un guion (
-). Así que<x-tags>,<my-element>y<my-awesome-app>son todos nombres válidos, mientras que<foo_bar>y<foo_bar>no lo son. Este requisito es para que el analizador HTML pueda distinguir elementos personalizados de elementos regulares. También asegura la compatibilidad directa cuando se agregan nuevas etiquetas a HTML.
Algunos recursos
- Se está compilando una "galería" de componentes web en http://customelements.io/
- WebComponents.js funciona como un WebComponents.js para los componentes web hasta que sean compatibles en todas partes. Consulte también la tabla de soporte de la página y el navegador web de WebComponents.js .
Las etiquetas personalizadas no son válidas en HTML5. Pero actualmente los navegadores admiten analizarlos y también puede usarlos usando css. Entonces, si desea usar etiquetas personalizadas para los navegadores actuales, puede hacerlo. Pero el soporte puede ser retirado una vez que los navegadores implementen los estándares W3C estrictamente para analizar el contenido HTML.
Los elementos HTML personalizados son un estándar W3 emergente al que he contribuido y que le permiten declarar y registrar elementos personalizados con el analizador. Puede leer las especificaciones aquí: dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/… . Además, Microsoft admite una biblioteca (escrita por antiguos desarrolladores de Mozilla), llamada X-Tag , lo que hace que trabajar con Web Components sea aún más fácil.
Me gustaría señalar que la palabra "válida" puede tener dos significados diferentes en este contexto, cualquiera de los cuales es potencialmente, um, válido.
¿Debería considerarse que un documento HTML con etiquetas personalizadas es válido como HTML5? La respuesta a esto es claramente "no". La especificación enumera exactamente qué etiquetas son válidas en qué contextos. Esta es la razón por la cual un validador de HTML no aceptará un documento con etiquetas personalizadas, o con etiquetas estándar en lugares incorrectos (como una etiqueta "img" en el encabezado).
¿Se analizará y procesará un documento HTML con etiquetas personalizadas de forma estándar y claramente definida en los navegadores? Aquí, quizás sorprendentemente, la respuesta es "sí". Aunque técnicamente el documento no se consideraría válido como HTML5, la especificación HTML5 especifica exactamente qué se supone que deben hacer los navegadores cuando ven una etiqueta personalizada: en resumen, la etiqueta personalizada actúa como un
<span>- no significa nada y no hace nada por defecto, pero se puede diseñar con HTML y acceder mediante javascript.
Para dar una respuesta actualizada que refleje páginas modernas.
Las etiquetas personalizadas son válidas si,
1) Contienen un guion
<my-element>
2) Están integrados en XML
<greeting xmlns="http://example.com/customNamespace">Hello!</greeting>
Esto supone que está utilizando el doctype HTML5 <!doctype html>
Teniendo en cuenta estas simples restricciones, ahora tiene sentido hacer todo lo posible para mantener su marcado HTML válido (deje de cerrar etiquetas como <img> y <hr> , es tonto e incorrecto a menos que use un doctype XHTML, que probablemente no necesite. )
Dado que HTML5 define claramente las reglas de análisis, un navegador compatible podrá manejar cualquier etiqueta que arroje, incluso si no es estrictamente válida.
Sé que esta pregunta es antigua, pero he estado estudiando este tema y, aunque algunas de las afirmaciones anteriores son correctas, no son la única forma de crear elementos personalizados. Por ejemplo:
<button id="find">click me</button>
<Query? ?attach="find" ?content="alert( find() );" ?prov="Hello there :D" >
I won''t be displayed :D
</Query?>
<style type="text/css">
[/?content] {
display: none;
}
</style>
<script type="text/javascript">
S = document.getElementsByTagName("Query?")[0];
Q = S.getAttribute("?content");
A = document.getElementById( S.getAttribute("?attach") );
function find() {
return S.getAttribute("?prov");
}
(function() {
A.setAttribute("onclick", Q);
})();
</script>
funcionaría perfectamente bien (en las versiones más nuevas de Google Chrome, IE, Firefox y Safari móvil hasta el momento). Todo lo que necesita es solo un carácter alfabético (az, AZ) para iniciar la etiqueta, y luego puede usar cualquiera de los caracteres que no sean alfa después. Si está en CSS, debe usar la "/" (barra invertida) para encontrar el elemento, tal como necesitaría Query / ^ {...}. Pero en JS, simplemente lo llamas como lo ves. Espero que esto ayude. Ver ejemplo here
-Mink CBOS
data-* atributos data-* son válidos en HTML5 e incluso en HTML4, todos los navegadores web los usan para respetarlos. Agregar nuevas etiquetas técnicamente está bien, pero no se recomienda solo porque:
- Puede entrar en conflicto con algo agregado en el futuro, y
- Hace que el documento HTML sea inválido a menos que se agregue dinámicamente a través de JavaScript.
Utilizo etiquetas personalizadas solo en lugares que a Google no le importan, por ejemplo, en un iframe de motor de juego, hice una etiqueta <log> que contenía <msg> , <error> y <warning> , pero solo a través de JavaScript . Y fue completamente válido, de acuerdo con el validador. ¡Incluso funciona en Internet Explorer con su diseño! ;]