Atributos não padrão em tags HTML. Coisa boa? Coisa ruim? Seus pensamentos?


92

HTML (ou talvez apenas XHTML?) É relativamente restrito quando se trata de atributos não padrão em tags. Se eles não fazem parte das especificações, seu código é considerado não compatível.

No entanto, atributos não padrão podem ser bastante úteis para passar metadados para Javascript. Por exemplo, se um link deve mostrar um pop-up, você pode definir o nome do pop-up em um atributo:

<a href="#null" class="popup" title="See the Popup!" 
   popup_title="Title for My Popup">click me</a>

Como alternativa, você pode armazenar o título do pop-up em um elemento oculto, como um intervalo:

<style>
    .popup .title { display: none; }
</style>
<a href="#null" title="See the Popup!" class="popup">
    click me
    <span class="title">Title for My Popup</span>
</a>

No entanto, estou indeciso quanto a qual deveria ser o método preferido. O primeiro método é mais conciso e, suponho, não estraga tanto os motores de busca e leitores de tela. Por outro lado, a segunda opção torna o armazenamento de grandes quantidades de dados mais fácil e, portanto, mais versátil. Também é compatível com os padrões.

Estou curioso para saber quais são os pensamentos desta comunidade. Como você lida com uma situação como essa? A simplicidade do primeiro método supera as desvantagens potenciais (se houver)?


3
Eles são chamados de atributos "expando" - se você quiser aprender mais sobre eles.
Jason Bunting,

2
AFAIK, atributos expando são definidos em tempo de execução usando javascript. Eles não fazem parte do XHTML em si
Philippe Leybaert

Respostas:


50

Sou um grande fã da solução HTML 5 proposta ( data-atributos prefixados). Edit: Eu acrescentaria que provavelmente existem melhores exemplos para o uso de atributos personalizados. Por exemplo, dados que um aplicativo customizado usará que não têm analogia nos atributos padrão (por exemplo, customização para manipuladores de eventos com base em algo que não pode necessariamente ser expresso em um className ou id).


2
Costumo seguir essa solução agora - embora ela não seja compatível com os padrões.
Tom Ritter

1
Sempre evitei isso, pois não valida. Mas agora que penso sobre isso, empinar tudo em um atributo class = "" (como metadados jquery) não é necessariamente melhor. Há alguma desvantagem prática e real para esse método na <terra do HTML5? Basicamente - que problemas surgirão agora? Parece que não é ideal, mas não tem efeitos colaterais que eu possa imaginar.
rocketmonkeys

@Rocketmonkeys Não tenho certeza, mas acho que usar dados dentro de um atributo de classe pode forçar o navegador a tentar aplicar regras css indefinidas a um elemento, isso pode causar alguns problemas ou problemas de desempenho. Mais uma vez, não tenho certeza.
Vitim.us

@ Vitim.us, se houver um impacto no desempenho, seria insignificante. Os navegadores são muito eficientes nesse tipo de coisa; o acerto para realmente aplicar estilos seria maior. E lembre-se, as classes não são algo inventado com o propósito de definir um estilo, são apenas dados de elementos como qualquer outro atributo. Qualquer atributo pode ser usado em um seletor, portanto, se houver tal impacto no desempenho, ele se aplicaria literalmente a qualquer atributo (incluindo data-prefixado) que você adicionar ao elemento.
ausência de pálpebras

@eyelidlessness esse é um bom argumento, tenho que concordar, mesmo que eu prefira usar a estrutura de dados corretamente dentro de Javascript, encontrei alguns casos em que usar o atributo de dados é adequado. Eu evito jquery como rocketmonkeys disseram. Eu realmente preciso parar de incomodar as pessoas com as micro otimizações.
Vitim.us

27

Os atributos personalizados fornecem uma maneira conveniente de transportar dados extras para o cliente. O Dojo Toolkit está fazendo isso regularmente e foi apontado ( Desmascarando os mitos do Dojo Toolkit ) que:

Os atributos personalizados sempre foram HTML válidos, eles simplesmente não validam quando testados em um DTD. [...] A especificação HTML afirma que qualquer atributo não reconhecido deve ser ignorado pelo mecanismo de renderização HTML nos agentes do usuário e o Dojo opcionalmente aproveita isso para melhorar a facilidade de desenvolvimento.


9

Outra opção seria definir algo assim em Javascript:

<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>

Em seguida, você pode usar isso mais tarde em seu código Javascript, presumindo que seu link tenha um ID que corresponde ao ID nesta tabela de hash.

Não tem as desvantagens dos outros dois métodos: nenhum atributo fora do padrão nem a feia extensão oculta.

A desvantagem é que pode ser um pouco exagerado para coisas tão simples como o seu exemplo. Mas para cenários mais complexos, onde você tem mais dados para passar, é uma boa escolha. Especialmente considerando que os dados estão sendo passados ​​como JSON, então você pode passar objetos complexos com facilidade.

Além disso, você mantém os dados separados da formatação, o que é bom para a manutenção.

Você pode até ter algo assim (o que você realmente não pode fazer com os outros métodos):

var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};

...

<a id="poi-2" href="/poi/2/">Hatsune</a>

E como você provavelmente usa alguma linguagem de programação do lado do servidor, essa tabela hash deve ser trivial para gerar dinamicamente (apenas serialize-a para JSON e coloque-a na seção de cabeçalho da página).


4

Bem, neste caso, a solução ideal é

<a href="#" alt="" title="Title of My Pop-up">click</a>

e usando o atributo title.

Às vezes, eu quebro as especificações se realmente precisar. Mas raramente, e apenas por um bom motivo.

EDIT: Não sei por que o -1, mas eu estava apontando que às vezes você acha que precisa quebrar as especificações, quando não precisa.


4

Por que não declarar o atributo popup_title em um DTD personalizado? Isso resolve o problema da validação. Faço isso com todos os elementos, atributos e valores não padronizados e, graças a essa validação, só vejo problemas reais com meu código. Isso também torna os erros do navegador menos possíveis com esse HTML.


2

Você pode aninhar elementos de entrada ocultos DENTRO do elemento âncora

<a id="anchor_id">
  <input type="hidden" class="articleid" value="5">
  Link text here
</a>

Então você pode facilmente extrair os dados

$('#anchor_id .articleid').val()

1
Sim, mas a melhor maneira é usar: <input type="hidden" title="article_id" value="5" />. Já que a classe é algo para CSS, dando de fato um código inválido se a classe não estiver nas informações de estilo. Mesmo se JS ou CSS estiverem desativados, os dados permanecerão ocultos.
Yeti

1
@Yeti, classe não é algo para CSS nem inválido se não aparecer nos estilos. São apenas dados sobre o elemento, como qualquer outro atributo. A associação com CSS é que ele é um seletor bem suportado.
ausência de pálpebras

0

Minha solução no final foi ocultar dados adicionais na tag id separados por algum tipo de delimitador (um sublinhado é um espaço, dois é o final desse argumento), o segundo arg há um id:

<a href="#" class="article" id="Title_of_My_Pop-up__47">click</a>

Feio, e assume que você ainda não está usando a tag id para outra coisa, mas é compatível com todos os navegadores.


-1

Meu sentimento pessoal em seu exemplo é que a rota do span é mais apropriada, pois atende aos padrões da especificação XHTML. No entanto, posso ver um argumento para atributos personalizados, mas acho que eles adicionam um nível de confusão que não é necessário.


10
A rota SPAN é um uso indevido da tag, no entanto. Pode atender aos padrões de validação, mas não atende aos padrões semânticos.
ceejayoz

-1

Eu estive quebrando minha cabeça com isso também. Eu gosto da legibilidade de atributos não padrão, mas não gosto que isso vá quebrar o padrão. O exemplo de span oculto é compatível, mas não é muito legível. Que tal isso:

<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>

Aqui, o código é muito legível, por causa da notação de par chave / valor JSON. Você pode dizer que estes são metadados que pertencem ao link apenas olhando para eles. A única falha que posso ver além de sequestrar o atributo "rel" é que isso ficaria confuso para objetos complexos. Eu realmente gosto da ideia de atributos prefixados "dados-" mencionados acima. Algum navegador atual suporta isso?

Aqui está outra coisa em que pensar. Quanto impacto o código não compatível tem no SEO?


7
O atributo rel descreve o relacionamento entre a página atual e o recurso vinculado. Não é um atributo genérico "Armazene todos os dados que desejar". Então, isso é horrível.
Quentin

1
Algum navegador atual suporta isso? - O que há para apoiar? Os navegadores já podem tolerar código não compatível. Considerando que isso faz parte do novo HTML5, não há nada a temer em adicionar o atributo data da mesma forma que você adicionaria qualquer outro atributo personalizado.
Eslavo de
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.