Will HTML 5 validação valer a vela?

StackOverflow https://stackoverflow.com/questions/432933

  •  10-07-2019
  •  | 
  •  

Pergunta

É amplamente considerado que a melhor razão para validar de um HTML é garantir que todos os navegadores irão tratá-lo de forma consistente e previsível.

O projecto de HTML 5, no entanto, contém duas especificações em um. Primeiro uma especificação autor, descrevendo os elementos e atributos que os autores HTML deve usar, e suas inter-relações. Validação de uma página HTML 5 baseia-se esta especificação. Os elementos e atributos incluídos não são diretamente extraídas HTML 4, mas têm necessidade de ser justificada a partir de primeiros princípios, o que significa que alguns HTML 4 características, tais como o atributo summary no

, longdesc em eo atributo de perfil em , atualmente não aparecem neste projecto. Tais características não são considerados obsoletos, eles simplesmente não estão incluídos. (A ausência do projecto continua a ser uma questão de disputa, embora sua inclusão em breve não parece provável.)

Em segundo lugar, o projecto define uma especificação de processamento de navegador que busca definir exatamente como analisador do navegador irá tratar qualquer fluxo de bytes é dado, independentemente de quão bem formado e válido o HTML. Isto significa que quando os navegadores suportam totalmente HTML 5, será possível prever como qualquer navegador irá tratar HTML para uma gama muito maior de entradas do que apenas aqueles que a validação passar.

Em particular, porque o HTML 5 é definida para ser 100% compatível com web de hoje, todos HTML válida 4, e todos inválida, mas comumente usado mark-up, continuará a ser processado exatamente o mesmo como é hoje, independentemente de se tratar de HTML 5 válida ou não.

Portanto, no mínimo, qualquer pessoa usar qualquer recurso do HTML 5, HTML 4, ou qualquer versão anterior do HTML, além de muitas extensões proprietárias, pode ter certeza que o seu HTML irá receber o tratamento consistente e previsível em todos os navegadores.

Diante disso, faz algum sentido para aqueles limite HTML 5 para o que irá validar, e qual benefício prático é que vamos começar a fazê-lo?

Foi útil?

Solução

  • Em primeiro lugar, há a camada de validade correspondente a “erros de análise” no HTML5 análise algoritmo . Esta camada é semelhante ao XML bem formatados. A razão mais importante para evitar ter erros em seus documentos sobre esta camada é que você pode obter uma árvore de análise surpreendente. Se o documento esteja livre de erros sobre esta camada, você tem menos surpresas para depuração quando escrever JS ou CSS que trabalha com o DOM.
  • Como um caso especial da camada acima mencionado, há o doctype HTML5: <!DOCTYPE html>. A razão por que alguém iria querer cumprir aqui é conseguir o modo de padrões da maneira mais fácil possível. É algo que você pode memorizar ao contrário dos HTML 4.01 ou XHTML 1.0 doctypes você precisa olhar para cima e copiar e colar cada vez. Claro, a razão por que você iria querer o modo de normas é menos surpresas na camada CSS.
  • A principal razão para se preocupar com a validação na camada superior ao algoritmo de análise está pegando seus erros para que você gaste menos tempo de depuração porque sua página não está funcionando como você está esperando.
  • O ponto anterior não explica por que você deve se preocupar com a validação quando um determinado elemento ou atributo que você não cometer erros de ortografia é suportado pelos navegadores como uma questão de herança, mas a especificação HTML5 ainda evita-lo. Aqui está o porquê HTML5 tem uma sintaxe Obsoleted assim:
    • HTML5 usa obsoletion de sinal para autores que algumas características são um desperdício de seu tempo. Estes incluem longdesc, summary e profile. (Nota que as pessoas discordam sobre se estes são, na verdade, perda de tempo, mas na sua redacção actual, HTML5 torna obsoleto.) Ou seja, se você tem recursos para melhorar a acessibilidade limitada, seus recursos limitados são melhor gasto em outra coisa que não longdesc e summary. Se você tem recursos para a pureza semântica limitado, seus recursos são mais bem gasto em outra coisa que fazer se você tem o encantamento certo em profile.
    • HTML5 obsoletes alguns elementos de apresentação que podem ser duplicados em CSS para os autores de orientação para o uso CSS para seu próprio bem. Desta forma, os autores que não consideram manutenção por conta própria é suposto ser guiado para um código mais sustentável, no entanto. Pessoalmente, eu prefiro fazer mais do material de apresentação legado conformes e deixando-a aos autores si para decidir qual caminho de fazer as coisas funciona para eles.
    • Algumas coisas são obsoletos por razões políticas. O elemento <font> está obsoleta, porque tornando-se conformando faria standardistas anti-<font> acho que as pessoas HTML5 ter enlouquecido, o que poderia levar ao mau PR. <applet> está obsoleta principalmente como uma questão de princípio de não dar marcação especial para um plug-in particular. O atributo classid em <object> está obsoleta, porque está em específico ActiveX-prática.
    • Algumas coisas são obsoletos com base na estética de design de linguagem. Isto inclui o atributo name em <a> eo atributo language em <script>.

(I desenvolver o validador Validator.nu HTML5 que é também o mecanismo de validação HTML5 utilizado pelo validador do W3C).

Outras dicas

Diante disso, faz algum sentido para aqueles limite HTML 5 para o que irá validar, e qual benefício prático é que vamos começar a fazê-lo?

Sim, é claro. Você se esquece de que o futuro não é fixo. Em particular, você assume implicitamente que HTML 5 specs nunca vai mudar, e nunca depreciar quaisquer recursos. Isto, é claro, só cimenta o status quo. É definitivamente desejável remover o suporte para alguns recursos no longo prazo, para tornar mais fácil para novos desenvolvimentos a ter lugar (em particular se estes podem entrar em conflito entre si).

Pode haver nenhum benefício imediato na produção de HTML válida 5 (exceto que ele ainda faz a validação e, assim, o desenvolvimento mais fácil). Mas pode haver um benefício de longo alcance, se a maioria dos sites melhorar em qualidade, porque faz passar além das tecnologias atuais e padrões muito mais fácil.

Validação nunca foi realmente sobre a obtenção de resultados consistentes em todos os navegadores, mesmo antes HTML5 começou. Isso é um mito propagado por aqueles que não entendem o que eles estão falando, mesmo se eles acham que eles fazem.

A verdadeira razão para a validação é e sempre foi puramente uma questão de garantia de qualidade. É apenas uma maneira de detectar erros, o que. Apesar de resultados para qualquer erro pode ser, ou pode em breve tornar-se, consistente entre navegadores, ainda é possível que o resultado em si não é como pretendido.

É importante que os autores de ser capaz de detectar erros em seu código, pois mais limpo, erro de marcação livre é mais fácil de trabalhar e manter, especialmente quando se trabalha em um ambiente de equipe. Enquanto a maioria dos erros individuais pode acabar sendo benigno e não causa grandes problemas, há alguns que podem dar resultados inesperados. por exemplo. Incorretamente, sobrepostos ou elementos não fechadas pode causar problemas de layout inesperados em alguns casos, e deixando um validador dizer-lhe onde está o erro, ajuda a corrigir o problema. Mas se os resultados são preenchidos com dezenas de erros de outra forma benigna, ele pode fazer o processo de detecção e mais difícil do que precisa ser.

Esta é, de fato, um dos meus quibbles com HTML5. Não há nenhum ponto que define um subconjunto de fluxos como 'válido', se um navegador deve lidar com todos os fluxos da mesma forma de qualquer maneira. As eras passadas na lista WHATWG debater mecanismos de fallback é um enorme desperdício de tempo de todos, especialmente quando XML já deve ter resolvido todos os problemas de análise.

Ela teria sido uma ideia útil para produzir um documento de melhores práticas em análise legados documentos inválidos, mas isso não tem parte em um padrão web, ele é apenas mais um ingrediente para mais turvar as águas em torno HTML5, que não pode decidir se ele quer ser codificação comportamento existente (como HTML 3.2 fez), redefinindo uma plataforma mais limpa (como HTML 3.0 tentado) ou adicionar novas extensões fragmentada.

De qualquer forma, a questão pode ser deslocada porque nunca haverá um navegador que "apoia plenamente HTML5". Há apenas muito, muito muito dela: fabricantes de navegadores não poderia implementar absolutamente tudo, até as minúcias mesmo que quisesse, o que, pelo menos Microsoft explicitamente não. Em vez disso, obviamente, características úteis será a partir dele por fornecedor escolhidas a dedo e encontrar uma maior aceitação.

HTML5 não é uma especificação HTML coerente, é alastrando receita de Hixie, ilegível e inacabado para cada coisa aleatória ele pensa um navegador web deve fazer. Ele irá falhar. E abordagem alternativa da W3, XHTML2, já falhou. Não há futuro rumo coerente para os padrões web. Nós cair a bola.

É uma boa pergunta.

O principal objetivo da validação (para mim pelo menos) é para me ajudar a detectar erros na minha marcação, e dar-me uma boa base sobre a qual construir ao testar páginas em navegadores diferentes; se a marcação é válida, ea página é borked no IE6, é uma questão IE6.

O fato de que os navegadores devem todos ainda se comportam de uma maneira previsível, mesmo se a sua marcação inclui HTML5 tecnicamente inválido, como um resumo da tabela, ou um accesskey âncora, turva as águas um tanto.

Como regra geral, eu sempre quero minhas páginas para validar, pela razão acima mencionado. No entanto, se (por exemplo) um atributo foi retirado da especificação HTML5 sem uma substituição aparentemente adequada que está sendo adicionado, eu poderia estar inclinado a continuar usando o atributo obsoleto ou obsoletas, e aceitar os erros de validação.

Como sempre, eu acho que é um caso de saber o seu ofício.

Se você sabe o que está fazendo, e fez um decisão consciente para construir uma página que não valida por razões de som, não é um problema. Se você está apenas escrevendo código que não valida porque você não sabe nada bem, isso é outra questão inteiramente.

Stephen

W3C HTML5 validador mantenedor aqui. Eu escrevi recentemente um curto “Por Validar?” seção para o “About” seção do validador HTML5:

http://validator.w3.org/nu/about.html# por-validate

A fonte para o texto desta seção é aqui:

https://github.com/validator/ validador / blob / master / site / nu-about.html # L160

e solicitações de pull com refinamentos sugeridos / adições são bem-vindos.

O que eu tenho lá atualmente é o seguinte:

A principal razão para executar seus documentos HTML através de uma conformidade verificador é simples: Para pegar não intencionais erros-erros que você pode caso contrário perdeu-para que você possa corrigi-los.

Além disso, alguns requisitos documento-Conformidade (regras de validade) na especificação HTML estão lá para ajudá-lo e os usuários de seus documentos evitar certos tipos de problemas potenciais. Para explicar a razão por trás desses requisitos, a especificação HTML contém essas duas seções:

Para resumir o que está indicado nas duas seções:

  • Existem alguns casos de marcação definidos como erros porque são potenciais problemas de acessibilidade, usabilidade, interoperabilidade, segurança ou manutenção, ou porque podem resultar em má desempenho, ou que possam causar seus scripts falhar de maneiras que são difícil de solucionar.
  • Junto com aqueles, alguns casos de marcação são definidas como erros, porque eles podem fazer com que você se deparar com problemas potenciais em HTML análise e comportamento de modo que de tratamento de erros, por exemplo, você pode acabar com alguma intuitiva, resultado inesperado no DOM.

Validando seus documentos alerta para esses problemas potenciais.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top