Antes porém de uma parte mais prática, se faz necessária uma explicação. Os navegadores Microsoft, por serem baseados em Jscript, interpretam o objeto de requisição como um ActiveXObject(quem não lembra das janelinhas do IE avisando risco de segurança por causa de scripts), e os outros navegadores, por serem baseados em Javascript, interpretam o objeto como sendo um Objeto do núcleo da linguagem, fazendo com que a gente tenha que testar o tipo de navegador da pessoa para criarmos o objeto de forma que funcione em qualquer navegador compatível com a tecnologia.

Criando o Objeto em navegadores microsoft:

var objetoXMLHttp = false;

try {

objetoXMLHttp= new ActiveXObject(“Msxml2.XMLHTTP”);

} catch (e) {

try {

objetoXMLHttp = new ActiveXObject(“Microsoft.XMLHTTP”);

} catch (e2) {

objetoXMLHttp = false;

}

}

Msxml2.XMLHTTP – Navegadores microsoft mais atuais(IE5+, Jscript 5.0)

Microsoft.XMLHTTP – Navegadores microsoft mais antigos(IE4-)

Os navegadores Microsoft possuem duas versões diferentes do objeto, este código tenta criar primeiramente um objeto do tipo Msxm12.XMLHTTP, que é implanteado pelos navegadores Microsoft mais atuais e é mais comum. Se não obtiver sucesso ele tenta criar um objeto do tipo Microsoft.XMLHTTP, que é implantado por navegadores Microsoft mais antigos, meio raro de se encontrar mas um pouco de compatibilidade não mata ninguém. Caso não obtenha sucesso em nenhuma das tentativas, é sinal que o navegador não é Microsoft, e devemos ciar o objeto de outra forma:

objetoXMLHttp = new XMLHttpRequest();

Esse bloco de código cria o objeto compatível todos os outros navegadores que suportam o mesmo e não são Microsoft.

Agora que você já sabe as diferenças básicas entre o objeto entre os navegadores, vamos criar uma função que nos retorne o objeto compatível com qualquer navegador que suporte o mesmo:

function criarObjetoXMLHTTPRequest() {

var objetoXMLHttp;

/*@cc_on

@if (@_jscript_version >= 5)

try {

objetoXMLHttp = new ActiveXObject(“Msxml2.XMLHTTP”);

} catch (e) {

try {

objetoXMLHttp = new ActiveXObject(“Microsoft.XMLHTTP”);

} catch (e) {

objetoXMLHttp = false;

}

}

@else

objetoXMLHttp = false;

@end @*/

if (!objetoXMLHttp && typeof XMLHttpRequest != ‘undefined’) {

try {

objetoXMLHttp = new XMLHttpRequest();

} catch (e) {

objetoXMLHttp = false;

}

}

return objetoXMLHttp;

}

Uma parte do código requer um pouco de atenção extra, o bloco “/*@cc_on”, que ativa o suporte de compilação condicional. O código de compilação condicional deve estar sempre dentro de um comentário, isso permite que navegadores que não suportam compilação condicional possam ignorar esta parte do script, como compilação condicional é recurso exclusivo de Jscript, somente navegadores IE irão ler esta parte do código. Isso torna o script compatível com todas as versões do IE que suportam o objeto e evita que navegadores baseados no gecko possam interromper o script ao tentar criar um objeto existente somente no internet explorer.

Queria deixar claro que é necessário um pouco de conhecimento de Javascript para conseguir entender corretamente esta seqüência de textos.

OBS: Tratamento de exceções não é suportado em versões de Jscript inferiores a 5, mas foi usado um try/catch da mesma forma quando é detectada esta versão para evitar erros em navegadores atuais, e navegadores mais antigos irão ignorar o bloco try/catch e criar o objeto corretamente.

Anderson Triacca – anderson@andersontriacca.com – www.andersontriacca.com

Olá a todos!
Este é o primeiro artigo falando especificamente sobre Ajax do portal, e também é o primeiro de uma seqüência de textos onde eu pretendo explicar Ajax desde a sua concepção mais básica até usos mais elaborados da tecnologia.

Uma coisa que eu tenho percebido navegando na internet é que a maioria dos tutoriais sobre Ajax está fortemente baseada em frameworks que facilitam o trabalho. Eu particularmente não gosto de usar frameworks por dois motivos, um porque eu me sinto sem controle sobre a aplicação que eu estou desenvolvendo, e dois porque eu acho que só se aprende realmente codificando na marra. Nada contra quem usa frameworks, longe disso, mas nesta seqüência de textos eu pretendo ensinar Ajax sem o uso de nenhum framework. Então preparem seu bloco de notas e mãos à obra.

Basicamente existem dois tipos de aplicações hoje em dia, aplicações web e aplicações desktop. Ambas têm suas vantagens e desvantagens. A grande vantagem das aplicações desktop é a velocidade de execução das mesmas, pois rodam localmente no computador do usuário. A grande vantagem das aplicações web é o fato de poderem ser acessadas de qualquer lugar que tenha internet, além de não precisarem ser instaladas na máquina do usuário. O problema das mesmas é a velocidade de execução, que muitas vezes deixa a desejar devido a velocidade das conexões e os temíveis recarregamentos de página.

A promessa do Ajax é unir o poder das aplicações desktop com a flexibilidade das aplicações web, eliminando o recarregamento de página, mas como ele faz isso? Pois bem, sempre que entramos em um site o nosso navegador faz uma requisição de uma página para o servidor, que nos devolve uma nova página remodelada de acordo com a requisição do navegador. Só que por menor que seja a mudança na página, sempre exige um recarregamento da mesma. O Ajax utiliza um objeto javascript (XMLHttp Request) para efetuar suas requisições em segundo plano, sem que o usuário perceba, mudando apenas partes da página sem precisar de recarregamento.
Este objeto XMLHttp request é a base da tecnologia, pois ele é o elo de comunicação entre o servidor e o navegador, o que permite efetuar uma requisição assíncrona (fora do sincronismo normal da página, que não necessita de recarregamento da página), segura, e rápida, pois muda apenas o necessário na página. Quando a requisição é muito grande ele nos permite colocar um pre-loader estilo flash para mostrar ao usuário que os dados estão carregando.

O Ajax está sendo usado em larga escala na web, o Google usa e abusa desta tecnologia em seus sites/aplicações. Um grande exemplo disso é o magnífico Google Maps(http://maps.google.com) e o Gmail(http://www.gmail.com). O futuro da web está no Ajax, pois estamos chegando num ponto onde aplicações web e aplicações desktop estão caminhando cada vez mais juntas, rumo a um novo modelo de programação que revolucionará a informática, e cabe a nós, desenvolvedores, fazer com que esta tecnologia seja cada vez mais difundida.

Por hoje é só, e preparem seus blocos de notas, pois semana que vem começa a parte prática do Ajax.

Anderson Triacca – anderson@andersontriacca.com – www.andersontriacca.com

Olá a todos. Antes de começar gostaria de falar um pouco sobre essa nova seção do MxStudio. Com o advento da chamada “Web 2.0” e o uso em larga escala do ajax se torna imprescindível a criação de uma seção para abordar o assunto neste portal. Esta seção segue duas linhas paralelas de textos, uma falando sobre ajax em si e outra falando sobre javascript(afinal, é preciso saber javascript para aprender ajax). Se tiverem alguma dúvida, crítica ou correção sobre os textos sintam-se à vontade para me mandar um email(elmariachibg@gmail.com). Espero que gostem dos textos, e agora mãos à obra.
Muitas pessoas podem pensar que javascript é uma linguagem um tanto quanto há muito tempo, não da forma como conhecemos hoje, mas existe. Javascript foi concebida inicialmente para ser uma linguagem de criação de scripts server-side, que vinha implantada nos servidores web da netscape(aliás, a Netscape foi quem inventou a linguagem). A Microsoft viu que esse negócio de linguagem de scripts server-side dava certo e então resolveu criar sua própria linguagem de script(batizada de JScript), e a implementou no seu servidor web IIS. Mas a Netscape não se conformou com isso, e teve outra idéia genial, e se no lugar do servidor, o agente do usuário pudesse processar os scripts, não seria muito mais rápida a resposta de uso? Pois estavam certos, e assim foi concebida a idéia de linguagem client-side.

Como o Netscape Navigator dominava o mercado, o alastramento de scripts nas páginas web foi bem rápido, e como a Microsoft estava perdendo mercado em navegadores, ela também resolveu adaptar sua linguagem de modo que pudesse rodar no navegador, e a implementou no internet explorer, e incorporou este no seu sistema operacional(quem não lembra do famoso Windows 95 com Internet Explorer?). Resultado, o navegador da Microsoft dominou o mercado.
Neste ponto da história existiam duas ótimas linguagens de scripts, o único problema é que ambas só funcionavam em seu navegador de origem, o que deixava os desenvolvedores de cabelos arrepiados (incompatibilidades semelhantes ainda assombram os profissionais da web hoje em dia).
Ao perceber este problema, uma empresa chamada ECMA resolveu padronizar a linguagem de modo que pudesse funcionar em todos os navegadores. Desta idéia nasceu um padrão chamado ECMA – 252, e a linguagem foi batizada de ECMAScript(na verdade hoje em dia nós dizemos que programamos em Javascript, quando na verdade o que escrevemos é ECMAScript). Abaixo segue uma tabela comparativa das versões da linguagem(as versões atuais da linguagem são Javascript 1.5, Jscript 5.6 e ECMAScript V3).

Algumas observações a serem tomadas: Em ECMA V1 não existiam instruções do tipo switch e expressões regulares, conseqüemente não são suportados em Javascript 1.3 e Jscript 3.0. ECMA V2 é idêntica a ECMA V1, apenas com a correção de alguns bugs, sem implementação de novos recursos. A versão atual em uso é ECMA V3. Jscript 5.5 e 5.6 são exatamente iguais quando falamos em linguagem client-side.
Como você viu javascript pode ser usado tanto client-side como server-side, mas nessa seqüencia de textos iremos abordar apenas a codificação client-side, pois é a mais utilizada e que mais nos interessa(nós que trabalhamos na área de desenvolvimento web).
O javascript usado na web é uma união do interpretador javascript(fornecido pela Microsoft e pela Mozilla para quem quiser implementar a linguagem em suas aplicações) com um navegador web compatível e com o DOM(Document Object Model recomendado pela W3C). Queria deixar bem claro que nenhum navegador atual suporta todos os recursos do DOM, mas suportam o suficiente para que seja possível seu uso em união ao javascript.
Agora que você já sabe o que é javascript, está na hora de você saber o que ele pode fazer. Muita gente não estuda javascript à fundo por acreditar no mito de que se trata apenas de uma linguagem para fazer validação de formulários. Graças a Deus estão enganados. Javascript é uma linguagem poderosa, que permite desde validar campos de entrada até criar pequenos jogos dentro do navegador, passando por barras de rolagem personalizadas em elementos da página e chamadas assíncronas de dados (famoso ajax). Javascript tem controle sobre a aparência do documento (pode modificar o HTML e o CSS da página), sobre o agente do usuário(através do objeto window pode acessar e modificar várias opções do navegador, com algumas limitações de segurança, logicamente), tem interação com o usuário(através dos tratadores de eventos que serão explicados no próximo texto), gravação de cookies e acesso à opções do monitor(através do objeto screen). As maiores limitações da linguagem são o fato de, por questões de segurança, não possuir acesso à arquivos locais do computador do usuário(grande problema enfrentado pelas pessoas que tentam fazer sistemas de upload por ajax), não ter suporte a recursos de rede e não possuir recursos gráficos(apenas pode modificar o HTML e CSS da página).
Bom, por hoje é só, espero que tenham gostado. No próximo texto estarei entrando mais a fundo nos temas citados hoje, e também estarei falando um pouco mais sobre padrões de programação.

Anderson Triacca – anderson@andersontriacca.com – www.andersontriacca.com

Links Alternativos

Olá a todos, na ultima coluna eu discutí um pouco de acessibilidade em imagens, e nesse artigo irei explicar um poco de acessibilidade na navegação da página, afinal de contas não adianta o deficiente poder entender as imagens do nosso site e não conseguir navegar direito nele não é mesmo?

Uma grande dificuldade que eu tenho notado quando os deficientes navegam em sites com leitores de tela é que quando chegam ao final da página eles simplesmente se perdem, pois não existe nenhuma indicação de que o conteúdo acabou, e muito menos de em que lugar da página eles estão.

Após algum tempo pensando eu encontrei uma possível solução para o problema, solução que eu gosto de chamar de Navegação Alternativa. Funciona da seguinte forma, no final do conteúdo você coloca uma indicação de que o conteúdo acabou e faz uma navegação para o deficiente.

Pareceu meio confuso? Vou explicar melhor. No final do conteúdo do site você deve colocar um parágrafo indicando que ali acaba o conteúdo, para que o deficiente possa se orientar, e no css você coloca display: none, para que ele não interfira no layout do site.

No html fica assim:

…
<p id=”final”>Fim do Conteúdo</p>
…

E no CSS fica assim:

…
#final {
display: none;
}
…

É uma coisa extremamente simples a ser feita, mas que vai fazer uma grande diferença para um deficiente visual. Agora vem a segunda e mais importante medida da navegação alternativa, a navegação alternativa(risos)…
Funciona da seguinte forma: você cria âncoras em locais estratégicos da página(menu de navegação, inicio do conteudo, final do conteúdo) e faz links para estas âncoras após a indicação do final do conteúdo.

Os lugares mais importantes para se colocar as âncoras são o menu de navegação e o início do conteúdo.
O menu de navegação para que ao chegar no final da página o deficiente possa saltar diretamente até o menu, sem ter que ler toda informação do topo(redundante para ele) novamente, e poder acessar rapidamente as outra páginas do site. E no início so conteudo para que se ele quiser ler o conteúdo novamente ele poss fazer isso rapidamente.

Outra lugar muito importante é antes do menu de navegação, para o deficiente poder ir direto ao conteúdo sem ter q ler todo menu novamente quando ele visitar uma nova página do site, esse link é popularmente chamado de “Pular Navegação”.

São todas orientações bem simples, que não exigem mais do que 10 minutos de desenvolvimento, mas que com certeza vão melhorar muito a experiência de um deficiente visual no seu site.

Obrigado a todos e até a próxima.

Anderson Triacca – anderson@andersontriacca.com – www.andersontriacca.com ]]> http://www.mxstudio.com.br/tecnologia/geral/links_alternativos/feed/ 0 http://www.mxstudio.com.br/marketingdigital/usabilidade/acessibilidade_nas_imagens/ http://www.mxstudio.com.br/marketingdigital/usabilidade/acessibilidade_nas_imagens/#comments Sat, 20 Jan 2007 00:00:00 +0000 anderson

Acessibilidade nas Imagens

Olá a todos, neste tutorial darei seqüência ao texto da semana passada, ensinando um pouco dos conceitos discutidos, então mãos à massa.

Pois bem, você desenha um layout lindo, com texturas e efeitos fantásticos, animações boas, vídeos, enfim, tudo que um site “chamativo” precisa ter, mas e quando chega na hora do título? Sim, aqueles títulos que você escreveu com uma fonte encontrada num site Tchekolosvako-Russo-Tailandês que nem você saberia encontrar de novo, e que com certeza o usuário não tem instalada na máquina, mas como ficou bonito no layout você não pode retirar. A solução é usar uma imagem no lugar do texto, mas daí quando o site for acessado com um leitor de tela, como não existe texto, o cego simplesmente não vai ter acesso aos títulos, o que torna a navegação dele extremamente complicada.

Você pode estar pensando, “mas se eu colocar um atributo alt(onde deve se inserir um texto alternativo) na imagem ela fica acessível a leitores de tela”. Ótimo raciocínio, realmente fica acessível, mas daí fica invisível ao Google, pois o Google analisa textos, e não imagens. Além de tornar o site muito confuso para pessoas que o acessarem com um navegador somente texto(muitos usuários de linux usam navegadores somente texto).

Agora sim temos um problema, mas não é muito complicado de resolvê-lo. A melhor solução, na minha opinião, seria deixar o texto no código html e substituí-lo pela imagem através da CSS, pois muitos leitores de tela não interpretam CSS e vão ler o texto, e se interpretarem vão também ler o texto, pois a marcação HTML tem precedência sobre a CSS num mecanismo de leitura de tela.
Imagine o código html assim:

…
<h1>Meu Título numa fonte muito desconhecida</h1>
…

Então na css você faria o seguinte:

…
h1 {
text-indent: -20000px;
display: block;
width: largura da imagem;
height: altura da imagem;
background: url(caminho da imagem) no-repeat;
}
…

Agora vou às explicações.

O text-indent serve pra indentar o texto. No nosso caso vamos usá-lo para esconder o texto, pois usando uma medida negativa ele vai ser indentado para a esquerda, como indicamos -20000px. ele vai ser indentado 20000px para a esquerda, ou seja, vai ficar escondido para qualquer monitor que use uma resolução de vídeo com menos de 20000px de largura. Assim visualmente o texto não aparece e pode ser substituído por uma imagem, e continua visível para os leitores de tela no html, sem contar que o Google vai poder interpretar o texto e vai colocá-lo uns pontinhos à frente em uma busca.

O display é mudado para block(ocupa somente a largura a altura especificadas nos atributos width e height) para você poder indicar uma altura e uma largura para a tag, que devem ser a mesma altura e largura da imagem que será usada como plano de fundo. Caso você não mude o display, em alguns navegadores a imagem simplesmente não irá aparecer.
Width e height dispensam explicações, são simplesmente indicações de largura e altura, que devem ser as mesmas da imagem que será usada.

E por fim colocamos nossa imagem como plano de fundo da tag usando a propriedade background. Assim nós temos nosso título acessível aos leitores de tela, acessível a navegadores somente texto e muito bem visível aos mecanismos de busca.

Outra consideração a ser tomada com imagens é quanto ao texto alternativo (atributo alt). Sempre que você usar uma tag img para inserir imagens no seu site é altamente recomendável indicar um texto alternativo para quem não puder visualizar a foto saber do que se trata essa foto. Na prática ficaria assim:

…
<img src=”flor.jpg” alt=”Flor do tipo rosa cor vermelha” />
…

Assim sua imagem fica acessível tanto para leitores de tela quanto para nevegadores somente texto, que exibirão o texto alternativo no lugar da foto. E no caso da foto não carregar o texto alternativo aparece para a pessoa saber do que se trata a foto, além de que assim seu site tem mais conteúdo e ficar melhor colocado numa busca.

Um cuidado a ser tomado com o atributo alt é quanto ao seu conteúdo, pois convenhamos que um texto alternativo do tipo “foto1” não ajuda muito um deficiente.
Espero que tenham gostado do texto, no próximo explicarei mais alguns macetes referentes à navegação alternativa e âncoras para leitores de tela.
Até a próxima.

Anderson Triacca – anderson@andersontriacca.com – www.andersontriacca.com ]]> http://www.mxstudio.com.br/marketingdigital/usabilidade/acessibilidade_nas_imagens/feed/ 5 http://www.mxstudio.com.br/marketingdigital/usabilidade/google__o_grande_cego/ http://www.mxstudio.com.br/marketingdigital/usabilidade/google__o_grande_cego/#comments Fri, 12 Jan 2007 00:00:00 +0000 anderson

Google, o grande Cego

O título pode parecer meio estranho, mas essa é uma das grandes verdades da web, o google é o maior cego da internet, e isso é muito bom para nós(desenvolvedores). Você deve estar pensando: ?esse cara é louco?, mas vou explicar um pouco da minha lógica, e depois você pode tirar suas conclusões.

Quando eu comecei a montar minhas páginas html eu fui questionado sobre como eu tratava da acessibilidade nas minhas páginas eu respondi que não me importava muito com isso, que deficientes não usam a internet(como eu era ingênuo nessa época).

Acontece que os deficientes(parciais ou totais) acessam sim a web, e acessam muito, cerca de 20% das pessoas que navegam na web são portadoras de algum tipo de deficiência, e não pensar nelas é excluir milhões de possíveis visitantes aos nossos sites.

Mas agora você deve estar se perguntando: ?como um cego acessa um site??, pois eu respondo, através de leitores de tela(progamas que lêem o conteudo do site e expressam de forma verbal para o deficiente poder acessar a página) tais como Jaws ou DoxVox. Mas se na hora que desenvolvemos o site não pensarmos nesses programas, eles com certeza irão confundir o deficiente no lugar de ajudá-lo.

Devemos tomar medidas preventivas para que um deficiente tenha uma boa experiência quando navegar em nosso site, medidas como colocar conteúdos alternativos para leitores de tela, separar conteúdo de estilização, usar webstandards, escrever html semântico, conteúdo alternativo para navegadores que não suportam flash, e outros mais(nas próximas colunas eu explico cada técnica mais detalhadamente).
Agora você me pergunta: ?onde o google do título entra nesta história??, pois ele é mais importante, mais inteligente e mais cego do que você pode imaginar.
Veja por este lado, quanto melhor a colocação do seu site numa busca mais visitas você vai ter. Agora você já se perguntou como o google determina quais sites aparecerão melhor numa busca?

Pois o google visita seu site semanalmente, e quanto mais você atualizar ele melhor ele ficará colocado numa busca, isso claro, se o google conseguir ler seu site. Para o google ler seu site ele precisa de conteúdo, muito conteúdo, e a melhor forma de se conseguir muito conteúdo é usar pouco código na marcação, e para isso existem os webstandards, que separam estruturação de estilização. Quanto mais acessível aos leitores de tela seu site for melhor cotado ele será pelo google e mais visitas ele terá, pois o google é o grande oráculo cego da web.

Vivemos num país onde existem muitas desigualdedes e preconceitos, pelo menos na internet vamos tentar fazer algo para mudar esse quadro.
Por hoje é só, e nos próximos artigos vou explicar na prática como tornar seu site acessível e melhor estruturado.
Até a próxima.

Anderson Triacca – anderson@andersontriacca.com – www.andersontriacca.com ]]> http://www.mxstudio.com.br/marketingdigital/usabilidade/google__o_grande_cego/feed/ 0