Resumo
- Em 25 de fevereiro de 1993, Marc Andreessen propôs o elemento opcional
IMG, comSRCobrigatório para buscar um bitmap ou pixmap e exibi-lo no ponto correspondente do documento. - A imagem podia aparecer sem ser um link. Quando o autor quisesse torná-la clicável, um elemento
Apoderia envolvê-la e definir outro destino. HTML 2.0 preservou essa composição e descreveuALTcomo alternativa textual.
A proposta de Marc Andreessen não tratava de inventar imagens na tela. Ela respondia a uma pergunta de estrutura: como um documento HTML poderia colocar uma imagem em meio ao texto sem fazer com que o endereço do arquivo fosse automaticamente o destino da navegação? Em 25 de fevereiro de 1993, Andreessen enviou à lista WWW-TALK uma resposta direta: criar um elemento IMG separado.
O elemento seria opcional e exigiria SRC="url". O navegador tentaria recuperar pela rede o bitmap ou pixmap indicado e exibi-lo onde a marcação aparecesse. Não haveria uma tag de fechamento. Assim, o documento poderia referenciar uma imagem como parte de sua apresentação sem declarar que o próprio arquivo era um link.
Para tornar a imagem clicável, haveria uma segunda camada. Andreessen explicou que IMG poderia ficar dentro de uma âncora. Nesse caso, a imagem responderia à ativação como um texto vinculado. Fora da âncora, IMG apenas mostraria a imagem. O autor podia inserir um elemento visual no documento e, separadamente, decidir se ele levaria a algum lugar.
No dia seguinte, Jim Davis perguntou por que o atributo se chamava SRC, em vez de HREF, e sugeriu que o elemento talvez indicasse também o tipo do conteúdo. Andreessen respondeu que não queria dar a HREF um significado adicional. A âncora já representava um destino de navegação; SRC indicaria o recurso a recuperar para exibição. Em <A HREF="destino"><IMG SRC="imagem"></A>, cada atributo teria seu papel.
A escolha permitia composições úteis. A mesma ilustração podia aparecer sem interação, apontar para uma explicação ou ser reutilizada em páginas com destinos diferentes. Alterar para onde o leitor seria levado não exigia mudar o arquivo da imagem. E colocar uma imagem no fluxo do documento não obrigava a transformar seu endereço de origem em destino.
Nem todos viam uma etiqueta exclusiva para imagens como o modelo definitivo. Em 1º de março, Dave Raggett defendeu que se considerasse um tratamento mais geral para mídia externa, com tipos MIME e negociação de formatos. Em março, Guido van Rossum discutiu o alcance de mecanismos como INCLUDE e EMBED, inclusive o risco de um documento incorporado incluir outros em cadeia. Um modelo genérico serviria a mais tipos de conteúdo, mas exigiria decisões sobre tipos, apresentação, recursão e comportamento em navegadores que não reconhecessem um formato. As mensagens preservam um debate; não apontam uma única intervenção que tenha encerrado a questão.
A proposta também deixava parte da interoperabilidade nas mãos dos navegadores. Andreessen citou XBM e XPM como formatos úteis, mas defendeu flexibilidade quanto ao que cada navegador suportaria. Se o X Mosaic não conseguisse interpretar um formato, mostraria uma imagem bitmap padrão como substituta. Ele escreveu ainda que o recurso já funcionava internamente no X Mosaic e era necessário para aquele navegador. Isso é uma afirmação atribuída sobre a implementação interna, não uma prova da data em que uma versão pública foi lançada nem da adoção por outros navegadores.
Em 1995, a discussão passou a tratar também do que deveria acontecer quando a imagem não pudesse ou não devesse ser processada. Em junho, participantes do grupo de trabalho HTML debateram quando um agente de usuário poderia apresentar o texto de ALT no lugar do recurso indicado em SRC, por limitação de processamento ou preferência do usuário. Também distinguiram entre não fornecer ALT e fornecê-lo vazio. Definir uma alternativa não garantia que autores a escrevessem de modo útil.
Publicado em novembro de 1995, o RFC 1866, que especificou HTML 2.0, formalizou IMG e os atributos SRC, ALT, ALIGN e ISMAP. SRC designava o URI do recurso gráfico; ALT fornecia texto substituto quando o recurso não fosse processado. O RFC também esclarecia que uma imagem IMG não era, por si só, uma âncora. Um gráfico essencial deveria ser referenciado por A; para um gráfico não essencial, IMG era apropriado. Ainda assim, o exemplo do documento colocava IMG dentro de A: a imagem não cria navegação sozinha, mas pode ser o conteúdo acionável de um link.
O padrão também mostra a distância entre a proposta e a prática de 1995. O email de Andreessen citava bitmaps e pixmaps e deixava a escolha dos formatos aos navegadores. O RFC dizia que GIF e JPEG eram comuns. Não acrescentou um atributo CONTENT-TYPE a IMG: o elemento nomeava um recurso e o navegador avaliava se o formato recebido era exibível. ALT existia como alternativa, mas a DTD não o tornava obrigatório.
A mudança histórica, portanto, não foi simplesmente “a Web ganhou imagens”. A proposta tornou possível endereçar uma imagem separadamente e colocá-la no documento sem fazê-la assumir o significado de um link. HTML 2.0 manteve essa composição e explicitou o limite entre exibição e navegação. As fontes sustentam essa história de projeto específica; não demonstram que IMG, sozinho, popularizou a Web, que o Mosaic foi o primeiro navegador gráfico ou que todas as implementações funcionaram da mesma forma.
Fontes
- Marc Andreessen, “proposed new tag: IMG”, 25 de fevereiro de 1993
- Jim Davis e Marc Andreessen sobre
SRC,HREFe tipo de conteúdo, 26 de fevereiro de 1993 · Resposta de Andreessen - Dave Raggett sobre tratamento geral de mídia, 1º de março de 1993 · Guido van Rossum sobre o escopo de inclusão, 13 de março de 1993
- Daniel Connolly sobre a redação de
ALT, 1º de junho de 1995 · Robert Lilley sobre texto alternativo, 2 de junho de 1995 - RFC 1866, Hypertext Markup Language — 2.0, novembro de 1995
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

