Esta é a forma como a especificação DOM define um “DOM”:

O Document Object Model (DOM) é um Application Programming Interface (API) para HTML válido e documentos XML bem formatados. Ele define a estrutura lógica dos documentos e o modo como um documento é acessado e manipulado.

Em outras palavras, o DOM é uma forma padrão para permitir que as linguagens de programação interajam com documentos HTML / XML. O W3C fornece, o que é chamado de linguagem de vinculações, para o ECMAScript. Isto significa que as funcionalidades definidos na especificação DOM foram implementadas nessa linguagem.

ECMAScript é uma “uniformização” da língua (script) dos “homens das cavernas” – Netscape JavaScript e Microsoft JScript para que todos os browsers possam compreender instruções escritas usando o ECMAScript.

Agora, existem três grandes “dialetos” do ECMAScript: JavaScript (Firefox / Chrome / Safari), JScript (IE), e ActionScript (Adobe Flash / Flex). Estes são chamados dialetos como suporte a código escrito antes da normalização e fornecem alguns recursos não disponíveis no ECMAScript ou em outros dialetos.

Os navegadores fornecem uma implementação das interfaces do DOM que permite ECMAScript (ou dialetos suportados) interagirem com o DOM de um documento XML/HTML. Assim, a maioria dos browsers decentes, lançado conforme os padrões, dizem qual ECMAScript é suportado para cada versão do seu navegador.

O DOM de uma página HTML tem uma “árvore-como estrutura” quando visualizadas. É importante notar que o DOM não representa o conteúdo do HTML, mas representa apenas objetos através dos quais o conteúdo pode ser acessado. Esses objetos são modelados após a marcação que existe na página HTML. As relações, funções, comportamentos e atributos desses objetos são identificados pelo DOM.

Bom, é isso! Você normalmente não precisa de saber sobre interfaces DOM principalmente se você trabalhar com uma biblioteca JavaScript. Mas se você estiver interessado, Quirksmode (http://www.quirksmode.org) tem uma excelente introdução ao DOM.

@font-face{
	font-family:'Comic Book';
	src:local('Comic Book'),url('Comic Book.ttf') format('TrueType');
}
p{font-family:'Comic Book',arial,helvetica,sans-serif}

Valores:

• O valor “local” informa se a fonte já existe no sistema operacional do usuário antes de ser instalada
• O valor “url” informa o caminho da fonte que será instalada
• O valor “format” informa qual é o formato da fonte que será instalada

Formatos:

Os formatos aceitos pelos browsers são:

• Embedded OpenType – .eot
• OpenType – .otf
• Scalable Vector Graphics – .svg e .svgz (formato .svg “gzipado”)
• TrueType – .ttf

O Internet Explorer suporta apenas o formato Embedded OpenType (.eot), portanto deverão ser declarados dois formatos, sendo um exclusivo para as versões do Internet Explorer (.eot) e/ou outro(s) para os demais browsers (.otf, .svg, .svgz e .ttf). Exemplo:

@font-face{
	font-family:'Comic Book';
	src:url('Comic Book.eot'); /* IE */
	src:local('Comic Book'),url('Comic Book.ttf') format('TrueType'); /* DEMAIS BROWSERS */
}
p{font-family:'Comic Book',arial,helvetica,sans-serif}

Exemplo declarando outros formatos:

@font-face{
	font-family:'Comic Book';
	src:url('Comic Book.eot'); /* IE */
	src:local('Comic Book'),
	    url('Comic Book.otf') format('OpenType');
	    url('Comic Book.svg') format('Scalable Vector Graphics');
	    url('Comic Book.svgz') format('Scalable Vector Graphics');
	    url('Comic Book.ttf') format('TrueType')
}
p{font-family:'Comic Book',arial,helvetica,sans-serif}

Compatibilidade:

A propriedade @font-face é compatível com os principais sistemas operacionais e browsers (inclusive o Internet Explorer 6):

• Linux – Chrome e Firefox
• Mac OS – Chrome, Firefox, Opera e Safari
• Windows – Internet Explorer 6, 7, 8 e 9, Chrome, Firefox, Opera e Safari

Talvez ajude…

• @font-face Generator – Gerar fontes para outros formatos
• Free Font Converter – Converter fontes para outros formatos

Em meio às tecnologias para troca de dados e comunicação entre aplicações pela web como REST, SOAP, WSDL etc, se destacam também as APIs que fornecem dados com simples requisições http diretamente do site via browser, sem a necessidade de processamento do lado do servidor pelo cliente do serviço. Para esses casos temos o JSONP como uma alternativa “bem em conta” para resolver problemas conhecidos. O objetivo desse post é dar uma introdução do que é e como usar o JSONP.

AJAX vs JSONP

Tecnicamente, JSONP não é AJAX, vamos a uma explicação bem breve da diferença:

AJAX se trata de requisições assíncronas por meio dos objetos XMLHttpRequest e XMLHttpResponse, que trafegam dados no formato XML ou texto puro. Esses dados são manipulados pelo programa javascript, que finalmente monta seus trechos de html sem a necessidade do recarregamento da página.

Já o JSONP requisita dados de forma assíncrona, assim como o AJAX, porém não utiliza os objetos XMLHttp e  só trabalha com objetos no formato JSON.

JSON – JavaScript Object Notation

Formato de dados que vem sendo fortemente utilizado para transporte de dados entre aplicações, principalmente web. Está ganhando seu espaço devido a sua simplicidade de implementação e leveza. É um subconjunto das notações de objetos javascript. Além disso, a manipulação dos dados em um objeto JSON requer um parse simples (usando o método eval do javascript) e não se faz necessária a navegação por DOM entre os nós e atributos de um XML, e por isso a preferência pelo JSON ao invés de XML para ajax na web.

Same Origin Policy

Existe uma limitação para o uso do Objeto XMLHTTPRequest no que se trata de requisições entre diferentes sites. Existe um padrão de segurança, implementado por linguagens de programação, nesse caso o javascript, chamado Same Origin Policy, ou Política de Mesma Origem. Essa recomendação de segurança impede que um documento leia ou envie informações para outra origem.

São considerados de origens diferentes quaisquer documentos que estejam em domínios diferentes, portas diferentes ou que utilizem protocolos de comunicação diferentes entre si.

Considerando a url: “http://www.afronteirafinal.com/”, podemos ter requisições que irão ter sucesso ou falhar nas seguintes situações:

JSONP – JSON with Padding

JSONP é entendido como um “pseudo-protocolo” que permite realizar requisições http e trafegar dados no formato JSON entre documentos de origens diferentes.

Como funciona:

A implementação do JSONP e bastante simples, porém é necessário que o serviço responsável pela entrega os dados forneca a opção de entrega na estrutura necessária para que os dados possam ser manipulados.

Não existem restrições para o carregamento de imagens e scripts de outras origem, por meio do atributo “src” das tags. A técnica por tras do JSONP se aproveita dessa possibilidade para carregar scripts externos conforme a necessidade, manipulando o DOM da página.

O que faz acontecer o JSONP é a inclusão de uma TAG “script” no header “<head>” da página. Essa tag “script” recebe um atributo “src” apontando para o site externo, que responde objetos no formato JSON , esse resultado é “parseado” e fica disponível para manipulação via JavaScript.

O que é o “padding”?

Padding ou prefix é o nome passado na requisição ao serviço, para que na resposta o método envolva os dados em formato JSON após a resposta. Quando a requisição é feita dessa forma:

<script type="text/javascript" src="http://domain1.com/getjson?jsonp=parseResponse" target="_blank"></script>

A palavra “parseResponse” será a o nome da função que envolverá o json, como um callback. O resultado será algo parecido com isso:

parseResponse({“name”:”Jujuzinho”, ”idade”:10, brinquedos:[“bola”,”pipa”,”ioiô”]})

Você, como um esperto desevolvedor, já terá declarado esse método (parseResponse) em seu programa, e este saberá como sabiamente utilizar os dados recebidos.

Suporte nos frameworks

Os frameworks JavaScript geralmente dão um bom suporte às implementações do JSONP, resolvendo a maioria das questões que teríamos que nos preocupar fazendo tudo “na unha”.

No caso do jQuery, ele abstrai as particularidades entre jsonp e ajax e incorpora o JSONP com mais um formato de dados para o seu objeto Ajax.

Em caso de dúvidas, primeiro procure a documentação do framework porque certamente ele trará informações de como implementar jsonp sem mais traumas.

No próximo episódio…

No próximo post sobre o assunto falaremos sobre o futuro. Como será feito o transporte de dados pela web. Protocolos de comunicação de verdade para rodar no browser. Que projetos já estão em andamento e como eles poderão resolver problemas que travam o avanço da comunicação entre apps web.

O QUE É SVG?

SVG é uma linguagem para descrever gráficos bidimensionais e aplicações gráficas em XML. Alguns exemplos de SVG são: o logo da Wikipedia (http://upload.wikimedia.org/wikipedia/commons/7/77/Wikipedia_svg_logo.svg) e o “Hello World” do SVG chamado de “Tiger” (http://www.amplesdk.com/examples/svg/tiger). Veja o fonte desses dois arquivos SVG para ver como SVG parece.

Demo SVG:

<svg xmlns:svg="http://www.w3.org/2000/svg"
  xmlns="http://www.w3.org/2000/svg"
  viewBox="0 0 200 100"
  width="200px" height="100px">
  <circle cx="50" cy="50" r="30"
  style="stroke:none; fill:#ff0000;"/>
  <g transform="translate(100, 20) scale(1.65)">
  <polygon points="36 25, 25 36, 11 36, 0 25,
  0 11, 11 0, 25 0, 36 11"
  style="stroke:none; fill:#0000ff;" />
  </g>
  <rect x="60" y="20" height="60" width="60"
  style="stroke:none; fill:#00ff00;
  fill-opacity: 0.5;" />
</svg>

O QUE É CANVAS?

A especificação do HTML 5 define da seguinte forma: “Elemento de tela que representa um processamento gráficos “bitmap” para gerar imagens, gráficos, jogos através de JavaScript”.

Vladimir Vukićević da Mozilla, em 2006, deu uma boa explicação sobre as diferenças entre o SVG e Canvas:

- SVG é baseado em XML. Isto significa que, cada elemento está disponível no DOM SVG (útil quando você deseja anexar os manipuladores de eventos javascript para um elemento). Canvas não é baseado em XML.

- Canvas é processado pixel por pixel. SVG é um monte de vetores e precisa ser manipulado como um grupo de formas. Uma analogia no mundo Photoshop seria, criar um retângulo usando a “ferramenta forma” contra usar o “PaintBrush”.

Demo Canvas:

E aqui está o JavaScript que o criou o desenho:

function drawSimpleCanvas() {
 var canvas =
 document.getElementById("simpleCanvas");
  if (canvas.getContext) {
  var ctx = canvas.getContext("2d");
  ctx. (); // the circle
  ctx.fillStyle = "#ff0000";
  ctx.arc(50, 50, 30, 0, 2*Math.PI, true);
  ctx.closePath();
  ctx.fill();
  ctx.save();
  // move and resize the octagon
  ctx.translate(100, 20);
  ctx.scale(1.65, 1.65);
  ctx.fillStyle = "#0000ff";
  ctx.beginPath();
  ctx.moveTo(36, 25); ctx.lineTo(25, 36);
  ctx.lineTo(11, 36); ctx.lineTo(0, 25);
  ctx.lineTo(0, 11); ctx.lineTo(11, 0);
  ctx.lineTo(25, 0); ctx.lineTo(36, 11);
  ctx.closePath();
  ctx.fill();
  // restore graphics as they
  // were before move and resize
  ctx.restore();
  ctx.fillStyle = "#00ff00";
  ctx.globalAlpha = 0.5;
  ctx.beginPath();
  ctx.rect(60, 20, 60, 60);
  ctx.closePath();
  ctx.fill();
 }
}

QUEM VAI GANHAR?

Mesmo que sejam completamente diferentes na sua natureza e finalidade, há várias coisas que pode ser feito usando “Canvas” e “SVG”. A recente popularização do elemento “Canvas” parecem para algumas pessoas a morte do SVG. Mas pelo que notei está longe da verdade.

O “Canvas” é tão bom como uma imagem – mas ele não manipula pixel por pixel. Neste momento, elemento Canvas não suporta os “manipuladores” de eventos (por exemplo, ter um retângulo 20x60px dentro de um canvas que seja clicável). Já com o SVG isso é possível.

Canvas em seu estado “natural” não é acessível. O SVG, porém, é bastante acessível.

No entanto existe diferenças significativas de desempenho entre Canvas e SVG. O resultado do experimento descrito no link (http://www.borismus.com/canvas-vs-svg-performance) é que: Canvas é mais adequado para um “gráficos intensivos” onde o objeto são os redesenhos com freqüência (como um jogo), enquanto o SVG é melhor para aplicações que envolvem grandes áreas de processamento (como Google Maps).

POSSO USÁ-LOS AGORA?

Sim, pode. Existem muitas iniciativas para permitir que os navegadores que não suportam SVG ou Canvas tornarem-se “usáveis” por outros meios. O Google tem um impressionante projeto SVG Web (http://code.google.com/p/svgweb/) que usa o Flash para renderizar SVG em navegadores que não suportam SVG nativamente. Para Canvas, o Google tem uma biblioteca “explorecanvas” (http://code.google.com/p/explorercanvas/) que utiliza VML (ou Silverlight) para processar os elementos Canvas (basta incluir o arquivo excanvas.js, e ele deve funcionar) no Internet Explorer.

ENTÃO… QUEM GANHA?

Ambos. Estas é uma fase fantástica para SVG e Canvas. Finalmente temos uma alternativa natural para o “Flash” e animação de necessidade básica. Mantenha seus olhos abertos no “mailing list” do “W3C HTML Working Group” (http://lists.w3.org/Archives/Public/public-html/) para as últimas notícias.

Se você não é desenvolvedor deve se perguntar nesse momento:

“- Eu não sou desenvolvedor, devo me perguntar nesse momento se preciso mesmo saber sobre meta tags?”

Bom, sim e não.  Você não precisa necessariamente saber onde aplica-las no código, mas tem que saber como funcionam e para que servem pois pode existir um campo específico para isso no seu publicador.

Existem algumas dúzias de meta tags que se pode usar no código mas, uma vez que a proposta é não sair do básico do SEO, vamos falar somente das mais importantes nessa série de textos. Aliás, vamos falar uma coisa que pouca gente aborda em textos sobre SEO: em geral as pessoas dão enfase à aplicação, enquanto aqui pretendo falar o real porquê  de usa-las de forma x ou y.

Palavras Chave – Keyword

As keywords são declaradas no topo das páginas e servem basicamente para enfatizar para nossos amigos buscadores sobre o que estamos falando no nosso texto. Há muitos e muitos anos, quando as estrelas eram jovens e Yahoo e Cadê já eram antigos, elas foram o principal campo de consulta dos robots de pesquisa. No código aparecem similar a isto aqui, dentro das tag de head:

<meta name="keywords" content="festa,sandices,quadrinhos" />

A relevância das palavras chave não é mais tão importante quanto já foi por causa dos espertinhos da Web: o camarada ia lá nas keywords dele e lançava “Sabrina Sato pelada, putaria, bunda”.  Daí o buscador ia lá todo feliz fazer a classificação e entregava o resultado pro usuário e, este último, frustrado, descobria que o texto era sobre coleções de selos do século 20 ao invés da referida moça desnuda.  Quem perdia credibilidade nessa história? O buscador, é claro.

Mas aí? Vale a pena usar?

Mas mesmo com essa falta de crédito, o uso bem feito de keywords pode ajudar um pouco na relevância da sua página. Tenha em mente que as palavras usadas nas keywords devem estar contidas no texto, se possível mais de uma vez ou, se não for o caso, ser um sinônimo ou estar estritamente correlacionada ao assunto em questão. Mesmo que você monte um set de palavras que pareçam favorecer o texto, tenha em mente que a má escolha delas pode detonar o seu posicionamento no buscador – logo, se não tiver certeza que aquelas são as melhores escolhas, PREFIRA NÃO USAR NENHUMA KEYWORD. Keywords que não tenham nenhuma ou que tenham pouca conexão com o texto prejudicam ao invés de ajudar.

Exemplo: você escreveu um texto sobre sorvete de jaca e em algum momento disse “seria legal que a Kibon lançasse o sorvete de jaca”.  “Sorvete” e “jaca” seriam palavras importantes como keyword, já Kibon, sendo citado uma única vez no texto e sem nenhuma informação relevante além da menção,  se usada como palavra chave seria a âncora que afundaria tua página por posições e mais posições – afinal, você disse pro buscador que seu texto era relevante sobre isso, ele acreditou, e te classificou na seção “textos relevantes da kibon” e não no “textos relevantes sobre sorvete de jaca”, que era seu assunto principal.

Reciclagem de keywords pode?

“-Entendi, tio Vespa. Posso então escolher as mesmas 5 keywords fodonas e pô-las em todo meu sáite?”

NÃO! Keywords repetidas em várias páginas é como dizer que todo seu site é uma imensa redundância, mesmo que isso não seja verdade. Se o site não tem uma forma rápida de “taguear” todas as páginas, use a regra do não usar nada ou aplique palavras chave apenas no que for conteúdo novo. Você pode usar a mesma palavra várias vezes, mas nunca no mesmo conjunto. Se numa pagina você usou “água, fogo, terra” na próxima poderia usar “água, fogo, ar” que não teria problema – mas nunca “água, fogo, terra” pra duas ou mais.

Outro ponto importante é a quantidade de keywords usadas, evite usar mais do que 5. Muitas keywords poluem o código e caem na regra que citei no texto anterior, “se todo mundo é especial então ninguém é especial”, mandando a relevância pro brejo.

Alguns sistemas, em especial blogs, tem aproveitado a capacidade de gerar tags dos publicadores para reaproveitar o tagueamento nas Keywords. Já vi gente que defende que essa reciclagem não é boa – buscadores são entidades ariscas e não gostam de redundância, ainda mais se for na mesma página. Eu discordo disso por um fato muito simples: keywords são palavras texto, simples, separados por vírgula, enquanto as tags são as mesmas palavras mas com um fatorzinho diferente: elas estão linkadas, logo não estão totalmente redundantes, estão complementando informação já citada – então acredito que não seja algo realmente prejudicial, embora acredite que seja melhor variar um pouco a informação de uma e de outra por questão de aumentar abrangência.

Bom, creio que a respeito de Keywords é o que há de principal a se falar. No próximo episódio falaremos a respeito de meta description. Até!

O caso é que tudo que escrevi no texto, embora de forma escrachada, realmente é funcional na hora de montar um texto relevante para os nossos amigos buscadores (em especial Google, Yahoo e Bing, que são nosso atuais ditadores de tendências na produção de textos web).

Enfim, o meu foco naquele texto em específico era realmente a produção do conteúdo e sobre como a forma de escrevê-lo influencia para chamar a atenção dos buscadores. Mas de que adianta isso sem uma formatação decente?

Meu objetivo nas próximas linhas é tentar explicar, da forma mais simples possível, técnicas básicas de SEO, de forma que sirva tanto de orientação rápida para desenvolvedores quanto para pessoas de foco editorial ou marketing. A priori, ater-me-ei apenas à formatação de texto, ignorando tags, meta-tags, url amigável e keywords (volto no assunto num próximo post).

O Código HTML

O HTML, como já mencionado em artigos anteriores, deve ser sempre, SEMPRE o mais simples e corretamente estruturado possível. O fato do texto não ter um bilhão de “style=…”, tags bizarras e código sujo já é um grande avanço na “achabilidade” da sua página. Grandes poluidores de código são os editores visuais, como FrontPage, Dreamweaver (embora este, se usado corretamente, é uma ferramenta excelente para se trabalhar), goLive e até os Microsoft Words da vida.  Dê preferência aos editores de texto aos visuais.

Essa regra não vale obviamente para os modernos publicadores, como o próprio WordPress, por exemplo, que sozinho já gera um código limpo e relativamente organizado, mais comuns na vida de quem tem foco maior na parte editorial da brincadeira.

Títulos, subtítilos, tópicos (H1, H2, H3)

Tá, já sabemos que devemos fazer o código limpo… Mas como criar a hierarquia de títulos dentro dele? Sim, essa hierarquia influência nossos amigos buscadores. Usando de bom senso, identifique na sua página o que é mais importante e priorize – mas lembre-se, muitas vezes isso não tem absolutamente nada a ver com peso visual ou mesmo com a estrutura “lógica” do texto. Isso significa que, em muitos casos, um H1 deve ser atribuído à um subtítulo ao invés de ir para o título propriamente dito, como seria de se supor.

-”Mas tio Vespa, como posso saber quando fazer esta inversão?”

Muito simples: Quem concentra o maior número de palavras chaves (a.k.a. “buscáveis”) ? O título ou o subtítulo?

Quem tiver mais força merecerá a honra de ser o portador do H1. Para definir isso, questione-se sobre quais palavras digitaria para procurar sobre aquele assunto – as mais óbvias decidem a pendenga.

Um exemplo simples: Imagine que você está convertendo uma matéria de revista para texto html. A matéria chama-se “Friozinho bom” e fala sobre pousadas em Campos do Jordão. Quando você quer procurar sobre pousadas em Campos do Jordão, você procura por “friozinho” no Google? É lógico que não, você vai digitar “Campos do Jordão Pousadas” – logo, o que você faz? Joga isso como subtítulo ou “chápeu” (aquele textinho menor que vai em cima do título em vários sites) e dá o H1 de presente para este texto, mesmo que o tal do “Friozinho bom” venha em fonte 55px e o “Pousadas em Campos do Jordão” em 11px.

Mas então por que não jogar o H1 no corpo do texto todo? Ou no textinho descritivo, o tal do olho da matéria? Ou ainda, por que não fazer 20 títulos de tópicos com H1 numa mesma página? Bom, a resposta é bem simples: Citando Os Incríveis, “se todo mundo é especial, então ninguém é especial”.

Basicamente é assim: cada divisão da sua página é setorizada e priorizada de forma diferente quando o buscador a lê, e cada um desses ele expecta que terá uma determinada formatação. Então se você classifica algo com um título H1 ele realmente espera um texto que tenha o tamanho condizente com o número de palavras que um título conteria – caso contrário ele solta um “ahá! Alguém tomou um Malandrops e tentou me passar a perna” e a posição da tua página vai pro espaço. Reserve H1 e H2 para as chamadas realmente importantes na página (lembrando que H1 é que nem mãe: só tem um por página).

O H2 pode também deve ser usado com parcimônia, mas pode repetir-se várias vezes pela página. H3 em diante, ao que me consta, tem peso relativamente indifirentes.

Mas e o resto do texto?

Bom, o resto do texto pode ser mantido nas boas e velhas DIVs ou Ps, seguindo orientações de semântica para elementos de bloco de texto.  Neste ponto, a grande estrela é a habilidade daquele que escreve o texto, ele é quem fará toda a diferença.

Mas claro, se você for o Dev ou tiver um por perto que saiba um pouquinho de Microformatos, esse é mais um pontinho a se ganhar com nossos amigos buscadores. :p

A técnica da lista

Uma idéia boa pra começar um texto “SEOzado” é, antes de escreve-lo, listar 10 palavras que você considera pontos centrais dentro do assunto à tratar e utiliza-las. Lembre-se, em geral serão as que você usaria se fosse procurar textos sobre o assunto no buscador. Se por acaso você esbarrar em caso de sinônimos e não sabe qual teria mais força, o Google Trends é um ótimo índice para tirar a dúvida do que as pessoas estão procurando mais. Mas lembre-se: cuidado para não exagerar nessa prática e criar um texto ótimo para se buscar mas uma joça para ser lido.

Links pra-que-te-quero

Sabe os termos que você usou para a lista anterior? Muitos deles são muito importantes e vale a pena dar links para eles. Se não tiver nada muito relevante em seu próprio site, não tenha medo de dar links para sites externos. “Qualquer site externo, tio Vespa?” Não, panguá, só os que sejam realmente relevantes. Use os que vierem melhor posicionados no google sobre o assunto, e  prefira artigos às notícias – notícias tem uma “relevância explosão”, são muito relevantes por curtos periodos, afinal, assuntos tendem a esfriar. Já artigos, por serem “base de conhecimento”, costumam manter-se importantes para os buscadores, em especial por conta do número de links que são apontados pra eles (coisa que vou destrinchar com mais calma mais pra diante). Na dúvida, linque para a o termo na Wikipédia que em 99% é uma ótima escolha.

No próximo episódio…

No próximo texto sobre SEO eu falarei sobre os meta-dados, como eles podem ajudar na sua relevância, e como usar de  sabedoria ao empregá-los sem dar tiros no próprio pé.  Até!