Flash Satay: Inserindo Flash de acordo com os padrões

por Drew McLellan

Tenho trabalhado com Flash durante muitos anos e estou ligeiramente descontente com os códigos necessários para inserir uma animação em páginas web. Quando publiquei um site em XHTML, recentemente, meu descontentamento com os códigos tornaram-se maiores, enquanto eu percebia que não era válido e estava levando minhas páginas para níveis inaceitáveis. Um método mais simples de inserção de Flash era necessário.

O Método Requentado

O Flash sempre foi veio com algum método de geração de páginas HTML que contém suas animações. Inicialmente, era uma ferramenta chamada AfterShock. Desde o lançamento do Flash 4, os autores podem exportar páginas HTML com a animação pelo próprio Flash. Este código produzido pelo Flash, de fato, é o padrão que você irá encontrar em 99% dos sites que usam animações Flash.

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com / pub / shockwave / cabs / flash / swflash.cab#version=6,0,0,0" width="400" height="300" id="movie" align="">

<param name="movie" value="movie.swf">

<embed src="movie.swf" quality="high" width="400" height="300" name="movie" align="" type="application/x-shockwave-flash" pluginspace="http://www.macromedia.com/go/getflashplayer">

</object>

Como você pode ver, é um pequeno monstro. Existem duas tags principais usadas para inserir a animação, fazendo com que todos os valores sejam declarados duas vezes. O Internet Explorer e os navegadores baseados nele usam uma tag; navegadores que são baseados no Netscape usam a outra. Chamemos isto de Método Requentado.

O elemento <object> é parte da especificação do XHTML, mas é mal implementado aqui. Ele é usado pelos navegadores baseados no IE para iniciarem um executável do Player do Flash e carregar a animação especificada. O elemento <param> é seu acompanhante, oferecendo qualquer quantidade de parâmetros desejada a ser passado ao player assim que o mesmo for iniciado.

O <embed> não é parte da especificação XHTML e impedirá sua página de ser válida. Ele é usado pelo Netscape e navegadores baseados nele para a exibição de animações em Flash. Parâmetros são passados dentro do elemento com o par de atributos nome/valor.

O Elemento <embed>

O elemento <embed> foi criado pela Netscape como seus métodos de inserção de plugins e players em páginas de internet. Ele não é parte da especificação do XHTML, e mesmo que navegadores diferentes do Netscape suportem-no, ele não é complacente aos padrões, então, está fora.

Tchau tchau, <embed> ... obrigado.

O Elemento <object>

Sem o <embed> , nos sobrou o elemento <object> , então, seria prudente compreender todas as suas capacidades. A grande novidade é que todos os navegadores de uso popular suportam o elemento <object> de uma forma ou de outra.

O elemento <object> não contém atributos obrigatórios, mas muitos estão disponíveis para o uso. Abaixo estão os mais interessantes, junto com alguns destaques da especificação do W3C.

classid (URI) Este atributo deve ser usado para especificar a localização da implementação do objeto via URI. Ele deve ser usado junto ou como uma alternativa ao atributo data (ver abaixo), dependendo do tipo do objeto envolvido.

codebase (URI) Este atributo especifica a base do caminho usado para URIs relativas especificadas pelo classid, data e atributos do arquivo. Quando ausente, seu valor padrão é o URI do documento atual.

data (URI) Este atributo deve ser usado para especificar a localização dos dados do objeto, ou generalizando, uma forma serial do objeto que pode ser usada para recriá-lo.

type (content-type) Este atributo especifica o tipo de conteúdo dos dados especificados no atributo data.

codetype (content-type) Este atributo especifica o tipo de conteúdo dos dados esperados quando baixamos o objeto especificado pelo classid.

Existem outros atributos que permitem fazer referências para a versão do arquivo, texto para ser exibido enquanto carregando (nós já podemos fazer isto pelo Flash), e assim por diante, como width , height , id , class e outros atributos comuns. Os listados acima são particularmente relevantes quando se está inserindo uma animação de Flash.

Outra coisa interessante que aprendi é que uma tag <object> pode conter elementos filhos que podem ser usados como alternativas se o navegador não possuir capacidade de exibir o objeto. De fato, é como o desagradável <embed> trabalha em navegadores Netscape - mas voltaremos nisso mais tarde.

O Processo

Armado com uma compreensão maior da codificação, comecei a testar em vários navegadores. Meu primeiro passo foi tentar a codificação da Macromedia com o <embed> removido e um XHTML limpo:

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com / pub / shockwave / cabs / flash / swflash.cab#version=6,0,0,0" width="400" height="300">

<param name="movie" value="movie.swf" />

</object>

Infelizmente, este formato simples não funciona em navegadores não-baseados no IE. Depois de uma pequena acrobacia e algumas pesquisas no Google, descobri que o GUID usado no atributo classid era específico para a configuração ActiveX do navegador. Na verdade, isto estava fazendo com que o Netscape 7 e o Mozilla ignorassem completamente o arquivo. O atributo classid desempenha, de qualquer forma, uma função importante: diz ao navegador qual plugin utilizar. Então não podemos simplesmente removê-lo sem substituir sua função com alguma outra coisa.

Felizmente, o plugin do Flash está configurado para responder a conteúdos com o tipo MIME definidos para application/x-shockwave-flash . Isto é ótimo, porque o atributo type nos permite especificar um tipo de conteúdo. Portanto, sai:

classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

... e entra:

type="application/x-shockwave-flash"

Codebase

A mudança acima por si só não faz com que as animações funcionem em navegadores Netscape. A próxima curiosidade da lista é o atributo codebase . Ele contém um caminho para uma cópia do plugin do Flash nos servidores da Macromedia. Isto é na verdade um uso incorreto do atributo, já que qualquer caminho dentro dele deveria estar no próprio domínio - por motivos de segurança.

Em muitos navegadores (principalmente no IE) este atributo desempenha outra função. O caminho contém uma especificação no fim que especifica qual versão do plugin o servidor deve enviar. Se a versão declarada for superior à versão atualmente instalada, o navegador pedirá ao usuário permissão para atualização. O lado ruim é que este atributo impede a animação de funcionar no Netscape e Mozilla quando utilizado desta forma, então ele deve sair. Discutiremos uma saída para esta funcionalidade mais a frente. Com o atributo codebase fora, nossa codificação está começando a ficar mais agradável:

<object type="application/x-shockwave-flash" width="400" height="300">

<param name="movie" value="movie.swf" />

</object>

Tente este código, e ele ainda não carregará a animação no Netscape. Chegando tão longe, achei que não existissem formas de usar uma codificação válida para colocar Flash em navegadores Netscape, e todas as respostas online para esta pergunta me disseram a mesma coisa. Então fiz o que eu sempre faço e comecei a testar coisas loucas.

Tendo Progresso

Quando tentei o atributo data, eu quase pulei de alegria, pois as animações repentinamente começaram a funcionar no Netscape e Mozilla. Retornando ao IE revelou que as animações funcionaram lá também.

<object type="application/x-shockwave-flash" data="movie.swf" width="400" height="300">

<param name="movie" value="movie.swf" />

</object>

Após testar com algumas animações pesadas, percebi algo estranho. Enquanto todos os navegadores estavam funcionando normalmente, IE/Windows não estava rodando - ele esperava pelo carregamento completo da animação antes de começar a apresentá-la. Isto é bom para animações pequenas, mas para algo sério, a perda da auto-reprodução é inaceitável. Percebi que era possível uma codificação válida para animações em Flash, mas somente quando a Microsoft tiver corrigido este problema com o IE/Windows.

O Método Satay

Alguns dias depois eu estava discutindo o ocorrido com Jeffrey Zeldman, expliquei como cheguei perto de uma solução mas não a encontrei. Ele ficou interessado por eu ter chegado perto, tendo experimentado o problema ele mesmo em projetos recentes. Isto me fez pensar, e enquanto dirigia de volta para casa, me veio a solução.

O único problema com o código que tinha era que o IE/Windows não auto-iniciava a animação. Ele aguarda o carregamento de toda a animação para iniciá-la. Isto é ótimo para animações bem pequenas, já que a espera não é perceptível. Então, que tal criar uma animação bem pequena como recipiente, na qual em seu primeiro frame carregue a animação que nós realmente queremos exibir?

Eu testei a possibilidade, e funcionou. É meio que um "hack", mas válido e justificável em minha opinião. A melhor coisa é que você não tem que criar uma "animação recipiente" para cada animação "verdadeira" - um pequeno recipiente pode funcionar com qualquer animação de Flash tendo as mesmas proporções.

Não importa se sua animação é feita de bife, carne de frango, ou carne de porco, você ainda precisa batê-lo e mergulhá-lo no molho para fazê-la funcionar. Nós chamamos isto de Método Satay.

A Animação Recipiente

Eu criei uma nova animação em Flash e inseri o seguinte ActionScript no Frame 1 diretamente na raíz da animação:

_root.loadMovie(_root.path,0);

Isto instrui o Flash-player a carregar uma animação, cujo nome está na variável path na raíz, no Nível 0 da animação atual. Tudo o precisamos é nos certificarmos de que o nome da animação que desejamos carregar está na variável path.

O Flash torna esta parte fácil. O player carrega qualquer nome/valor que seja passado para uma animação de Flash em uma variável na raíz da animação. Isto é útil para diversas aplicações, mas em nosso caso significa que precisamos apenas chamar a animação desta forma:

c.swf?path=movie.swf

A animação recipiente é c.swf . Estou passando para ela uma variável chamada path com o valor de movie.swf . Isto significa que nosso ActionScript, quando processado, se tornará isto:

_root.loadMovie("movie.swf",0);

Você pode modificar o comportamento da animação recipiente para fazer qualquer coisa que você deseje - desde que continue pequena. Você pode utilizar o método GET ou POST para passar as variáveis para o recipiente caso você necessite, por exemplo. No entanto, este método só funcionará bem se o recipiente possuir um tamanho de alguns Kb.

A Codificação

Isto nos deixa somente com a codificação para finalizar. Nós sumimos com diversos atributos, adicionamos alguns novos e remodelamos tudo:

<object type="application/x-shockwave-flash" data="c.swf?path=movie.swf" width="400" height="300">

<param name="movie" value="c.swf?path=movie.swf" />

</object>

Então aí está - simples, limpo e muito melhor para a interpretação. Mas e quanto à funcionalidade que perdemos ao remover o atributo codebase?

Compensando

O principal problema com a remoção do atributo codebase é que no IE e navegadores similares ele não informará mais sobre atualização do Flash Player. Isto é realmente útil, porque é, de fato, a única forma que a maioria dos usuários têm de manter seus players atualizados.

O trabalho é simples: apenas inclua uma sacrificante animação na página inicial do seu site com o atributo codebase incluso nela. Precisa ser uma animação sem nenhum propósito com o site - apenas uma animação em branco de 1Kb que avise o usuário caso ele tenha uma versão antiga do plugin. Não é uma solução limpa, mas é prática. Você não deve perder nenhum amigo com isso.

Conteúdo Alternativo

Lembra do comportamento da tag <object> que eu estava comentando antes, onde o navegador tentará executar um elemento filho se não conseguir funcionar pelo próprio objeto? É muito legal.

Se você olhasse o código fonte da página inicial da Macromedia.com, você veria que eles inserem uma imagem alternativa se o usuário não puder visualizar as animações em Flash. Eles detectam o Flash Player com JavaScript, e então usam JavaScript para escrever o HTML dinamicamente baseado na detecção. Feio, feio, feio. Eu faria assim:

<object type="application/x-shockwave-flash data="c.swf?path=movie.swf" width="400" height="300">

<param name="movie" value="c.swf?path=movie.swf" />

<img src="noflash.gif" width="200" height="100" alt="" />

</object>

Se o navegador não sabe como executar objetos com o tipo MIME de application/x-shockwave-flash , ele simplesmente irá para o próximo elemento filho e tentará executá-lo. Eu imagino que uma simples imagem deve estar de bom tamanho para a maioria das pessoas. Se ainda não funcionar, você pode simplesmente usar um texto.

Trabalho em progresso

Eu escrevi este artigo como um simples homem em busca do conhecimento, e dessa forma, um trabalho em progresso. Considere-o como uma teoria científica: o que eu digo hoje só é verdadeiro até que seja desmentido.

-----

Este artigo foi publicado originalmente na edição 154 da A List Apart e pode ser acessado aqui.

Traduzido por Rafael Cesar.