From 2c2df5ea01eb5cd8b9ea226b2869337e59c5fe3e Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:50:24 +0100 Subject: unslug pt-pt: move --- .../developer_guide/index.html | 77 ++++ .../guia_de_programacao/index.html | 77 ---- .../progressive_web_apps/identificavel/index.html | 62 --- .../responsive/media_types/index.html | 433 +++++++++++++++++++++ .../responsive_design_building_blocks/index.html | 428 ++++++++++++++++++++ .../elementos_base_desenho_adaptavel/index.html | 428 -------------------- .../web/progressive_web_apps/responsivo/index.html | 156 -------- .../web/progressive_web_apps/seguro/index.html | 35 -- 8 files changed, 938 insertions(+), 758 deletions(-) create mode 100644 files/pt-pt/web/progressive_web_apps/developer_guide/index.html delete mode 100644 files/pt-pt/web/progressive_web_apps/guia_de_programacao/index.html delete mode 100644 files/pt-pt/web/progressive_web_apps/identificavel/index.html create mode 100644 files/pt-pt/web/progressive_web_apps/responsive/media_types/index.html create mode 100644 files/pt-pt/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html delete mode 100644 files/pt-pt/web/progressive_web_apps/responsivo/elementos_base_desenho_adaptavel/index.html delete mode 100644 files/pt-pt/web/progressive_web_apps/responsivo/index.html delete mode 100644 files/pt-pt/web/progressive_web_apps/seguro/index.html (limited to 'files/pt-pt/web/progressive_web_apps') diff --git a/files/pt-pt/web/progressive_web_apps/developer_guide/index.html b/files/pt-pt/web/progressive_web_apps/developer_guide/index.html new file mode 100644 index 0000000000..7c63675479 --- /dev/null +++ b/files/pt-pt/web/progressive_web_apps/developer_guide/index.html @@ -0,0 +1,77 @@ +--- +title: PWA - Guia de programação +slug: Web/Progressive_web_apps/Guia_de_programacao +tags: + - Aplicações + - Aplicações da Web progressivas + - Apps + - Guia de Programação + - Landing + - Off-line + - PWA + - Persistente + - Web + - progressivo +translation_of: Web/Progressive_web_apps/Developer_guide +--- +

{{draft}}

+ +

Nos artigos listados aaui, irá encontrar guias sobre cada aspeto da programação para a geração de aplicações da Web progressivas (PWAs). For all other documentation about web development, which generally pertains to PWAs as well, see our primary web development documentation.

+ +

--->>> Titles below are just for the list; give articles good SEO names and feel free to tweak those and this as needed... <<<---

+ +
+
+

Básico da aplicação da Web

+ +
+
Introduction and getting started with PWA development
+
some description
+
Installing and uninstalling web apps
+
An introductory guide to how a web app can be installed on the user's device...
+
Using service workers to run offline
+
description
+
Alerting the user using notifications
+
description
+
Creating a web app from an existing site
+
description
+
+ +

Tópicos avançados

+ +
+
Pushing data from the server to your web application
+
some description
+
Resource management
+
description
+
Integration with the host device
+
description
+
Security and privacy
+
description
+
Gaming topics for web app developers
+
description
+
+
+ +
+

Polishing web apps

+ +
+
Web API equivalents for common native APIs
+
some description
+
Platform-specific tips and issues
+
description
+
Web application performance guide
+
description
+
Ensuring a good user experience
+
description
+
+ +

Tópicos relacionados

+ +
+
some topic
+
some description
+
+
+
diff --git a/files/pt-pt/web/progressive_web_apps/guia_de_programacao/index.html b/files/pt-pt/web/progressive_web_apps/guia_de_programacao/index.html deleted file mode 100644 index 7c63675479..0000000000 --- a/files/pt-pt/web/progressive_web_apps/guia_de_programacao/index.html +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: PWA - Guia de programação -slug: Web/Progressive_web_apps/Guia_de_programacao -tags: - - Aplicações - - Aplicações da Web progressivas - - Apps - - Guia de Programação - - Landing - - Off-line - - PWA - - Persistente - - Web - - progressivo -translation_of: Web/Progressive_web_apps/Developer_guide ---- -

{{draft}}

- -

Nos artigos listados aaui, irá encontrar guias sobre cada aspeto da programação para a geração de aplicações da Web progressivas (PWAs). For all other documentation about web development, which generally pertains to PWAs as well, see our primary web development documentation.

- -

--->>> Titles below are just for the list; give articles good SEO names and feel free to tweak those and this as needed... <<<---

- -
-
-

Básico da aplicação da Web

- -
-
Introduction and getting started with PWA development
-
some description
-
Installing and uninstalling web apps
-
An introductory guide to how a web app can be installed on the user's device...
-
Using service workers to run offline
-
description
-
Alerting the user using notifications
-
description
-
Creating a web app from an existing site
-
description
-
- -

Tópicos avançados

- -
-
Pushing data from the server to your web application
-
some description
-
Resource management
-
description
-
Integration with the host device
-
description
-
Security and privacy
-
description
-
Gaming topics for web app developers
-
description
-
-
- -
-

Polishing web apps

- -
-
Web API equivalents for common native APIs
-
some description
-
Platform-specific tips and issues
-
description
-
Web application performance guide
-
description
-
Ensuring a good user experience
-
description
-
- -

Tópicos relacionados

- -
-
some topic
-
some description
-
-
-
diff --git a/files/pt-pt/web/progressive_web_apps/identificavel/index.html b/files/pt-pt/web/progressive_web_apps/identificavel/index.html deleted file mode 100644 index 712d465d91..0000000000 --- a/files/pt-pt/web/progressive_web_apps/identificavel/index.html +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Identificável -slug: Web/Progressive_web_apps/Identificavel -tags: - - Aplicações - - Aplicações da Web modernas - - Aplicações da Web progressivas - - Manifesto - - identificável - - manifesto da Web -translation_of: Web/Progressive_web_apps -translation_of_original: Web/Progressive_web_apps/Discoverable ---- -
-
As soon as you publish a new web app, you want the world to know about it. Search engines do ok, but often more control is desired over how your apps are exposed in search results. The new W3C Manifest for a web application can help with this, along with other available features.
- -
-
- -

Objetivos eventuais para as aplicações da Web :

- - - -

Guias principais

- -

None written as yet; contributions appreciated.

- -

Tecnologias

- - - - - - - - - - - - - - - - - - -
TecnologiaDescriçãoResumo de suporteEspecificações mais recentes
Web app manifestDefines features of an app such as name, icon, splash screen, and theme colors, for use in contexts such as app listings and device home screens.Experimental, Supported in Chrome, limited support in Firefox (more detail){{SpecName('Manifest')}}
- -

Ferramentas

- -

Add links to useful tools/libraries.

- -

Consulte também

- -
-
Open Graph
-
A defacto standard providing a format for specifying similar metadata in the HTML <head> using meta tags. Supported by Facebook and other properties.
-
diff --git a/files/pt-pt/web/progressive_web_apps/responsive/media_types/index.html b/files/pt-pt/web/progressive_web_apps/responsive/media_types/index.html new file mode 100644 index 0000000000..0038962474 --- /dev/null +++ b/files/pt-pt/web/progressive_web_apps/responsive/media_types/index.html @@ -0,0 +1,433 @@ +--- +title: Média +slug: Web/CSS/Como_começar/Mídia +tags: + - 'CSS:Como_começar' +translation_of: Web/Progressive_web_apps/Responsive/Media_types +--- +

{{ PreviousNext("CSS:Como começar:Tabelas", "CSS:Como começar:JavaScript") }}

+ +

Muitas das páginas neste tutorial focalizaram nas propriedades e nos valores das CSS que você pode usar para especificar o modo de exibir o documento.

+ +

Esta página mostra novamente a proposta e a estrutura das folhas de estilo CSS.

+ +

Informação: Média

+ +

A proposta das CSS é especificar como os documentos são apresentados ao usuário. A apresentação pode tomar mais de uma forma.

+ +

Por exemplo, você provavelmente está lendo esta página em um dispositivo de exibição. Mas você pode também querer projetá-lo em uma tela para uma grande audiência, ou imprimi-la. Estas diferentes mídias podem ter diferentes características. CSS proporciona maneiras para apresenter um documento diferentemente em diferentes mídias.

+ +

Para especificar regras específicas para um tipo de mídia, use @media seguido do tipo de mídia e de chaves para incluir as regras

+ + + + + + + + +
Exemplo
Um documento em um site na web tem uma área de navegação para permitir ao usuário mover em torno do site. +

Na linguagem de marcação, o elemento principal da área de navegação tem o id nav-area.

+ +

Quando o documento é impresso a área de navegação não tem propósito, então a folha de estilo remove-a completamente:

+ +
+ 
+@media print {
+  #nav-area {display: none;}
+  }
+
+
+
+ +

Alguns tipos de mídia comuns são:

+ + + + + + + + + + + + + + + + + + + + +
screenExposição na tela do computador
printMídias paginadas
projectionExposição projetada
allTodas as mídias (o padrão)
+ + + + + + + + +
Mais detalhes
Existem outras maneiras para especificar o tipo de mídia com uma série de regras. +

A linguagem de marcação do documento permite o tipo de mídia tornar-se específico quando a folha de estilo é ligada ao documento. Por exemplo, em HTML você pode opcionalmente especificar o tipo de mídia com o atributo media na tag LINK.

+ +

Em CSS você pode usar @import no começo da folha de estilo para importar outras folhas de estilo de uma URL, opcionalmente especificando o tipo de mídia.

+ +

Usando estas técnicas você pode separar regras de estilo para diferentes tipos de mídia em diferentes aquivos. Esta é algumas vezes uma maneira útil para estruturar sua folha de estilos.

+ +

Para detalhes completos sobre tipos de mídia, veja Media em CSS Specification.

+ +

Existem mais exemplos da propriedade display em uma página posterior neste tutorial: Dados XML.

+
+ +

Impressão

+ +

CSS possui suporte específico para impressão e para mídias paginadas em geral.

+ +

Uma regra @page pode configurar as margens da página. Para imprimir frente e verso, você pode especificar as margens separadamente para @page:left e @page:right.

+ +

Para mídias impressas, você normalmente usa unidades de comprimento apropriadas em polegadas (in) e pontos (pt = 1/72 polegadas), ou centímetros (cm) e milímetros (mm). É igualmente apropriado o uso de ems (em) para combinar tamanhos de fontes, e porcentagens (%).

+ +

Você pode controlar como o conteúdo do documento quebra através de limites de página, usando as propriedades page-break-before, page-break-after e page-break-inside.

+ + + + + + + + +
Exemplos
Esta regra configura as margens da página para uma polegada em todos os quatro lados: +
+ 
+@page {margin: 1in;}
+
+
+ +

Esta regra assegura que todos os elementos H1 comecem em uma nova página:

+ +
+ 
+h1 {page-break-before: always;}
+
+
+
+ + + + + + + + +
Mais detalhes
Para detalhes completos sobre o suporte das CSS para páginas de mídia, veja Paged media em CSS Specification. +

Como outras características das CSS, imprimir depende do seu navegador e de suas configurações. Por exemplo, seu navegador Mozilla proporciona por padrão margens, cabeçalhos e rodapés quando é impresso. Quando outros usuários imprimem seu documento, você provavelmente não poderá predizer o navegador e as configurações que eles usarão, então você provavelmente não poderá controlar os resultados completamente.

+
+ +

Interfaces do utilizador

+ +

CSS tem algumas propriedades especiais para dispositivos que suportem a interface de usuário, como a tela do computador. Isto faz a aparência do documento mudar dinamicamente como o usuário trabalha com a interface.

+ +

Não existe um tipo de mídia especial para dispositivos com interfaces de usuários.

+ +

Existem cinco seletores especiais:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
SeletorSeleciona
E:hoverQualquer elemento E que tenha um ponteiro sobre ele
E:focusQualquer elemento E que tenha um foco no teclado
E:activeO elemento E que é envolvido na corrente ação do usuário
E:linkQualquer elemento E que seja um hiperlink para uma URL que o usuário não visitou recentemente
E:visitedQualquer elemento E que seja um hiperlink para uma URL que o usuário visitou recentemente
+ +

A propriedade cursor especifica a forma do ponteiro: Algumas das formas comuns são como segue. Coloque seu mouse sobre os itens nesta lista para ver as formas comuns dos ponteiros no seu navegador:

+ + + + + + + + + + + + + + + + + + + + + + + + +
SeletorSeleciona
pointerIndica um link
waitIndica que o programa não pode aceitar a entrada
progressIndica que o programa está trabalhando, mas ainda pode aceitar a entrada
defaultO padrão (usualmente uma flecha)
+ +


+ Uma propriedade outline cria um contorno que é normalmente usado para indicar foco do teclado. Estes valores são similares aos da propriedade border, exceto que você não pode especificar lados individuais.

+ +

Algumas outras características das interfaces de usuário são implementadas usando atributos, de uma maneira normal. Por exemplo, um elemento que está desabilitado ou somente leitura tem o atributo disabled ou o atributo readonly. Seletores podem especificar estes atributos como qualquer outros atributos, usando colchetes: {{ mediawiki.external('disabled') }} ou {{ mediawiki.external('readonly') }}.

+ + + + + + + + +
Exemplo
Estas regras especificam estilos para um botão que muda dinamicamente como a interação do usuário com isso: +
+ 
+.green-button {
+  background-color:#cec;
+  color:#black;
+  border:2px outset #cec;
+  }
+
+.green-button[disabled] {
+  background-color:#cdc;
+  color:#777;
+  }
+
+.green-button:active {
+  border-style: inset;
+  }
+
+
+ +

Este wiki não suporta uma interface de usuário na página, então estes botões não são "clicáveis". Aqui estão algumas imagens estáticas para ilustrar a idéia:

+ + + + + + + +
+ + + + + + + + + + + + + + + + +
Clique AquiClique AquiClique Aqui
 
desativadonormalativo
+
+ +

Um botão plenamente funcional também tem um contorno escuro em toda a sua volta quando isto é o padrão, e um contorno pontilhado na face do botão quando ele é focado pelo teclado. Isto pode também ter um efeito quando o ponteiro está sobre ele.

+
+ + + + + + + + +
Mais detalhes
Para mais informações sobre interfaces de usuário em CSS, veja User interface em CSS Specification. +

Existe um exemplo da linguagem de marcação Mozilla para interfaces de usuário, XUL, na segunda parte deste tutorial.

+
+ +

Ação: Imprimir um documento

+ +

Crie um novo documento HTML, doc4.html. Copie e cole o conteúdo daqui, tendo certeza de ter rolado a tela para pegar tudo isto:

+ +
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
+<HTML>
+
+<HEAD>
+<TITLE>Impressão de amostra</TITLE>
+<LINK rel="stylesheet" type="text/css" href="style4.css"></strong>
+</HEAD>
+
+<BODY>
+<H1>Seção A</H1>
+<P>Esta é a primeira seção...</P>
+
+<H1>Seção B</H1>
+<P>Esta é a segunda seção...</P>
+
+<DIV id="print-head">
+Dirigir para mídias paginadas
+</DIV>
+
+<DIV id="print-foot">
+Página:
+</DIV>
+
+</BODY>
+</HTML>
+
+
+ +

Crie uma nova folha de estilo, style4.css. Copie e cole o conteúdo daqui, tendo certeza de ter rolado a tela para pegar tudo isto:

+ +
+
/*** Impressão de amostra ***/
+
+/* Padrão para a tela */
+#print-head,
+#print-foot {
+  display: none;
+  }
+
+/* Somente impressão */
+@media print {
+
+h1 {
+  page-break-before: always;
+  padding-top: 2em;
+  }
+
+h1:first-child {
+  page-break-before: avoid;
+  counter-reset: page;
+  }
+
+#print-head {
+  display: block;
+  position: fixed;
+  top: 0pt;
+  left:0pt;
+  right: 0pt;
+
+  font-size: 200%;
+  text-align: center;
+  }
+
+#print-foot {
+  display: block;
+  position: fixed;
+  bottom: 0pt;
+  right: 0pt;
+
+  font-size: 200%;
+  }
+
+#print-foot:after {
+  content: counter(page);
+  counter-increment: page;
+  }
+
+} /* Fim de somente impressão */
+
+
+ +

Quando você exibe este documento em seu navegador, ele usa o estilo padrão do navegador.

+ +

Quando você imprime (ou prevê a impressão) do documento, a folha de estilo coloca cada seção em uma página separada, e adiciona um cabeçalho e um rodapé para cada página. Se o seu navegador suportar contadores, isto adiciona um número na página no seu rodapé.

+ + + + + + + + +
+ + + + + + +
+ + + + + + +
+
Cabeçalho
+ +
Secção A
+ +
Esta é a primeira secção...
+ +
Página: 1
+
+
+ 		+ + + + + + +
+ + + + + + +
+
Cabeçalho
+ +
Secção B
+ +
Esta é a segunda secção...
+ +
Página: 2
+
+
+
+ + + + + + + + +
Desafios
Mova o estilo específico de impressão para um arquivo CSS separado. +

Use as ligações nesta página para ler a CSS Specification. Ache detalhes de como importar o novo arquivo CSS específico para impressão em sua folha de estilo.

+ +

Faça os cabeçalhos serem azuis quando o ponteiro do mouse estiver sobre eles.

+
+ +

O que vem depois?

+ +

Se teve dificuldade para entender esta página, ou se você tem algum comentário sobre ela, por favor contribua nesta página de Discussão.

+ +

Até agora, todas as regras de estilo neste tutorial foram especificadas em arquivos. As regras e seus volumes são fixos. A próxima página descreve como você muda as regras dinamicamente usando uma linguagem de programação: JavaScript

+ +

{{ PreviousNext("CSS:Como começar:Tabelas", "CSS:Como começar:JavaScript") }}

diff --git a/files/pt-pt/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html b/files/pt-pt/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html new file mode 100644 index 0000000000..bb101b0350 --- /dev/null +++ b/files/pt-pt/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html @@ -0,0 +1,428 @@ +--- +title: Elementos base do desenho adaptável +slug: Web/Progressive_web_apps/Responsivo/Elementos_base_desenho_adaptavel +tags: + - Aplicações + - CSS + - Design Adaptável + - HTML5 + - Movel +translation_of: Web/Progressive_web_apps/Responsive/responsive_design_building_blocks +--- +
+

Este artigo discute os componentes essenciais de desenho responsivo, com ligações para outros artigos que ajudam a aprofundar, se for necessário.

+
+ +

Para os desenvolvedores da Web, hoje em dia é bastante comum serem chamados a criar um site ou aplicação Web que muda a sua interface de acordo com o navegar (browser) ou dispositivo que lhe estiver a aceder, e assim proporcionar uma experiência ótima. Uma possível abordagem a este desafio é criar versões diferentes da aplicação ou site para diferentes plataformas ou navegadores e servi-los de forma apropriada depois de detetar qual o navegador ou plataforma que está a olhar para o site. Mas esta solução seria cada vez mais ineficiente: os métodos para determinar o navegador são intrinsecamente propícios a erros, e manter várias cópias do código pode tornar-se um pesadelo.

+ +

Em geral é muito melhor criar uma única versão do código que não toma decisões  com base no navegador ou plataforma, mas que faz testes a fim de saber quais as funcionalidades suportadas pelo navegador, ou quais os parâmetros do mesmo. Depois, este código é ajustado em função das funcionalidades disponíveis. Costuma-se chamar a isto desenho responsivo ou desenho adaptativo (estes dois termos referem-se a abordagens diferentes ao mesmo problema; para uma discussão sobre as diferentes entre ambos, leia Responsive design versus adaptive design).

+ +

Esta solução é muito mais fiável, a sua manutenção é mais fácil, e pensa mais no futuro. Já não traz o problema que é desenvolver mais versões do site à medida que surgem novos navegadores e plataformas, pois o código é ajustado à medida que os navegadores e as funcionalidades existentes mudam.

+ +

Ainda assim tem desvantagens. Se o conteúdo, disposição (layout) e funcionalidade precisam de ser extremamente diferentes para cada dispositivo, pode não ser uma boa abordagem. Além disso, pegar num site que já existe e adicionar-lhe características de desenho responsivo / adaptável, para ser mais amigo dos dispositivos móveis, pode implicar um esforço maior do que simplesmente criar uma site ou aplicação separado, especialmente se for um site empresarial em expansão. Leia mais sobre vantagens e desvantagens de desenho adaptável.

+ +
+

Pode ler a nossa discussão sobre desenho adaptável, se precisar de peceber melhor o contexto e as bases.

+
+ +

Grelhas fluídas

+ +

O melhor sítio para começar é com medições fluídas do layout da aplicação — essencialmente, isto significa utilizar uma combinação de percentagens e em/rem para dar tamanho ao texto e contentores, em vez de unidades fixas como pixel. Desta forma, o layout adapta-se a diferentes dimensões do viewport, o que traz muitas vantagens. Vejamos um exemplo.

+ +

Escrevemos um protótipo simples-mas-divertido de uma aplicação chamada Snapshot, a qual grava um stream de vídeo da sua webcam (usando {{domxref("navigator.getUserMedia", "getUserMedia()")}}) e depois permite capturar imagens estáticas desse stream (com a {{HTMLElement("canvas")}} do HTML5), e guarda-os numa galeria. Depois pode ver as imagens capturadas e apagá-las. Outros artigos discutem esta funcionalidade mais detalhadamente, mas agora só nos interessa o layout.

+ +
+

Note: Pode encontar a aplicação Snapshot no Github; veja o código e ajude a melhorar. Também pode ver o Snapshot ao vivo. Note que getUserMedia() é uma tecnologia experimental, que de momento apenas funciona no Google Chrome e Firefox desktop. No futuro planeia-se mais funcionalidade e melhor organização do Snapshot.

+
+ +

O layout na versão desktop do Snapshot consiste em três colunas, que mostram o stream, imagem de captura e a galeria, respetivamente.

+ +

+ +

A marcação é muito simples:

+ +
<x-deck selected-index="0">
+  <x-card>
+    …
+  </x-card>
+  <x-card>
+    …
+  </x-card>
+  <x-card>
+    …
+  </x-card>
+</x-deck>
+ +
+

Note: Estes elementos "x-" esquisitos não devem ser familiares; fazem parte do Brick, a biblioteca da Mozilla de elementos UI para aplicações web móveis. Utilizámos o Brick para criar o layout móvel do Snapshot, sobre o qual irá ler mais em baixo.

+
+ +

Para que fiquem lado a lado, usamos estas regras:

+ +
x-card {
+  width: 100%;
+}
+
+x-card:nth-child(1), x-card:nth-child(2) {
+  width: 30%;
+  float: left;
+  padding: 2rem;
+}
+
+x-card:nth-child(3) {
+  width: 40%;
+  float: left;
+  height: 100%;
+  overflow: auto;
+  padding: 2rem;
+}
+ +

Demos largura ({{cssxref("width")}}) 30% às primeiras duas colunas, e à terceira, 40% de largura, e deixamos as colunas flutuarem (float) à esquerda. Assim ficam lado a lado, e mantêm as mesmas proporções à medida que varia o tamanho da janela do navegador. Este é um exemplo muito simples de uma grelha, mas pode aplicar este princípio a grelhas mais complexas, conforme necessário.

+ +

Dimensões dos contornos da caixa

+ +

O espaçamento não afeta a largura e altura totais dos contentores porque mudámos a propriedade {{cssxref("box-sizing")}} para border-box em todos os elementos:

+ +
*, *:before, *:after {
+  -webkit-box-sizing: border-box;
+  -moz-box-sizing: border-box;
+  box-sizing: border-box;
+}
+ +

Basicamente, isto significa que, agora, {{cssxref("width")}} e {{cssxref("height")}} definem as dimensões de um elemento incluindo os conternos, e não só o conteúdo. Por isso, ao fixar width: 40%, a largura da caixa será 40%  do pai, e larguras de {{cssxref("padding")}} ou {{cssxref("border")}} serão subtraídas da largura do conteudo, em vez de adicionadas. Isto é muito útil! Leia mais no artigo * { Box-sizing: Border-box } FTW, escrito pelo Paul Irish.

+ +

Flexible replaced elements

+ +

Até agora tudo bem, mas há algumas questões à espera de se chegarem à frente. Primeiro, vamos ver o que acontece quando incluímos os elementos {{HTMLElement("video")}} e {{HTMLElement("img")}} nas duas primeiras colunas, nus e sem estilo.

+ +

+ +

Como o tamanho dos elementos substituídos é ditado pelo tamanho dos média inseridos neles, e este média tem tamanho fixo, explodem para fora dos elementos que os contem e fazem uma confusão no layout. É horrível, mas em geral este problema é resolvido com CSS simples:

+ +
img, video {
+  max-width: 100%;
+}
+ +

Isto diz aos elementos substituídos para permanecerem dentro da largura do elementos que os contem, em qualquer circunstância. Contudo, se não forem tão largos como os elementos pai, não aumenta para os preencher. No exemplo da fotografia, o código final é um pouco diferente:

+ +
x-card:nth-child(1) video, x-card:nth-child(2) img {
+  width: 100%;
+    …
+}
+ +

Isto porque, no nosso caso, queremos de facto que vídeo e imagem preencham o elemento pai em qualquer circunstância — uma diferença subtil mas importante em relação a {{cssxref("max-width")}} — logo, terão sempre o mesmo tamanho. O vídeo muda de tamanho dinamicamente, mas as capturas de ecrã não, portanto, ao ampliar o ecrã podia obter-se um layout desorganizado, com elementos de dimensões diferentes, quando se utiliza max-width: 100%, por exemplo:

+ +

+ +

Consultas de média

+ +

Grelhas fluídas são um ótimo começo, mas notará que em certos pontos, (conhecidos como breakpoints) o layout começa a desfazer-se. Nestes pontos vai querer retificar o problema no layout, e para o efeito pode usar consultas de média.

+ +
+

Nota: As consultas de média são uma funcionalidade CSS3 que permite aplicar CSS seletivamente, em função do resultado de testes a funcionalidades do média — para aprofundar as bases, leia Media queries.

+
+ +

Disposição típica no desktop

+ +

Como já vimos, no nosso exemplo temos um layout para computador de secretária (desktop). O mesmo é definido pelas regras CSS no topo da folha de estilos, antes de quaisquer consultas de média.
+
+

+ +

Layout de largura média

+ +

Também temos um layout de largura média, o qual pretendemos que funcione bem em tablets e portáteis com ecrã estreito. É definido pelo CSS na primeira consulta:

+ +
@media all and (max-width: 1024px) {
+  x-card:nth-child(1), x-card:nth-child(2) {
+    width: 50%;
+  }
+
+  x-card:nth-child(3) {
+    width: 100%;
+    clear: left;
+  }
+
+  x-card:nth-child(3) img {
+    width: 20%;
+  }
+}
+ +

Aqui estamos a mudar larguras das colunas e a remover float na terceira coluna (e adicionar clear para acautelar comportamentos imprevisíveis de elementos flutuantes). Também alterámos largura das imagens dentro do terceiro contentor, (a galeria, que já não é uma coluna) e agira há 5 em cada linha (dantes eram 3).

+ +

+ +

Layout em ecrã estreito / telemóvel

+ +

Por fim temos layout para ecrãs estreitos, adequado para aplicações móveis ou "open Web apps" (por exemplo, uma aplicação do Firefox OS). Este foi criado em várias partes. Primeiro, como esperado, há uma consulta de média no CSS. Como é bastante comprida, vamos analiśa-la aos poucos:

+ +
@media all and (max-width: 480px) {
+  x-card:nth-child(1), x-card:nth-child(2), x-card:nth-child(3) {
+    width: 100%;
+    float: none;
+    padding: 0;
+  }
+
+  button {
+    margin-top: 0;
+    border-radius: 0;
+  }
+
+  x-card:nth-child(1) video, x-card:nth-child(2) img {
+    border-radius: 0px;
+    border: none;
+    padding: 0;
+    background-color: 0;
+  }
+ +

Este primeiro bloco repõe várias coisas dos layouts mais largos que não eram necessárias para a aplicação móvel.

+ +
  x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) {
+    margin-top: 17.5vw;
+  }
+
+  x-card:nth-child(1) button, x-card:nth-child(2) button {
+    position: absolute;
+    bottom: 0;
+  }
+
+  x-card:nth-child(2) button:nth-of-type(2) {
+    bottom: 5.9rem;
+  }
+
+  x-card:nth-child(1) button {
+    font-size: 7vw;
+  }
+
+  x-card:nth-child(2) button {
+    font-size: 7vw;
+  }
+ +

Estas regras estipulam o tamanho dos botões dentro dos dois primeiros cartões, e dão a todo o conteúdo uma margem superior para o conteúdo não se preder debaixo dos botões de navegação (ler em baixo). Isto é necessário porque Mozilla Brick (ler também em baixo) obriga os seus componentes a ter 100% da largura e altura do ecrã. Nestes, usámos unidades vw (viewport width) — 1vw equivale a 1% da largura do viewport. Assim as dimensões aumentam e diminuem em conjunto com a largura do viewport.

+ +

Quando se clica numa imagem da galeria, aparece um botão para removê-la e outro para cancelar remoção, e não queremos que os dois botões fiquem um em cima do outro. Na última parte desta secção, damos aos botões posição absoluta na parte de baixo dos cartões em que se encontram, para o layout ser apresentável em diferentes variações no tamanho do viewport. Depois acrescentamos uma regra que desloca o segundo botão de qualquer cartão mais para cima, num comprimento igual ao de um botão.

+ +
x-card:nth-child(3) img {
+  width: 50%;
+}
+ +

Esta regra muda a largura das imagens da galeria para aparcerem 2 em cada linha.

+ +
  nav {
+    width: 100%;
+    position: absolute;
+    z-index: 1000;
+
+    display: -webkit-flex;
+    display: -moz-flex;
+    display: -ms-flexbox;
+    display: flex;
+  }
+
+  nav button {
+    font-size: 6.8vw;
+
+    -webkit-flex: 1;
+    -moz-flex: 1;
+    -ms-flex: 1;
+    flex: 1;
+
+    border-left: 1px solid rgba(100,100,100,0.4);
+  }
+
+  nav button:first-child {
+    border-left: 0;
+  }
+}
+ +

Por fim, mudamos o valor de display do elemento {{HTMLElement("nav")}} para flex, de forma a que seja apresentado (estava none no CSS por omissão, no incío da folha de estilos, pois não era necessário nos outros formatos). Depois damos posição absoluta e {{cssxref("z-index")}} para que não ocupe espaço no fluxo do documento, e fique sobre as x-cards (foi por isso que há bocado demos margem superior às x-cards).

+ +

A seguir, o font-size dos botões é 6.8vw. Porquê? Porque a margem superior dos x-cards ficou 17vw anteriormente. Todos os botões na aplicação têm line-height igual a 2.5 (veja o CSS por omissão no início da folha). E 6.8 x 2.5 = 17.

+ +

Por último, utilizámos flex: 1; para os botões ocuparem sempre a mesma proporção de espaço na mesma linha. Vejamos a imagem em baixo o layout móvel:

+ +

single column layout for mobile app view, with three buttons to navigate between cards, an image viewer, and a Save Picture button at the button.Mas ainda há truques na manga para este layout de aplicação móvel! Como referimos anteriormente, utilizámos Mozilla Brick, uma coleção pré-fabricada de componentes para IU de telemóvel. Em particular, usámos o componente deck (baralho de cartas) e o seu simpático efeito de transição entre cartas quando se pressionam os botões. Se quiese saber mais, leia Mozilla Brick: ready made UI components.

+ +

O mais relevante neste artigo é uqe não queríamos que o CSS relativo ao Brick e ficheiros JavaScript aplicados à demarcação a não ser que estivéssemos a olhar para a aplicação em aspeto móvel. Para tal, incluímos o CSS do Brick na página com recurso a um elemento {{HTMLElement("link")}} separado e um atributo media:

+ +
<link href="dist/brick.css" type="text/css" rel="stylesheet" media="all and (max-width: 480px)">
+ +

Aqui diz que a folha de estilo inteira só será ligada ao HTML se e só se a largura do viewport for 480px ou menos. Passando ao JavaScript, elementos {{HTMLElement("script")}} não aceitam atributoss media, então tem que se usar outra estratégia. Felizmente existe um conceito em JavaScript chamado {{domxref("window.matchMedia()")}}, que executa outros conceitos dependendo do resultado de uma consulta de média. Abrimos o ficheiro brick.js e à volta de todo o código existente, colocámos:

+ +
if (window.matchMedia("(max-width: 480px)").matches) {
+  // O código inteiro do ficheiro brick.js está aqui!
+}
+ +

Assim nada dentro do ficheiro brick.js será executado a não ser que a largura do viewport seja 480px ou menos. Problema resolvido.

+ +

Ecrãs mesmos grandes

+ +

Podes ter reparado que se o viewport alargar muito (como um ecrã de cinema), o layout pára de crescer, e centra-se no espaço disponível. Isto é relativamente simples de conseguir. Poderias usar uma consulta de média a min-width para fixar a largura do elemento {{HTMLElement("body")}} a determinado momento:

+ +
@media all and (min-width: 1400px) {
+  body {
+    width: 1400px;
+    margin: 0 auto;
+  }
+}
+ +

Mas é mais fácil aplicar a regra seguinte e retirar por completo a consulta de média:

+ +
body {
+  max-width: 1400px;
+  margin: 0 auto;
+}
+ +

Falha na orientação

+ +

Tabém nos deparámos com problemas de orientação: o layout do tablet foi concebido para orientação em modo retrato, e fica horrível se pusermos o aparelho em modo paisagem. Para consertar isto, acrescentamos uma consulta que só tem efeito em modo paisagem:

+ +
@media all and (max-width: 480px) and (orientation: landscape) {
+  nav {
+    width: auto;
+
+    -webkit-flex-direction: column;
+    -moz-flex-direction: column;
+    -ms-flex-direction: column;
+    flex-direction: column;
+  }
+
+  nav button {
+    font-size: 6.8vh;
+  }
+
+  nav button {
+    border-left: 0;
+  }
+
+  x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) {
+    margin-top: 0;
+  }
+
+  x-card:nth-child(1) button, x-card:nth-child(2) button {
+    font-size: 2rem;
+  }
+}
+ +

Isto faz o seguinte:

+ + + +

Assim obtém-se o seguinte layout:

+ +

+ +
+

Nota: Outra solução no que respeita à orientação pode ser simplesmente fixar a orientação da aplicação, em retrato ou paisagem. Se estiver a desenvolver uma aplicação instalada, ou uma aplicação do Firefox OS, pode fazê-lo facilmente com o campo de oritentação do manifesto. Se quer uma solução que funcione em geral nas aplicações web, pode recorrer à API de orientação do ecrã, e/ou apresentar uma mensagem que peça ao utilizador para rodar o ecrã se estiverem a usar a orientação errada (por exemplo, se window.innerWidth for maior que  window.innerHeight, assume-se que o jogo está em modo paisagem e mostra-se uma mensagem "por favor rode o ecrã").

+
+ +

Viewport

+ +

Um último problema a mencionar na nossa aplicação de exemplo relaciona-se com consultas de média em navegadores móveis. Se víssemos o meu exemplo num navegador móvel, não iríamos ver o simpático layout móvel. Em vez disso, veríamos a imagem em baixo.

+ +

Porque isto acontece? Curto e grosso, os navegadores móveis mentem. Não foto-realizam páginas da internet à largura verdadeira do viewport. Em vez disso, realizam as páginas a uma largura maior que a assumida (próxima da largura de um portátil), e depois encolhem o resultado para caber no ecrã do telemóvel. Isto é um mecanismo de defesa sensato — sites da velha guarda que não fazem consultas de média teriam péssima aparência se fossem realizados numa largura de 320px ou 480px. Mas não ajuda desenvolvedores web responsáveis, que escreveram layouts para ecrãs pequenos no CSS com consultas de média e querem que os dispositivos móveis as utilizem!

+ +

Existe uma maneira de anular este comportamento de fotorrealização — viewport, que está inserido nas páginas HTML sob forma da etiqueta {{HTMLElement("meta")}}. No meu exemplo, vamos adicioná-lo ao {{HTMLElement("head")}}:

+ +
<meta name="viewport" content="width=480">
+ +

Isto obriga o navegador a realizar corretamente o layout móvel da nossa aplicação — width=480 diz-lhe: "realize o HTML a 480 pixels de largura", e portanto, as consultas de média são devidamente efetuadas. Há muitas mais opções disponíveis na etiqueta meta do viewport, as quais pode aprodundar em Utilizar etiqueta meta do viewport para controlar layout em navegadores móveis.

+ +
+

Nota: Há uma especificação chamada adaptação de dispositivos, que define a mesma funcionalidade mas em CSS, usando uma regra "at" @viewport. Provavelmente é um local mais lógica para tal informação, mas as especificação ainda não é tão largamente suportada como a etiqueta meta do viewport, pelo que deve manter essa solução por enquanto.

+
+ +

Vídeo e imagens adaptáveis

+ +

Outro problema cada vez mais comum é tornar o peso (em KB) de imagens e vídeo adaptáveis tal como as dimensões no ecrã. Sim, quer que as imagens fiquem dentro da IU da aplicação quer esteja num telemóvel ou desktop, mas também deve considerar que aplicações móveis têm viewport muito menores que programas desktop, então deve tentar dar aos dispositivos móveis uma imagem mais pequena para transferir. Em geral (e variando com a região do mundo), telemóveis têm banda mais curta e menos memória que os computadores, então uns KB extra também contam.

+ +

Outro desafio é lidar com ecrãs de elevada resolução — gráficos de varredura (bitmaps) pensados para baixas resoluções correm perigo de ficarem minúsculos se apresentados em ecrãs com alta resolução, pelo que os dispositivos aplicam um fator de ampliação às páginas para evitar tal. Infelizmente, imagens de varredura ampliadas podem ficar muito "pixelizadas".

+ +

Imagens de fundo em CSS

+ +

No caso das imagens de fundo em CSS, isto é fácil de resolver. Segundo a metodologia móvel primeiro, cria-se o layout móvel nas instruções CSS por omissão, ou seja, antes de aplicar quaisquer consultas de média. Depois, as consultas de média disponibilizam CSS que só é aplicado quando o viewport tiver larguar superior a um dado limiar. Vejamos um breve exemplo:

+ +
header {
+  height: 300px;
+  width: 100%;
+  background: url(images/small-header.jpg) center;
+}
+
+@media all and (min-width: 480px) {
+  header {
+    background: url(images/large-header.jpg) center;
+  }
+}
+ +

Isto significa que navegadores móveis só vão descarregar a imagem de fundo peqeuna (small-header.jpg), uma vez que não satisfazem a consulta de média, e ignoram a imagem grande (large-header.jpg). Também é possível servir um elemento gráfico com uma resolução mais elevada recorrendo a consultas de média de resolução, como se segue:

+ +
button {
+  background: url(images/low-res-header.jpg) 1rem center ;
+}
+
+@media only screen and (-webkit-min-device-pixel-ratio: 2),
+       only screen and ( min-resolution: 192dpi),
+       only screen and ( min-resolution: 2dppx) {
+  button {
+    background: url(images/high-res-header.jpg) 1rem center ;
+  } 
+}
+ +

Parece complicado mas não é — estamos a utilizar diversas consultas de média, uma vez que, nos dias que correm, diferentes navegadores suportam diferentes consultas de média de resolução (e unidades diferentes — dpi, dppx, sem unidade). Brett Jankord tem uma boa explicação no artigo Cross Browser Retina/High Resolution Media Queries.

+ +

<video>

+ +

Vídeo em HTML5 está relativamente bem servido em termos de adaptabilidade. Se desejar, pode referir diversos ficheiros com o elemento {{HTMLElement("source")}}, cada um com o caminho de um ficheiro e MIME type:

+ +
<video controls>
+  <source src="videos/720/crystal720.mp4" type="video/mp4">
+  <source src="videos/720/crystal720.webm" type="video/webm">
+</video>
+ +

Mas ainda pode ir um passo mais além. Pode incluir atributos media no elemento <source> com consultas de média — o vídeo carregado no navegador vai depender do formato suportado pelo mesmo e também dos resultados das consultas de média. Por exemplo:

+ +
<video controls>
+  <source src="videos/320/crystal320.mp4" type="video/mp4" media="all and (max-width: 480px)">
+  <source src="videos/320/crystal320.webm" type="video/webm" media="all and (max-width: 480px)">
+  <source src="videos/720/crystal720.mp4" type="video/mp4" media="all and (min-width: 481px)">
+  <source src="videos/720/crystal720.webm" type="video/webm" media="all and (min-width: 481px)">
+</video>
+ +

Isto permite ao site servir diferentes ficheiros de vídeo em função no espaço disponível, a fim de otimizar a experiência do utilizador.

+ +

<img>

+ +

Imagens HTML são uma proposta mais difícil. Não existe mecanismo inerente para servir ficheiros diferentes em função do tamanho do viewport e, devido ao número de comportamentos incómodos dos navegadores, as soluções são mais difíceis de criar do que imagina. Atualmente estão em curso algumas propostas de métodos padrão para realizar esta tarefa  — o "W3C responsive images community group" discutiu este problema durante séculos até chegar ao elemento <picture>, o qual tem estrutura semelhante ao elemento {{HTMLElement("video")}}, com alternativas de ficheiro fonte ( {{HTMLElement("source")}}  ) selecionáveis através de consultas de média. Outra proposta, srcset, foi avançada pela Apple e usa uma abordagem diferente, que consiste em incluir um atributo srcset em cada elemento {{HTMLElement("img")}}, no qual se referem as imagens em conjunto com "dicas" ("hints") que o navegador pode usar para determinar qual é a imagem que mais se adequa ao tamanho do viewport, resolução, etc. Não se pretende que os métodos sejam mutuamente exclusivos.

+ +

Isto é tudo muito bonito, mas nenhuma destas soluções está pronta para produção — ambas estão numa fase muito recuada de padronização e não são compatíveis com a maioria dos navegadores. Atualmente temos que depender de em vários {{glossary("Polyfill")}}s e outras soluções, nenhuma das quais é perfeita em todas as situações, pelo que cada pessoa deve decidir qual é a solução acertada para a sua situação em particular. Seguem-se algumas soluções disponíveis:

+ +
+
HiSRC
+
Plugin jQuery que permite criar versões pequenas, médias e grandes de uma imagem, e depois serve a mais apropriada de acordo com a resolução do navegador e velocidade da ligação à internet.
+
Mobify.js capturing
+
Uma técnica da Mozilla que permite capturar a fonte da página antes de ser analisada (parsed) pelo navegador. Desta forma, pode-se mudar os atributos src da imagem com JavaScript, de acordo com funcionalidades do navegador, e evitar problemas de pré-carregamento do navegador. É primissor mas ainda não funciona bem em navegadores antigos.
+
Picturefill
+
Um polyfill baseado em JavaScript para elementos <picture>, que funciona muito bem, mas necessita de marcação muito especializada.
+
Adaptive images
+
Uma solução do lado do servidor, que grava o tamanho do viewport num cookie, e redimensiona imagens através de uma combinação de PHP e .htaccess para um tamanho mais apropriado. Não requer demarcações HTML ou programas JavaScript, mas tem diversas limitações.
+
+ +

SVG e outros gráficos vetoriais

+ +

Para certas imagens (não fotografias, mas sim ícones e outros elementos da interface do utilizador), utilizar gráficos vetoriais é uma boa solução. As mesmas são geradas por algoritmos matemáticos em vez de armazenar informação de cada pixel da imagem, pelo que os ficheiros tendem a ser mais pequenos e podem ser facilmente ampliadas ou visualizadas em dispositivos de alta resolução (pelo menos em teoria). Seguem-se algumas ideias, que também ajudam a diminuir o número de pedidos HTTP — outro fator chave no desempenho de aplicações móveis:

+ + + +

Ver também

+ + diff --git a/files/pt-pt/web/progressive_web_apps/responsivo/elementos_base_desenho_adaptavel/index.html b/files/pt-pt/web/progressive_web_apps/responsivo/elementos_base_desenho_adaptavel/index.html deleted file mode 100644 index bb101b0350..0000000000 --- a/files/pt-pt/web/progressive_web_apps/responsivo/elementos_base_desenho_adaptavel/index.html +++ /dev/null @@ -1,428 +0,0 @@ ---- -title: Elementos base do desenho adaptável -slug: Web/Progressive_web_apps/Responsivo/Elementos_base_desenho_adaptavel -tags: - - Aplicações - - CSS - - Design Adaptável - - HTML5 - - Movel -translation_of: Web/Progressive_web_apps/Responsive/responsive_design_building_blocks ---- -
-

Este artigo discute os componentes essenciais de desenho responsivo, com ligações para outros artigos que ajudam a aprofundar, se for necessário.

-
- -

Para os desenvolvedores da Web, hoje em dia é bastante comum serem chamados a criar um site ou aplicação Web que muda a sua interface de acordo com o navegar (browser) ou dispositivo que lhe estiver a aceder, e assim proporcionar uma experiência ótima. Uma possível abordagem a este desafio é criar versões diferentes da aplicação ou site para diferentes plataformas ou navegadores e servi-los de forma apropriada depois de detetar qual o navegador ou plataforma que está a olhar para o site. Mas esta solução seria cada vez mais ineficiente: os métodos para determinar o navegador são intrinsecamente propícios a erros, e manter várias cópias do código pode tornar-se um pesadelo.

- -

Em geral é muito melhor criar uma única versão do código que não toma decisões  com base no navegador ou plataforma, mas que faz testes a fim de saber quais as funcionalidades suportadas pelo navegador, ou quais os parâmetros do mesmo. Depois, este código é ajustado em função das funcionalidades disponíveis. Costuma-se chamar a isto desenho responsivo ou desenho adaptativo (estes dois termos referem-se a abordagens diferentes ao mesmo problema; para uma discussão sobre as diferentes entre ambos, leia Responsive design versus adaptive design).

- -

Esta solução é muito mais fiável, a sua manutenção é mais fácil, e pensa mais no futuro. Já não traz o problema que é desenvolver mais versões do site à medida que surgem novos navegadores e plataformas, pois o código é ajustado à medida que os navegadores e as funcionalidades existentes mudam.

- -

Ainda assim tem desvantagens. Se o conteúdo, disposição (layout) e funcionalidade precisam de ser extremamente diferentes para cada dispositivo, pode não ser uma boa abordagem. Além disso, pegar num site que já existe e adicionar-lhe características de desenho responsivo / adaptável, para ser mais amigo dos dispositivos móveis, pode implicar um esforço maior do que simplesmente criar uma site ou aplicação separado, especialmente se for um site empresarial em expansão. Leia mais sobre vantagens e desvantagens de desenho adaptável.

- -
-

Pode ler a nossa discussão sobre desenho adaptável, se precisar de peceber melhor o contexto e as bases.

-
- -

Grelhas fluídas

- -

O melhor sítio para começar é com medições fluídas do layout da aplicação — essencialmente, isto significa utilizar uma combinação de percentagens e em/rem para dar tamanho ao texto e contentores, em vez de unidades fixas como pixel. Desta forma, o layout adapta-se a diferentes dimensões do viewport, o que traz muitas vantagens. Vejamos um exemplo.

- -

Escrevemos um protótipo simples-mas-divertido de uma aplicação chamada Snapshot, a qual grava um stream de vídeo da sua webcam (usando {{domxref("navigator.getUserMedia", "getUserMedia()")}}) e depois permite capturar imagens estáticas desse stream (com a {{HTMLElement("canvas")}} do HTML5), e guarda-os numa galeria. Depois pode ver as imagens capturadas e apagá-las. Outros artigos discutem esta funcionalidade mais detalhadamente, mas agora só nos interessa o layout.

- -
-

Note: Pode encontar a aplicação Snapshot no Github; veja o código e ajude a melhorar. Também pode ver o Snapshot ao vivo. Note que getUserMedia() é uma tecnologia experimental, que de momento apenas funciona no Google Chrome e Firefox desktop. No futuro planeia-se mais funcionalidade e melhor organização do Snapshot.

-
- -

O layout na versão desktop do Snapshot consiste em três colunas, que mostram o stream, imagem de captura e a galeria, respetivamente.

- -

- -

A marcação é muito simples:

- -
<x-deck selected-index="0">
-  <x-card>
-    …
-  </x-card>
-  <x-card>
-    …
-  </x-card>
-  <x-card>
-    …
-  </x-card>
-</x-deck>
- -
-

Note: Estes elementos "x-" esquisitos não devem ser familiares; fazem parte do Brick, a biblioteca da Mozilla de elementos UI para aplicações web móveis. Utilizámos o Brick para criar o layout móvel do Snapshot, sobre o qual irá ler mais em baixo.

-
- -

Para que fiquem lado a lado, usamos estas regras:

- -
x-card {
-  width: 100%;
-}
-
-x-card:nth-child(1), x-card:nth-child(2) {
-  width: 30%;
-  float: left;
-  padding: 2rem;
-}
-
-x-card:nth-child(3) {
-  width: 40%;
-  float: left;
-  height: 100%;
-  overflow: auto;
-  padding: 2rem;
-}
- -

Demos largura ({{cssxref("width")}}) 30% às primeiras duas colunas, e à terceira, 40% de largura, e deixamos as colunas flutuarem (float) à esquerda. Assim ficam lado a lado, e mantêm as mesmas proporções à medida que varia o tamanho da janela do navegador. Este é um exemplo muito simples de uma grelha, mas pode aplicar este princípio a grelhas mais complexas, conforme necessário.

- -

Dimensões dos contornos da caixa

- -

O espaçamento não afeta a largura e altura totais dos contentores porque mudámos a propriedade {{cssxref("box-sizing")}} para border-box em todos os elementos:

- -
*, *:before, *:after {
-  -webkit-box-sizing: border-box;
-  -moz-box-sizing: border-box;
-  box-sizing: border-box;
-}
- -

Basicamente, isto significa que, agora, {{cssxref("width")}} e {{cssxref("height")}} definem as dimensões de um elemento incluindo os conternos, e não só o conteúdo. Por isso, ao fixar width: 40%, a largura da caixa será 40%  do pai, e larguras de {{cssxref("padding")}} ou {{cssxref("border")}} serão subtraídas da largura do conteudo, em vez de adicionadas. Isto é muito útil! Leia mais no artigo * { Box-sizing: Border-box } FTW, escrito pelo Paul Irish.

- -

Flexible replaced elements

- -

Até agora tudo bem, mas há algumas questões à espera de se chegarem à frente. Primeiro, vamos ver o que acontece quando incluímos os elementos {{HTMLElement("video")}} e {{HTMLElement("img")}} nas duas primeiras colunas, nus e sem estilo.

- -

- -

Como o tamanho dos elementos substituídos é ditado pelo tamanho dos média inseridos neles, e este média tem tamanho fixo, explodem para fora dos elementos que os contem e fazem uma confusão no layout. É horrível, mas em geral este problema é resolvido com CSS simples:

- -
img, video {
-  max-width: 100%;
-}
- -

Isto diz aos elementos substituídos para permanecerem dentro da largura do elementos que os contem, em qualquer circunstância. Contudo, se não forem tão largos como os elementos pai, não aumenta para os preencher. No exemplo da fotografia, o código final é um pouco diferente:

- -
x-card:nth-child(1) video, x-card:nth-child(2) img {
-  width: 100%;
-    …
-}
- -

Isto porque, no nosso caso, queremos de facto que vídeo e imagem preencham o elemento pai em qualquer circunstância — uma diferença subtil mas importante em relação a {{cssxref("max-width")}} — logo, terão sempre o mesmo tamanho. O vídeo muda de tamanho dinamicamente, mas as capturas de ecrã não, portanto, ao ampliar o ecrã podia obter-se um layout desorganizado, com elementos de dimensões diferentes, quando se utiliza max-width: 100%, por exemplo:

- -

- -

Consultas de média

- -

Grelhas fluídas são um ótimo começo, mas notará que em certos pontos, (conhecidos como breakpoints) o layout começa a desfazer-se. Nestes pontos vai querer retificar o problema no layout, e para o efeito pode usar consultas de média.

- -
-

Nota: As consultas de média são uma funcionalidade CSS3 que permite aplicar CSS seletivamente, em função do resultado de testes a funcionalidades do média — para aprofundar as bases, leia Media queries.

-
- -

Disposição típica no desktop

- -

Como já vimos, no nosso exemplo temos um layout para computador de secretária (desktop). O mesmo é definido pelas regras CSS no topo da folha de estilos, antes de quaisquer consultas de média.
-
-

- -

Layout de largura média

- -

Também temos um layout de largura média, o qual pretendemos que funcione bem em tablets e portáteis com ecrã estreito. É definido pelo CSS na primeira consulta:

- -
@media all and (max-width: 1024px) {
-  x-card:nth-child(1), x-card:nth-child(2) {
-    width: 50%;
-  }
-
-  x-card:nth-child(3) {
-    width: 100%;
-    clear: left;
-  }
-
-  x-card:nth-child(3) img {
-    width: 20%;
-  }
-}
- -

Aqui estamos a mudar larguras das colunas e a remover float na terceira coluna (e adicionar clear para acautelar comportamentos imprevisíveis de elementos flutuantes). Também alterámos largura das imagens dentro do terceiro contentor, (a galeria, que já não é uma coluna) e agira há 5 em cada linha (dantes eram 3).

- -

- -

Layout em ecrã estreito / telemóvel

- -

Por fim temos layout para ecrãs estreitos, adequado para aplicações móveis ou "open Web apps" (por exemplo, uma aplicação do Firefox OS). Este foi criado em várias partes. Primeiro, como esperado, há uma consulta de média no CSS. Como é bastante comprida, vamos analiśa-la aos poucos:

- -
@media all and (max-width: 480px) {
-  x-card:nth-child(1), x-card:nth-child(2), x-card:nth-child(3) {
-    width: 100%;
-    float: none;
-    padding: 0;
-  }
-
-  button {
-    margin-top: 0;
-    border-radius: 0;
-  }
-
-  x-card:nth-child(1) video, x-card:nth-child(2) img {
-    border-radius: 0px;
-    border: none;
-    padding: 0;
-    background-color: 0;
-  }
- -

Este primeiro bloco repõe várias coisas dos layouts mais largos que não eram necessárias para a aplicação móvel.

- -
  x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) {
-    margin-top: 17.5vw;
-  }
-
-  x-card:nth-child(1) button, x-card:nth-child(2) button {
-    position: absolute;
-    bottom: 0;
-  }
-
-  x-card:nth-child(2) button:nth-of-type(2) {
-    bottom: 5.9rem;
-  }
-
-  x-card:nth-child(1) button {
-    font-size: 7vw;
-  }
-
-  x-card:nth-child(2) button {
-    font-size: 7vw;
-  }
- -

Estas regras estipulam o tamanho dos botões dentro dos dois primeiros cartões, e dão a todo o conteúdo uma margem superior para o conteúdo não se preder debaixo dos botões de navegação (ler em baixo). Isto é necessário porque Mozilla Brick (ler também em baixo) obriga os seus componentes a ter 100% da largura e altura do ecrã. Nestes, usámos unidades vw (viewport width) — 1vw equivale a 1% da largura do viewport. Assim as dimensões aumentam e diminuem em conjunto com a largura do viewport.

- -

Quando se clica numa imagem da galeria, aparece um botão para removê-la e outro para cancelar remoção, e não queremos que os dois botões fiquem um em cima do outro. Na última parte desta secção, damos aos botões posição absoluta na parte de baixo dos cartões em que se encontram, para o layout ser apresentável em diferentes variações no tamanho do viewport. Depois acrescentamos uma regra que desloca o segundo botão de qualquer cartão mais para cima, num comprimento igual ao de um botão.

- -
x-card:nth-child(3) img {
-  width: 50%;
-}
- -

Esta regra muda a largura das imagens da galeria para aparcerem 2 em cada linha.

- -
  nav {
-    width: 100%;
-    position: absolute;
-    z-index: 1000;
-
-    display: -webkit-flex;
-    display: -moz-flex;
-    display: -ms-flexbox;
-    display: flex;
-  }
-
-  nav button {
-    font-size: 6.8vw;
-
-    -webkit-flex: 1;
-    -moz-flex: 1;
-    -ms-flex: 1;
-    flex: 1;
-
-    border-left: 1px solid rgba(100,100,100,0.4);
-  }
-
-  nav button:first-child {
-    border-left: 0;
-  }
-}
- -

Por fim, mudamos o valor de display do elemento {{HTMLElement("nav")}} para flex, de forma a que seja apresentado (estava none no CSS por omissão, no incío da folha de estilos, pois não era necessário nos outros formatos). Depois damos posição absoluta e {{cssxref("z-index")}} para que não ocupe espaço no fluxo do documento, e fique sobre as x-cards (foi por isso que há bocado demos margem superior às x-cards).

- -

A seguir, o font-size dos botões é 6.8vw. Porquê? Porque a margem superior dos x-cards ficou 17vw anteriormente. Todos os botões na aplicação têm line-height igual a 2.5 (veja o CSS por omissão no início da folha). E 6.8 x 2.5 = 17.

- -

Por último, utilizámos flex: 1; para os botões ocuparem sempre a mesma proporção de espaço na mesma linha. Vejamos a imagem em baixo o layout móvel:

- -

single column layout for mobile app view, with three buttons to navigate between cards, an image viewer, and a Save Picture button at the button.Mas ainda há truques na manga para este layout de aplicação móvel! Como referimos anteriormente, utilizámos Mozilla Brick, uma coleção pré-fabricada de componentes para IU de telemóvel. Em particular, usámos o componente deck (baralho de cartas) e o seu simpático efeito de transição entre cartas quando se pressionam os botões. Se quiese saber mais, leia Mozilla Brick: ready made UI components.

- -

O mais relevante neste artigo é uqe não queríamos que o CSS relativo ao Brick e ficheiros JavaScript aplicados à demarcação a não ser que estivéssemos a olhar para a aplicação em aspeto móvel. Para tal, incluímos o CSS do Brick na página com recurso a um elemento {{HTMLElement("link")}} separado e um atributo media:

- -
<link href="dist/brick.css" type="text/css" rel="stylesheet" media="all and (max-width: 480px)">
- -

Aqui diz que a folha de estilo inteira só será ligada ao HTML se e só se a largura do viewport for 480px ou menos. Passando ao JavaScript, elementos {{HTMLElement("script")}} não aceitam atributoss media, então tem que se usar outra estratégia. Felizmente existe um conceito em JavaScript chamado {{domxref("window.matchMedia()")}}, que executa outros conceitos dependendo do resultado de uma consulta de média. Abrimos o ficheiro brick.js e à volta de todo o código existente, colocámos:

- -
if (window.matchMedia("(max-width: 480px)").matches) {
-  // O código inteiro do ficheiro brick.js está aqui!
-}
- -

Assim nada dentro do ficheiro brick.js será executado a não ser que a largura do viewport seja 480px ou menos. Problema resolvido.

- -

Ecrãs mesmos grandes

- -

Podes ter reparado que se o viewport alargar muito (como um ecrã de cinema), o layout pára de crescer, e centra-se no espaço disponível. Isto é relativamente simples de conseguir. Poderias usar uma consulta de média a min-width para fixar a largura do elemento {{HTMLElement("body")}} a determinado momento:

- -
@media all and (min-width: 1400px) {
-  body {
-    width: 1400px;
-    margin: 0 auto;
-  }
-}
- -

Mas é mais fácil aplicar a regra seguinte e retirar por completo a consulta de média:

- -
body {
-  max-width: 1400px;
-  margin: 0 auto;
-}
- -

Falha na orientação

- -

Tabém nos deparámos com problemas de orientação: o layout do tablet foi concebido para orientação em modo retrato, e fica horrível se pusermos o aparelho em modo paisagem. Para consertar isto, acrescentamos uma consulta que só tem efeito em modo paisagem:

- -
@media all and (max-width: 480px) and (orientation: landscape) {
-  nav {
-    width: auto;
-
-    -webkit-flex-direction: column;
-    -moz-flex-direction: column;
-    -ms-flex-direction: column;
-    flex-direction: column;
-  }
-
-  nav button {
-    font-size: 6.8vh;
-  }
-
-  nav button {
-    border-left: 0;
-  }
-
-  x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) {
-    margin-top: 0;
-  }
-
-  x-card:nth-child(1) button, x-card:nth-child(2) button {
-    font-size: 2rem;
-  }
-}
- -

Isto faz o seguinte:

- - - -

Assim obtém-se o seguinte layout:

- -

- -
-

Nota: Outra solução no que respeita à orientação pode ser simplesmente fixar a orientação da aplicação, em retrato ou paisagem. Se estiver a desenvolver uma aplicação instalada, ou uma aplicação do Firefox OS, pode fazê-lo facilmente com o campo de oritentação do manifesto. Se quer uma solução que funcione em geral nas aplicações web, pode recorrer à API de orientação do ecrã, e/ou apresentar uma mensagem que peça ao utilizador para rodar o ecrã se estiverem a usar a orientação errada (por exemplo, se window.innerWidth for maior que  window.innerHeight, assume-se que o jogo está em modo paisagem e mostra-se uma mensagem "por favor rode o ecrã").

-
- -

Viewport

- -

Um último problema a mencionar na nossa aplicação de exemplo relaciona-se com consultas de média em navegadores móveis. Se víssemos o meu exemplo num navegador móvel, não iríamos ver o simpático layout móvel. Em vez disso, veríamos a imagem em baixo.

- -

Porque isto acontece? Curto e grosso, os navegadores móveis mentem. Não foto-realizam páginas da internet à largura verdadeira do viewport. Em vez disso, realizam as páginas a uma largura maior que a assumida (próxima da largura de um portátil), e depois encolhem o resultado para caber no ecrã do telemóvel. Isto é um mecanismo de defesa sensato — sites da velha guarda que não fazem consultas de média teriam péssima aparência se fossem realizados numa largura de 320px ou 480px. Mas não ajuda desenvolvedores web responsáveis, que escreveram layouts para ecrãs pequenos no CSS com consultas de média e querem que os dispositivos móveis as utilizem!

- -

Existe uma maneira de anular este comportamento de fotorrealização — viewport, que está inserido nas páginas HTML sob forma da etiqueta {{HTMLElement("meta")}}. No meu exemplo, vamos adicioná-lo ao {{HTMLElement("head")}}:

- -
<meta name="viewport" content="width=480">
- -

Isto obriga o navegador a realizar corretamente o layout móvel da nossa aplicação — width=480 diz-lhe: "realize o HTML a 480 pixels de largura", e portanto, as consultas de média são devidamente efetuadas. Há muitas mais opções disponíveis na etiqueta meta do viewport, as quais pode aprodundar em Utilizar etiqueta meta do viewport para controlar layout em navegadores móveis.

- -
-

Nota: Há uma especificação chamada adaptação de dispositivos, que define a mesma funcionalidade mas em CSS, usando uma regra "at" @viewport. Provavelmente é um local mais lógica para tal informação, mas as especificação ainda não é tão largamente suportada como a etiqueta meta do viewport, pelo que deve manter essa solução por enquanto.

-
- -

Vídeo e imagens adaptáveis

- -

Outro problema cada vez mais comum é tornar o peso (em KB) de imagens e vídeo adaptáveis tal como as dimensões no ecrã. Sim, quer que as imagens fiquem dentro da IU da aplicação quer esteja num telemóvel ou desktop, mas também deve considerar que aplicações móveis têm viewport muito menores que programas desktop, então deve tentar dar aos dispositivos móveis uma imagem mais pequena para transferir. Em geral (e variando com a região do mundo), telemóveis têm banda mais curta e menos memória que os computadores, então uns KB extra também contam.

- -

Outro desafio é lidar com ecrãs de elevada resolução — gráficos de varredura (bitmaps) pensados para baixas resoluções correm perigo de ficarem minúsculos se apresentados em ecrãs com alta resolução, pelo que os dispositivos aplicam um fator de ampliação às páginas para evitar tal. Infelizmente, imagens de varredura ampliadas podem ficar muito "pixelizadas".

- -

Imagens de fundo em CSS

- -

No caso das imagens de fundo em CSS, isto é fácil de resolver. Segundo a metodologia móvel primeiro, cria-se o layout móvel nas instruções CSS por omissão, ou seja, antes de aplicar quaisquer consultas de média. Depois, as consultas de média disponibilizam CSS que só é aplicado quando o viewport tiver larguar superior a um dado limiar. Vejamos um breve exemplo:

- -
header {
-  height: 300px;
-  width: 100%;
-  background: url(images/small-header.jpg) center;
-}
-
-@media all and (min-width: 480px) {
-  header {
-    background: url(images/large-header.jpg) center;
-  }
-}
- -

Isto significa que navegadores móveis só vão descarregar a imagem de fundo peqeuna (small-header.jpg), uma vez que não satisfazem a consulta de média, e ignoram a imagem grande (large-header.jpg). Também é possível servir um elemento gráfico com uma resolução mais elevada recorrendo a consultas de média de resolução, como se segue:

- -
button {
-  background: url(images/low-res-header.jpg) 1rem center ;
-}
-
-@media only screen and (-webkit-min-device-pixel-ratio: 2),
-       only screen and ( min-resolution: 192dpi),
-       only screen and ( min-resolution: 2dppx) {
-  button {
-    background: url(images/high-res-header.jpg) 1rem center ;
-  } 
-}
- -

Parece complicado mas não é — estamos a utilizar diversas consultas de média, uma vez que, nos dias que correm, diferentes navegadores suportam diferentes consultas de média de resolução (e unidades diferentes — dpi, dppx, sem unidade). Brett Jankord tem uma boa explicação no artigo Cross Browser Retina/High Resolution Media Queries.

- -

<video>

- -

Vídeo em HTML5 está relativamente bem servido em termos de adaptabilidade. Se desejar, pode referir diversos ficheiros com o elemento {{HTMLElement("source")}}, cada um com o caminho de um ficheiro e MIME type:

- -
<video controls>
-  <source src="videos/720/crystal720.mp4" type="video/mp4">
-  <source src="videos/720/crystal720.webm" type="video/webm">
-</video>
- -

Mas ainda pode ir um passo mais além. Pode incluir atributos media no elemento <source> com consultas de média — o vídeo carregado no navegador vai depender do formato suportado pelo mesmo e também dos resultados das consultas de média. Por exemplo:

- -
<video controls>
-  <source src="videos/320/crystal320.mp4" type="video/mp4" media="all and (max-width: 480px)">
-  <source src="videos/320/crystal320.webm" type="video/webm" media="all and (max-width: 480px)">
-  <source src="videos/720/crystal720.mp4" type="video/mp4" media="all and (min-width: 481px)">
-  <source src="videos/720/crystal720.webm" type="video/webm" media="all and (min-width: 481px)">
-</video>
- -

Isto permite ao site servir diferentes ficheiros de vídeo em função no espaço disponível, a fim de otimizar a experiência do utilizador.

- -

<img>

- -

Imagens HTML são uma proposta mais difícil. Não existe mecanismo inerente para servir ficheiros diferentes em função do tamanho do viewport e, devido ao número de comportamentos incómodos dos navegadores, as soluções são mais difíceis de criar do que imagina. Atualmente estão em curso algumas propostas de métodos padrão para realizar esta tarefa  — o "W3C responsive images community group" discutiu este problema durante séculos até chegar ao elemento <picture>, o qual tem estrutura semelhante ao elemento {{HTMLElement("video")}}, com alternativas de ficheiro fonte ( {{HTMLElement("source")}}  ) selecionáveis através de consultas de média. Outra proposta, srcset, foi avançada pela Apple e usa uma abordagem diferente, que consiste em incluir um atributo srcset em cada elemento {{HTMLElement("img")}}, no qual se referem as imagens em conjunto com "dicas" ("hints") que o navegador pode usar para determinar qual é a imagem que mais se adequa ao tamanho do viewport, resolução, etc. Não se pretende que os métodos sejam mutuamente exclusivos.

- -

Isto é tudo muito bonito, mas nenhuma destas soluções está pronta para produção — ambas estão numa fase muito recuada de padronização e não são compatíveis com a maioria dos navegadores. Atualmente temos que depender de em vários {{glossary("Polyfill")}}s e outras soluções, nenhuma das quais é perfeita em todas as situações, pelo que cada pessoa deve decidir qual é a solução acertada para a sua situação em particular. Seguem-se algumas soluções disponíveis:

- -
-
HiSRC
-
Plugin jQuery que permite criar versões pequenas, médias e grandes de uma imagem, e depois serve a mais apropriada de acordo com a resolução do navegador e velocidade da ligação à internet.
-
Mobify.js capturing
-
Uma técnica da Mozilla que permite capturar a fonte da página antes de ser analisada (parsed) pelo navegador. Desta forma, pode-se mudar os atributos src da imagem com JavaScript, de acordo com funcionalidades do navegador, e evitar problemas de pré-carregamento do navegador. É primissor mas ainda não funciona bem em navegadores antigos.
-
Picturefill
-
Um polyfill baseado em JavaScript para elementos <picture>, que funciona muito bem, mas necessita de marcação muito especializada.
-
Adaptive images
-
Uma solução do lado do servidor, que grava o tamanho do viewport num cookie, e redimensiona imagens através de uma combinação de PHP e .htaccess para um tamanho mais apropriado. Não requer demarcações HTML ou programas JavaScript, mas tem diversas limitações.
-
- -

SVG e outros gráficos vetoriais

- -

Para certas imagens (não fotografias, mas sim ícones e outros elementos da interface do utilizador), utilizar gráficos vetoriais é uma boa solução. As mesmas são geradas por algoritmos matemáticos em vez de armazenar informação de cada pixel da imagem, pelo que os ficheiros tendem a ser mais pequenos e podem ser facilmente ampliadas ou visualizadas em dispositivos de alta resolução (pelo menos em teoria). Seguem-se algumas ideias, que também ajudam a diminuir o número de pedidos HTTP — outro fator chave no desempenho de aplicações móveis:

- - - -

Ver também

- - diff --git a/files/pt-pt/web/progressive_web_apps/responsivo/index.html b/files/pt-pt/web/progressive_web_apps/responsivo/index.html deleted file mode 100644 index 23bf84f782..0000000000 --- a/files/pt-pt/web/progressive_web_apps/responsivo/index.html +++ /dev/null @@ -1,156 +0,0 @@ ---- -title: Desenho responsivo -slug: Web/Progressive_web_apps/Responsivo -tags: - - Aplicações - - Aplicações da Web progressivas - - Desenvolvimento da Web - - Responsivo -translation_of: Web/Progressive_web_apps/Responsive/responsive_design_building_blocks -translation_of_original: Web/Progressive_web_apps/Responsive ---- -
-
As aplicações da Web responsivas utilizam tecnologias, tais como consultas de multimédia e viewport para se certificar que as suas UIs irão enquadrar qualquer fator de forma: pc, telemóvel, tablet, ou que quer que venha a seguir.
- -
-
- -

Guias núcleo

- -
-
The building blocks of responsive design
-
Learn the basics of responsive design, an essential topic for modern app layout.
-
Mobile first
-
Often when creating responsive application layouts, it makes sense to create the mobile layout as the default, and build wider layouts on top.
-
- -

Tecnologias

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
TecnologiaDescriçãoResumo de suporteÚltimas especificações
Media queriesDefines expressions allowing styling to be selectively applied to content depending on viewport size, resolution, orientation, etc.Widespread across modern browsers (more detail)Media Queries Level 4
@viewport/viewport meta tagControls viewport settings, primarily on mobile devices.@viewport: Experimental (more detail)
- Viewport meta tag: Widespread across modern mobile devices		CSS Device Adaptation Module Level 1
FlexboxA very useful CSS feature for creating flexible, responsive layouts.Widespread across modern browsers (more detail)CSS Flexible Box Layout Module Level 1
- -

Ferramentas

- -
-
Modernizr
-
A feature detection library for applying different CSS and JS to your page depending on whether certain CSS/JS features are supported.
-
css3-mediaqueries-js
-
A JavaScript polyfill to add Media Query support to old versions of IE (5+.)
-
- -

Consulte também

- -
-
Graphics for responsive sites
-
Ideas to keep in mind when designing graphics for responsive sites and applications.
-
Responsive navigation patterns
-
How do you make a UI that looks and works as great on a smartphone as it does on the desktop? Learn how to design UIs that change to fit your user's screen.
-
- -
- - - - - -
diff --git a/files/pt-pt/web/progressive_web_apps/seguro/index.html b/files/pt-pt/web/progressive_web_apps/seguro/index.html deleted file mode 100644 index 6ef841c83f..0000000000 --- a/files/pt-pt/web/progressive_web_apps/seguro/index.html +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: Segurança -slug: Web/Progressive_web_apps/Seguro -tags: - - Aplicações - - Aplicações da Web modernas - - Aplicações da Web progressivas - - HTTPS - - Segurança - - Seguro - - Web -translation_of: Web/Progressive_web_apps -translation_of_original: Web/Progressive_web_apps/Safe ---- -
-
A plataforma da Web fornece um mecanismo de entrega seguro que evita a espionagem e garante que o conteúdo não foi adulterado - desde que aproveite o HTTPS e desenvolva as suas aplicações com a segurança em mente.
- -
-
- -

Guias principais

- -

Aidna sem guias principais listados. Contribuições são bem-vindas.

- -

Tecnologias

- -

Não são necessárias novas tecnologias — a Web já funciona como isto!

- -

Ferramentas

- -

Interligue aqui para quaisquer ferramentas úteis.

- -

Consulte também

- -

Interligue aqui outra informação útil.

-- cgit v1.2.3-54-g00ecf