É aceitável para XHTML inválido?

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

  •  08-06-2019
  •  | 
  •  

Pergunta

Tenho notado que muitos sites, inclusive o SO, usam XHTML como linguagem de marcação e não cumprem as especificações.Apenas navegando na fonte para SO, faltam tags de fechamento de parágrafos, elementos inválidos, etc.

Portanto, as ferramentas (e os desenvolvedores) deveriam usar o tipo de documento XHTML se quiserem produzir marcações inválidas?E os navegadores deveriam ser mais firmes na aceitação de marcações ruins?

E antes que alguém grite hipócrita, meu blog tem uma marcação inválida envolvendo o captha (ou tinha da última vez que verifiquei), que envolve o estilo da tag noscript.

Foi útil?

Solução

Há muitas razões para usar marcação válida.Meu favorito é que ele permite que você use a validação como uma forma de teste de regressão, evitando que a marcação equivalente à "rotação delta" leve a problemas reais de renderização quando os erros atingirem uma massa crítica.E realmente, é simplesmente desleixado permitir que erros "preguiçosos", como erros de digitação e tags mal aninhadas/não fechadas, se acumulem.A marcação válida é uma forma de identificar programadores apaixonados.

Há também a questão da depuração:a marcação válida também fornece uma linha de base estável para trabalhar nos inevitáveis ​​problemas de compatibilidade entre navegadores.Nenhum desenvolvedor web que valoriza seu tempo deve começar a depurar problemas de compatibilidade do navegador sem primeiro garantir que a marcação seja pelo menos sintaticamente válida – e qualquer outra marcação inválida deve ter uma boa razão para estar lá.

(Aliás, stackoverflow.com falha em ambos os testes e sugestões para corrigir os problemas eram recusou.)

Dito isso, para responder à sua pergunta específica, provavelmente não vale a pena usar um dos doctypes XHTML, a menos que você planeje produzir documentos válidos (ou pelo menos ao menos marcação bem formada).As principais vantagens do XHTML derivam do fato de que XHTML é XML, permitindo que seja processado e transformado por ferramentas e tecnologias que funcionam com XML.Se você não planeja tornar seu XML XHTML bem formado, não faz sentido escolher esse tipo de documento.A especificação HTML 4 mais recente provavelmente fará tudo o que você precisa e é muito mais indulgente.

Outras dicas

Devemos sempre tentar validá-lo de acordo com os padrões.Teremos certeza de que o site será exibido e funcionará bem nos navegadores atuais E nos navegadores futuros.

Não creio que, se você especificar um tipo de documento, haja alguma razão para não aderir a esse tipo de documento.

O uso de XHTML facilita a detecção automatizada de erros, cada alteração pode ser verificada automaticamente em busca de marcações inválidas.Isso evita erros, especialmente ao usar conteúdo gerado automaticamente.É realmente fácil para um desenvolvedor web usando um mecanismo de modelagem (JSP, ASP.NET StringTemplate, etc.) copiar/colar uma tag de fechamento a mais ou a menos.Quando este for o seu único erro, ele poderá ser detectado e corrigido imediatamente.Certa vez, trabalhei em um site que apresentava 165 erros de validação por página, dos quais 2 ou 3 eram bugs reais.Estes foram difíceis de encontrar na confusão de outros erros.A validação automática teria evitado esses erros na origem.

Escusado será dizer que escolher um padrão e segui-lo nunca pode beneficiar a interoperabilidade com outros sistemas (screen scrapers, leitores de tela, mecanismos de pesquisa) e nunca me deparei com uma situação em que uma solução XHTML semântica válida com CSS não fosse possível para todos principais navegadores.

Obviamente, ao trabalhar com sistemas complexos, nem sempre é possível manter o seu tipo de documento, mas isso é principalmente resultado de uma comunicação inadequada entre as diferentes equipes que desenvolvem diferentes partes desses sistemas, ou, muito provavelmente, sistemas legados.No último caso, provavelmente é melhor isolar esses casos e alterar seu tipo de documento de acordo.

É bom ser pragmático e não aderir ao XHTML só porque alguém disse isso, independentemente dos custos, mas com o conhecimento atual sobre CSS e navegadores, ferramentas de teste e validação, na maioria das vezes os benefícios são muito maiores que os custos.

Você pode dizer que tenho um TOC na validade do XHTML.Acho que a maioria dos problemas com o código não ser válido vem de programadores que não sabem a diferença entre HTML e XHTML.Tenho escrito XHTML e CSS 100% válidos há algum tempo e nunca tive grandes problemas de renderização com outros navegadores.Se você mantiver tudo válido e não tentar nada muito exótico em termos de CSS, você economizará muito tempo em correções.

Eu não usaria XHTML apenas para me poupar do estresse filosófico.De qualquer forma, não é como se algum navegador o estivesse tratando como XHTML.

Os navegadores rejeitarão marcações ruins se a página for enviada como application/xhtml+xml, mas raramente o são.Isto é bom.

Eu ficaria mais preocupado com coisas como o uso inline de CSS e JavaScript com Stack Overflow, só porque eles dificultam a manutenção.

Embora eu acredite na busca por XHTML e CSS válidos, muitas vezes isso é difícil de fazer por vários motivos.

  • Primeiro, parte do conteúdo pode ser carregado via AJAX.Às vezes, os fragmentos não são inseridos corretamente no DOM existente.
  • O HTML que você está visualizando pode não ter sido produzido no mesmo documento.Por exemplo, a página pode ser composta de componentes ou modelos e, em seguida, reunida logo antes de o navegador a renderizar.Isso não é uma desculpa, mas você não pode presumir que o HTML que você está vendo foi codificado manualmente de uma só vez.
  • E se parte do código gerado pelo Markdown for inválido?Você não pode culpar o Stack Overflow por não produzir código válido.
  • Por último, o objetivo do DOCTYPE não é simplesmente dizer "Ei, estou usando um código válido", mas também avisar o navegador sobre o que você está tentando fazer, para que ele possa pelo menos chegar perto de analisar corretamente essa informação.

Não acho que a maioria dos desenvolvedores especifique um DOCTYPE e deixe explicitamente de segui-lo.

embora eu concorde com o sentimento de "se funcionar bem, não se preocupe com isso", é bom seguir um padrão, mesmo que ele não seja totalmente suportado no momento.você ainda pode usar Tabela para layout, mas não é bom por um motivo.

Não, você não deve usar XHTML se não puder garantir a boa formação e, na prática, não poderá garantir isso se não usar o serializador XML para gerar marcação.Ler sobre a produção de XML.

A boa formação é o coisa que diferencia XHTML de HTML.XHTML com erro de marcação "apenas um" deixa de ser XHTML. Tem que ser perfeito sempre.

Se o site "XHTML" parece funcionar com alguns erros, é porque navegadores ignoram o DOCTYPE e interpretar a página como HTML.

Ver Proxy XHTML isso força a interpretação das páginas como XHTML.A maior parte do tempo eles falham miseravelmente.Esta é uma das razões pelas quais o futuro do XHTML é incerto e por que o desenvolvimento de HTML foi retomado.

Depende.eu tive isso problema com meu blog onde um vídeo do YouTube causou XHTML inválido, mas foi renderizado corretamente.Por outro lado, tenho um link "XHTML válido" e uma combinação de uma reivindicação "XHTML válido" e XHTML inválido não é profissional.

Como o SO não afirma ser válido, acho que é aceitável, mas pessoalmente, se eu fosse Jeff, ficaria incomodado e tentaria consertar, mesmo que pareça bom em navegadores modernos, mas algumas pessoas preferem seguir em frente e realmente fazer as coisas. em vez de corrigir bugs inexistentes.

Contanto que funcione no IE, FF, Safari (insira outro navegador aqui), você estará bem.A validação não é tão importante quanto renderizar corretamente em vários navegadores.Só porque é válido, não significa que funcionará corretamente no IE, por exemplo.

Execute o Google Analytics ou similar em seu site e veja que tipo de navegador seus usuários estão usando e, em seguida, julgue quais navegadores você mais precisa oferecer suporte e se preocupe com os menos importantes quando tiver tempo livre para fazê-lo.

Eu digo, se renderizar bem, então não importa se é pixel perfeito.

Demora um pouco para colocar um site em funcionamento da maneira que você deseja, voltar e fazer alterações vai mudar um pouco a forma como a página é renderizada, então você tem que consertar aqueles problemas.

Bem, não estou dizendo que você deveria criar páginas da web desleixadas, mas não vejo razão para consertar o que não está quebrado.Os navegadores não abandonarão o suporte para correção de erros em um futuro próximo.

Não entendo por que todo mundo se envolve tentando fazer com que seus sites se ajustem ao padrão, quando alguns navegadores ainda têm problemas para renderizar corretamente o código padrão.Trabalho com web design há cerca de 10 anos e parei de codificação dupla (leia:hackear css) e mudar coisas estúpidas só para poder colocar um botão no meu site.

Acredito que usar um < div> fará com que você seja inválido de qualquer maneira, e ficará um pouco mais difícil executar qualquer JavaScript/AJAX importante sem ele.

Existem tantos padrões e eles são tão mal “aplicados” ou apoiados que não acho que isso importe.Não me entenda mal, acho que deveria haver padrões, mas como eles não são aplicados, ninguém os segue e há uma enorme espiral descendente.

Para 99,999% dos sites existentes, isso realmente não importa.A única vez que isso aconteceu, executei a entrada HTML por meio do HTMLTidy para torná-la XHTML e, em seguida, executei meu processamento nela.

Basicamente, é o velho axioma do programador:não confie em nenhuma entrada.

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