Complemente a Tela com Marcação HTML, Parte 1: Combine a API de tela e o modelo HTML/CSS

Os híbridos que oferecem o melhor dos dois mundos

A tela HTML é excelente em vários aspectos, inclusive o ótimo desempenho proporcionado pela baixa sobrecarga e pela manipulação direta dos pixels. Entretanto, a tela é deficiente em algumas áreas em que o HTML vai muito bem: renderização de texto, SEO, acessibilidade e marcação independente do dispositivo. Este artigo compara e contrasta os pontos fortes do modelo HTML tradicional e da API de tela. Explore a ideia de um aplicativo híbrido HTML/tela que usa os melhores aspectos dos dois mundos. Você também revisará diversas técnicas para sobrepor elementos HTML sobre um elemento de tela.

Kevin Moot, Software Developer, The Nerdery

Photo of Kevin MootKevin Moot se interessa por computação gráfica desde criança, quando criava jogos com seu Apple IIe (com a sua ampla variedade de seis cores e a impressionante resolução de 280x192). Trabalha com a tecnologia de tela do HTML5 para vários websites de ponta e é especializado em HTML/CSS, JavaScript e .NET. Atualmente, Kevin é desenvolvedor de software interativo na empresa The Nerdery.



Ryan DeLuca, Software developer, The Nerdery

Photo of Ryan DeLucaRyan DeLuca começou a programar em 1998 e, depois de alguns anos, transformou seu hobby em uma carreira profissional de freelancer. Decidiu formalizar a sua formação e obteve seu bacharelado em 2011 pela Universidade de Wisconsin-Superior. Logo depois da formatura, Ryan passou a fazer parte da The Nerdery como engenheiro de software especializado em PHP, JavaScript, CSS e HTML. Seus vários talentos também envolvem bancos de dados relacionais/SQL e manipulação de gráficos.



25/Set/2012

Introdução

Na Parte 1 desta série em duas partes, saiba mais sobre a criação de aplicativos que combinam as vantagens da API de tela e do modelo HTML/CSS. A API de tela pode ser uma ótima opção para aplicativos da web que exigem gráficos de alto desempenho e baixa sobrecarga. No entanto, pode ter deficiências quando se trata de arquitetar um aplicativo inteiro com base na tela, sem levar em conta a utilidade do modelo HTML/CSS tradicional. Em vez de não dar valor a ele, saiba como aproveitar os muitos aspectos úteis do HTML/CSS que são difíceis (ou até mesmo impossíveis) de obter na tela.

Abreviações usadas frequentemente

  • API: Interface de programação de aplicativos
  • CSS: Folhas de estilo em cascata
  • HTML: linguagem de marcação de Hipertexto
  • UI: Interface com o usuário

Este artigo examina uma abordagem "híbrida" para projetar aplicativos que utilizam componentes tradicionais de HTML juntamente com elementos de tela. As motivações dessa abordagem serão discutidas — explicaremos inclusive por que uma implementação baseada somente em tela está longe de ser ideal e examinaremos os pontos fortes e fracos do modelo HTML tradicional comparado com a API de tela. Os vários exemplos também ajudam a planejar o layout e a interação entre os elementos de HTML e tela ao projetar o seu aplicativo.

É possível fazer o download do código-fonte dos exemplos usados neste artigo.


Pontos fortes do modelo HTML e CSS

O modelo da web tradicional, que usa HTML e CSS, é excelente em vários cenários. Esta seção revisa os benefícios mais úteis do modelo HTML que não tem um bom suporte (ou simplesmente não são suportados) na API de tela — especificamente, seu robusto suporte de texto e os benefícios associados a uma marcação HTML significativa do ponto de vista semântico.

Suporte de texto robusto do HTML

Um dos pontos fortes importantes do HTML é a sua capacidade de anotar texto facilmente com indicações de estilização, de tags de formatação como <b></b> a regras de CSS como font-weight:bold.

A API de tela, por outro lado, expõe um método fillText() que renderiza uma sequência de texto como um bitmap. É uma chamada simples e de baixo nível, com muitas limitações. Uma das maiores limitações é que somente uma regra de estilo uniforme pode ser aplicada à sequência de texto fornecida a fillText(). Nesse contexto, uma "regra de estilo" pode ser considerada como uma regra única que define o tipo de fonte, tamanho, cor, etc. (semelhante a uma regra de CSS).

Texto com estilo uniforme

Considere o texto na Figura 1.

Figura 1. Texto de amostra
Texto de amostra

Como todo o texto segue uma regra de estilo uniforme — fonte Arial vermelha em itálico — é possível renderizar esse texto facilmente, com a mesma qualidade, usando HTML/CSS ou tela.

O código das Listagens 1 e 2 compara como renderizar esse texto usando HTML, CSS e canvas. Consulte Recursos para ver um exemplo funcional.

A Listagem 1 mostra o texto da Figura 1 renderizado em HTML e CSS.

Listagem 1. Renderizando texto com um estilo uniforme em HTML e CSS
<style>
    .uniform-style {
        font: italic 12px Arial;
        color: red;
    }   
</style>
<span class="uniform-style">
    Variety is the spice of life!
</span>

A Listagem 2 mostra o mesmo texto renderizado usando a tela

Listagem 2. Renderizando texto com um estilo uniforme na tela
var canvas = document.getElementById('my_canvas');
var context = canvas.getContext('2d');

context.font = 'italic 12px Arial';
context.fillStyle = 'red';
context.fillText('Variety is the spice of life!', 0, 50);

Texto com estilo dinâmico

Considere o texto na Figura 2.

Figura 2. Texto com estilo dinâmico
Texto com estilo dinâmico

A Listagem 3 ilustra as regras de CSS necessárias para renderizar esse texto

Listagem 3. Renderizando texto com um estilo dinâmico em HTML e CSS
<style>
    .dynamic-style {
        font: 12px Arial;
        color: blue;
    }
    .dynamic-style strong {
        font-size : 18px;
        color: green;
    }    
    .dynamic-style em {
        color: red;
        font-weight: bold;
        font-style: italic;
    }    
</style>
<span class="dynamic-style">
    <strong>Variety</strong> is the <em>spice of life</em>!
</span>

Já que não existe o conceito de tags HTML ou classes de CSS na API de tela — que permitiriam anotar o uso de estilos de fontes diferentes — renderizar o mesmo bloco de texto do exemplo anterior é algo muito mais complexo.

Já que a API de tela funciona como uma máquina de estado sequencial, a reprodução do efeito na Figura 2 exige algo que poderia ser descrito como uma abordagem semelhante à de uma máquina de escrever. É necessário selecionar um estilo a ser utilizado, digitar a parte do texto que deve usar esse estilo, selecionar um estilo diferente para usar, digitar a parte seguinte, etc.

De modo geral, é possível fazer isso usando o algoritmo a seguir:

  1. Configurar o estilo a ser usado na parte seguinte do texto (Arial de 18px, verde).
  2. Renderizar a parte seguinte do texto na tela (Variety).
  3. Mover um certo número de pixels para a direita (60).
  4. Repetir as etapas de 1 a 3 em cada parte do texto.

A Listagem 4 mostra a implementação mais básica e ingênua desse algoritmo.

Listagem 4. Renderizando texto com estilo dinâmico na tela
context.font = '18px Arial';
context.fillStyle = 'green';
context.fillText('Variety', 0, 50);
context.translate(60, 0);  //move 60 pixels to the right (a)

context.font = '12px Arial';
context.fillStyle = 'blue';
context.fillText('is the', 0, 50);
context.translate(35, 0); //move 35 pixels to the right (b)

context.font = 'italic bold 12px Arial';
context.fillStyle = 'red';
context.fillText('spice of life!', 0, 50); // (c)

A Figura 3 mostra como os três blocos de texto separados aparecerão conforme forem renderizados em sequência.

Figura 3. Renderização de texto na tela
Renderização de texto na tela

Mais adiante neste artigo, você verá como melhorar essa abordagem incluindo outra camada de abstração sobre a função fillText() da tela nativa. Independentemente da abordagem, o algoritmo de máquina de escrever continua sendo a parte principal.

Deve-se ressaltar que a maioria dos estilos de texto que supomos que existem no HTML/CSS — como quebra automática de linha, espaçamento das letras e altura da linha — não é suportada de forma nativa na API de tela. Se for preciso, você pode ter que modificar o algoritmo e implementar as funções por conta própria.

A esta altura, você já deve saber por que a renderização de texto não é um problema banal para a API de tela e por que o modelo HTML tradicional prevalece quando se trata de formatar texto com o mínimo de esforço.


Semântica significativa do HTML

Uma estrutura de HTML significativa e semanticamente correta é fundamental para um bom design da web. A marcação HTML escrita com uma estrutura adequada e com significado proporciona vários benefícios.

No fundo, a tela é simplesmente uma plotadora de gráficos — portanto, o conceito de marcação significativa não existe, e os benefícios da marcação HTML com significado basicamente desaparecem nos aplicativos escritos somente para a tela. Por exemplo, do ponto de vista dos mecanismos de procura e usuários com comprometimento visual, um elemento de tela aparece basicamente como uma caixa preta vazia.

A seguir, examinaremos vários benefícios oferecidos pela marcação HTML com significado.

Conhecimento dos mecanismos de procura

Os mecanismos de procura criam seus índices de procura com base nas informações lidas por bots/spiders automatizados de procura— quando um spider de procura acessa a sua página da web, ele analisa o HTML para extrair o máximo possível de informações significativas.

Já que, no fim das contas, o texto renderizado programaticamente na tela é simplesmente um bitmap, o texto será completamente ignorado pelos spiders de procura. Portanto, é importante entender que, se o seu aplicativo for desenvolvido exclusivamente na tela, os spiders de procura poderão obter poucas informações contextuais da sua página.

Mesmo assim, os mecanismos de procura conseguem ler qualquer texto de fallback dentro de um elemento <canvas> destinado a navegadores incompatíveis com o HTML5, como na Listagem 5.

Listagem 5. Texto de fallback dentro de um elemento de tela
<canvas>
   We are sorry, your browser doesn't support HTML5!
</canvas>

Esse problema não é novidade para a tela — historicamente, a falta de conhecimento dos mecanismos de procura é um problema enfrentado por aplicativos escritos para plug-ins de navegador, como Flash e Silverlight.

Acessibilidade

Os usuários com comprometimento de visão usam ferramentas que convertem texto para fala (leitores de tela) para ler o conteúdo das páginas da web. A marcação HTML estruturada possibilita que as ferramentas de leitura de tela entendam a diferença entre um cabeçalho, um rodapé, uma lista, etc. Os aplicativos que não produzem marcação HTML, como aplicativos baseados em tela, não deixam vestígios de conteúdo que possam ser reconhecidos pelos leitores de tela.

O HTML bem estruturado também permite que os usuários usem atalhos de teclado padrão para navegar na página. Por exemplo, a tecla TAB coloca o link seguinte da página em foco, como na Figura 4.

Figura 4. Usando a tecla TAB para colocar um link da página em foco
Usando a tecla TAB para colocar um link da página em foco

Até mesmo os plug-ins de navegador como o Flash e o Silverlight fizeram grandes avanços em termos de acessibilidade suportando atalhos de teclado usados normalmente. Infelizmente, a tela não fornece nenhuma conformidade integrada para acessibilidade.

Dispositivos a agentes do usuário

Em última análise, cabe ao agente do usuário decidir como a página será renderizada. Alguns dispositivos podem interpretar a mesma marcação HTML de forma diferente dos outros. Por exemplo, na maioria dos dispositivos móveis, o toque em um elemento <input type="text"> faz com que o dispositivo exiba um teclado na tela para o usuário inserir uma entrada. Os navegadores compatíveis com a especificação HTML5 fornecem uma variedade ainda mais ampla de tipos de entrada, como email, website, número de telefone, data, etc.

A Figura 5 mostra como um elemento <input type="date"> aparece em um dispositivo iOS. O navegador exibe automaticamente um selecionador de data com todos os recursos; não há necessidade de código adicional para implementar o selecionador, além da definição do tipo do elemento de entrada como date.

Figura 5. Tratamento de <input type="date"> no iPhone
Tratamento de <input type=

Ao escrever HTML, semanticamente correto, basicamente você estabelece um contrato com os agentes do usuário, confiando que ele tem capacidade de apresentar o conteúdo da melhor maneira para os usuários do dispositivo específico.

Por outro lado, todo o conteúdo renderizado em um elemento de tela é exibido de forma consistente em todos os dispositivos. Você está quebrando o acordo com o usuário; você não confia mais que o dispositivo sabe qual é a melhor forma de apresentar o conteúdo.

Conhecimento dos hiperlinks

Os hiperlinks são os elementos básicos da web — é difícil imaginar o mundo sem eles. Além de permitir que os usuários naveguem pelos links, os agentes do usuário modernos fornecem a ele vários recursos contextuais adicionais: abrir páginas em uma nova guia, copiar endereços de link, links de email, etc.

Embora seja possível renderizar texto em uma tela, o conceito de hiperlinks tecnicamente não existe.

Mesmo se você se encarregasse de simular um hiperlink renderizando um texto azul sublinhado, o agente do usuário não saberá que se trata de um hiperlink verdadeiro e não poderá oferecer informações contextuais úteis para o usuário.


Pontos fortes da API de tela

Considerando os pontos fortes do HTML, situação dos aplicativos escritos para tela não é boa. Entretanto, arquitetar as soluções com base na tela oferece vários benefícios. As principais vantagens residem no alto desempenho gráfico da tela e no potencial para consistência em vários dispositivos.

Desempenho gráfico

Há certas tarefas que o HTML e a tela podem realizar — como renderizar imagens, texto e animações.

Já que a tela não tem a sobrecarga associada à análise de HTML e à manutenção de um modelo de documento hierárquico, essas tarefas têm um desempenho invariavelmente mais rápido quando são executadas na tela.

Em aplicativos centrados no HTML, as ações de incluir, remover ou atualizar um nó são os fatores que mais atrapalham o desempenho. Essas atualizações do modelo de documento frequentemente forçam o navegador a repintar ou refazer o fluxo da página inteira — algo que pode exigir muito do computador. A realização de atualizações no modelo de documento muitas vezes por segundo — que é necessária em um aplicativo em tempo real — pode deixar o navegador muito lento.

Quando a velocidade é muito importante, a mudanças de uma arquitetura centrada em HTML para uma arquitetura centrada na tela pode ser o "santo graal" para obter um desempenho máximo. O custo do alto nível de desempenho é lidar com uma API de baixo nível e não com uma linguagem de marcação robusta, como o HTML, e com a flexibilidade do CSS.

Consistência em vários dispositivos

A aparência consistente em várias plataformas sempre foi uma dificuldade para o modelo HTML/CSS tradicional devido às variações nos mecanismos de layout do navegador. Embora seja possível fazer com que as páginas da web tenham uma aparência muito semelhante em várias plataformas, é difícil obter um nível de design consistente "perfeito em cada pixel".

Esses problemas são eliminados quando os gráficos são plotados em uma tela. A tela permite um grau de controle no nível do pixel sobre a aparência dos gráficos e do texto e garante que a saída seja 100% consistente em todas as plataformas.


Lógica dos híbridos de tela/HTML

Ao criar um aplicativo orientado à tela, é possível utilizar recursos do modelo HTML/CSS tradicional para superar as limitações da tela.

Como já foi mencionado, uma das maiores limitações da tela é a dificuldade de implementar componentes de UI robustos e acessíveis. Ao decidir sobre a melhor abordagem para implementar uma UI, a avaliação dos requisitos dos elementos da UI pode ser um exercício útil. Estes são alguns critérios a serem considerados:

  • Qual é o conteúdo desejado do elemento de UI?
  • Com que frequência é necessário atualizar esse conteúdo?
  • Qual é o nível desejado de interatividade, se houver?

Um requisito de peso em qualquer uma dessas áreas pode indicar que uma implementação é melhor do que a outra. Por exemplo, se o conteúdo desejado é simplesmente a exibição textual de algum aspecto do aplicativo, um elemento HTML básico provavelmente é mais eficiente e não causaria perda de desempenho. No entanto, se você quisesse que o elemento fosse animado ou rico em conteúdo atualizado com frequência, o uso da tela pode ser uma abordagem melhor. Se a facilidade de interação é necessária, normalmente os elementos HTML fornecem a abordagem mais natural, principalmente em comparação com as funções fornecidas por bibliotecas como o jQuery.

A seguir, examinaremos várias situações que são adequadas para uma implementação híbrida de tela/HTML.

Protótipos rápidos

A criação de um protótipo rápido pode ser muito mais rápida com o HTML e o CSS do que com a tela. Pense, por exemplo, em um aplicativo que tem um menu. Como a estrutura HTML/CSS é adequada para os menus e é possível aproveitar várias bibliotecas já existentes, como plug-ins de jQuery, o esforço necessário para implementar um menu em HTML é pequeno, comparado à implementação equivalente na tela. A redução de desempenho associada aos elementos HTML não é um problema importante para o protótipo porque ele é uma prova de conceito, não um sistema totalmente otimizado.

Os aspectos do protótipo que usam HTML e CSS podem ser implementados mais tarde na tela, quando o aplicativo estiver totalmente desenvolvido. No caso do exemplo de menu, a conversão do menu para a tela no produto final irá melhorar bastante o desempenho, porque você remove as dependências do modelo de documento do navegador.

Ferramentas de desenvolvimento

As ferramentas de desenvolvimento podem ser uma opção natural para HTML e CSS por causa da facilidade do uso da marcação HTML para exibir uma grande quantidade de informações. A inclusão de um console no aplicativo para fins de depuração seria um exemplo disso. O console de depuração pode exibir estatísticas como quadros por segundo, uma lista de todos os objetos do aplicativo e suas coordenadas, etc.

Novamente, a redução do desempenho provocada pela introdução de elementos HTML não é um grande problema nesse caso porque as ferramentas se destinam somente a desenvolvedores e nunca serão exibidas para o usuário final.

Sobreposições da interface com o usuário

Se a aplicativo requer uma UI rica que combina texto com elementos de formulário, como caixas de seleção e menus suspensos, o HTML é uma solução natural. A reprodução desses tipos de componentes na tela pode ser muito demorada e o aplicativo provavelmente terá problemas de acessibilidade.

Por outro lado, os pontos fortes do HTML podem fornecer uma experiência rica ao usuário. Por exemplo, uma coleção de componentes de UI baseados em HTML pode constituir uma exibição superior que flutua sobre a área da tela.

Para minimizar o impacto do desempenho em tempo real do aplicativo, lembre-se de alterar o modelo de documento o mínimo possível (atualizações, inserções e remoções de elementos). Se as atualizações de documento são frequentes, o aplicativo pode ficar muito lento.

Interfaces acompanhantes com o usuário

Quando um elemento de UI se destina a aparecer fora do componente em tempo real e interativo do aplicativo, pode haver uma grande oportunidade de usar HTML e CSS. Por exemplo, o elemento de UI pode aparecer somente durante uma sequência inicial introdutória ou quando o aplicativo é pausado.

Uma interface para carregar/salvar um jogo é outro grande exemplo de possibilidade de uso de uma UI acompanhante baseada em HTML. Já que o jogo sofre uma pausa quando o usuário está salvando-o, não há impacto no desempenho em tempo real do aplicativo. O HTML/CSS permitiria desenvolver rapidamente essa interface, obtendo todos os benefícios da marcação não estruturada.


Implementando híbridos de tela/HTML

Esta seção revisa várias abordagens básicas para combinar um elemento de tela com outros elementos HTML dentro do layout de uma página da web. Embora a lista não seja exaustiva, as abordagens descritas abaixo fornecem vários exemplos de como aproveitar melhor os pontos fortes do HTML e da tela e, ao mesmo tempo, minimizar os pontos fracos. Ao planejar a arquitetura do seu aplicativo, leve em conta qual abordagem (ou conjunto de abordagens) se adapta melhor aos seus objetivos.

Os cenários a seguir pressupõem dois componentes primários:

  • O elemento de tela, que contém principalmente o componente de gráficos e animação
  • Os elementos HTML, que contêm aspectos diferentes da UI — como menus, elementos de navegação, formulários, etc.

Realizando um elemento de tela

A tag <canvas> é considerada um elemento de nível de bloco — portanto, a abordagem mais simples para combinar elementos de HTML e tela é simplesmente a inserção de um elemento <canvas> no corpo do documento. Como o elemento será posicionado de forma relativa por padrão, não há necessidade de marcação especial ou CSS para que o elemento flua juntamente com o restante do documento.

A tela como um elemento em tela

Um elemento <canvas> pode ser posicionado de forma absoluta na página com um índice z, para que apareça em primeiro plano.

Essa abordagem é adequada para aplicativos de tela que não interagem com os outros elementos HTML encontrados na página — algo semelhante à integração de um aplicativo em Flash.

Já que a tela é o elemento do primeiro plano que fica mais acima, o elemento de tela poderá capturar todas as formas de entrada do usuário (cliques do mouse, eventos de toque, etc.).

A Figura 6 ilustra o método de posicionar uma tela como um elemento de primeiro plano posicionado de forma absoluta.

Figura 6. Dispondo um elemento de tela em camadas acima do documento
Dispondo um elemento de tela em camadas acima do documento

Clique para ver a imagem maior

Figura 6. Dispondo um elemento de tela em camadas acima do documento

Dispondo um elemento de tela em camadas acima do documento

O código da Listagem 6 demonstra o CSS necessário para posicionar o elemento como a camada mais acima no primeiro plano, usando um índice z grande.

Listagem 6. CSS que posiciona a tela como um elemento em primeiro plano
canvas {
    position: absolute;
    z-index: 100;
    bottom: 0px;
    right: 0px;
}

A tela como um elemento em segundo plano

O elemento <canvas> também pode ser usado para exibir conteúdo no segundo plano de uma página da web.

É possível usar essa abordagem para produzir cenas ricas e animadas em segundo plano sob o conteúdo HTML padrão. A cena na tela em segundo plano ficará visível nas áreas transparentes do documento.

Figura 7. Dispondo um elemento de tela em camadas abaixo do documento
Dispondo um elemento de tela em camadas abaixo do documento

Clique para ver a imagem maior

Figura 7. Dispondo um elemento de tela em camadas abaixo do documento

Dispondo um elemento de tela em camadas abaixo do documento

O código da Listagem 7 mostra como posicionar o elemento de tela como a camada mais abaixo definindo um índice z negativo.

Listagem 7. CSS para posicionar a tela como um elemento em segundo plano
canvas {
    position: absolute;
    z-index: -1;
    top: 0px;
    left: 0px;
}

Dispondo em camadas sobre a tela

Outra abordagem envolve dispor um elemento HTML ou mais em camadas acima de um elemento de tela. Como mostra a Figura 8, essa abordagem pode ser uma concorrente forte para aplicativos que requerem um conjunto rico de componentes de UI. Nesse caso, um conjunto de componentes de UI baseados em HTML flutuariam acima da camada de gráficos fornecida pela tela.

Figura 8. Dispondo elementos HTML em camadas sobre uma tela
Dispondo elementos HTML em camadas sobre uma tela

Clique para ver a imagem maior

Figura 8. Dispondo elementos HTML em camadas sobre uma tela

Dispondo elementos HTML em camadas sobre uma tela

Cada um dos componentes de UI individuais pode ser disposto usando o CSS para que apareçam em uma certa posição em primeiro plano sobre a tela.

A Listagem 8 mostra um exemplo de como posicionar um componente da UI contido em um elemento <div> configurando um índice z alto.

Listagem 8. CSS para posicionar um componente HTML como elemento em primeiro plano
div.user-interface {
    position: absolute;
    z-index: 100;
    top: 50px;
    left: 50px;
}

Já que os componentes de UI baseados em HTML estão na camada mais acima, eles responderão por padrão à entrada do usuário. Por exemplo, se um determinado elemento contiver um elemento de UI como uma caixa de seleção ou um hiperlink, um clique do mouse de um usuário será interceptado por esses elementos. Normalmente, um clique em um desses elementos nunca "cairia" para a superfície da tela, que está abaixo. Entretanto, em alguns casos, pode ser recomendável que a entrada do usuário caia até a tela.

É possível configurar um elemento HTML específico para ignorar a entrada do usuário conectando a propriedade de CSS pointer-events, como mostra a Listagem 9. A configuração de pointer-events como none faz com que o elemento ignore todos os comportamentos que normalmente seriam associados à entrada do usuário — todo o texto, hiperlinks e elementos de formulário dentro do <div> não poderiam ser selecionados e basicamente seriam inutilizáveis.

Listagem 9. CSS para configurar a propriedade pointer-events
div.user-interface {
    position: absolute;
    z-index: 100;
    top: 50px;
    left: 50px;
    pointer-events:none;
}

Os eventos de entrada caem para a camada abaixo, onde o elemento <canvas> poderia interceptá-los. Por exemplo, poderia haver um listener de eventos no elemento <canvas> para capturar o movimento do mouse.

A propriedade pointer-events é suportada por todos os navegadores, com exceção do Internet Explorer (há soluções alternativas para imitar um comportamento semelhante no Internet Explorer).

Dispondo em camadas sobre a tela com uma superfície de entrada

Um método alternativo de capturar a entrada do usuário é semelhante à abordagem anterior, mas não requer o uso de uma propriedade de CSS pointer-events:none . Nessa abordagem, uma camada adicional é incluída sobre a tela e os elementos de UI em HTML. A camada adicional é incluída somente para capturar a entrada do usuário.

Essa abordagem é adequada para cenários em que os elementos HTML existem somente para exibição. Não será possível interagir com os elementos HTML da interface, porque a superfície de entrada capturaria todos os eventos antes que eles chegassem aos elementos subjacentes. A Figura 9 mostra um exemplo.

Figura 9. Dispondo os elementos HTML sobre uma tela com uma superfície de entrada adicional
Dispondo os elementos HTML sobre uma tela com uma superfície de entrada adicional

É possível implementar a superfície de entrada criando um <div> posicionado de forma absoluta com a mesma largura e altura da tela. Se você deixar o <div> vazio, terá basicamente uma camada transparente cujo único propósito é capturar a entrada do usuário.

Para capturar a entrada do usuário, basta conectar todos os listeners de eventos a esse <div>. Já que esse é o elemento que fica mais acima, todas as entradas do usuário serão capturadas por esse elemento e não pelos elementos subjacentes.


Próximas etapas

A Parte 2 desta série irá ampliar os conceitos abordados neste artigo e repassar um exemplo de implementação de um aplicativo híbrido de tela/HTML. Você aprenderá, passo a passo, como incluir uma UI de HTML básica sobre um jogo em tela e como criar um elemento de UI na tela. A Parte 2 também tratará de questões de animação e renderização de texto e mostrará como aproveitar as vantagens do HTML e da tela.

A Figura 10 ilustra o mesmo conceito de jogo construído na Parte 2.

Figura 10. Aplicativo de amostra que combina elementos de HTML e tela
Aplicativo de amostra que combina elementos de HTML e tela

Conclusão

Neste artigo, você aprendeu sobre os pontos fortes e fracos do modelo HTML em comparação com a API de tela, os motivos da criação de um aplicativo híbrido de tela/HTML e diversas abordagens para dispor elementos de HTML e tela em camadas.

Agora que você está pensando em como selecionar uma arquitetura para aproveitar melhor os pontos fortes do HTML e da tela, acompanhe Parte 2 desta série, na qual você utilizará as suas novas qualificações para implementar um jogo espacial de tiro.


Download

DescriçãoNomeTamanho
Article source codecanvashtmlpt1sourcecode.zip2KB

Recursos

Aprender

Obter produtos e tecnologias

  • jQuery: obtenha a conhecida biblioteca do JavaScript que simplifica a travessia de documentos HTML, a manipulação de eventos, animação e interações Ajax para o desenvolvimento rápido na web.
  • Modernizr: faça o download da biblioteca de JavaScript de software livre que ajuda a desenvolver os websites da próxima geração, com HTML5 e CSS3.
  • Versões de avaliação de produto IBM: Faça o download ou explore as versões de teste online no IBM SOA Sandbox e tenha em suas mãos ferramentas de desenvolvimento de aplicativo e produtos de middleware do DB2, Lotus, Rational, Tivoli e WebSphere.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=836999
ArticleTitle=Complemente a Tela com Marcação HTML, Parte 1: Combine a API de tela e o modelo HTML/CSS
publish-date=09252012