2009-11-02 8 views
5

Al leer las listas de correo y observar las especificaciones, no puedo decir cuáles son los límites de HTML5 como software o tecnología programática. He visto dónde han intentado estandarizar los formatos de video y audio en HTML5 y parece que pueden estar escribiendo las definiciones de XHTML5 en la especificación de HTML5. También parece que la especificación es extremadamente extensa y cubre temas que están fuera de las meras definiciones y las instrucciones de procesamiento mínimamente requeridas de un lenguaje de marcado.¿Cuáles son los límites o las definiciones de alcance del desarrollo de HTML5?

Con la versión 5 ¿HTML ahora es una interfaz de aplicación opuesta a solo un lenguaje de marcado? Si es así, ¿cuáles son los límites y los límites definidos de la tecnología? Si no es así, ¿por qué hay tantos temas irrelevantes para el procesamiento del marcado que toman tal foco de atención en el proceso de desarrollo de la tecnología? ¿Cuándo finalizan los límites de un lenguaje de marcado y comienzan las preferencias de la aplicación de usuario? Con HTML5, esa separación no parece muy clara, pero como estándar de la industria debería ser clara, ¿no?

Respuesta

3

No eres la primera persona que se pregunta sobre esto. Véase la discusión entre Rob Sayre y el editor de HTML 5 (hixie): http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg-html5-specification-that-should-be-removed/#comment-7559

Mi opinión es la siguiente: hay un número de

  1. ampliamente implementado, pero las viejas tecnologías underspecified o no especificado (por ejemplo, "DOM 0 "características, análisis de sopa de etiquetas)
  2. " nuevas "tecnologías importantes, que los proveedores de navegadores modernos desearían implementar interoperativamente (por ejemplo, video, lienzo, fuera de línea).

Si hixie está interesado en ellos y no hay otros pasos de edición de arriba para mantener una especificación separada, hixie prefiere mantenerlos en HTML5, "[reformulado] pagando el precio de una especificación hinchada por no cale el progreso web" .

Por cierto, si quiere una respuesta autorizada, debería preguntarle a hixie o en los foros de discusión de HTML5.

[editar] encontró un correo electrónico Además de hixie en cosas división de la especificación HTML 5: http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html

+0

Si se trata de un estándar de comunidad, entonces ¿por qué se espera que una sola persona sea la fuente de todas las respuestas para la definición de la tecnología de la especificación? ¿Por qué esta respuesta no está definida explícitamente en el estándar? Parece que la especificación no sabe para qué tecnología es una especificación. ¿Estoy completamente equivocado cuando digo eso? –

+0

Hace preguntas meta sobre el trabajo de otras personas y no entiendo por qué. Sí, idealmente no habría un comportamiento de muerte cerebral ya implementado y en el que se confíe, el contenido y la presentación estarían 100% separados. Habría una línea clara entre lo que está en HTML5 y lo que está fuera. Habría 100 expertos en tecnologías web que tendrían tiempo para escribir especificaciones de alta calidad y las especificaciones se implementarían sin errores y se implementarían a los usuarios en 3 meses. Sin embargo, no vivimos en un mundo ideal y no tengo ningún problema con la configuración actual que es fácilmente reparable. – Nickolay

+0

El trabajo es un estándar y se aplica a muchos aspectos de la web, lo que afecta directamente a todos los que se desarrollan para la web. No es un trabajo personal y es por eso que estoy preguntando. Todo en su hipotético, a excepción de su línea de tiempo, generalmente se considera una expectativa mínima en la redacción de especificaciones respaldadas por los organismos de estándares. Hubo 150 "expertos" que se unieron para escribir XML. Considere cómo los estándares se unen para ISO o IETF. En esos grupos, es como presentar una disertación doctoral con defensa extendida por parte del autor. ¿Por qué debe HTML tener expectativas más bajas? –

0

Usted puede encontrar este artículo muy interesante: X/HTML 5 Versus XHTML 2 http://xhtml.com/en/future/x-html-5-versus-xhtml-2/

Desde W3C es lento en conseguir una especificación actualizada y la web no sólo está fragmentando más, pero hay necesidades que pueden que no son realmente posibles debido a que las especificaciones son tan antiguas, HTML5 está trabajando para solucionarlas, como la etiqueta canvas y la incorporación de video/audio. Esto reemplaza la etiqueta <object> que se usa demasiado y se debe usar Flash en su lugar.

La web ha ido más allá de servir páginas web, ahora tenemos aplicaciones de JavaScript, por lo que ahora podemos tener más interactividad de la que era posible debido a algunos cambios no solo de HTML5, sino del movimiento hacia una versión más nueva de JavaScript.

Por lo tanto, HTML5 debería ser algo más que un lenguaje de marcado, ya que las aplicaciones web han ido más allá de los servidores que solo sirven páginas estáticas, que es un lenguaje de marcado adecuado.

+0

entiendo completamente su punto de vista y que ofrecía una muy buena respuesta, pero que no respondieron a la pregunta. ¿Cuáles son los límites del alcance de HTML5 y dónde termina HTML5 y comienza el agente de usuario? Tu respuesta realmente solo reiteró lo que creía sobre HTML5 en primer lugar. –

+0

No creo que haya un límite de alcance más allá de lo que creen que pueden agregar, ya que están tratando de predecir lo que puede ser necesario, ya que no estará completamente en los navegadores y será común durante unos 10 años. –

+0

El navegador deberá decidir cómo manejar lo que tiene prioridad. Si quiero usar la aplicación Quicktime para algunas películas, pero el resto está usando las integradas, eso no es algo que la especificación pueda determinar, los navegadores tendrán que lidiar con eso. –

2

Con la versión HTML 5 es ahora una interfaz de aplicación en lugar de sólo un lenguaje de marcado?

Sí.

Si es así, ¿cuáles son los límites y los límites definidos de la tecnología?

Principalmente una regla autoimpuesta de no tomar ninguna nueva característica importante más.

¿Cuándo finalizan los límites de un lenguaje de marcado y comienzan las preferencias de la aplicación de agente de usuario?

Es borroso. ¿Es esta página de desbordamiento de pila un documento o una aplicación?

Con HTML5, esa separación no parece muy clara, pero como estándar de la industria debería ser clara, ¿no?

La especificación es clara en sus requisitos operacionales. No necesita ser claro al definir una distinción entre documentos y aplicaciones.

+0

El contenido HTML y contenido es un documento. JavaScript y AJAX son una interfaz de aplicación. La aplicación real es el software de agente de usuario que interpreta el JS y analiza el HTML. La distinción de roles hace que la separación de tecnologías sea bastante clara. La especificación tiene que ser clara al definir las diferencias entre los documentos y las aplicaciones a fin de aclarar sus intenciones. La especificación obviamente no es tan clara o no tendría que hacer esta pregunta o recibir tales respuestas ofuscadas. –

0

HTML, desde el principio, ha tenido esta tensión entre el marcado y el comportamiento (véase Why do we have an IMG element?). El HTML y la web ya están inexorablemente relacionados. Las especificaciones de HTML oscilan entre la pureza técnica y la pavimentación de los caminos de los vacas.

HTML es un lenguaje de marcado, pero el comportamiento de la aplicación que implementa la especificación está restringido. Para un marcado más puro, XML o SGML serían más apropiados.

Según tengo entendido, usted se pregunta por qué la especificación no se limita a la parte de marcado (x/HTML 5) y, en su lugar, también especifica el comportamiento del agente de usuario, ¿es correcto? Si es así, creo que es porque la especificación cubre el comportamiento del usuario-agente, intencionalmente. Especifica cómo debe comportarse la aplicación de implementación para cumplir con la especificación.

Si empezaras desde cero hoy, no terminarías con HTML5. Sin embargo, no estamos comenzando desde cero y las especificaciones de HTML siempre han intentado equilibrar el mundo real con el ideal.

+0

Marcado es el vocabulario y las restricciones estructurales de ese vocabulario. El comportamiento siempre ha sido un problema de controles de formulario y JavaScript. No veo la confusión. El W3C incluso ha sido muy claro acerca de esto en el lado de XML con estándares separados para eventos XML y XForms. No entiendo la confusión que afirmas ha sido tan evidente durante tanto tiempo. –

+0

Veo ahora a lo que llega. Pero como señalas, con XML hay separación. HTML ha sido menos puro; de ahí el conflicto entre los grupos W3C y WHATWG al especificar XHTML2 y HTML5. Sé que estarías en desacuerdo, pero ese HTML se ha estado acercando al marcado/comportamiento por algún tiempo. Use XML para separaciones más claras. – Don

+0

¿Está diciendo que con respecto al desarrollo para la web debería estar contento con la confusión porque la especificación está desordenada? –

1

A riesgo de sonar como una simplificación excesiva: si está en la especificación, es parte del estándar. Para cumplir, un agente tendrá que implementar las porciones especificadas.

El hecho de que no sea "solo un lenguaje de marcado" no es algo nuevo con HTML 5. Las especificaciones de HTML siempre fueron un poco más que simplemente el marcado de documentos. Por lo que puedo decir, los esfuerzos para perfeccionar HTML en una definición de solo marcado llegaron a su máximo esplendor con XHTML.

HTML 5 parece ser un reconocimiento de que el marcado puro en sí mismo no es suficiente para abordar ciertas preocupaciones del mundo real, y un estándar actualizado podría ayudar a resolver esos problemas: "¿Pero qué debería pasar en esta situación? " "Oh, bueno, eso depende del agente de usuario, no nos preocupamos por eso en nuestra especificación de marcado". ... No es una solución muy satisfactoria en una web donde la experiencia del usuario final se resiente debido a la falta de consenso sobre estos temas.

¿Es una API? quizás, pero como lenguaje funcionará como un simple marcado cuando sea necesario (piense en agentes de usuario no gráficos). En algunos casos, debería funcionar mejor que las opciones disponibles.

Para responder a su última pregunta: no, en una norma, la separación entre el lenguaje de marcado y el comportamiento del agente de usuario no necesita ser "clara como el cristal". ¿Qué te hizo pensar que lo hizo? Pero sospecho que es más claro de lo que piensas: ¿puedes dar un ejemplo de una parte de la especificación en la que no estás seguro de si se está refiriendo al marcado o al comportamiento del agente de usuario?

+0

¿Qué preocupaciones del mundo real no se resuelven al restringir la especificación de HTML al lenguaje de marcado? Si hay preocupaciones adicionales, ¿por qué no se abordan en las especificaciones relacionadas con la aplicación por separado? Aún así, ¿cuáles son las definiciones y el alcance de la especificación HTML5, porque parece que arrojaron un poco de todo en la especificación completamente sin tener en cuenta ningún tipo de objetivo original o previsto para el idioma en su conjunto.Si la especificación no es clara en cuanto a la separación entre el marcado y la aplicación, ¿cómo determinan los desarrolladores las decisiones claras sobre mejores prácticas? –

+2

Preocupación del mundo real: cómo debe comportarse el agente cuando se enfrenta a un documento que contiene errores. ¿Por qué no está en especificaciones separadas? Buena idea: deberías hacer eso. Oh, no tienes tiempo? Sí. Es por eso. –

+0

¿Cómo ayudaría una separación más clara a tomar "decisiones sobre las mejores prácticas"? definiciones aquí: http://www.w3.org/TR/html5/infrastructure.html#terminology, scope here: http://www.w3.org/TR/html5/introduction.html#scope. ¿Qué decisiones estás tratando de tomar en tu desarrollo que no puedes hacer debido a una supuesta falta de separación adecuada? Tus comentarios suenan cada vez más como ruido. Un ejemplo concreto sería muy útil para hacer esta discusión en realidad * sobre * algo. –

0

Aquí está el enlace que establece las diferencias entre HTML5 y HTML4. Se quitaron muchos atributos y etiquetas de HTML5, ya que se manejaban mejor con CSS. ¿Qué pasa si la facilidad del programador si él no está dominado el CSS?

0

Quizás la mejor respuesta a su pregunta es "¿Qué está tratando de hacer?".

Lo digo porque si usted está buscando construir una aplicación web que funcione en navegadores web modernos (léase: no IE) usando HTML5, entonces el alcance/límites que le interesarán son los que Los principales fabricantes modernos de navegadores están actualmente apoyando y planean respaldar pronto.

Google Wave hizo esto y se le ocurrió un gran producto que funciona en el navegador (Firefox/Chrome/Safari/Opera). Algunos arrendatarios básicos de HTML5 que ya son ampliamente compatibles son video/audio/canvas/storage/geo.

HTML5 Support http://radar.oreilly.com/upload/2009/05/html5.png

http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html

+0

No entiendo lo que muestra la tabla. Nadie es compatible con la mayoría de HTML5 de una manera uniforme y nadie lo hará desde hace bastante tiempo porque tiene 9000 páginas e incluye todo tipo de funciones extrañas. La especificación de SVG fue casi tan larga y, como resultado, casi nadie la adoptó y quienes la adoptaron no la adoptaron por completo. –

+0

El objetivo de la tabla no es que TODO HTML5 sea compatible de manera uniforme, sino que 6 de las principales características importantes de HTML5 sí son compatibles con 4 navegadores diferentes. – philfreo

Cuestiones relacionadas