Ao veicular arquivos JavaScript, é melhor usar o método application / javascript ou application / x-javascript

95

Toda a questão se encaixa no título. E para adicionar algum contexto: não estou perguntando qual é o melhor de acordo com o que as especificações dizem, mas sim o que funciona melhor dada a mistura de navegadores implantados atualmente.

Alguns pontos de dados:

  • O Google usa text/javascriptpara o JS usado em sua página inicial.
  • O Google usa text/javascriptno Google Docs.
  • O Google usa application/x-javascriptpara servir arquivos JavaScript com seu serviço de bibliotecas Ajax .
  • O Yahoo usa application/x-javascriptpara servir seu JS.
  • O Yahoo usa application/x-javascriptpara o JavaScript servido em sua página inicial.
javascript  http  content-type 
— avernet
fonte
4
Engraçado. Você dá uma terceira alternativa em seus exemplos ... E de acordo com Tim, os dois grandes jogadores estão errados (no que diz respeito aos padrões), o que provavelmente significa apenas que os navegadores são tolerantes (sem grandes novidades aqui) e pode não importar.
— PhiLho
1
possível dupe: Javascript MIME Type
— Bergi

Respostas:

115
  • text/javascript é obsoleto
  • application/x-javascript foi experimental ao decidir mudar para ...
  • application/javascript é o tipo MIME oficial atual para JS

Dito isso, os navegadores geralmente ignoram o content-typeenviado pelo servidor e prestam muita atenção ao typeatributo (e alguns podem ainda não reconhecer application/javascript).

Minha recomendação:

  • Use o aplicativo / javascript no servidor
  • Use HTML 5 e omita o typeatributo dos elementos do script

NB: a especificação HTML contradiz o padrão MIME, e há um esforço para mudá-lo de volta para text/javascriptque isso possa mudar no futuro.

— Quentin
fonte
3
Esta pergunta de alguns meses atrás diz exatamente o oposto. Alguém está enganado :) "Kelly está certa, os navegadores tendem a confiar no tipo MIME enviado com os cabeçalhos de resposta em vez do atributo type da tag de script" stackoverflow.com/questions/189850/…
— Marco
6
Ah não! Organizações grandes, monolíticas e lentas devem estar certas! A especificação deve estar errada! Narghh. Continuarei a confiar na especificação e em minha própria experiência em empresas grandes (lentas), mesmo que uma delas me empregasse.
— Quentin
1
Hmm, alguém se esqueceu de dizer ao W3C que text / javascript está obsoleto. Parece ser o padrão em HTML 5 . :: coça a cabeça :: Também parece (se minha leitura superficial desta seção estiver correta) que os agentes do usuário devem ir apenas no typeatributo, ignorando assim o Content-typecomportamento seria correto.
— big_m
1
@big_m - Isso ocorre porque muitos navegadores não reconhecem, application/javascriptportanto, especificá-lo fará com que eles ignorem o script. Os agentes de usuário não devem ignorar o Content-Type. O atributo type diz a eles o que esperar. Se eles não apoiarem, não devem se preocupar em solicitá-lo. Se o servidor disser que é algo diferente, eles devem continuar assim ao invés do que o HTML diz (pelo menos de acordo com o HTTP, você pode estar olhando para uma especificação diferente, você não forneceu nenhum link).
— Quentin de
1
@Quentin, eu estava me referindo à seção HTML 5 sobre o scriptelemento, ao qual criei um link . Minha leitura dessa seção é diferente do que você descreve; parece dar muita importância ao typeatributo e não faz menção à verificação de Content-Type, exceto para determinar a codificação de caracteres. Concordo que parece que seria sábio para o agente do usuário verificar se o Content-Type corresponde ao que é esperado, mas não encontrei nada na especificação HTML que requeira ou mesmo recomende fazer isso.
— big_m
7

Se você escolher usar application / javascript para js em suas páginas, o IE7 e o IE8 não executarão seu script! Culpe a Microsoft o quanto quiser, mas se quiser que a maioria das pessoas execute suas páginas, use text / javascript.

— Drew B
fonte
3
Quando você diz que "application / javascript" não funcionará, você quer dizer se isso é definido como o tipo de conteúdo na resposta HTTP ou como o atributo "type" de uma tag de script? A pergunta original era sobre o tipo de conteúdo nas respostas HTTP. Com base em outras respostas, parece que apenas o valor do atributo "type" nas tags de script fará diferença de qualquer maneira no IE.
— Jesse Hallett
7

Costumava ser language="javacript". Em seguida, mudou para type="text/javascript". Agora sim type="application/javacript". Ok, isso está ficando estúpido. Alguns dos navegadores mais antigos não reconhecem o novo application/javascript, mas ainda reconhecem o mais antigo text/javascript. Pretendo continuar usando isso, ou então vou perder horas do meu tempo tentando mudar CADA instância de text/javascriptem application/javascript.
Agora, algum dia, o oposto pode ser verdade. Algum dia, os navegadores mais recentes podem rejeitar a técnica antiga para serem estritamente compatíveis com os padrões.
Mas até que as pessoas que visitam meu site comecem a reclamar que "desde a atualização do meu navegador, cerca de 50% do seu site desapareceu", não tenho motivo para alterar o código do meu site.

— Sandip Armal Patil
fonte
7

Aqui está a resposta de 2020 para essa pergunta.

text/javascripté o tipo MIME JavaScript correto de acordo com o padrão HTML , que afirma:

Os servidores devem usar text/javascriptpara recursos JavaScript. Os servidores não devem usar outros tipos MIME JavaScript para recursos JavaScript e não devem usar tipos MIME não JavaScript.

E também :

[…] O tipo MIME usado para se referir ao JavaScript nesta especificação é text/javascript, visto que é o tipo mais comumente usado, apesar de ser um tipo oficialmente obsoleto de acordo com a RFC 4329.

O trabalho está em andamento para refletir essa realidade em uma RFC no nível da IETF: https://datatracker.ietf.org/doc/draft-ietf-dispatch-javascript-mjs/

Qualquer afirmação de que " text/javascripté o obsoleto" diz isso com base na RFC 4329, que tanto o padrão HTML quanto o rascunho da IETF acima mencionado (ou seja, uma próxima RFC) estão corrigindo explicitamente.

— Mathias Bynens
fonte
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.