Esta é a página principal do guia. Se não tiver conhecimentos de Dynamic HTML leia as secções seguintes. Se tiver experiência com layers e programação de event handlers, salte para a secção "Como funciona" e depois para a descrição dos Ficheiros.

No separador Imagens, aborda-se o uso de imagens nas entradas dos menus. So separador Extras, aborda-se alguns elementos acessórios que modificam uma página com menus dinâmicos.

Finalmente, o leitor pode usar o separador de Contacto para enviar a sua opinião, solicitar informações e descobrir outras páginas semelhantes.

Os menus dinâmicos são uma forma muito confortável e eficiente de multiplicar as ferramentas de navegação num sítio.

Quando se visita um sítio pela primeira vez, percorrer todas as páginas de uma secção em busca de informação específica é fastidioso e por isso um atalho que conduza a uma página mais próxima do objectivo é benvindo. Para os utilizadores experientes de um dado sítio, a vantagem dos menus dinâmicos é ainda maior, pois são uma ferramenta poderosa para navegar rapidamente através das várias secções.

Todavia, os menus dinâmicos devem ser sempre olhados como um melhoramento da navegação e não como o sistema fundamental. O leitor deve garantir que todas as páginas são acessíveis através de ligações (links) normais. Não deixe que o seu sítio dependa dos menus dinâmicos.

Neste guia, procuro realçar o valor da compatibilidade entre plataformas (computador/sistema operativo/browser) diferentes. O leitor deve procurar abranger a mais vasta audiência possível com uma única versão do seu sítio em vez de desenvolver versões por medida para plataformas diferentes. Neste caso, os custos subiriam rapidamente e as características disponíveis em cada versão divergiriam com o tempo. Provavelmente, o leitor debater-se-ia no futuro com escassez de recursos e terminaria por manter apenas as versões mais relevantes.

A modularidade é a chave para a eficiência no Web design. Desenhar, criar, manter e desenvolver um sítio é muito mais fácil quando é mesmo é composto por módulos. Sempre que é necessária uma actualização, só se muda um ficheiro em vez de rever todas as páginas afectadas pela actualização. É certo que a modularidade impõe algumas restrições às variações de design das páginas mas creio que este custo é negligenciável face aos ganhos de eficiência.

Neste exemplo usei três módulos (ver Ficheiros):

• a ficheiro de estilos (style sheet),
• as funções de menu e
• o conteúdo dos menus.

As páginas HTML chamam estes módulos para implementar os menus dinâmicos. Se fôr necessária uma nova entrada nos menus, basta alterar o ficheiro com o conteúdo dos menus.

Em 1998 surgiu a primeira versão de DynamicHTML (DHTML) baseada em Cascading Style Sheets e JavaScript 1.2. Os browsers Netscape Navigator 4 (NN) e Microsoft Internet Explorer 4 (IE) foram os primeiros a reconhecer DHTML, embora com duas implementações diferentes, forçando os web designers a duplicar o código (à época, o NN tinha cerca de 80% de quota de mercado e o IE tinha apenas 15%, mas era já aparente que o suporte ao IE seria decisivo no futuro próximo).
Anos mais tarde, o World Wide Web Consortium (W3C, www.w3c.org) publicou as especificações de um Document Object Model (DOM), os dois browsers aderiram a ela e agora o código está reunificado.

O acesso ao DHTML depende destas tecnologias: se um browser não consegue ler as definições de estilo (normalmente num ficheiro *.css) ou interpretar funções de JavaScript 1.2, não implementará DHTML.

Se o leitor pondera a hipótese de incluir DHTML no seu design, deverá considerar os condicionamentos seguintes:

Versões anteriores dos browsers

As versões Netscape Navigator 3, Internet Explorer 3 e anteriores não conseguem ler o código DHTML. Quando comecei a usar DHTML em 1998 esta limitação era fundamental, pois a maioria dos utilizadores não podia tirar proveito dos menus dinâmicos. É por esse motivo que eu mantenho sempre uma ligação (link) na raiz dos menus dinâmicos (neste caso: Guia, Ficheiros, Imagens, ...).
Actualmente, a maioria dos browsers de computador consegue reproduzir DHTML mas há um vasto leque de dispositivos - telefones móveis, computadores de bolso (PDA), televisões, écrans (telas) em automóveis, aviões, barcos - usados para navegar na Web que podem não reproduzir DHTML.
A utilização da abordagem modular proporciona uma vantagem adicional: como o código DHTML é armazenado em módulos, se o browser não fôr capaz de ler os módulos, não carregará o código, poupando tempo de download e interpretações erradas. Se o código DHTML estivesse incluído nas páginas HTML, seria apresentado como código normal pois os browsers antigos eram muito tolerantes na sintaxe.
Assim, o link <link rel="stylesheet" href="dm.css" type="text/css"> é ignorado por um browser que não consiga ler folhas de estilo bem como o link <SCRIPT LANGUAGE="JavaScript1.2" TYPE="text/javascript" SRC="dm_func.js"></SCRIPT> é ignorado se o browser só conseguir ler JavaScript 1.2.

Funcionalidades desligadas

Por vezes, as funcionalidades de stylesheets e JavaScript estão desligadas por iniciativa do utilizador ou do administrador de sistema por razões de segurança ou para combater elementos indesejados (cookies e janelas pop-up). Se o DHTML é realmente necessário ao sítio do leitor, informe claramente os visitantes que CSS e JavaScript têm de estar activas.

Sítios multi-plataforma

Muito provavelmente, o sítio do leitor será acedido a partir de um leque variado de plataformas. Aconselho por isso a que se evitem soluções específicas da plataforma, sobretudo se produzirem resultados inesperados noutras plataformas. O leitor não se deve obrigar a obter resultados idênticos e perfeitos em todas as plataformas mas deve procurar apresentar resultados razoáveis em quase todas as plataformas, mesmo que os resultados sejam sub-óptimos em algumas delas.
É ainda frequente que o web designer não esteja a par de todas as implementações possíveis nas várias plataformas, embora seja importante testar os sítios com plataformas diferentes.
Um exemplo da minha experiência: usei fundos parcialmente transparentes para tabelas inseridas em layers e o NN 4 apresentou fundos opacos. Com o IE não detectei erros.

Estranheza do utilizador

Para a maioria dos utilizadores, a página é a metáfora principal da Web. E as páginas não mudam quando se move o dedo sobre elas. Daí que muitos utilizadores possam reagir com estranheza quando "algo" salta da página ao passar o ponteiro do rato sobre um link. É por isso importante que os menus dinâmicos sejam obviamente reconhecíveis como elementos de navegação, autónomos do conteúdo da página.
Algumas pessoas movem o ponteiro do rato depressa enquanto outras o fazem devagar (se calhar, estão a utilizar outro tipo de dispositivo), por isso os menus devem ser visíveis durante o tempo suficiente para que os utilizadores tenham tempo de ler todas as entradas e mover o ponteiro até à posição desejada.
Há utilizadores que passarão com o ponteiro sobre os links enquanto procuram outros elementos. Se o utilizador quiser ler ou clicar num link que fica escondido sob um menu dinâmico, ele reagirá com desagrado à nova tecnologia.
É por esse motivo que os menus devem ser escondidos automaticamente ao fim de alguns segundos. Também por isso procuro manter a área sob os menus livre de links e textos.

Tamanho do écran (tela)

É uma assunção corrente pensar que os utilizadores têm acesso a écrans (telas) com uma resolução igual ou superior a 1024 x 768 pixels. Penso que esta assumpção é imprudente, sobretudo nos casos em que os sítios se destinam a audiências vastas e indiferenciadas na Internet. Pelo contrário, se o leitor estiver a fazer um sítio para a Intranet de uma empresa, poderá assumir certas características sobre as plataforma dos utilizadores. No caso geral, há que ser conservador, atendendo aos utilizadores espalhados pelo mundo com computadores antigos ou telefones móveis novos, "set top boxes" para televisão, PDAs, consolas de jogos, etc..
Por regra, planeio os meus sítios para resoluções próximas de 800 x 600, tendo o cuidado de apresentar o conteúdo principal e a navegação numa área de 640 x 480 no topo esquerdo do écran (tela). Por isso, limito as barras de navegação e os menus aos primeiros 600 pixels de largura. Depois de observada esta regra, deixo que o conteúdo se estenda por toda a área disponível; se o utilizador tiver um écran (tela) grande tirará partido disso, caso contrário terá que usar as barras de deslocamento (scroll)...
Claro que este princípio não se aplica a criações de web design artístico. Sem embargo, o leitor deve estar ciente que limita a sua audiência ao requerer grandes écrans (telas).

Limitações do écran (tela)

Além do tamanho, é importante prestar atenção às cores, contrastes, transparências, elementos animados ou que piscam (blink). O leitor não deve confiar nas cores para passar informação essencial pois há utilizadores que são daltónicos, enquanto outros mostram imagens a preto e branco.
Aconselho o leitor a não investir demasiado nos elementos gráficos, tais como molduras não rectangulares, barras decorativas e gráficos sofisticados. Ficam muito bonitos em grandes écrans (telas) e com fontes regulares mas se o leitor experimentar reduzir a janela, aumentar as fontes, poderá frustar-se depressa.
O mais comum funciona bem: um contraste forte baseado em preto sobre fundo branco ou branco sobre fundo preto. O fundo branco é desagradável para algumas pessoas e preferem um cinzento (e.g., #f0f0f0) ou outro tom muito claro. O leitor deve evitar os fundos de brilho médio (e.g., #808080) nas páginas de texto pois reduz a metade a margem de contraste.

Se está a criar um sítio informativo simples, sugiro ao leitor uma visita a www.microsoft.com, www.ibm.com, www.yahoo.com e www.reuters.com, por exemplo. Estas grandes empresas não precisam de provar nada em Web Design e concentram-se em servir os conteúdos aos seus clientes. O leitor não precisa de um web design diferente para alcançar a sua audiência. Só precisa de servir aos seus clientes os conteúdos que eles procuram.

A descrição da máquina de estados dos menus dinâmicos é elementar:

0. Na condição inicial os menus estão escondidos, só os links dos títulos são visíveis.
1. Se o utilizador passar o ponteiro sobre um dos links dos títulos, o menu dinâmico correspondente é mostrado.
2. Se o utilizador escolher uma das entradas do menu, o browser segue para o destino indicado. Se se abrir uma nova página, os menus dinâmicos regressam à condição inicial. Caso contrário, os menus continuam visíveis até que uma das duas situações seguintes ocorrra.
3. Se o utilizador passar com o ponteiro sobre um novo links do título enquanto um outro menu está visível, este é previamente escondido antes que o novo menu seja apresentado.
4. Se o utilizador não actuar sobre os menus durante um interalo especificado, o menu é automaticamente escondido e a página regressa à condição inicial.

Depois desta arenga teórica :-) é hora de descrever o funcionamento prático dos menus dinâmicos.

Cada layer (camada) é composto por uma porção de código HTML encapsulado (limitado) num bloco <DIV ID="dynmenuX"> ... </DIV>. A identificação (ID) contém o nome de cada layer. O código de cada layer é idêntico àquele que se adicionaria numa página normal na secção do corpo <BODY> ... </BODY>.

A posição dos layers (logo dos menus) na página é especificada na stylesheets (ver StyleSheet: dm.css) e é fixa. A única operação a implementar é mostrar ou esconder os layers modificando a propriedade visibility (visibilidade).

Cada layer contém um menu e cada meu contém uma lista de ligações para diversos destinos.

Normalmente, eu uso uma tabela para formatar os menus. A tabela tem a propriedade a WIDTH (largura) especificada mas a altura é livre para acolher um número variável de entradas do menu. Se se incluir a especificação NOWRAP dentro da tag <TD>, o bloco <TD>...</TD> estender-se-á na horizontal até atingir a largura da mais longa entrada, evitando o salto de linha. Isto pode acontecer também se usar uma palavra muito longa ou um elemento gráfico com largura superior à especificada em WIDTH . Finalmente, se usar menus com texto pode acontecer que estes cresçam em altura e largura se o utilizador alterar o tamanho das letras (e ele deve poder fazê-lo de forma a poder ler confortavelmente).
Numa frase, a especificação WIDTH é um minorante da largura real da tabela.

Neste exemplo, cada layer usa uma tabela com um mínimo de 134 pixels de largura e a largura total dos layers ocupará um mínimo de 134 x 5 = 670 pixels. A localização dos layers pode sobrepôr-se sem que os menus se sobreponham porque antes de mostrar um layer, todos os outros são escondidos (ver Functions: dm_func.js).

Neste exemplo só são considerados três events:

Mostrar os menus

O menu dinâmico é mostrado quando o ponteiro passa sobre um dos links dos títulos. Esta operação é desencadeada pelo event handler onMouseOver: <a href="....html" onMouseOver="showMenu(0)">. A função showMenu() limita-se a mudar a propriedade visibility do layer correspondente para visible e programa um time-out para garantir que o menu desaparece ao fim de algum tempo se o utilizador não desencadear outras acções que alterem o estado de visibility.
Não é necessário usar o event handler onMouseOut porque o estado do menu dinâmico é alterado por outras acções.
O menu é escondido quando o utilizador activa outro menu (ver Funcões: dm_func.js) ou quando uma nova página é carregada, pois a condição inicial dos menus dinâmicos estabelece a propriedade de visibility igual a hidden (escondida).

Time-out para esconder o menu

Além dos dois casos anteriores, o menu dinâmico pode ser escondido por um time-out. Este time-out é lançado no momento em que o menu se torna visível; se o utilizador não desencadear uma acção que conduza à ocultação do menu no prazo de 8000 millisegundos, o menu é escondido ao expirar o time-out. Caso contrário, o menu permaneceria permanentemente visível, aborrecendo o utilizador.
Este intervalo de tempo deve ponderar a experiência dos utilizadores com menus dinâmicos - maior experiência conduziria a intervalos mais curtos - com o tempo que o utilizador demora a ler as linhas do menu e mover o ponteiro para a entrada desejada - o que conduziria a intervalos maiores.

Roll-overs de imagens

Este event handler não está relacionado com os menus dinâmicos e é abordado na página de extras.

Uma nota final sobre os time-outs: se um time-outs expirar quando já não é necessário (por exemplo, para esconder um menu que já está escondido), o comando é normalmente ignorarado pois os browsers são muito tolerantes a erros. No entanto, é boa prática de programação limpar o time-out quando se sabe que ele já não será necessário (por exemplo, porque o menu acaba de ser escondido pela função em curso).

Analogamente, se se apagar um time-out que já não existe, o comando é sistematicamente ignorado, por isso não é necessário inquirir a existência de um time-out antes de o apagar no início da função hideMenu(idx) (ver Funções: dm_func.js).

Espero que esta guia sobre os menus dinâmicos lhe tenha sido útil. O leitor é livre de analizar, copiar e alterar o código aqui apresentado de forma a adaptá-lo aos seus sítios.

Uma nota final sobre o modo como eu creio que se deve usar DynamicHTML (DHTML): quando vou ao sítio da Microsoft com o Internet Explorer, tenho acesso aos menus dinâmicos com atalhos para o interior do sítio, enquanto que quando acedo com o browser Mozilla, não vejo quaisquer menus dinâmicos. Ainda assim, é possível navegar no sítio usando os links dos títulos. Não pretendo discutir se a política da Microsoft de não suportar outros browsers é adequada.

O que pretendo realçar é que um sítio deve ser totalmente acessível sem DHTML. Este deve ser usado apenas como um melhoramento. Se não estiver seguro do funcionamento do seu sítio sem DHTML e não tiver um browser antigo disponível, experiemente desligar o JavaScript no seu browser normal e veja como se navega no seu sítio.

Reconheço que algumas porções do meu sítio exigem DHTML. Não são, todavia, páginas destinadas a informação; foram criadas apenas por amor à arte, diversão e beleza.