MEU SITE PESSOAL

http://www.artemanhaweb.com.br/vini/

Internacionalização

Técnicas básicas para disponibilizar o conteúdo em um  formato internacional:

Codificação: Utilize Unicode sempre que possível para conteúdo, bases de dados, etc. Declare sempre a codificação do conteúdo.

Essa codificação de caracteres que escolhe e determina quantos bytes são mapeados para caracteres no seu texto.

Normalmente as codificações de caracteres limitam-no a uma escrita particular ou conjunto de idiomas. O Unicode permite-lhe lidar simplesmente com a maior parte das escritas e idiomas em utilização à volta do mundo. Desta forma, o Unicode simplifica o manuseamento de conteúdo em vários idiomas, seja dentro de uma única página ou ao longo de um ou mais sítios. O Unicode é particularmente útil quando usado em formulários, escritas e bases de dados, onde necessita frequentemente suportar vários idiomas. O Unicode também torna muito directo adicionar novos idiomas ao seu conteúdo.

A menos que declare corretamente qual a codificação de caracteres que está a usar, os seus utilizadores não conseguem ler o seu conteúdo. Isto deve-se a suposições incorretas que possam ser efetuadas pela aplicação ao interpretar o seu texto sobre quantos bytes mapear para os caracteres.

Saídas: Utilize caracteres diferentes das saídas (p.ex.á á ou á) sempre que puder.

Saídas tais como Referências de Caracteres Numéricos (NCRs) e entidades são formas de representação de qualquer caractere Unicode em markup com utilização de caracteres ASCII. Por exemplo, pode representar o caractere "á" em X/HTML como á or á or á.

Tais saídas são úteis para representar claramente caracteres invisíveis ou ambíguos, e para prevenção de problemas com caracteres da sintaxe como o & comercial ou sinais de maior e menor. Também podem ser úteis em ocasiões para representar caracteres não suportados pela sua codificação de caracteres ou indisponível a partir do seu teclado. De outra forma deve sempre usar caracteres em vez de saídas.

Idioma: Declare o idioma dos documentos e indique as alterações internas do idioma.

A informação sobre o idioma (humano) do conteúdo é também importante para acessibilidade, estilo, pesquisa, edição, e outros motivos. Quanto mais e mais conteúdo for etiquetado e etiquetado corretamente, as aplicações que possam detectar informação do idioma irão tornar-se cada vez mais úteis e dominantes.

Quando declarar o idioma, deverá necessitar de expressar informação sobre uma gama específica de conteúdo de uma forma diferente a partir da metadata sobre o documento como um todo. É importante entender esta distinção.

Apresentação vs. conteúdo. Utilize folhas de estilo para apresentação de informação. Restringir marcação a semânticas.

É um princípio importante do desenho da Web manter a forma como o conteúdo é formado ou apresentado para o separar do próprio texto. Isto faz com que seja simples aplicar estilos alternativos para o mesmo texto, por exemplo, de forma a exibir o mesmo conteúdo tanto num navegador convencional como num dispositivo pequeno de mão.

Este princípio é particularmente útil para a localização, porque as escritas diferentes têm necessidades tipográficas diferentes. Por exemplo, devido à complexidade de caracteres Japoneses, pode ser preferível evidenciar em páginas X/HTML Japonesas de outras formas que não negrito ou itálico. É muito mais fácil aplicar tais mudanças se a apresentação for descrita com CSS, e a markup é muito mais limpa e mais gerível se o texto for correcta e inequivocamente etiquetado como "evidenciado" em vez de apenas "negrito".

Poderá poupar tempo e esforço considerável durante a localização para trabalhar com ficheiros CSS em vez de ter de mudar a markup, porque quaisquer alterações necessárias podem ser efectuadas num local único para todas as páginas, e o tradutor pode-se focar no conteúdo em vez de na apresentação.

Imagens, animações & exemplos: Verifique se é traduzível e se tem um desvio cultural inapropriado.

Se desejar que o seu conteúdo comunique realmente com pessoas, necessita falar o seu idioma, não apenas através do texto, mas também através de imagens locais, cores, objectos e preocupações. É fácil ignorar a natureza específica cultural do simbolismo, comportamento, conceitos, linguagem corporal, humor, etc. Deverá obter retorno na adequabilidade e relevância das suas imagens, clips de vídeo, e exemplos de utilizadores de dentro do país.

Deverá também ter cuidado quando incorporar texto em gráficos quando o conteúdo for traduzido. Texto em fundos complexos ou espaços restritos podem provocar problemas consideráveis para o tradutor. Deverá fornecer gráficos para o grupo de localização que tem o texto numa camada separada e deverá ter em mente que o texto em idiomas como o Inglês e o Chinês irá certamente expandir-se na tradução.

Formulários. Utilize uma codificação apropriada em ambos os formulários e servidores. Suporta formatos locais de nomes/endereços, horas/datas, etc.

A codificação usada para uma página HTML que contém um formulário deverá suportar todos os caracteres necessários para introduzir dados nesse formulário. Isto é particularmente importante se o mais provável consistir no facto de os utilizadores introduzirem a informação em vários idiomas.

As bases de dados e escritas que recebem dados de formulários em páginas em vários idiomas devem também conseguir suportar os caracteres para todos aqueles idiomas em simultâneo.

Autorização de textos: Utilize texto simples e conciso. Tenha cuidado quando escrever as frases de vários conjuntos de palavras.

Texto simples e conciso é mais fácil de traduzir. É também mais fácil para ler caso o texto não esteja no seu idioma principal.

Deverá ter um cuidado considerável ao compor mensagens de várias sub-conjuntos de palavras, ou quando inserir textos variáveis em conjuntos de palavras. Por exemplo, suponha que o seu site utiliza escrita JSP e que decide compor certas mensagens seguidas. Poderá criar mensagens juntando sub-conjuntos de palavras separados, como por exemplo "Apenas" ou "Não", "devolva resultados em ", e "qualquer formato" ou "HTML". Porque a ordem do texto nas frases de outros idiomas pode ser muito diferente, a sua tradução poderá apresentar grandes dificuldades.

De forma semelhante, é importante evitar fixar as posições de variáveis no texto como "Página 1 de 10". A sintaxe de outros idiomas poderá necessitar que os números sejam revertidos para fazer sentido. Se usar PHP, isto irá significar a utilização de um conjunto de palavras de formatação como "Página %1\$d de %2\$d.", em vez do mais simples "Página %d de %d.". Este último não é traduzível nalguns idiomas.

Navegação. Inclua em cada página uma navegação claramente visível para páginas ou sites localizados, com o idioma de destino.

Onde tiver versões de uma página ou site num idioma diferente, ou para um país ou região diferente, deverá fornecer uma forma para o utilizador ver a versão que prefere. Isto deverá estar disponível a partir de qualquer página no seu site onde exista uma alternativa.

Quando fornecer ligações a páginas noutros idiomas, use o nome do idioma de destino no idioma e escrita nativos. Não assuma que o utilizador possa ler Inglês. Por exemplo, numa ligação a uma página Francesa, "Francês" seria escrito "français". Isto também se aplica se estiver a orientar o utilizador a uma página específica do país ou região ou site, ex. "Alemanha" deverá ser "Deutschland".

Texto da direita para a esquerda. Para XHTML, adicione dir="etl" à etiqueta html. Utilize-o apenas para mudar a direção base.

Texto em idiomas como o Árabe, Hebraico, Persa e Urdu é lido da direita para a esquerda. Esta ordem de leitura leva tipicamente ao texto alinhado à direita e a imagens de espelho de coisas como configuração de páginas e tabelas. Pode definir o alinhamento padrão e ordenação do conteúdo da página da direita para a esquerda incluindo simplesmente dir='rtl" numa etiqueta html.

A direção definida na etiqueta html define a direção base para o documento que alinha a descer através de todos os elementos da página. Não é necessário repetir o atributo nos elementos de nível inferiores a não ser que deseje mudar explicitamente o fluxo direcional.

Texto embebido em, por exemplo, escrita em Latim ainda corre da esquerda para a direita dentro do fluxo geral da direita para a esquerda. Tam como os números. Se estiver a trabalhar com idiomas da direita para a esquerda, deverá familiarizar-se com o básico do algoritmo bidirecional Unicode. Este algoritmo cuida de muito do texto bidirecional sem a necessidade de intervenção do autor. Existem algumas circunstâncias, porém, onde os caracteres de controlo Unicode ou markup são necessários para assegurar o efeito correto.

Tabelas Acessíveis

Elementos básicos para construção de tabelas:

Table

Apesar de criado com a finalidade de apresentar dados tabulares, o elemento TABLE é muito utilizado para a diagramação dos elementos visuais das páginas. Com o advento do CSS (folhas de estilo em cascata - linguagem voltada para a formatação visual dos elementos HTML) o uso de tabelas para solucionar o desenho de páginas deveria ter sido descartado. No entanto, tabelas continuam sendo usadas com esse objetivo.

Tr,Td

O elemento TR marca a linha da tabela e o elemento TD marca o conteúdo da célula como dado.

Lendo uma tabela: Pessoas sem problema de visão  e Pessoas portadoras de deficiência visual

Para pessoas sem problemas de visão, as informações contidas na tabela são compreendidas apenas avaliando o conteúdo da tabela, dados específicos são encontrados cruzando visualmente colunas e linhas.

No entanto para pessoas portadoras de deficiência visual, a compreensão e obtenção de dados de uma tabela não é uma tarefa fácil se essa tabela for construída de forma não acessível. Pessoas portadoras de deficiência visual utilizam-se geralmente de leitores de tela. Os leitores de tela não lêem a ‘tela’ e sim decodificam a sua estrutura HTML.

Dessa forma, o uso de elementos HTML que estruturem de forma clara a tabela auxiliam a sua leitura por pessoas que se utilizam leitores de tela.

Tabelas Acessíveis

A. CAPTION para o título da tabela

O elemento CAPTION é o título da tabela. O uso de outros elementos como H1, P, TD ou TH pode ter “visualmente” o sentido de título, mas não são semanticamente corretos, e tampouco, acessíveis.

No código HTML o elemento CAPTION deve ser colocado após a marcação TABLE e antes

de qualquer outra marcação que seguir.

Por padrão, o elemento CAPTION é mostrado centralizado logo acima da tabela. Para

modificações no visual deve ser usado o CSS.

EX:  <table sumary="" >

<caption>Material escolar</caption>

<tr>...segue o resto da tabela...

B. Atributo summary para a finalidade da tabela

Atributo summary para a finalidade da tabela. O atributo “summary” deve vir dentro do elemento TABLE servindo como informação auxiliar para entendimento da tabela para leitores de tela e displays Braille, não sendo visível em navegadores de interface gráfica.

O atributo “summary” descreve a finalidade da tabela e dá uma indicação da estrutura

geral, sendo necessário para compreensão de tabelas complexas.

EX: <table sumary="Material escolar - Levantamento comparativo de preços.">

<caption> Material escolar </caption>

<tr>...segue o resto da tabela...

C.TH para identificar os cabeçalhos

Para tabelas simples, o uso apropriado do elemento TH é essencial para tornar a tabela

acessível. Utilize o elemento TH para a identificação de cabeçalhos em linhas e colunas

pelos leitores de tela.

D. Abbr

O atributo 'abbr' permite a abreviação de um cabeçalho longo de modo que ele não seja lido por inteiro toda vez que o leitor de tela o encontrar, lendo apenas a abreviação nas

demais vezes.

Ex: <table sumary="Material escolar - Levantamento comparativo de preços.">

<caption>Material escolar</caption>

<tr>

<th abbr=”hidrocor”>Estojo caneta hidrocor / loja</th>

<th>...segue o resto da tabela...

E. THEAD, TBODY e TFOOT grupos de linhas para tabelas extensas

Os elementos THEAD, TBODY E TFOOT são necessários em tabelas extensas,

que ocupam mais de uma página.

O elemento THEAD agrupa uma ou mais linhas de cabeçalho da tabela. O elemento TFOOT

agrupa linhas com informações de rodapé. No código HTML o elemento TFOOT deve

aparecer antes do elemento TBODY.

O elemento TBODY define o corpo da tabela que contém as células de dados. Uma tabela

pode conter mais de um elemento TBODY separando os diferentes grupos de dados.

O uso desses elementos permite que:

As linhas contidas nos elementos THEAD e TFOOT sejam fixas no navegador,

permitindo que as células de dados contidas no TBODY ‘rolem’ entre as duas;

Que quando impressas, as tabelas mostrem o cabeçalho e o rodapé em todas

as páginas.

Os elementos THEAD, TFOOT e TBODY de uma tabela devem ter o mesmo número de

colunas.

F. Agrupando colunas – elementos COLGROUP e COL

O elemento COLGROUP cria um grupo/estrutura de colunas, permitindo sua diferenciação.

A tabela do próximo exemplo contém dois grupos de colunas. O primeiro grupo de colunas

contém 10 colunas e o segundo contém 5 colunas.

G. SPAN

O atributo “span” costuma ser mais vantajoso em grupos de colunas com as mesmas
características. O elemento COL é um elemento vazio, sem função estrutural e serve
como suporte para os atributos. O elemento COL pode estar no interior ou no exterior de
um grupo explícito de colunas - COLGROUP.
O atributo “span” também pode ser utilizado no elemento COL, sempre que seja
necessário isolar uma coluna no interior de um grupo.

H.Atributos id e headers - Uma forma de associar cabeçalhos e células de dados

O atributo “headers” é utilizado nas células de tabelas (<td></td>) em conjunto com o
atributo id na célula de cabeçalho (<th></th>) para associar as células de dados aos seus
respectivos cabeçalhos.
O atributo headers é requerido sempre que os cabeçalhos estiverem situados em posições

irregulares, em relação aos dados aos quais eles se referem.

I. Atributo scope -Uma outra forma de associar cabeçalhos e células de dados

De forma semelhante aos atributos “id” e “header”, o uso do atributo scope é uma outra
forma de se agrupar cabeçalhos de colunas com suas respectivas informações e assim

melhorar a acessibilidade das tabelas de dados.

MicroFormatos

Definição de Web Semântica

No início da internet, tivemos o HTML para criar e marcar o conteúdo. Com ele, que é usado até hoje em todas as páginas existentes, é possível criar textos, links, inserir imagens e tabelas, formulários, e muito mais. Porém a classificação e o uso destes elementos permite apenas funcionalidade e não significado. Um link geralmente assume a forma de um texto ou imagem, que uma vez clicado leva a outra página, mas não diz o significado, a natureza dessa relação. Adicionar significado à relação dos elementos é a idéia principal por trás da semântica na web.

POR QUE É IMPORTANTE?

Para os usuários a diferença não é tão transparente ou mesmo útil no dia a dia. Pouca ou nenhuma funcionalidade nova é agregada para a intereção do usuário. Mas para os buscadores e indexadores, isso faz toda a diferença, e isso sim acaba afetando a qualidade da navegação dos usuários, além das relações comerciais (ou não) entre os próprios sites. Um exemplo seria procurar restaurantes, com determinada faixa de preço, com boa avaliação dos frequentadores, em determinada região. Outro exemplo seria procurar todos os artigos de um determinado autor que estão publicados sob determinada licensa de uso.

Definição de Microformatos

Microformatos são conjuntos de formatos de dados que usam tecnologias e padrões web para contextualizar informações online. As informações publicadas ganham marcações moduladas que levam em conta o seu significado em situações específicas, o que facilita a sua recuperação, seu compartilhamento e sua utilização.

Os microformatos fazem parte da "web semântica", mas ao contrário desta, procuram servir mais aos usuários do que aos programas e sistemas. Como se baseiam na grafia de XHTML, qualquer pessoa com domínio desta linguagem pode criar redes de dados de acordo com suas necessidades. Sua implementação é relativamente simples.

Os microformatos podem representar diversos tipos de conteúdo publicado em páginas web, como pessoas, eventos, links. Sua aplicação faz com que o HTML da página receba marcações compreensíveis por browsers ou ferramentas de busca compatíveis com microformatos.

O uso de microformatos pode permitir que editores de conteúdo eliminem ambiguidades no conteúdo publicado. Por exemplo, a palavra "belo horizonte" deixa de ser uma inserção neutra dentro de um texto e passa a ser reconhecida como o nome de uma cidade. Desta maneira, os resultados das buscas podem ser mais precisos e adaptados às necessidades de cada usuário.

Algumas restrições incluem o fato de que estes formatos ainda não são reconhecidos por todos os browsers. Embora possam ser lidas pelo Firefox, o Internet Explorer 7 não as reconhece (embora a Microsoft inclua esta funcionalidade no IE8).

Outro fator que dificulta a sua implementação é que as páginas precisam ser assinaladas uma a uma, embora já seja possível automatizar algumas etapas do processo.

Há ainda a dificuldade de associar todo o tipo de conteúdo publicado a estes formatos. Informações como bibliografias, por exemplo, ou a programação de filmes ainda não podem ser estruturadas (embora se possa marcar sites de filmes). Mas na medida em que mais editores forem aderindo ao seu uso, os microformatos tenderão a se adaptar a demandas cada vez mais especializadas como estas.

Definição dos microformatos hCard e hCalendar

hCard

A especificação hCard é baseado no padrão internacional conhecido como “vCard”. Trata-se de um arquivo de texto que é implementado em quase todos programas que armazenam informações de contato e qualquer sistema operacional no mundo inteiro. O propósito da especificação hCard é fornecer um padrão para compartilhar informações comerciais de alguém em páginas de HTML e XML e suas linguagens derivadas e pode representar não somente informações pessoais de contato, mas também sobre empresas, grandes corporações e lugares. Estes dados podem ser publicados em páginas web e lidos por aplicativos que compreendem o formato hCard (a ferramenta hCard Creator ajuda na criação). A formatação dos dados é feita através de estilos CSS, pois estes estão definidos por marcações padrões de XHTML.

hCalendar

A especificação hCalendar é baseado no padrão internacional para calendário e informações sobre eventos chamado de “iCalendar”. A lógica é a mesma: um hCalendar é 1:1 (um por um) 100% compatível com o padrão iCalendar utilizado em softwares como o Outlook ou o Google Calendar por exemplo. Assim como o hCard possui o seu “creator”, o hCalendar também possui o seu conhecido como hCalendar Creator. Compartilhar informações de eventos é bem comum, dado esse fato surgiu a necessidade de desenvolver um padrão microformat para se compartilhar informações de eventos.A formatação dos dados também é feita através de estilos CSS.

Aplicar microformats para marcação de contato (hCard), e informações sobre evento (hCalendar).

hCard

Abaixo segue um exemplo de hCard com as principais propriedades inseridas e que são utilizadas no hCard Creator. O que esta em negrito são as propriedades do hCard.

<div class="vcard">

            <img src="http://www.revolucao.etc.br/imagens/foto_henrique_costa_pereira.jpg" alt="photo" class="photo"/>

            <span class="fn n">

                        <span  class="given-name">Henrique</span> <span  class="additional-name">Costa</span> <span class="family-name">Pereira</span>

            </span>

            <div class="org">Visie</div>

            <a class="email" href="mailto:henrique.costapereira@gmail.com">henrique.costapereira@gmail.com</a>

            <div class="adr">

            <div class="street-address">Av Paulista, 1000 - Centro</div>

            <span class="locality">São Paulo</span> ,

            <span class="region">SP</span> ,

            <span class="postal-code">38400-360</span>

            <span class="country-name">Brasil</span>

            </div>

            <div class="tel">9999-9999</div>

</div>

vcard: é a propriedade obrigatória que identifica qual a especificação que está sendo utilizada. Todas as especificações microformats começam com uma tag e uma propriedade que envolve todas as outras no formato de “pai e filho”, exatamente como no exemplo acima. Todas as outras propriedades são filho da propriedade vcard, ou seja, devem ser devidamente aninhadas dentro de uma estrutura que contenha a classe “vcard” como no exemplo dado anteriormente. As sub-propriedades podem ter ainda outras propriedades dependentes dela como no caso da propriedade “adr”. Se observar a propriedade “street-address”, ela é filha da propriedade “adr”, que por sua vez é filha direta da propriedade “vcard”.

photo: significa “foto” :D . Esta propriedade geralmente é utilizada na tag <img> que contém a foto da pessoa do hCard. Este é um daqueles casos em que não faz nenhum sentido utilizar esta propriedade em outra tag que não seja a tag <img>

fn: é a abreviação de “family name”. Essa propriedade pode ser usada para compartilhar o nome completo da pessoa sem nenhuma outra sub-propriedade (ou propriedade filho) da seguinte maneira:

<span class="fn">Henrique Costa Pereira </span>

Entretanto, existe outra propriedade que pode expandir a quantidade de descrição do nome de uma pessoa. Esta propriedade chama-se “n”, que é a abreviação de “nome” apenas e é utilizado quando se quer utilizar outras propriedades que estão presente no vCard como honorific-prefix, given-name, additional-name, family-name, honorific-suffix. Por isso que no exemplo dado anteriormente temos o seguinte trecho:

<span class="fn n">

      <span  class="given-name">Henrique</span> 

      <span  class="additional-name">Costa</span> 

      <span     class="family-name">Pereira</span>
</span>

Veja outro exemplo dessas propriedades aplicadas:

<cite class="fn n">

            <span class="honorific-prefix">Dr.</span>
            <span class="given-name">John</span>
            <span class="additional-name">Philip</span>
            <span class="additional-name">Paul</span>
            <span class="family-name">Stevenson</span>,
            <span class="honorific-suffix">Jr.</span>,
            <span class="honorific-suffix">M.D.</span>,
            <span class="honorific-suffix">A.C.P.</span>
</cite>

As subpropriedades nunca devem ser aplicadas sem as propriedades pai. Você precisa sempre saber se uma propriedade depende de outra. Isso vale para todas as especificações microformats. Sempre que existir um atributo dependente de outro, será necessário a estrutura completa na markup.

Ou seja, “fn” é o seu nome completo e “n” é a propriedade necessária para poder declarar outras propriedades especificas como “given-name” (primeiro nome), “additional-name” (nome do meio) e “family-name” (sobrenome ou último nome). Com isso nós temos nosso primeiro exemplo prático de aplicação de propriedades filhas, ou seja, propriedades que dependem de outra.

Veja um exemplo do que não deve ser feito:

<div class="vcard">

     <span class="fn">
             <span  class="given-name">Henrique Costa Pereira</span>
     </span>
</div>

Você não deve utilizar a propriedade “given-name” sem a propriedade pai, que é “fn” (que está riscada). Veja o correto abaixo:

<div class="vcard">

     <span class="fn">
             <span  class="given-name">Henrique Costa Pereira</span>
     </span>
</div>

Outra coisa que não deve ser feita é combinar a propriedade raiz, com outras propriedades como no exemplo:

<div class="vcard fn">

        <span  class="given-name">Henrique Costa Pereira</span>
</div>

E também não é possível combinar propriedades com suas sub-propriedades como no exemplo:

<div class="vcard">

           <span  class="fn given-name">Henrique Costa Pereira</span>
</div>

Os dois exemplos acima são “ilegais” e NUNCA devem ser utilizados dessa maneira em nenhuma especificação microformat composta.

org: significa “organização”. Ou seja, o nome da empresa. Esta proprieda possui outras 2 propriedades filhas “organization-name” e “organization-unit”. Entretanto, se nenhuma das duas propriedades filhas for encontrada (ou seja, se você não usá-las) a propriedade “org” assumirá automaticamente o valor de “organization-name”. Na maioria dos casos nenhuma das duas sub-propriedades de “org” são necessárias ou mesmo utilizadas.

email: a mais óbvia das propriedades. Geralmente esta propriedade é utilizada junto com a tag <a> como no exemplo:

<a class="email" href="mailto:henrique.costapereira@gmail.com">henrique.costapereira@gmail.com</a>

Entretanto esta não é uma obrigação.

adr: é uma sub-propriedade do hcard ao mesmo tempo em que também é um especificação microformat composta por si só que vamos ver mais á frente. Mas em resumo, ela significa endereço e possui outras propriedades filhas onde pelo menos uma propriedade filho é obrigatória. Veja um exemplo abaixo;

<div class="adr">

    <div class="street-address">665 3rd St.</div>
    <div  class="extended-address">Suite 207</div>
    <span class="locality">San Francisco</span>,
    <span class="region">CA</span>
    <span class="postal-code">94107</span>
    <div class="country-name">U.S.A.</div>
</div>

Veja o trecho do exemplo que eu havia dado anteriormente:

<div class="adr">

        <div class="street-address">Av Paulista, 1000 - Centro</div>
        <span class="locality">São Paulo</span> ,
        <span class="region">SP</span> ,
        <span class="postal-code">38400-360</span>
        <span class="country-name">Brasil</span>
</div>

As propriedades filha de “adr” são: “street-address”, significa “endereço da rua” (mesmo que seja uma avenida para os mais espertinhos). As outras são “locality” (localidade, geralmente o nome da cidade), “region” (região, geralmente o nome do estado ou província), “postal-code” (CEP) e “country-name” (nome do país). Outras propriedades aqui!

tel: significa “telefone” e possui uma sub-propriedade e uma excessão. Geralmente as pessoas utilizam a propriedade “tel” sozinha e sem nenhuma outra sub-propriedade junto como no exemplo geral que eu havia dado:

<div class="tel">9999-9999</div>

A sub-propriedade é chamada de “type” e pode receber os seguintes valores: “home” (para telefone residencial), work (para o telefone do trabalho), pref (para o telefone preferencial), fax (para o número do seu fax) , cell (seu celular) e pager (número do seu pager). Como “type” é uma subpropriedade de “tel”, é preciso de uma segunda propriedade para o número desses telefones propriamente ditos, que no caso é “value”.

Esta é uma propriedade genérica usada geralmente em sub-propriedades quando a propriedade pai não necessariamente precisa de filhos (ou sub-propriedades) para ter seu valor. Como o número do telefone é inserido na propriedade “tel”, quando ela possui uma sub-propriedade dentro, é necessário alocar este valor para outra propriedade. Então sempre que usar a sub-propriedade “type” para indicar o tipo do número do telefone que está compartilhando, será necessário usar também a sub-propriedade genérica chamada de “value” para colocar o número do telefone propriamente dito conforme o exemplo abaixo:

 <div class="tel">

    <span class="type">cell</span>
    <span class="value">9999-9999</span>
</div>

Só o conteúdo que importa!

Veja um exemplo abaixo:

<p class="vcard">

            <span class="fn">
                        <span  class="given-name">Marcos Borges será o nosso palestrante esta  noite</span>
            </span> e ele vai falar sobre biologia  marinha.
</p>

Quando um parser interpretar este trecho e remover o conteúdo relacionado a “given-name”, o resultado será:

 Marcos Borges será o nosso palestrante esta noite

A propriedade “given-name” refere-se ao nome e é somente isto que ela deve conter.

Bom, como o objetivo das propriedades é descrever trechos de informação, você só deve deixar dentro delas o que realmente for a informação que diz respeito a propriedade. Colocar trechos de informações desnecessárias dentro de uma propriedade é o erro mais comum ao escrever microformats. Isso ocorre quando se coloca texto que não condiz com o valor da propriedade.

hCalendar

Veja um exemplo de hCalendar. Em negrito estão as propriedades do hCalendar:

<p class="vevent">     O que: <span class="summary">Festa dos blogueiros</span><br />      Quando: <abbr class="dtstart" title="2006-09-01T19:30:00">1  de setembro às 7:30 da noite!</abbr> até ás <abbr class="dtend" title="2006-09-01T21:30:00">9:30</abbr><br  />      Onde: <span class="location">Escritório da  Visie: Av Fagundes Filho, Vila Monte Alegre, nº 145, São  Paulo/SP</span>      <span class="description">Este é  o encontro oficial de todos os blog de tenconologia do Brasil, não  perca!</span> </p>

Observe que o conteúdo que não faz parte de nenhum campo, eu deixei do lado de fora de qualquer uma das propriedades como os trechos “o que”, “quando”, “onde”, assim como eu já falei anteriormente. Observe que eu utilizei a tag <br /> propositalmente também, mas poderiam não estar ali. Se quiser uma quebra de linha, é mais interessante que você utilize CSS para isso. De qualquer maneira, eu inseri a tag <br /> somente para mostrar que ela pode sim estar ali, desde que fora de qualquer propriedade.

Vamos ver mais algumas considerações. Você observou que o formato da data é o do design pattern <abbr> + date time? Pois é, por isso foi necessário trabalhar os coneitos dele lá atrás. Brian Suda (de novo o cara) criou um XSLT que extrai o conteúdo microformato de qualquer site com o padrão hCalendar e o exporta para o formato .ics (iCalendar) utilizado pelos softwares, chamado de X2V.

As únicas propriedades OBRIGATÓRIAS do hCalendar são apenas 3. Elas são “vevent”, a propriedade raiz que não pode faltar nunca, “summary” que é uma breve descrição do evento e “dstart”, que é a data do evento (sem isso como vamos saber que algo vai acontecer?). Todas as outras propriedades são opcionais.

vcalendar – Esta propriedade pode ser usada para um ou mais eventos e é aplicada como uma propriedade raiz que supõe englobar mais de um evento, onde cada evento dentro dessa propriedade “vcalendar” possui sua própria propriedade raiz “vevent”. Esta propriedade é opcional e pode ser omitida.

vevent – Esta é a propriedade raiz e sua utilização é obrigatória.

dtstart – Data de início do evento

dtend – Data do fim do evento

duration – Duração do evento

summary – Resumo do evento, ou título do evento, ou nome do evento etc.

uid – É como se fosse um identificador do evento, onde geralmente se utiliza uma url.

dtstamp – Date e hora de quando o documento sobre o evento foi criado.

method – Valores para esta propriedade são PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINECOUNTER. Por exemplo um valor igual a “request” indica que foi feita uma requisição para o evento ocorrer.

category – Valores comuns para esta propriedade são: MEETING, APPOINTMENT, CONFERENCE, EXPO. Esta propriedade pode repetir, onde um evento pode estar enquadrado em mais de uma categoria.

location – Diz onde o evento vai acontecer.

url – Este é óbvio. A URL dá página do evento se ouver. esta propriedade e “uid” são basicamente a mesma coisa e só foi marida no padrão hCalendar porque faz parte do padrão iCalendar.

description – Uma descrição mais detalhada e/ou uma sinopse do evento diferente da informação provida pelo campo “summary”.

last-modified – Date e hora em que a informação sobre o evento foi atualizada.

status – Valores comuns que indicam o estatus de um evento são: TENTATIVE, CONFIRMED, CANCELLED

class – Indica a classificação de um evento com os seguintes valores: PUBLIC, PRIVATE, CONFIDENTIAL.

Vamos usar a criatividade agora e ver como nós podemos expandir a especificação hCalendar misturando um hCalendar com um hCard:

<p class="vevent">

        O que: <span class="summary">Festa dos blogueiros</span><br />

        Quando: <abbr class="dtstart"  title="2006-09-01T19:30:00">1 de setembro às 7:30 da  noite!</abbr> até ás <abbr class="dtend"  title="2006-09-01T21:30:00">9:30</abbr><br />

        Onde: <span class="location vcard">

                                   Escritório da <span class="fn">Visie</span>:

                                   <address class="adr">

                                       <span class="street-address">Av Fagundes Filho</span>

                                       <span class="extended-address">Vila Monte Alegre, nº 145</span>

                                       <span class="locality">São Paulo</span>

                                       <abbr class="region" title="São Paulo">SP</abbr>

                                   </address>

              </span>

                        <span class="description">Este é o encontro oficial de  todos os blog de tenconologia do Brasil, não perca!</span>

</p>

Como foi dito anteriormente, o hCard também é para empresas. Ou seja, pegue o atributo “location” e à partir dele eu criei o hcard que poderá ser “enxergado” por parsers separadamente do evento em si. Poderíamos ter apenas colocado a especificação adr ao invés da especificação hCard? Claro que sim. Tudo vai depender do nosso interesse em manipular a informação e como nós vamos querer manipulá-la. Mas não vamos parar por aqui. Vamos colocar a especificação geo nesse bolo:

<p class="vevent">

                        O que: <span class="summary">Festa dos blogueiros</span><br />

                        Quando: <abbr class="dtstart"  title="2006-09-01T19:30:00">1 de setembro às 7:30 da  noite!</abbr> até ás <abbr class="dtend"  title="2006-09-01T21:30:00">9:30</abbr><br />

                        Onde: <span class="location vcard">

                                   Escritório da <span class="fn">Visie</span>:

                                   <address class="adr">

                                        <abbr class="geo" title="42.352163;-71.062867"><span  class="street-address">Av Fagundes Filho</span></abbr>

                                        <span class="extended-address">Vila Monte Alegre, nº 145</span>

                                        <span class="locality">São Paulo</span>

                                        <abbr class="region" title="São Paulo">SP</abbr>

                                   </address>

                        </span>

                        <span class="description">Este é o encontro oficial de  todos os blog de tenconologia do Brasil, não perca!</span>

</p>

Pronto, agora nós temos um hCalendar, mais um hCard, mais a especificação geo tudo junto! Quanta informação este trecho carrega não? Por isso que chamam este tipo de microformats de “compostos”, pela capacidade que possuem de serem modulares (podem se aplicar a qualquer contexto que possua este tipo de informação) e podem ser mesclados sem perda de dados e sem redundâncias como no exemplo.

Passo a passo: Como utilizar uma ferramenta de tradução microformatos para criar um link que permita o usuário baixar ou mover o conteúdo para outro local (por exemplo, traduzir hCard para vCard para download em um programa de catálogo de endereços).

 

Vamos supor que você quer facilitar a vida de quem acessa o seu site para pessoas que não utilizam extensions (nem o Firefox), pessoas que não possuem muito conhecimento de informática, mas pelo menos importam arquivos .vcf para seus contact book como o Outlook. Brian Suda criou um arquivo de XSLT que parseia seu HTML e transforma o hcard em um arquivo vCard que pode ser importado por qualquer aplicativo que armazena informações de contato.

Basta proceder da seguinte maneira como no exemplo:

hCard para vCard

<a type="text/directory" href="http://h2vx.com/vcf/tantek.com">Download vCard</a>

hCalendar para iCalendar

<a type="text/calendar" href="http://h2vx.com/ics/microformats.org/wiki/events">Download iCalendar</a>

Nos exemplos acima apenas passei o endereço tantek.com do hCard (que é onde hcard está no XHTML) e o endereço microformats.org/wiki/events do hCalendar pelo parser em XSLT criado por Brian Suda. Basta substituir o endereçotantek.com  e o microformats.org/wiki/events pelo endereço que você quiser fornecer vCards ou iCalendar. Se você quiser alterar o XLST (que é a parte mais difícil e que já foi pensada e implementada por Suda) e colocar suas próprias features ou hospedar no seu próprio site.

Referências:

http://www.w3c.br/Padroes/WebSemantica

http://microformats.org/

http://www.avellareduarte.com.br/projeto/conceitos/websemantica/websemantica.htm

http://www.avellareduarte.com.br/projeto/conceitos/websemantica/websemantica+microformatos.htm

http://campus.tableless.com.br/2012/05/microformats-compostos-1/

http://campus.tableless.com.br/2012/05/microformats-compostos-2/

http://microformats.org/wiki/H2VX

http://h2vx.com/vcf/

http://h2vx.com/ics/

Técnicas de Substituição de Imagens e Padrões de Repetição para Imagens

Técnicas de substituição de imagens vem do termo inglês “Image Replacement”, a técnica é usada para substituir(ocultar) um texto por uma imagem com o mesmo texto, através da propriedade background do css.   

Image replacement e SEO:

SEO(Search Engine Optimization) é um conjunto de técnicas de desenvolvimento de um site, focando a melhor visibilidade nos resultados dos grandes motores de busca para este. A indexação feita pelos se baseia em textos, uma tag de grande utilização para rankeamento dos motores busca como o famos Google é a tag <h1>, partindo dessa ideia chegamos a um bom motivo para utilizar o image replacement: boa visibilidade nos motores de busca, sem deixar aparência do site de lado, conforme mostramos abaixo a codificação do exemplo anterior:

HTML:
<h1>Exemplo</h1>

CSS:
h1 { width: 200px; height: 50px; background: url('') no-repeat; text-indent: -909em; overflow: hidden;

Técnica de Gilder/Levin

Criada por Tom Gilder e Levin Alexander, esta técnica usa um SPAN vazio para conter a imagem e, usando posicionamento absoluto, sobrepõe o texto com a imagem.

Desvantagens:

Usa um SPAN vazio. Um elemento vazio é, de certa forma, algo que não deveria ser usado nunca, por que a imagem deve representar um texto realmente presente no conteúdo, conforme já mencionado, por questões de acessibilidade, levando em conta a interpretação de um leitor de tela.

Impossibilita o uso de imagens transparentes.

Vantagens:

Funciona perfeitamente para usuários com CSS habilitado e imagens desabilitadas.

Exemplo:

HTML:

<h1 id="titulo"><span></span>Ao vencedor, as batatas</h1>

CSS:

#titulo{

  width:438px;

  height:36px;

  position:relative;

  overflow:hidden;

}

#titulo span{

  position:absolute;

  width:100%;

  height:100%;

  background:#fff url() no-repeat;

}

O que a técnica faz é estabelecer as dimensões do “container”, no caso o H1, exatamente iguais às da imagem, posicioná-la com posicionamento relativo e definir overflow hidden, para que o texto não extrapole os limites, caso o usuário o redimensione pelo browser. Depois coloca o SPAN com posicionamento absoluto e com as mesmas dimensões do “container”, com a imagem de fundo. Note que o SPAN fica acima do H1, por causa do posicionamento absoluto. Não é necessário usar z-index.

Fahrner Image Replacement (FIR)

Todd Fahrner membro do W3C, colaborador da WaSP, desenvolvedor e autor consagrado no universo Web Standards é inventor da técnica de substituir texto por imagem. A técnica inventada por Fahrner recebeu seu nome e é conhecida pelo acrônimo FIR iniciais para Fahrner Image Replacement.

O código FIR:

HTML:

<h1 id="topo">

<span>CSS para Web Design</span>

</h1>

CSS:

h1#topo {

width: 270px;

height: 40px;

background-image: url(cwd.gif);

}

h1#topo span {

display: none;

}

Radu Darvas <img> Replacement

A técnica de Radu Darvas propõe o uso do elemento IMG na marcação estrutural, para abrigar uma imagem GIF transparente de um pixel com o atributo "alt" definido com o texto da informação passada pela imagem.

O código de Radu Darvas:

HTML:

<h1 id="topo">

<img src="spacer.gif" alt="CSS para Web Design!" />

<span>CSS para Web Design</span>

</h1>

CSS:

h1#topo {

width: 270px;

height: 40px;

background-image: url(cwd.gif);

}

h1#topo span { display: none;}

h1#topo img {

width: 0px;

height: 0px;

}

Stuart Langridge Image Replacement

A técnica de Stuart não usa o elemento extra SPAN e esconde o texto declarando padding igual à altura da imagem e height igual à zero. Devido ao box model quebrado do IE são acrescidas algumas regras CSS extras para aquele navegador.

HTML:

<h1 id="topo">

CSS para Web Design

</h1>

CSS:

h1#topo {

    padding: 40px 0 0 0; /* padding-top=altura imagem */

    overflow: hidden;

    background: url(cwd.gif) no-repeat;

    height: 0 !important;

    height /**/:40px; /* height=altura imagem - hack IE5's */

 }

Malarkey Image Replacement (MIR)

Na técnica de Malarkey também não aparece elemento extra SPAN e o texto é escondido com uso de letter-spacing muito grande e negativo.

É necessário um 'hack' para o Ópera que interpreta erroneamente a declaração letter-spacing.

HTML:

<h1 id="topo">

CSS para Web Design

</h1>

CSS:

 h1#topo {

 letter-spacing : -1000em;

 width:270px;

 height: 40px;

 background-image: url(cwd.gif);

 }

 /* Hack para Opera, esconde do MacIE */

 /*\*/html>body #topo {

 letter-spacing : normal;

 text-indent : -999em;

 overflow : hidden;

 }/* Fim do hack */

Lindsay Image Replacement

Nesta técnica o texto é escondido declarando-se um tamanho de fonte muito pequeno, igual a 1px e fazendo a cor do texto igual a cor do fundo.

HTML:

<h1 id="topo">

CSS para Web Design

</h1>

CSS:

h1#topo {

 background: url(cwd.gif) no-repeat;

 width: 270px;

 height: 40px;

 font-size: 1px;

 color: #xxx; /* cor do fundo */

Dave Shea Image Replacement

Dave Shea usando a técnica original com um elemento SPAN extra, proposta por Fahrner desenvolveu uma versão usando o atributo title para fornecer um toltip quando o ponteiro do mouse passa sobre a imagem e deixando o elemento SPAN vazio.

HTML:

<h1 id="topo" title="CSS para Web Design">

<span></span>

CSS para Web Design

</h1>

CSS:

h1#topo {

 position: relative;

width: 270px;

 height: 40px;

 }

h1#topo span {

 background: url(cwd.gif) no-repeat;

 position:absolute;

 width: 100%;

 height: 100%;

 }

Referências:

http://www.acessibilidade.gov.pt
http://www.acessibilidade.gov.pt/w3/TR/WCAG20-TECHS/C30.html