Por que alguém se incomodaria em marcar corretamente e semanticamente?

_{Observe que eu tento marcar o mais semanticamente possível, porque gosto da aparência e da aparência deles, mas não porque estou ciente de outras vantagens impressionantes. O objetivo da minha pergunta é ser capaz de educar os outros}

Bem, eu já vi muitos artigos e tutoriais que costumam dizer "Vamos marcar isso da maneira mais semântica possível".

Mas um pensamento estranho me ocorreu, por quê?

Por que alguém precisaria (ou desejaria) se preocupar com os elementos específicos que transmitem o significado semântico correto? Especificamente, eu estou me referindo aos novos elementos HTML5, como <time>, <output>, ou <address>. Especialmente, se a página "funcionar" (é renderizada perfeitamente em todos os navegadores).

Por que eu gostaria de usar elementos como <time>ou <address>, onde nada (ou, na pior das hipóteses, um genérico <span>) funciona tão bem?

Estou perguntando isso porque estou vendo uma infinidade de sites (muito populares) (incluindo este) que não seguem essas práticas recomendadas.

Funcionalidade livre

Usar corretamente <label>s significa que você pode clicar no rótulo para inserir o campo de texto. Muitos navegadores adicionarão a funcionalidade padrão lógica a muitas tags de acordo com a especificação oficial, o que significa que você pode usar menos plug-ins JavaScript e escrever menos código do que um site feito inteiramente de <div>s e <span>s.

Acessibilidade

Relacionadas à funcionalidade gratuita, a semântica significa muito para o software de leitura de tela. O texto na frente de um campo de entrada não será lido da mesma maneira que um <label>testamento. Os leitores de tela ignoram a maior parte do seu CSS; portanto, depende principalmente da estrutura do seu HTML.

CSS lógico

Por que usar um div #headerquando você pode usar um <header>estilo diretamente? As tags semânticas facilitam a marcação de itens e tornam seu estilo muito mais portátil; se você tem um certo estilo de strikeout e sempre usa <del>elementos, o estilo é muito mais portátil. <del>significa a mesma coisa para todos, mas todos nomearão sua .deletedTextclasse de maneira diferente.

Também ajuda a manter todos na mesma página em grandes projetos; ninguém gosta de aprender as convenções de nomeação de classe esotérica de outras pessoas.

SEO

Mecanismos de busca como o Google fizeram uso crescente de HTML e metadados semânticos . Os Rich Snippets do Google também usam metadados especiais destinados a transmitir conteúdo semântico.

Por que não é tão comum

É preciso trabalho e as pessoas estão acostumadas a julgar um site pela aparência e pelo funcionamento . Muitas vezes, não há explicação para a semântica, porque as pessoas que escrevem o caso de negócios para aplicativos não o entendem ou por que é importante.

É muito difícil para pessoas não técnicas entenderem ou avaliarem a semântica HTML.

Se um site parece bom e parece funcionar, por que se preocupar? Muitas pessoas não podem sequer sabe que é nada mais do que isso. Semelhante à acessibilidade, isso tende a ser ignorado até que alguém da sua equipe realmente entenda isso.

Se você deseja que o HTML semântico seja uma prioridade em seu projeto, é necessário apresentar o caso. Mostrar à sua equipe / chefe como o site funciona em um leitor de tela também é uma ferramenta útil.

A resposta para isso é simplesmente transmitir informações e estruturar seu documento .

Quando você usa spans e divs, o documento não possui uma estrutura. Não há listas, parágrafos, tabelas ou hiperlinks. Nada. Realmente não faz sentido escolher HTML como uma linguagem de marcação e ignorar o vocabulário que ele oferece para expressar e estruturar seu conteúdo. Estrutura é a palavra importante aqui. HTML é para estruturar não exibido. É para isso que serve o CSS.

Se você marcar seu código semântica, estará dando aos leitores humanos e às máquinas a chance de entender os dados dentro de seus elementos. Se você usar os elementos span e div por todo o caminho, não terá essas informações extras, e deduzi-los apenas dos valores pode não ser possível.

Da mesma forma, se eu quiser raspar sites e extrair apenas os cabeçalhos para criar um Sumário para eles, minha aranha precisará saber qual é o cabeçalho. Não pode fazer isso sem os elementos apropriados.

Por último, mas não menos importante, se você usar apenas divs e spans, será difícil estilizá-los com CSS. Os seletores de CSS funcionam na estrutura do seu documento e, se for uma estrutura ambígua, as regras de CSS ficam difíceis de aplicar. Como você decide se div div divrealmente se refere a table tr tdou body ul li? Você precisaria adicionar classes e IDs, mas reinventaria a roda.

Veja também a recomendação do W3C

O uso dos elementos semânticos apropriados garantirá que a estrutura esteja disponível para o agente do usuário. Isso envolve explicitamente indicar o papel que diferentes unidades têm na compreensão do significado do conteúdo. A natureza de uma parte do conteúdo como parágrafo, cabeçalho, texto enfatizado, tabela etc. pode ser indicada dessa maneira. Em alguns casos, os relacionamentos entre unidades de conteúdo também devem ser indicados, como entre títulos e subtítulos, ou entre as células de uma tabela. O agente do usuário pode tornar a estrutura perceptível para o usuário, por exemplo, usando uma apresentação visual diferente para diferentes tipos de estruturas ou usando uma voz ou tom diferente em uma apresentação auditiva.

Para adicionar as já boas respostas aqui, uma coisa que eu não vi mencionada é a compatibilidade com a frente . À medida que a especificação evolui, é possível que funcionalidades adicionais sejam especificadas para certos elementos semânticos. Se o seu código estiver semanticamente correto, ele poderá tirar proveito dessa funcionalidade sem manutenção mínima.

Uma razão pela qual você não vê muitos sites seguindo a semântica perfeitamente é que não há um caso comercial para ele a maior parte do tempo. Se impulsionar as vendas (ou uma categoria relacionada, como a exposição), vale a pena gastar dinheiro escrevendo HTML semântico.

O melhor caso para o uso semântico de tags é quando você está consumindo ou usando HTML com uma ferramenta. Por exemplo, o uso de tags semânticas permite estilizar diretamente elementos sem medo de adicionar ou remover estilos de outra coisa. Além disso, se você precisar analisar o HTML usando um raspador ou algo parecido, certamente apreciará o HTML bem formado e semântico, pois fica mais fácil escrever consultas XPath e DOM para encontrar o que você precisa.

Devo observar que as classes não substituem diretamente as tags semânticas. Eu tenho classes reutilizáveis [error, information, warning]que transmitem significados diferentes e, portanto, estilos com base na tag à qual estão anexados.

Porque pode ser útil ou necessário para rastreadores e serviços da Web (computadores AKA se comunicando com computadores). Se você escrever:

<span class="time">Sep 16 at 2:17</span>

... o rastreador da Web não será necessário entendê-lo como uma data, um material de hora. Ou será muito mais difícil localizá-lo como uma informação de data.

Se você usar:

 <time datetime="2012-02-11 16:24:02">feb 11 2012 at 16:24:02</time>

... será muito mais fácil para qualquer rastreador encontrar e analisar as coisas.

Quando digo rastreadores, não me refiro necessariamente aos mecanismos de pesquisa :)

Eu administro uma pequena empresa de consultoria na Web, e nossa abordagem atual é não usar as novas tags HTML5 porque estamos tentando equilibrar muitos fatores. Nesse caso, o equilíbrio está entre usabilidade, usabilidade e SEO:

• SEO: O que outras respostas disseram aqui - isso pode ajudar um pouco o SEO, embora, com base na minha experiência, quanto mais óbvia seja uma estratégia de SEO, menor a probabilidade de ajudar.

• Usabilidade nº 1: é razoável supor que as tags HTML5 conferem algum tipo de vantagem na usabilidade. Para usuários cegos, é certo que qualquer recurso que o navegador acessível fornecer a eles será melhor do que qualquer coisa que eu possa fornecer. Para o usuário típico, é muito mais discutível. Talvez o uso de um reprodutor de mídia não esfoliado fornecido pelo navegador seja mais fácil do que o widget menos familiar que eu colocaria lá. Ou talvez o padrão do seu navegador seja uma porcaria (como a maneira como o MP3 player padrão do Windows Chrome para de funcionar periodicamente).

• Usabilidade # 2: IE antigo. O IE antigo requer vários shims HTML5 que incham a página para que qualquer uma dessas tags funcione. Você precisa adicionar algum script às tags de cabeçalho que chama CreateElement () em um loop em todas as tags HTML5 que você está usando. Se você não vai vasculhar cada página pelas tags que você usa, isso significa todas as tags HTML5. Isso precisa ser executado em todas as páginas, em linha, o que significa que não há armazenamento em cache. E más notícias: o IE antigo é o mais lento para executar o Javascript, por isso cria uma pequena guinada enquanto carrega. Em seguida, você deve se familiarizar com vários Javascript e CSS antigos apenas no IE, e frequentemente em Flash, para tornar todos os elementos não suportados mais recentes renderizados corretamente. Você pode detectar o recurso antes de decidir carregar o código IE antigo, mas então você ' fazendo com que usuários antigos do IE esperem até que scripts suficientes sejam carregados para detectar esse recurso antes mesmo de começar a solicitar tudo o que faz essas tags funcionarem. Você poderia detectar e enviar apenas o material antigo do IE para os usuários com esses navegadores, mas isso pode tornar o cache difícil ou impossível, dependendo da sua plataforma. Entregar código diferente para diferentes usuários também significa que o teste é mais complicado - já teve um bug de assincronia? Que tal um que só ocorre em um navegador específico? E apenas na produção? Inscreva-me. Então, você provavelmente só vai enviar esse inchaço para todos. Entregar código diferente para diferentes usuários também significa que o teste é mais complicado - já teve um bug de assincronia? Que tal um que só ocorre em um navegador específico? E apenas na produção? Inscreva-me. Então, você provavelmente só vai enviar esse inchaço para todos. Entregar código diferente para diferentes usuários também significa que o teste é mais complicado - já teve um bug de assincronia? Que tal um que só ocorre em um navegador específico? E apenas na produção? Inscreva-me. Então, você provavelmente só vai enviar esse inchaço para todos.

Até a morte do IE8, o valor dessas tags HTML5 mais recentes não é alto o suficiente para os problemas de desempenho que elas trazem. Ainda estamos para trabalhar com uma audiência em que ela está quase morta *, mas um dia.

* Nossas métricas mais recentes mostram o IE8 em 6% para o site com o menor número de visitantes do IE8 e em 24% com o maior número de visitantes do IE8. Longe, longe de morto.

A resposta curta é "Não há uma boa razão na prática". Quase todos os argumentos dados em favor da marcação "semântica" são apenas pensamentos do que poderia ou deveria acontecer, em vez de algo tangível. Por exemplo, os motores de busca são muitas vezes referidos, mas não há nenhuma evidência pública de seu cuidar a menos cerca de timeou outputou address.

Indiretamente, podemos inferir que eles não se importarão no futuro próximo. O site schema.org , por alguns dos principais mecanismos de pesquisa, favorece claramente uma abordagem específica à "marcação semântica" com base em algo completamente diferente, como microdados ( itemscopee atributos relacionados). E eles realmente fazem isso principalmente para grandes sites comerciais ou comunitários.

Usar spanou divfuncionar melhor do que as novidades do HTML5, pois as últimas não são reconhecidas pelas versões antigas do IE, mesmo para fins de estilo. Então, você precisa de alguns truques para fazê-los "funcionar", mesmo como elementos de contêiner.

No entanto, existem alguns elementos "semânticos" que têm um significado real atribuído a eles por navegadores, software auxiliar ou mecanismos de pesquisa. Usar h1para o cabeçalho principal sempre foi uma boa prática por esses motivos. A utilização labelde rótulos de campo de formulário tem um impacto real na usabilidade e acessibilidade. E assim por diante; consulte O guia pragmático do HTML: Princípios .

HTML não é apenas uma linguagem de interface do usuário, é também uma linguagem de estruturação de dados. Ele foi projetado para ajudar máquinas heterogêneas a ter uma maneira comum de identificar o tipo de informação que chega para o servidor. Daí tantas tags diferentes. As páginas HTML devem ser consideradas como estruturas de dados.