2010-08-29 19 views
7

Incluso las nuevas etiquetas HTML5 no son suficientes para describir estructuras sin caer de nuevo en div s. Lo que me impide cambiar:¿Qué me impide utilizar etiquetas arbitrarias en HTML?

<div class="post"> 
    <div class="userinfo"> 
     <span class="name">Casey</span> 
     <img class="avatar" src="..." /> 
    </div> 
    <div class="body"> 
     <p>blah blah blah</p> 
     <p>blah blah blah</p> 
     <p>blah blah blah</p> 
    </div> 
</div> 

en algo así como:

<post> 
    <userinfo> 
     <name>Casey</name> 
     <img class="avatar" src="..." /> 
    </userinfo> 
    <pbody> 
     <p>blah blah blah</p> 
     <p>blah blah blah</p> 
     <p>blah blah blah</p> 
    </pbody> 
</post> 

Para mí, el segundo ejemplo es mucho más limpio. ¿Hay algo (es decir, compatibilidad con el navegador) que me impida hacer esto?

(Me doy cuenta de lo que se es, en esencia, XML, pero en ese caso, la pregunta es, "¿Cómo se ve el apoyo navegador como para la prestación de páginas web XML?")

+5

¿Qué te detiene? Las especificaciones, duh. –

+1

Si desea páginas válidas que funcionen en todos los navegadores y sean rastreadas por los motores de búsqueda, me mantendría alejado de ellas. PERO, nada le impide usar XSLT para transformar un documento XML en HTML. Umbraco usa esto ** muy ** con éxito. – Marko

+0

Pregunte a ** 'Jon Skeet' ** para crear un nuevo idioma para usted. – shamittomar

Respuesta

6

Una razón es que Internet Explorer (y las versiones anteriores de Firefox) no tienen un respaldo para las etiquetas que no están definidas y terminan ignorándolas tanto para el diseño como para el anidamiento. Without a shiv, su sitio se romperá horriblemente en esos navegadores.

+0

¿No se puede superar esa limitación agregando reglas de estilo como "mostrar" para las etiquetas nuevas/arbitrarias? El estilo no definido no es razón suficiente para rechazar la idea de usar etiquetas xml válidas como una extensión semántica de html5. Es muy necesario si vamos a estructurar documentos en formatos significativos y buscables. El W3C agregó varias etiquetas semánticas, pero no hay forma de que puedan predecir todas las etiquetas que se necesitarán. HTML5 usa sintaxis XML, y debe ser compatible con extensiblity XML, con la advertencia de que el diseñador DEBE decirle al navegador cómo darle estilo. HTML es sobre marcado, no estilo. – Steve

1

La cuestión es que sería no validar y las nuevas etiquetas simplemente serían ignoradas.

+1

Tengo la impresión de que la validación no significa nada prácticamente, y para el problema de las nuevas etiquetas ignoradas, CSS puede arreglarlo fácilmente ('post, userinfo, pbody {display: block}'). –

+1

@Casey, su impresión es incorrecta. 'display: block' [no reparará el problema de las etiquetas faltantes en IE] (http://net.tutsplus.com/tutorials/html-css-techniques/how-to-make-all-browsers-render-html5-mark -up-properly-even-ie6 /): no se aplicarán estilos a elementos que IE no comprenda. Necesita usar otra solución (JavaScript o HTC) para que IE entienda las etiquetas. Tampoco soluciona problemas con versiones anteriores de Firefox, que volverán a anidar elementos desconocidos. –

1

La mayoría de los navegadores tratarán las etiquetas como arbitrarias (como la forma en que los navegadores antiguos tratan las etiquetas HTML5). Nada le impide usar sus propias etiquetas, pero no es una forma bien aceptada de codificar HTML. HTML debe usar etiquetas predefinidas.

Si está interesado en la codificación con etiquetas arbitrarias, puede ir con XML. Puede formatear XML con XSLT (utilizado de forma similar a las hojas de estilo, pero mucho más potente). Eche un vistazo aquí: http://www.w3schools.com/xml/xml_xsl.asp

3

Puede usar sus propias etiquetas, pero el problema es que debido a que no son estándar, los navegadores no sabrán que pueden tener etiquetas de cierre coincidentes. Y, por supuesto, el documento no se validará como HTML/X-HTML adecuado.

<blah> 
    This is some <span>test</span> test text with another <bogus>tag</bogus> tag 
    within, which ends with a fake self-closing <tag /> 
</blah> 

navegadores verán <blah>, no ahora cómo tratar con él, y tratarlo como esencialmente "nada" e ignorarlo. Luego, con mucho gusto, analizarán el siguiente fragmento y verán un texto simple, con un lapso válido dentro. Eventualmente alcanzarán el </blah> e ignorarán eso también.

Esta es la razón Javascript y CSS tuvieron que soportar el comentario secuencia de apertura HTML como parte de sus respectivas definiciones de la lengua:

<script type="text/javascript"> 
<!-- // <--actually a part of the javascript spec, treated as a comment. 
    alert('hey!'); 
//--> 
</script> 

Cuando se introdujo el Javascript en primer lugar, hay todavía muchos otros navegadores por ahí que eran totalmente desconocen Javascript, por lo que ignoran las etiquetas, y felizmente envían su código Javascript. Lo mismo para CSS.

Si realmente necesita etiquetas personalizadas, puede producir el documento como XML con su DTD adjunta, y usar XSLT para transformarlo en un documento HTML/X-HTML válido.

+0

con respecto a la pieza "los navegadores no sabrán que pueden tener etiquetas de cierre coincidentes". En realidad, pienso lo contrario ... ¿tiene alguna prueba para confirmarlo? – Pacerier

+0

' Verá este texto' Intente eso en cualquier navegador. Si se ignoraron las etiquetas desconocidas y se verificaron las etiquetas de cierre, no se vería el texto. –

+0

@Marc B. Veo el texto en las últimas versiones de Chrome/FF/IE/Opera/Safari. Creo que funciona en cualquier navegador que pueda pensar que tiene un share mayor al 0.1% del total de usuarios de Internet – Pacerier

1

¿Cuál es el objetivo de las etiquetas que elige? Si su objetivo es presentar información, entonces usar divs y otras estructuras orientadas a la presentación es genial. Sus etiquetas se ven más como si estuvieran tratando de describir los datos reales. Si ese es el caso, entonces XML con XSLT se transforma en el lado del servidor para producir HTML para el marcado de la presentación es lo mejor. Recuerde que un navegador es simplemente un motor de renderizado y utiliza las especificaciones de HTML, ya que es un plano de lo que debe representar para un sitio determinado. El navegador no necesita comprender la información como una "publicación" o "información del usuario" porque no tiene contexto para resguardar qué hacer desde una perspectiva de representación con esa información.CSS puede ayudar a un navegador a entender visualmente lo que quiere hacer, pero pregúntese primero cuál es el objetivo de tener su marcado de esa manera, almacenar sus datos (estilo XML) o presentarlos. Si para presentarlo, debe seguir los estándares si desea continuar utilizando un navegador como motor de representación. Buena suerte, sería genial si todos pudiéramos definir nuestros esquemas de presentación, ¡idea divertida!

1

getElementsByTagName me falla con etiquetas personalizadas. Ejemplo,

<acme:mytag id="mytag"> 
    <div id ="x">x</div> 
    <div id ="y">y</div> 
    <div id ="z">z</div> 
</acme:mytag> 

Esta falla con IE8 (modo no estándar o modo estándar)

var mytag = document.getElementById('mytag'); // it's found 
var mydivs = mytag.getElementsByTagName ('div'); // but this is always 0 

A menos que su etiqueta html lee

<html XMLNS:acme> 
... 
</html> 
Cuestiones relacionadas