html - pagina - ¿Es el marcado semántico demasiado abierto?
title html (10)
Estoy echando un vistazo a Dive Into HTML5 . Parece bonito e interesante, pero estoy desconcertado.
En la década de 1990, en el momento en que Netscape era el navegador y el HTML era HTML2 o HTML3, había muchas etiquetas: dirección, cita, código ... La mayoría de ellas están sin usar a partir de hoy, probablemente incluso estén obsoletas.
HTML5 introduce etiquetas para expresar "significado semántico" a la etiqueta en sí. Esto es todo diversión y juegos, pero veo algo muy extraño en este enfoque. Técnicamente, la semántica puede ser muy abierta. HTML5 tiene etiquetas para artículo, hora, barras de navegación, pie de página. ¿Por qué no debería contener etiquetas para el ícono de la publicación, el lugar del autor, el nombre y el apellido, o cualquier otra cosa a la que desee asignar semántica específica (estoy seguro de que <rant> y <nsfw> serían etiquetas muy importantes):? Pensé que XML era la estrategia para asignar semántica a las cosas. Nada le prohíbe colocar un fragmento XML bajo un elemento div XHTML , y asignarle una hoja de estilo para que lo haga correctamente, o para delegar en el visor adecuado el manejo de ese espacio de nombres (por ejemplo, al manejar RSS o SVG ).
En conclusión, no entiendo la razón detrás de estas extensiones enfocadas hacia la semántica, cuando está claro que la semántica es un tema muy amplio, que garantiza una cantidad potencialmente infinita de etiquetas semánticas. Como estoy bastante seguro de que hay personas inteligentes en el W3C , creo que estoy equivocado, pero me gustaría saber por qué.
Pensé que XML era la estrategia para asignar semántica a las cosas.
Por lo que sé, no, no lo fue. XML permite definir nuevos lenguajes que se analizan todos de la misma manera, porque todos usan la sintaxis XML.
No proporciona, en sí mismo, ninguna forma de agregar significado ("semántica" significa "significativo") a esos idiomas. Y hasta que las computadoras obtienen inteligencia artificial, en realidad no entienden el significado, de modo que el significado es justo lo que se acuerda entre los seres humanos. HTML es el lenguaje más comúnmente utilizado con el significado acordado de sus etiquetas.
Como el HTML es tan común, es útil agregarle algunas etiquetas significativas que sean bastante generales en su aplicación. Las nuevas etiquetas HTML5 están destinadas a eso. De hecho, los autores de las especificaciones HTML5 podrían continuar por esta ruta, creando etiquetas para cada significado específico posible, pero como no son robots, probablemente no lo harán.
<section> es útil y lo suficientemente general como para ser aplicable de manera significativa en muchos documentos. <author-last-name> no es. Distinguir entre los dos es una llamada de juicio, por lo que los humanos, y no las computadoras, escriben la especificación.
Para semánticas personalizadas que son demasiado específicas para agregarse a HTML como etiquetas, HTML5 define los microdata .
"¿Por qué no debería contener etiquetas para el ícono de la publicación, el lugar del autor, el nombre y el apellido, o cualquier otra cosa a la que desee asignar una semántica específica (estoy seguro y sería una etiqueta muy importante):?"
Utiliza <dialog> para describir conversaciones o comentarios. Rant y NSFW son términos subjetivos, por lo tanto, tiene sentido no usarlos.
Por lo que entiendo, un grupo de desarrolladores web con experiencia investigaron y buscaron lo que la mayoría de los sitios web tienen en común en html. Se dieron cuenta de que la mayoría de los sitios web tienen las etiquetas id = "header", id = "footer", id = "section" y id = "nav", por lo que decidieron que necesitamos etiquetas HTML para reemplazar esas ID. En otras palabras, no espere que le den una gran cantidad de vocabulario HTML. Manténgalo tan simple como sea posible mientras aborda las etiquetas HTML más necesarias.
La etiqueta NAV es MUY importante para proporcionar accesibilidad también. Desea que sepan dónde está la navegación en lugar de obligarlos a encontrar si los enlaces son para la navegación o no.
¿Por qué son útiles las etiquetas para artículo, hora, barras de navegación y pie de página?
Porque facilitan el análisis de herramientas de procesamiento de texto como Google.
No tiene nada que ver con la semántica (al menos en el significado ''amplio''). En su lugar, solo dicen: aquí está el cuerpo de la página (la parte de texto más importante) y hay una barra de navegación llena de enlaces. Con este enfoque, puede extraer fácilmente lo que necesita.
En una palabra, AJAX. Las nuevas etiquetas están diseñadas para admitir lo que hacen los desarrolladores del mundo real al reemplazar algunas de las <div class="sidebar-wrap"><div class="styling-hook"><div><ul class="nav"> Tipo de divitis que muchos sitios web sufren. El único <div> queda en el HTML5 es el gancho de estilo.
La semántica que se promociona a las etiquetas de las clases es la que los desarrolladores han adoptado libremente en masa como mejores prácticas, dado un período de adopción de xhtml / css extendido. Echa un vistazo a la edición del desarrollador de WHATWG de la página de secciones de especificaciones here . El documento en sí es un placer, pero no lo estropearé si aún no lo ha visto.
Una de las razones menos obvias para algunas decisiones tomadas por el W3C es la importancia de Webkit. Si observa, puede ver que fueron mejores que algunos al tomar el trabajo actual del Grupo de Trabajo HTML5 e implementar ideas. Históricamente han estado muy por delante en cuanto al cumplimiento ( ver aquí ). El W3C le dio una alta prioridad a sus (es decir, Android, iPhone, Googlebot, Chrome, Safari, Dreamweaver, etc.). Google, usuarios de framework, Wordpress / Moveable Type / Joomla! Los usuarios de tipo y otros querían bloques de construcción independientes, por lo que este es el estilo que obtenemos.
Facebook es modular. Las cuadrículas de diseño receptivo son modulares. Wordpress es modular. Ajax funciona mejor con estructuras de página modulares. Los widgets son módulos. Los complementos son módulos. Parece que deberíamos estar tratando de descubrir cosas como la forma de aplicar estas etiquetas para que sea más fácil enganchar los elementos apropiados y activarlos en nuestra Web 2.0 híbrida de documentos / aplicaciones / información.
Para concluir, HTML5 debe escribirse como xml (nuevamente, consulte la especificación) para garantizar que las herramientas y máquinas que realizan solicitudes ajax para una parte de un documento obtendrán una respuesta útil bien formada. Qué increíble en combinación con cosas como consultas de medios para dispositivos como lectores de feeds, impresoras braille, anotadores, etc.,. ¡Veo un futuro (cercano) donde cualquier cosa con buen contenido semántico es su propia fuente de noticias automágicamente! Esto solo ocurre si los desarrolladores adoptan y escriben documentos compatibles.
He estado leyendo el libro Transcending CSS de Andy Clark (página 33).
..., ahora se acepta ampliamente que los nombres de presentación como encabezado , izquierda o rojo que describen el aspecto o la posición de un elemento son malas elecciones.
Después de leer estas líneas me pregunté: hey, ¿no hay elementos en las especificaciones de HTML5 como encabezado, pie de página? ¿Por qué el pie de página es más semántico? Andy en su libro aboga por utilizar la información del sitio para la ID del pie de página div y esto tiene más sentido en mi humilde opinión. Footer es un nombre de presentación (describe la posición del elemento).
Míralo desde el ángulo en el que intentas hacer afirmaciones sobre la página o sobre los objetos a los que se hace referencia desde la página. Si ves una etiqueta de <pie de página>, todo lo que puedes decir es "cosas aquí es un pie de página" y pasarlo. Como tal, agregar etiquetas personalizadas no es una solución tan genérica como agregar atributos y permitir que las personas utilicen su propia elección de URI para especificar predicados y, opcionalmente, valores: RDFa gana sin parar porque puede expresar cualquier declaración triple que desee de RDF en Una página, de una manera u otra.
No estoy de acuerdo con agregar etiquetas adicionales. Si el vocabulario detallado fuera realmente importante, entonces podría haber un nombre de etiqueta diferente para cada palabra en el diccionario. Los nombres de etiquetas adicionales no son útiles, ya que pueden comunicar un significado adicional a los humanos, pero no hacen nada para facilitar el análisis de la máquina del lenguaje. Esta es la razón por la que no me gustan las etiquetas "semánticas" para HTML5 ya que creo que esta es una pendiente resbaladiza para proporcionar un vocabulario demasiado complejo, mientras que solo brinda una solución débil a un problema que no se resuelve completamente.
En mi opinión, los datos de la estructura del lenguaje de marcado tanto como los describen en forma de diagrama de árbol. Mediante el análisis de la estructura y el uso adecuado de las convenciones semánticas, como RDFa, se puede aprovechar el contexto para proporcionar un significado específico a los nombres de etiquetas genéricos. En tal caso, no es necesario que exista un vocabulario excesivo y los nombres de etiquetas estructuralmente redundantes, como pie de página y aparte, podrían eliminarse. El objetivo final es hacer que el contenido sea más rápido y más preciso para que lo interpreten tanto los humanos como las máquinas al mismo tiempo que utilizan el menor código posible para lograr ese resultado. Cómo esa solución es menos importante, excepto para HTML5.
Solo quiero abordar una parte de su pregunta. Tu dices:
En la década de los noventa, en el momento en que Netscape era el navegador y html era HTML2 o HTML3, había muchas etiquetas: dirección, cita, código ... La mayoría de ellas no están en uso hasta hoy, probablemente incluso obsoletas.
Hay una gran cantidad de etiquetas para elegir en html, pero la falta de uso no implica que estén obsoletas. En particular, las etiquetas de encabezado <h1> , etc, y <ul> , <ol> se utilizan para unir elementos en listas de una manera que considero semántica. Muchas personas pueden no usar etiquetas semánticamente, pero el esfuerzo por crear microformats es una continuación continua de la idea que considera un artefacto de los años noventa. Los esfuerzos para que la web semántica se convierta en un ganador continúan, a pesar de que la búsqueda de texto completo y el análisis de enlaces (en forma de Google) son los ganadores en cuanto a cómo encontrar y comprender la web.
Sería genial ver una versión actualizada de las estadísticas web de Google que muestren "html tal como se habla". Pero tienes razón en que muchas etiquetas están infrautilizadas.
Si html5 tendrá éxito es una pregunta abierta e interesante, pero las etiquetas que usted describe como obsoletas no fueron a ninguna parte, estaban allí en HTML 4.01 y xhtml . HTML5 parece ser un esfuerzo para solidificar lo que es útil en las etiquetas. Al final, si html5 obtiene soporte en los navegadores y facilita el trabajo de los desarrolladores web, tendrá éxito. xhtml2 falló porque fracasó rotundamente en obtener la adopción en los navegadores y no hizo nada para facilitar el trabajo de los creadores de páginas web. Las fuerzas que trabajan en html5 parecen muy conscientes de la falla de xhtml2, y creo que están evitando que html5 sufra un destino similar.
Ya hay una gran cantidad de semánticas en el formato HTML en las formas de clases e ID, de las cuales hay una cantidad (casi) infinita de posibilidades de, y cada uno tiene su propia manera de manejar estas semánticas. Uno de los objetivos de HTML5 es tratar de estructurar esto. Aún podrás extender la semántica de las etiquetas con clases e ids. También lo más probable es que haga las cosas más fáciles para los motores de búsqueda.
Yo también odio la forma en que W3C va con sus especificaciones. Hay muchas cosas que no me gustan, y esta moda "semántica" es una de ellas. (Otros incluyen tomarse para siempre para completar sus especificaciones y dejar demasiados detalles importantes para que los navegadores los implementen según lo deseen)
Por encima de todo, no me gusta porque hace que mi trabajo como desarrollador web sea más difícil. A menudo tengo que elegir si la página web es "semánticamente correcta" o "agradable a la vista / estética". El último gana, por supuesto, porque eso es lo que quieren los usuarios, pero como resultado, las validaciones comienzan a fallar y todo se vuelve bastante no semántico (tablas para el diseño y otras cosas).
Otro tema en el que frunzo el ceño es que oficialmente han declarado que el atributo "clase" es para semántica, pero luego lo usaron para selectores de presentación visual en CSS.
En pocas palabras: NO MEZCLAR SEMÁNTICA Y REPRESENTACIÓN VISUAL . Si utiliza algún mecanismo para describir la semántica (como nombres de etiquetas, valores de atributos o lo que no sea más), no lo use con fines funcionales / visuales y viceversa.
Si diseñara HTML, simplemente agregaría un atributo "semántico" que podría (como el atributo "clase") agregarse a cualquier etiqueta. Luego habría una serie de valores predefinidos como todos esos encabezados / pies de página / artículos / citas / etc.
Las etiquetas definirían la funcionalidad. Básicamente, podría reducir las etiquetas HTML a solo un puñado, como "div", "table / tr / td", "a", "img", "form", "input" y "select". Probablemente me perdí algunos, pero este es el grueso. El estilo visual se lograría a través de CSS.
De esta manera, las tres áreas (semántica, representación visual y funcionalidad) serían completamente independientes y no se enfrentarán en las soluciones de la vida real.
Por supuesto, no creo que W3C esté interesado en soluciones prácticas ...