Tableless » xml http://tableless.com.br Tableless - Desenvolvimento inteligente com padrões web Fri, 18 May 2012 12:22:56 +0000 pt-br hourly 1 http://wordpress.org/?v=3.3.2 Documentos poliglotas com XHTML5 http://tableless.com.br/documentos-poliglotas-com-xhtml5/ http://tableless.com.br/documentos-poliglotas-com-xhtml5/#comments Wed, 16 May 2012 13:35:51 +0000 Talita Pagani http://tableless.com.br/?p=6057 Quando se começou a falar massivamente a respeito do HTML5, em 2009, muitos desenvolvedores (inclusive eu) torceram o nariz para o fato de poder voltar a utilizar a sintaxe tolerante do HTML, ou seja, tags em uppercase ou sem fechamento, valores de atributos sem aspas, fechar tags em ordem incorreta, entre outros. Inclusive, comentei especificamente sobre isso em um outro artigo.

Grande parte dos desenvolvedores aprenderam  e se habituaram a utilizar a sintaxe do XHTML, que segue as diretrizes do XML para documentos bem formados e que apresentariam erros de renderização caso essas diretrizes são fossem seguidas. Isto nos permitia códigos mais limpos e bem estruturados. Porém, no HTML5, a escolha é sua e você não será punido por não fechar tags.

Com toda essa preocupação, no mesmo ano começou a ideia do XHTML5, uma tentativa de contornar o problema, adicionando as restrições de marcação do XML a documentos escritos em HTML5. Podemos dizer que seria uma tentativa de unir o melhor de cada especificação. O artigo escrito por Bruce Lawson para o HTML5 Doctor (com versão traduzida no Pinceladas da Web) foi um dos primeiros a comentar sobre o tema.

Durante cerca de 1 ano isto era uma forma, digamos, marginalizada de tratar essa questão, por não ser algo reconhecido pelo  WHATWG / HTML WG. Mas em 2010 surgiu o primeiro draft com a proposta de nortear o uso do HTML5 com a sintaxe do XML/XHTML. O W3C denominou essa metodologia de marcação poliglota.

O que é um documento com marcação poliglota?

Um documento com marcação poliglota é um documento escrito em HTML5 que pode ser processado tanto como HTML quanto como XML dentro de um conjunto de restrições definidas, porém, ainda seguindo a especificação do HTML5. Eles são compatíveis com o HTML e XHTML.

Significa que você pode utilizar todo o poder do HTML5 dentro do padrão de marcação bem formada do XML. É importante ressaltar que isto não afeta as tags que você pode utilizar. Por exemplo, elementos que são considerados deprecated em XHTML mas válidos no HTML5 continuam a ser válidos. Uma exceção é com relação a algumas tags que são excluídas de documentos poliglotas por não serem possível de serem replicadas em um parser XML (como é o caso da tag <noscript>).

Mas em linhas gerais, esta “fusão” não altera a especificação, mas sim as regras de sintaxe para processamento e há influência no DOM também (ex.: document.write não é permitido, mas sim innerHTML).

Segundo o W3C, um documento poliglota resulta em:

  • Um documento HTML5 válido;
  • Um documento XML bem formado (mas não significa um documento XML válido);
  • DOM idêntico quando processado tanto como HTML quanto como XML, isto porque os parsers geram diferentes DOMs para determinados atributos relativos ao XML.

Como escrever um documento poliglota

Um dos principais requisitos para escrever um documento em XHTML5 é o MIME-type utilizado. Isto vai definir se o navegador irá interpretar o documento como HTML ou XHTML. Segundo o WHATWG, um documento HTML5 se torna um documento poliglota se for provido o MIME-type application/xhtml+xml.

1
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />

Até algum tempo atrás, o IE não suportava este MIME-type. Para isso, você pode indicar que o MIME-type é o usual text/html. Ele pode ser utilizado junto com o primeiro (separando por vírgula), ou pode ser feita uma validação do navegador para decidir qual o MIME-type a ser utilizado.

O doctype passa a ser opcional, mas ainda é recomendável utilizar para prevenir o quirks mode dos navegadores. Se utilizado, a palavra doctype deve ser escrito adequadamente em uppercase, ex.: <!DOCTYPE html>. A meta-tag que especifica o charset e a declaração <?xml version=”1.0” encoding=”UTF-8”?> (herdada do XHTML 1.1) também passam a ser opcionais se o charset desejado para o documento é UTF-8 (padrão do XML).

Além disso é preciso definir também o namespace do XHTML na tag <html>:

1
<html xmlns="http://www.w3.org/1999/xhtml">

Ao utilizar recursos como SVG e MathML, é preciso especificar também o atributo xml para a tag raiz correspondente de cada um.

Outras recomendações são:

  • Usar tanto o atributo lang quanto xml:lang na tag <html>;
  • Usar tbody / thead / tfoot em <table>s;
  • Quando o elemento <col> é utilizado em tabelas, utilizar também o elemento <colgroup>;
  • Não utilizar o elemento <noscript>;
  • Não iniciar as tags <pre> e <textarea> com linha em branco;
  • Utilizar innerHTML ao invés de documento.write;
  • Para scripts embutidos na página, escreva o código entre uma seção CDATA com os delimitadores comentados. É uma forma de fazer com que o parser do XML (que analisa apenas a marcação) não acuse erros ao utilizar < ou & no script;
  • Os atributos xml:space e xml:base são permitidos apenas nos elementos relativos a SVG e MathML;
  • Elementos que podem ter conteúdo mas estão vazios não devem ser minimizados para o formato de tag órfã. Ex.: <p /> não deve ser utilizado, mas sim <p></p>.

Ao escrever documentos poliglotas, é possível utilizar todas as funcionalidades do HTML5 com uma garantia de código bem formado de acordo com as restrições do XHTML. Com isso, é possível ter um código mais organizado e consistente que seja mais fácil de produzir, manter e reutilizar a longo prazo, principalmente quando este trabalho é realizado em equipe.

Referências

Polyglot Markup: HTML-Compatible XHTML Documents
XHTML5 in a nutshell
Benefits of polyglot XHTML5
HTML 5 + XML = XHTML 5

Posts Relacionados

]]> http://tableless.com.br/documentos-poliglotas-com-xhtml5/feed/ 13 Ah, o maravilhoso mundo real http://tableless.com.br/ah-o-maravilhoso-mundo-real/ http://tableless.com.br/ah-o-maravilhoso-mundo-real/#comments Thu, 10 Sep 2009 21:03:31 +0000 Elcio Ferreira http://tableless.com.br/?p=1601 O Diego publicou, há mais de uma semana, um artigo sobre o impacto da mudança de estratégia do W3C em relação ao ciclo de vida de seus padrões. O artigo gerou algumas opiniões contrárias nos comentários, em relação ao fato de ele ter dito que bordas arredondadas são mais importantes que a web semântica e em relação à estratégia de especificações modulares do W3C. Vou compartilhar minha opinião sobre os dois pontos.

Em primeiro lugar, é importante distinguir o ideal daquilo que é possível fazer. Li um bocado sobre RDF e ontologias há uns dez anos. Li “A Revolução Inacabada”, vi o RSS nascer e se tornar popular, vi as primeiras aplicações entenderem o formato. RDF falhou. Dez anos se passaram e continuamos escrevendo HTML para ser lido por navegadores e só. Há poucos exemplos de aplicações semânticas na vida real, e a maioria seria desenvolvida de uma forma ou de outra.

Há muita gente, por exemplo, definindo seu próprio padrão de XML para trocar dados com sistemas parceiros. Quantos desses estão usando RDF, com uma ontologia interpretada automaticamente por sistemas que “descobrem” os serviços um do outro? Ou seja, não há novidades nisso nos últimos dez anos.

Escrever HTML bom é importante, porque vai ajudar o Google a indexar seu site e vai facilitar a vida de quem tentar HTML parsing nele. Mas, seja sincero, você tem mesmo esperanças de que alguém vá lê-lo como XML? Vê alguma vantagem real em validar seu código como XHTML, além de provar a si próprio que fez tudo direito? E onde está a promessa dos microformats? Microformats só fazem diferença se forem usados por muita gente. Ninguém vai fazer um parser de um formato usado em apenas um site. Você consegue citar, de cabeça, cinco sites que usem microformats e não foram feitos por você? Ah, claro, não vale incluir na lista o microformats.org.

Nem RSS é um bom exemplo de aplicação de semântica XML. Existem pelo menos dois formatos populares do padrão, além do padrão Atom, que serve para a mesma coisa. E não sei de nenhum leitor de RSS de sucesso que faça parsing dos feeds como XML. O que todos fazem é ler e interpretar a string. É isso mesmo que você entendeu, quase tão bom quanto um CSV! Outro exemplo digno de nota é o SOAP, que foi criado para fornecer aos webservices a capacidade de “autodescoberta”. Você conhece alguém que use isso de verdade? Já viu algum robô que varre a web em busca de serviços e entende sozinho como usá-los? SOAP só tem a vantagem de oferecer tooltips para ajudar os programadores .Net que usam Visual Studio. Enquanto isso, lá fora, XMLRPC e REST (com JSON) estão mudando o mundo.

Por que essas tecnologias falharam, embora pareçam todas boas idéias? Meu palpite é que elas exigiam um raciocínio de longo prazo, um tipo de aposta, que é muito difícil de conseguir. Embora XHTML, Microformats ou SOAP sejam idéias muito boas, aplicá-las em seu site só vai ter valor se muito mais gente o fizer. Se você aplicar o formato sozinho vai perder seu tempo.

O que é muito diferente de, por exemplo, deixar de usar tabelas para layout, escrever bom HTML ou usar jQuery. Essas coisas lhe devolvem um benefício imediato. Se deixar de usar tabelas para layout vai ter um site mais leve e vai perder muito menos tempo quando tiver que mudar o layout, se escrever HTML bom vai ter menos trabalho para escrever CSS, para fazer o CSS mobile e o de impressão, e se usar jQuery vai escrever javascript em um terço do tempo.

Note que esses três exemplos também tiram benefícios do fato de muita gente estar usando. Há muitos bons lugares para se aprender HTML e CSS, há muitos sistemas Open Source que já trabalham gerando código bom e os buscadores entendem a semântica do bom HTML. Mas você não depende desses benefícios para tomar a decisão de uso. Quando começamos, há dez anos, a fazer layouts tableless, não aparecíamos melhor no Google e praticamente não havia sistemas gerando HTML direito. Mas o fizemos assim mesmo porque os benefícios imediatos compensavam o esforço.

É por isso que eu temo que nunca teremos uma web semântica de verdade, e estamos condenados a fazer HTML parsing para sempre.

Há exceções. RSS, por exemplo. RSS é uma sombra do que poderia, mas é um padrão de sucesso, amplamente adotado. E não pode ser explicado com minha teoria do benefício individual imediato. Se você estiver usando RSS sozinho no mundo, não terá nenhum benefício. Talvez o sucesso do RSS se deva ao fato de precisar de uma pequena rede de usuários para oferecer um grande benefício.

Você já se perguntou como foram vendidos os primeiros aparelhos de FAX? Ter um FAX só faz sentido se mais gente tiver. Foram vendidos aos pares. As empresas o compravam para trocar documentos entre a matriz e as filiais. O fato de poder trocar documentos com o resto do mundo era, no início, um “benefício adicional”. Se você precisa trocar conteúdo com um site parceiro e vocês forem os únicos usuários de RSS no mundo, terá valido a pena. Conforme a comunidade de usuários aumentava, o valor de ter RSS crescia. Muita gente começou a usar Bloglines e todo mundo queria entrar na festa.

Há alguns anos eu percorri o país com o pessoal da Locaweb comparando o modelo de adoção do RSS com o que eu imaginava que seriam os microformats. Eu estava errado. Pense um segundo no formato de reviews dos microformats. Qual o real benefício de usá-lo? Há alguma aplicação indispensável, onde você realmente quer estar, baseada em hReview? Para que você vai perder seu tempo?

Será que não estamos resolvendo o problema errado? Quando o Diego diz que bordas arredondadas são mais importantes que RDF, será que ele não tem razão? Para meus clientes, hoje, bordas arredondadas com CSS significam um site mais rápido, mais barato (menos tempo gasto recortando imagens) e, para os sites muito visitados, economia de banda. É uma diferença pequena, mas é uma vantagem. E RDF? Além de oferecer RSS, que nem vai ser lido como XML, o que eu posso fazer de real hoje com RDF para meus clientes?

Desculpe se meu raciocínio parece mesquinho. Ele é. Estou tentando ser realista. Uma das principais influências sobre as decisões humanas é a inércia, e não acredito que o mundo vá, num futuro próximo, adotar de maneira revolucionária o RDF ou mesmo o XHTML. Ainda acho essas idéias fantásticas, só não sei se são possíveis.

O realismo também me faz crer que a nova estratégia de especificações modulares do W3C é uma coisa boa. Sofremos décadas com implementações parciais do HTML 4 e do CSS 2. Agora vamos assumir a realidade inevitável. Os desenvolvedores de navegador se sentirão mais à vontade para dizer a você o que funciona ou não. E não precisamos esperar anos para a definição de um padrão. Podemos usar os recursos com os quais o consórcio já concordou hoje. Leva mesmo alguns anos para o W3C bater o martelo sobre determinado padrão, e as especificações modulares representam um ciclo de releases muito mais dinâmico.

Já temos um acordo sobre CSS Transform, bordas arredondadas, múltiplos backgrounds, repetição no DOM, validadores de formulários, SVG, DOM Storage, querySelectors e uma série de outros recursos legais. Por que esperar até a próxima Olimpíada para dizer aos desenvolvedores de browsers: “Ok, pessoal, fechamos tudo, HTML 5 e CSS 3 já são padrões, podem implementar”? De qualquer maneira, a adoção modular das especificações do W3C é inevitável. Embora a especificação tenha saído inteira, a adoção foi modular no HTML 3, no HTML 4, no CSS 2. Sabendo que não vai ser diferente mesmo, não é melhor que tenhamos bonitas tabelas de compatibilidade entre o que existe e o que cada navegador suporta?

Dá uma olhada na lista de módulos do CSS3. Você não quer esperar isso tudo ficar pronto para ter bordas arredondadas.

Posts Relacionados

]]> http://tableless.com.br/ah-o-maravilhoso-mundo-real/feed/ 33 SEO – Sitemaps http://tableless.com.br/seo-sitemaps/ http://tableless.com.br/seo-sitemaps/#comments Wed, 02 Jul 2008 15:47:23 +0000 Diego Eis http://tableless.com.br/?p=996 O Sitemaps é um formato simples de XML que serve para informar aos sistemas de buscas sobre seus endereços disponíveis para indexação. Esse XML relaciona as URLs existentes do seu site, com algumas informações como data da última atualização, prioridade da página em relação às outras páginas e freqüencia de atualização.

O sitemap.xml é um arquivo que pode ser gerado automaticamente por um plugin ou até mesmo escrito à mão pelo desenvolvedor.

O código básico do Sitemap:

1
2
3
4
5
6
7
8
9
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
    <loc>http://www.example.com/</loc>
<em>    <lastmod>2005-01-01</lastmod></em>
<em>    <changefreq>monthly</changefreq>
    <priority>0.8</priority></em>
</url>
</urlset>

As tags que podem ser inseridas no sitemap.xml são essas:

<urlset>
Executa o encapsulamento do arquivo e faz referência ao padrão de protocolo atual.

<url>
Tag pai de cada entrada de URL. O restante das tags são as tags filhas dessa tag.

<loc>
URL da página. Esse URL deve começar com um protocolo (como http) e terminar com
uma barra final, caso seja exigido pelo seu servidor. Esse valor deve conter menos
de 2.048 caracteres.

<lastmod>
A data da última modificação do arquivo. Essa data deve estar no formato de
data e hora do W3C. Esse formato permite omitir o horário, se desejar, e
usar AAAA-MM-DD.

Lembre-se de que esta tag é separada do cabeçalho If-Modified-Since (304) que o servidor pode retornar, e os mecanismos de pesquisa podem usar as informações de ambas as fontes de forma diferente.

<changefreq>
A freqüência com que a página é alterada. Esse valor fornece informações gerais para os mecanismos de pesquisa e pode ser que ele não corresponda exatamente à freqüência de indexação da página. Os valores válidos são:

  • always
  • hourly
  • daily
  • weekly
  • monthly
  • anual
  • never

O valor “always” deve ser usado para descrever os documentos que sempre são alterados quando acessados. O valor “never” deve ser usado para descrever os URLs arquivados. Observe que o valor dessa tag é considerado uma dica e não um comando. Mesmo que os indexadores de mecanismo de pesquisa possam considerar essas informações ao tomar decisões, pode ser que indexem as páginas marcadas como “horárias” com menos freqüência do que isso e talvez façam a indexação de páginas marcadas como “anualmente” com mais freqüência do que isso. Os indexadores podem indexar páginas marcadas como “nunca” periodicamente, para que possam lidar com alterações inesperadas
nessas páginas.

<priority>
A prioridade desse URL em relação a outros URLs do mesmo site. Os valores válidos vão de 0.0 a 1.0. Esse valor não afeta o modo como as páginas são comparadas às páginas em outros sites — apenas permite que os mecanismos de pesquisa saibam quais páginas você considera mais importantes para os indexadores.

A prioridade padrão de uma página é 0,5.
Observe que não é provável que a prioridade atribuída a uma página influencie a posição dos URLs nas páginas de resultados de um mecanismo de pesquisa. Os mecanismos de pesquisa podem usar essas informações quando selecionam entre URLs no mesmo site. Use essa tag para aumentar a probabilidade de a maioria das páginas importantes estarem presentes em um índice de pesquisa.

Além disso, observe que a atribuição de uma prioridade alta a todos os URLs no site provavelmente não o ajudará. Como a prioridade é relativa, ela só é usada para priorizar os URLs do seu site.

Tabela retirada do sitemaps.org

Local dos arquivos sitemaps.xml

É importante saber que o local que o sitemap.xml é colocado determina o quais urls podem ser colocadas no arquivo. Exemplo: fiz um sitemap.xml para o site de treinamentos da Visie cuja URL é visie.com.br/treinamento. No meu sitemap.xml apenas poderá haver URLs que comecem com visie.com.br/treinamento e não apenas visie.com.br.

Todas as URLs que estão no Sitemap precisam utilizar o mesmo protocolo – no exemplo da Visie estou utilizando o HTTP – e precisam estar no mesmo host que o Sitemap. Por exmeplo, se o Sitemap estiver localizado em: visie.com.br/treinamento/sitemap.xml, ele não pode incluir URLs de um subdominio.visie.com.br.

Informando os buscadores que seu sitemap.xml existe

Há duas maneiras fáceis para avisar aos sistemas de busca que seu sitemap.xml está disponível:

  • Enviando o seu Sitemap por meio da interface de envio do mecanismo de pesquisa
  • Especificando a localização do Sitemap no seu arquivo robots.txt

Enviando o seu Sitemap por meio da interface de envio do mecanismo de pesquisa. O Google tem um local muito interessante onde além de informar o endereço do seu sitemap.xml você pode ter uma série de outras informações importantes para seu site, é o Google Webmaster Tools.

Especificando a localização do Sitemap no seu arquivo robots.txt. Para indicar o sitemap.xml pelo robots.txt basta acrescentar essa linha: Sitemap:

Se você quiser, você pode colocar vários endereços de Sitemaps, bastando inserir várias linhas como as de cima indicando os endereços dos respectivos sitemaps.

Ter um sitemap.xml não garante que você uma URL seja ou não mais indexada que as outras. Mesmo assim, é um adendo para que os buscadores fiquem mais informados com os endereços do seu site. Se você não utiliza nenhum plugin para que o sitemap.xml seja gerado automaticamente, fique atento às atualizações das URLs. Você pode estar informando aos buscadores URLs antigas e isso pode afetar nos resultados organicos com o do Google. Se você quiser testar alguns plugins ou programas para gerar seu sitemap.xml automaticamente, visite este link.

Posts Relacionados

]]> http://tableless.com.br/seo-sitemaps/feed/ 26 Charsets e Encodes – Tabelas de caracteres http://tableless.com.br/charsets-e-encodes-tabelas-de-caracteres/ http://tableless.com.br/charsets-e-encodes-tabelas-de-caracteres/#comments Mon, 31 Mar 2008 10:00:18 +0000 Diego Eis http://tableless.com.br/?p=965 Quando você escreve um documento HTML (ou qualquer outra linguagem baseada em SGML) é necessário que especifiquemos o Charset utilizado. O Charset é o conjunto de caracteres utilizados para escrever o documento. Um jogo de caracteres consiste em ter 1) repertório com caracteres e 2) uma posição de referência para cada um dos caracteres no repertório. Cada caractere é identificado e localizado por este código de posição. Por exemplo, na tabela ASCII, as posições 65, 66 e 67 se referem às letras A, B e C respectivamente. Abaixo, veja a tabela de caracteres ASCII:

  • 00 – (NUL)
  • 01 – (SOH)
  • 02 – (STX)
  • 03 – (ETX)
  • 04 – (EOT)
  • 05 – (ENQ)
  • 06 – (ACK)
  • 07 – (BEL)
  • 08 – (BS)
  • 09 – (HT)
  • 10 – (LF)
  • 11 – (VT)
  • 12 – (FF)
  • 13 – (CR)
  • 14 – (SO)
  • 15 – (SI)
  • 16 – (DLE)
  • 17 – (D1)
  • 18 – (D2)
  • 19 – (D3)
  • 20 – (D4)
  • 21 – (NAK)
  • 22 – (SYN)
  • 23 – (ETB)
  • 24 – (CAN)
  • 25 – (EM)
  • 26 – (SUB)
  • 27 – (ESC)
  • 28 – (FS)
  • 29 – (GS)
  • 30 – (RS)
  • 31 – (US)
  • 32 – (Espaço)
  • 33 – !
  • 34 – “
  • 35 – #
  • 36 – $
  • 37 – %
  • 38 – &
  • 39 – ‘
  • 40 – (
  • 41 – )
  • 42 – *
  • 43 – +
  • 44 – ,
  • 45 – –
  • 46 – .
  • 47 – /
  • 48 – 0
  • 49 – 1
  • 50 – 2
  • 51 – 3
  • 52 – 4
  • 53 – 5
  • 54 – 6
  • 55 – 7
  • 56 – 8
  • 57 – 9
  • 58 – :
  • 59 – ;
  • 60 – <
  • 61 – =
  • 62 – &gt/
  • 63 – ?
  • 64 – @
  • 65 – A
  • 66 – B
  • 67 – C
  • 68 – D
  • 69 – E
  • 70 – F
  • 71 – G
  • 72 – H
  • 73 – I
  • 74 – J
  • 75 – K
  • 76 – L
  • 77 – M
  • 78 – N
  • 79 – O
  • 80 – P
  • 81 – Q
  • 82 – R
  • 83 – S
  • 84 – T
  • 85 – U
  • 86 – V
  • 87 – W
  • 88 – X
  • 89 – Y
  • 90 – Z
  • 91 – [
  • 92 - \
  • 93 - ]
  • 94 – ^
  • 95 – _
  • 96 – `
  • 97 – a
  • 98 – b
  • 99 – c
  • 100 – d
  • 101 – e
  • 102 – f
  • 103 – g
  • 104 – h
  • 105 – i
  • 106 – j
  • 107 – k
  • 108 – l
  • 109 – m
  • 110 – n
  • 111 – o
  • 112 – p
  • 113 – q
  • 114 – r
  • 115 – s
  • 116 – t
  • 117 – u
  • 118 – v
  • 119 – w
  • 120 – x
  • 121 – y
  • 122 – z
  • 123 – {
  • 124 – |
  • 125 – }
  • 126 – ~
  • 127 – (DELETE)

A tabela de caracteres ASCII (Código Padrão Americano para Intercâmbio de Informações) foi a primeira tabela utilizada em larga escala. O computador foi desenvolvido nos Estados Unidos. No vocabulário americano, não existem acentos, além disso, era um código de 7 bits, e não 8. Ou seja, ao invés de 256 posições, a tabela ASCII tinha apenas 128 posições – como você sabe, tudo nos computadores são um grupo de zeros (0) e uns (1) chamados de bits. Esses zeros e uns formam grupos de oito em oito que chamados de bytes e representam um número entre 0 e 255. Como as imagens, áudio, vídeos, programas e tudo o que temos nos sistemas de hoje, os caracteres que aparecem na sua tela são grupos de zeros e uns.
O computador se popularizou e a necessidade de utilizar acentos e outros tipos de caracteres (Chineses, por exemplo) tornou-se um problema.
Hoje, a maioria das tabelas utilizadas foram criadas suprindo as necessidades de um idioma específico, por este motivo elas se tornaram muito limitadas.
Por exemplo, se você estiver escrevendo um documento utilizando a tabela de caracteres chinesa, você não poderá escrever algo em hebraico neste documento.
Por conta disso muitos problemas podem surgir, por exemplo, seria impossível criar um curso online de hebraico para chineses. Será também um problema se você tiver que fazer um site ou sistema com suporte a diversos idiomas. Por exemplo, um sistema de blog projetado para uso internacional. Isso por que a posição dos caracteres varia de tabela para tabela. Dois codificadores podem usar o mesmo número para dois caracteres diferentes ou usar números diferentes para o mesmo caractere.

A tabela de caractéres Unicode – UTF-8

A Web é acessada por pessoas do mundo inteiro. Ter um sistema ou um site que limite o acesso e pessoas de outros países é algo que vai contra a tradição e os ideais da internet. Por isso, foi criado uma tabela que suprisse essas necessidades, essa tabela se chama Unicode. A tabela Unicode suporta algo em torno de um milhão de caracteres. Ao invés de cada região ter sua tabela de caracteres, é muito mais sensato haver uma tabela padrão com o maior número de caracteres possível. Atualmente a maioria dos sistemas e browsers utilizados por usuários suportam plenamente Unicode. Por isso, fazendo seu sistema Unicode você garante que ele será bem visualizado aqui, na China ou em qualquer outro lugar do mundo.
O que o Unicode faz é fornecer um único número para cada caractere, não importa a plataforma, nem o programa, nem a língua.

Antes de começar, você precisa saber

Há algumas recomendações que você precisa saber antes de começar a mudar seu site para Unicode.
Existem três principais maneiras para você indicar a seu site qual tabela de caractere você está utilizando:

  1. Cabeçalho HTTP Content-type – Desta forma é necessário configurar o servidor web, algo que não é fácil nem para qualquer um. Dependendo de onde você trabalha, se for em um lugar grande, com vários sites neste mesmo servidor, pode ser a melhor maneira porque você terá que fazer isso uma vez. Caso for vários projetos com servidores diferentes isso pode ser uma dor de cabeça.
  2. Metatag Content-type – Colocando este código no HEAD de seu documento, ele avisará para o browser localmente e na hora da renderização do site qual Charset ele deve utilizar para exibir os caracteres. Esta é uma ótima escolha caso você não tenha acesso aos servidores. Certamente é a maneira mais simples de ser utilizada.
    1
    &lt;meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /&gt;
  3. Através do prolog xml – O prolog XML é utilizado em documentos XML ou XHTML para indicar a versão e a tabela de caracteres daquele documento.
    1
    &lt;? xml version="1.0" encoding="UTF-8" ?&gt;

    Não é uma boa utilizar este prolog por conta do chaveamento do Internet Explorer 6 para Quirks Mode. Quando o prolog é utilizado, o Internet Explorer 6 renderiza os sites como o Internet Explorer 5, trazendo muitos problemas de compatibilidade. Não recomendo.

Outro ponto importante é não esquecer de salvar seu documento no formato da tabela que você indicou. Não adianta nada indicar que código que está utilizando a tabela de caracteres UTF-8 e seu editor salvar seus documentos com a tabela ISO-8859-1. Isso fará com que os caracteres de seu documento apareçam corrompidos. Por isso, ao definir qual será a tabela utilizada no projeto (recomendo sempre UTF-8), defina como seu editor irá salvar seus documentos. Todos os editores de código hoje em dia tem essa opção, basta procurar. Não adianta também você salvar seus arquivos em UTF-8 e o resto da equipe continuar utilizando ISO-8859-1. Os arquivos irão corromper da mesma maneira. É uma decisão que a equipe inteira deve tomar para não haver retrabalho e dor de cabeça.

Se um projeto já está no ar, é bom fazer uma análise para ter certeza se vale a pena ou não mudar a tabela de um projeto que já está no ar e funcionando. Recomendo que esse novo padrão sempre comece a ser utilizado em novos projetos. Mesmo assim, um bom programador pode fazer um script que converta a tabela de caracteres de um diretório inteiro.

O importante é garantir que seu site aqui seja visto da maneira correta em outros lugares do mundo. Isso é importante para você e seu cliente.

Posts Relacionados

]]> http://tableless.com.br/charsets-e-encodes-tabelas-de-caracteres/feed/ 17 WordPress – Uma pequena introdução http://tableless.com.br/wordpress-uma-pequena-introducao/ http://tableless.com.br/wordpress-uma-pequena-introducao/#comments Sun, 10 Feb 2008 02:00:07 +0000 Diego Eis http://tableless.com.br/wordpress-uma-pequena-introducao O WordPress não foi feito para ser um CMS. Ele foi criado primeiramente para suprir necessidades de criação de blogs. Por acaso, talvez como se fosse um acidente, começamos a utilizá-lo para criar websites, desde os mais simples até os mais complicados. O pessoal do WordPress curtiu a ideia e agora está melhorando cada vez mais o sistema para que ele se torne um CMS de verdade, mesmo assim mantendo toda a simplicidade do WordPress original. E o melhor, é tudo de graça.

Quero mostrar aqui o caminho das pedras. O que você precisa aprender para não ficar batendo cabeça no começo. É coisa simples.

Criando o index.php e o style.css

Para fazer um tema de WordPress, você precisa apenas de dois arquivos: index.php e o style.css.

O style.css tem uma pequena sintaxe no começo do arquivo com informações do autor do Template. Essas informações serão utilizadas pelo WordPress na tela de Templates.

A sintaxe que está escrita no meu style.css é este:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Você pode utilizar esse código e modificar para ficar com suas informações. Não precisa decorar, isso é coisa de maluco. ;-)

Crie um <strong>style.css</strong> com este código dentro. Não iremos utilizar o CSS neste artigo.

Crie também um <strong>index.php</strong> com a estrutura básica de HTML. Eu utilizo sempre assim:

[cc lang="html">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title></title>
</head>
<body>

</body>
</html>

Daqui para frente, irei colocar apenas o código que irá dentro do BODY do documento. Portanto, tudo que iremos ver agora, insira dentro do BODY do seu documento.

As Template Tags

O segredo do WordPress são as Template Tags. Você pode conferir todas aqui: http://codex.wordpress.org/Template_Tags

Os templates do wordpress são escritos em PHP. Isso torna pro designer um pouco complicado, mas não muito. Se você souber um pouco de PHP, fazer um template é muito fácil, porque PHP é uma linguagem que todo mundo usa. Para facilitar, o WordPress chama as funções do PHP que são utilizadas pelo seu sistema de Template Tags. As Template Tags não passam de funções PHP que recuperam do banco, informações que você precisará para compor o conteúdo do site. Para o programador isso não muda nada. Mas para o pessoal que não é tão íntimo assim com a linguagem PHP, a forma que usamos essas “funções” (Template Tags) facilita demais.

O Loop – Listando os posts na página

O Loop é o responsável pelo trecho de código que será repetido para cada post impresso na tela.

1
2
3
<?php while ( have_posts() ) : the_post (); ?>

<?php endwhile; ?>

Pra você chamar os posts do blog é muito simples. Você começará utilizando duas Template Tags dentro deste código de Loop.

1
2
3
4
<?php while ( have_posts() ) : the_post (); ?>
<h2><? the_title(); ?></h2>
<? the_content(); ?>
<?php endwhile; ?>

A primeira Template Tag que coloquei foi a the_title(). Ela chama os títulos dos posts do site.
A segunda, the_content() chama o conteúdo dos posts. O Conteúdo vem escrito da forma que você criou no WordPress.

Apenas com esse código acima, você não faz um blog completo. Um blog tem outras características importantes. E são elas que iremos ver agora.

Características de um Blog

Há algumas características que compõem um blog. Essas características são encontradas geralmente em blogs, isso não quer dizer que em sites de notícias não podem contem essas características:

  • Comentários
  • Categorias
  • Data, autor
  • Feed
  • Arquivo (histórico)
  • Busca
  • Permalink

Não iremos mostrar em nosso código como se faz Comentários nem Categorias. O Artigo iria ficar muito mais complicado. Portanto, se estiver interessado, faça a Oficina de WordPress da Visie.

Vamos agora melhorar um bocado esse código para que o site se pareça mais com um blog.

Primeiro, vamos colocar Permalinks nos títulos dos posts.

1
2
3
4
5
6
<?php while ( have_posts() ) : the_post (); ?>

<h2><a href="<? the_permalink(); ?>"><? the_title(); ?></a></h2>
<? the_content(); ?>

<?php endwhile; ?>

Autor e Data

A Template Tag que iremos utilizar é a the_author_posts_link() para Autor, que colocará a o nome do Autor com o link para seus posts. E a the_time() para colocar a data.

1
2
3
4
5
6
7
8
<?php while ( have_posts() ) : the_post (); ?>

<p>por <? the_author_posts_link(); ?> em <? the_time(); ?></p>

<h2><a href="<? the_permalink(); ?>"><? the_title(); ?></a></h2>
<? the_content(); ?>

<?php endwhile; ?>

Você pode deixar a Template Tag the_time do jeito que você quiser. Ela usa aquela tabela de formatação padrão de data do PHP, você pode encontrar essa tabela aqui: http://php.net/date/
Iremos formatar nossa data aqui:

1
2
3
4
5
6
7
8
<?php while ( have_posts() ) : the_post (); ?>

<p>por <? the_author_posts_link(); ?> em <? the_time(d/m/Y); ?></p>

<h2><a href="<? the_permalink(); ?>"><? the_title(); ?></a></h2>
<? the_content(); ?>

<?php endwhile; ?>

BUSCA

Para colocar um formulário de busca é muito simples. O código do formulário será:

1
2
3
4
<form action="<? bloginfo('home'); ?>">
<input name="s" type="text" id="busca" value="<? =$_GET['s'] ?>" />
<input type="submit" value="Procurar" />
</form>

A Template Tag bloginfo() tráz do banco informações sobre o site. Neste caso, ele vai trazer a URL da home do site.
Os inputs do formulário de busca do WordPress já vem com nomes pré-definidos, o input de busca, por exemplo, chama-se s.

Nosso código está assim agora.

1
2
3
4
5
6
7
8
9
10
11
12
13
<form action="<? bloginfo('home'); ?>">
<input name="s" type="text" id="busca" value="<? =$_GET['s'] ?>" />
<input type="submit" value="Procurar" />
</form>

<?php while ( have_posts() ) : the_post (); ?>

<p>por <? the_author_posts_link(); ?> em <? the_time(d/m/Y); ?></p>

<h2><a href="<? the_permalink(); ?>"><? the_title(); ?></a></h2>
<? the_content(); ?>

<?php endwhile; ?>

Arquivo e Histórico

Para criar os arquivos, ou histórico, iremos utilizar a Template Tag: wp_get_archives().

1
<? wp_get_archives(); ?>

Por padrão, essa Template Tag irá gerar uma lista de links dos meses que há posts. Preste bem atenção no código HTML que ele retorna. Ele cria uma lista de LI sem UL ou OL envolta.

Por tanto, temos que escrever dessa forma:

1
2
3
<ul>
<? wp_get_archives(); ?>
</ul>

Ele faz deste modo caso você queira colocar uma CLASS ou ID para nomear a lista.

Linkando o FEED o arquivo CSS

O WordPress já cria os Feeds automaticamente. O trabalho que temos é colocar um link para o que o visitante consiga copiar o endereço do RSS e cadastrar no leitor de Feeds preferido dele. Podemos oferecer em RSS, RSS 2 ou ATOM. Existem pessoas que oferecem os três formatos. Vamos oferecer apenas um formato: o RSS2.

A tag link tem um atributo ‘rel’. O atributo rel é mandatório, ele vai dizer qual será o resto da tag. Se você por exemplo colocar o valor rel=”stylesheet”, você está dizendo ao navegador que essa tag link é relativo a uma folha de estilo.

O valor ‘alternate’ diz ao navegador que estamos diponibilizando o conteúdo de nosso site em um meio alternativo:

1
2
<link rel="alternate" ...
<link rel="stylesheet" ...

A tag type serve para indicar o tipo de arquivo que será carregada. No caso da folha de estillo, existem dois tipos que são utilizados hoje: o XSLT, que é utilizado para formatar código XML. E o tipo CSS, que é para formatar código HTML.

1
2
<link rel="alternate" type="application/rss+xml" href="<? bloginfo('rss_url'); ?>" />
<link rel="stylesheet" type="text/css" href="<? bloginfo('stylesheet_url'); ?>" />

Novamente iremos utilizar a tag boginfo(). Agora ela irá buscar o endereço do RSS e do CSS.

Perceba que utilizamos neste exemplo apenas um arquivo, o index.php para listar o conteúdo. O WordPress tem uma maneira eficaz de hierarquia de arquivos. Por exemplo: nós precisamos de um arquivo chamado archives.php para criar a lista de histórico. Na falta deste arquivo, o WordPress utiliza o index.php para criar a lista. Se tivéssemos feito o archives.php e colocado o código que utlizamos acima que cria a lista de histórico, o WordPress não utilizará o index.php.

Posts Relacionados

]]> http://tableless.com.br/wordpress-uma-pequena-introducao/feed/ 35 PDF grátis sobre XSLT http://tableless.com.br/pdf-gratis-sobre-xslt/ http://tableless.com.br/pdf-gratis-sobre-xslt/#comments Mon, 28 Jan 2008 22:55:58 +0000 Diego Eis http://tableless.com.br/pdf-gratis-sobre-xslt A Visie está disponibilizando um PDF grátis sobre XSLT.

A linguagem XSLT é utilizada para transformar dados de um formato XML em vários outros formatos. Há implementações de XSLT para praticamente qualquer linguagem de programação disponível hoje, incluindo PHP, JSP, ASP, ColdFusion, Python, Visual Basic, .NET e Delphi. No PDF estudamos os fundamentos e principais comandos da linguagem, permitindo a transformação de conteúdo baseado em XML em formatos como TXT, CSV, HTML e o próprio XML. Entre os exemplos realizados estão a transformação em HTML de um arquivo XML com dados de previsão do tempo atualizados em tempo real, e a criação de um sistema de clipping de notícias baseado em RSS ou ATOM.

O conteúdo do PDF era usado para ministrar cursos aqui na Visie sobre XSLT. Se quiser sugerir alguma alteração, por favor, me diga. E claro, divulgue para outros desenvolvedores.

Aproveite!

Posts Relacionados

]]> http://tableless.com.br/pdf-gratis-sobre-xslt/feed/ 21 HTML simples com XML e CSS http://tableless.com.br/html-simples-com-xml-e-css/ http://tableless.com.br/html-simples-com-xml-e-css/#comments Thu, 06 Dec 2007 20:15:08 +0000 Elcio Ferreira http://tableless.com.br/html-simples-com-xml-e-css Qualquer um que codifique HTML, ou mesmo use um editor WYSIWYG, já esbarrou no problema. Se você trabalha com internet, já deve ter tido também esse problema. O código se tornou complexo, com várias tabelas, uma dentro da outra. Vários frames, com uma porção de scripts para manter o
conteúdo atualizado entre eles. Uma parte da aplicação rodando em um pop-up, com um script
que atualiza o conteúdo principal.

Então, cumprindo a lei de Murphy, um dos seguintes fatos indesejáveis acontece:

  1. Um cliente liga reclamando que o site está dando um tal de “erro de script” quando clica num link, você
    tenta, mas não consegue reproduzir o erro em nenhum navegador.
  2. Alguém da diretoria resolve que os títulos devem ser azuis, não vermelhos. E você se
    põe a localizar <font face=”verdana” size=”5″ color=”red”> para poder mudar a cor.
  3. Alguma tabela não fechada corretamente estádando problemas no Netscape, mas o código tem cincotabelas aninhadas e você perde um dia tentando acharo defeito.
  4. Você percebe uma certa demora para carregar algumaspáginas, vai conferir o código e descobrealgumas coisas assim: <font face=”Verdana”><b></b><i></i><fontsize=”1″><b></b></font><fontface=”Arial”>Texto</font></font>

Que fazer? É claro que com muito cuidado e talentoesse tipo de problema pode ser evitado, mas isso envolve umaquantidade de trabalho insana. Já vi muitos projetosonde se gastou mais tempo preso nas entranhas de umcódigo complexo do que em qualquer outra fase doprojeto.

Tem um pessoal na web que propõe umasolução bastante interessante para isso.É a turma do WaSP (www.webstandards.org.) Assoluções não são apenas uma listade novas tecnologias, mas também uma filosofia dedesenvolvimento baseada na simplicidade.

Baseado nessa filosofia da simplicidade, que tem me rendidoresultados surpreendentes, gostaria de fazer algumassugestões interessantes:

XHTML

Quem já trabalha com XML certamente percebeu o poderda flexibilidade e da simplicidade. Éimpossível escrever um XML com erros de sintaxe,porque os interpretadores reclamam imediatamente. Émuito simples escrever documentos XML, sendo fácilextrair dados de qualquer banco de dados etransformá-los em XML (a maioria dos SGBDs incorporaou tem planos de incorporar o suporte nativo a XML.)Através da poderosa linguagem XSL e da farta oferta deparsers gratuitos, XML pode ser transformado em praticamentequalquer formato de arquivo.

XHTML nada mais é do que uma forma de escrever umdocumento HTML de modo que ele também seja umdocumento XML válido. Ou seja, seu documento HTMLganha a coerência e flexibilidade de um documento XML,podendo ser facilmente lido por ferramentasautomáticas e convertido em outros formatos dearquivos. Com XHTML torna-se muito fácil oferecer osdados do seu site através de WAP ou de um RSS(http://rssficado.pilger.inf.br)por exemplo. Torna-se fácil também transformaro resultado de uma consulta a banco de dados ou um documentoXML numa página web.

A boa notícia é que é muito fácilescrever XHTML. Qualquer um que escreva HTML pode aprender afazê-lo sem muita dificuldade. Existem inclusive umasérie de ferramentas interessantes para tornar esseprocesso mais produtivo, como o excelente HTML Tidy(http://tidy.sourceforge.net)que tem uma eficiência impressionante para umaferramenta automática.

CSS e a Abordagem Semântica

Como você cria um título num documento HTML?

O meio comum hoje em dia para fazê-lo é:<font face=”Arial” size=”4″ color=”blue”>Texto doTítulo</font>.

Quando eu estudei HTML, em 1996, aprendi que existia uma tagespecífica para criação detítulos. É a tag h1. Assim, a maneira de secriar um título em HTML seria: <h1>Texto doTítulo</h1>.

Extremamente mais simples, não é verdade? Etorna o código também mais significativo. Assimum interpretador pode saber, por exemplo, onde estãoos títulos no meio do texto. Ou seja, esta abordagemdá significado semântico ao código.Aquele tag passa a significar alguma coisa, mesmo quenão seja vista num browser que renderize a fonte maiore azul que você tinha planejado.

Aliás, por falar no texto azul, se você usar asegunda abordagem seu título será exibido comos estilos padrão do navegador, e seu azul vai para obeleléu. Como você não quer perder abonita formatação que havia planejado, aquientra uma segunda linguagem, o CSS. Com CSS você podecolocar toda essa informação sobreformatação num arquivo externo. Assimvocê fica com um arquivo HTML apenas cominformação (que fica muito mais simples,organizado e rápido de se escrever) e mantémtoda a formatação num arquivo externo. Se umdia seu chefe resolver que todos os títulos do sitetem que ser vermelhos ao invés de azuis (acredite,isso é muito comum) você sóprecisará alterar uma palavra em um únicoarquivo e todos os títulos do site estarãoautomaticamente ajustados.

No Tables

Tabelas são um recurso muito útil do HTML. Semtabelas como exibiríamos informaçõescomo uma lista de produtos, um extrato bancário ou umcalendário? O problema é que tabelas tem sidousadas para muito mais do que isso. É preciso colocaro menu ao lado do texto? Cria-se uma tabela. É precisoque o texto tenha uma largura delimitada? Cria-se uma tabela.Imagem junto ao texto? Menu no cabeçalho? Duas colunasde texto? Tabela neles!

E como fica, nessa situação, a semânticado documento? Como você deve imaginar, nãohá aqui aquela prática separaçãoentre informação e formatação.Além disso, temos um outro sério problema: embrowsers antigos, ou mesmo em browsers modernos maldesenvolvidos, como o Internet Explorer, as tabelas sósão exibidas depois que a última tag</table> chega ao navegador.

É por isso que, quando você estáconectado via dial-up, em alguns sites a tela fica em brancodurante longos segundos (às vezes minutos) atéque é exibido de uma vez só.

Abrir mão de tabelas para montar layouts vai tornarseu código muito menor, mais simples e organizado. Vaitambém centralizar a formatação,colocando tudo que se refere a layout em um únicoarquivo. Imagine a facilidade de manutenção.Melhora também a experiência do usuário,pois a informação é exibida instantaneamente, assim que chega ao browser.

Dá-se a esta abordagem o nome de tableless. Apesar donome, não é a ausência total de tabelas,mas o seu uso apenas onde é semanticamentejustificável. De lambuja, um documento tableless bempensado vai funcionar em qualquer navegador, em qualquer sistema operacional, mesmo em PDAs.

No Frames, No Pop-ups, No DHTML

Pense muito antes de aplicar uma solução
baseada em frames, DHTML, scripts absurdos, pop-ups, plugins,
ActiveX, Applets ou qualquer outra tecnologia que quebre
essas duas premissas da internet:

- A web é um ambiente multiplataforma.

- Cada documento na web tem um endereço associado a
ele.

Não vou me alongar nesse tópico, mas gostaria que você tomasse um tempo para ler:

Vamos com calma

O interessante dessa abordagem baseada na simplicidadeé que você não precisa fazer tudo de umavez. Se está inseguro para começar, pode apenaseliminar as tags <font> e criar um arquivo CSSúnico. Ou pode começar usando os recursos deXML do seu banco de dados para gerar XHTML, ou criando umRSS. O importante é começar a simplificar antes que você fique maluco!

Posts Relacionados

]]> http://tableless.com.br/html-simples-com-xml-e-css/feed/ 7 O Caminho Suave para o Tableless http://tableless.com.br/o-caminho-suave-para-o-tableless/ http://tableless.com.br/o-caminho-suave-para-o-tableless/#comments Thu, 06 Dec 2007 20:11:11 +0000 Elcio Ferreira http://tableless.com.br/o-caminho-suave-para-o-tableless A maior parte dos desenvolvedores web, designers ou programadores, começaram antes do surgimento dos movimentos em prol dos padrões web, usando tabelas para montar layouts em editores WYSIWYG, e ainda hoje este método é usado na maioria dos projetos de internet. Logo, é natural que muita gente, ao começar a entender o valor dos padrões, se pergunte como migrar do desenvolvimento “tradicional” para o desenvolvimento de código semanticamente coerente.

É um caminho muito duro o que separa o desenvolvedor acostumado a editores visuais do desenvolvimento de código coerente. E é muito comum que o designer desista após uma primeira tentativa frustrada de desenvolver um website tableless, com layout CSS e XHTML validado.

Por isso gostaria de propor um caminho gradual, mais suave, para aqueles que querem se aventurar pela primeira vez pelos padrões web. O princípio desse método é da recompensa. Você pode obter um grande benefício aproximando seu código dos padrões web, mesmo que não faça tudo de uma vez. Quero mostrar como você pode começar, e obter benefícios imediatos.

Limpe seu HTML

A minha primeira recomendação é que você estude CSS. Comece pela formatação básica de fonte, cor e tamanho. Isso vai te garantir código menor e produtividade maior com pouquíssimo esforço.

Assim, ao criar um item de menu, você vai evitar códigos como este:

<a href="parceiros.asp"><font
face="Arial, Helvetica, Sans-serif" size="2"
color="#FF3300"><b>Parceiros</b></font></a>

Colocando no lugar:

<a href="parceiros.asp" class="menu">Parceiros</a>

Tendo no CSS:

.menu{
font-family: Arial, Helvetica, Sans-serif;
font-size: 80%;
font-weight: bold;
color:#FF3300;
}

Como você pode ver, o CSS é extremamente simples. Aprender esses quatro atributos, mais o “font-style” (para fazer itálico), é a primeira coisa que eu recomendo. É claro, isso apenas faz cócegas nas possibilidades do CSS, ainda há muito o que aprender, mas recomendo começar por aí porque é algo que você pode aprender em alguns minutos e vai te salvar muito, muito tempo. E você vai começar a ter o controle da formatação, tendo todas as definições de fonte em um único arquivo, podendo alterar, por exemplo, a qualquer momento, a fonte de todo o conteúdo ou de todos os menus do site.

O passo seguinte para limpar seu HTML é se livrar do spacer.gif, aquele gif transparente de 1 pixel que se usa para dar espaços em tabelas, e das dezenas de tabelas aninhadas. Para isso vamos começar a estudar o “box-model”.

O pulo-do-gato aqui é um atributo CSS chamado padding. O padding é a distância entre as bordas de um elemento e o texto dentro dele. Assim, se é preciso que o conteúdo de uma célula esteja a 10 pixels da borda esquerda, ao invés de inserir uma célula extra como espaçador, ou inserir mais uma tabela, basta definir uma classe para essa célula. Uma vez que você já está colocando a formatação no CSS, provavelmente esta célula já tem uma classe. Então basta:

.conteudo{
padding-left:10px;
}

Isso vai fazer com que o texto esteja a 10 pixels da borda esquerda do documento. Ah, claro, o CSS também pode livrar você de definir no HTML as bordas e o background das células de sua tabela. Lembre-se, quanto mais layout e formatação você colocar no CSS, mais controle terá sobre seu site, principalmente em mudanças de layout durante o processo de produção e em futuras manutenções. O site também será mais leve para carregar.

Concluímos então que, após aprender os atributos de formatação de fonte, o passo seguinte é aprender os atributos background, border e padding. Indo até aqui você com certeza será um desenvolvedor muito mais feliz! Depois de limpar seu HTML, ganhar controle sobre a formatação de seu site e se tornar muito mais produtivo, você está pronto para passar à segunda etapa, correndo atrás da semântica.

Começando o Trabalho de Gente Grande

Muito bem, agora você já pode limpar seu código. Vamos estudar um exemplo prático. No começo de cada uma de suas páginas você tem um título, cujo código hoje é assim:

<font face="Arial, Helvetica, Sans-serif" size="4"
color="#FFFF00"><b>Novidades</b></font>

Ao limpar esse código, você vai substituir esse monte de tags por uma só. Que tag você vai usar? Como o CSS te permite formatar qualquer elemento, muita gente que começa a estudar o assunto acha que é indiferente que tag usar, e coloca algo como:

<p class="titulo">Novidades</p>

Agora, veja bem, outro desenvolvedor poderia resolver o mesmo problema com:

<div class="titulo">Novidades</div>

E o resultado visual poderia ser o mesmo. Acontece que há algo na natureza do HTML que nos diz que tag usar. Chamamos esse algo de “semântica”: as tags do HTML tem significado. A tag P é para parágrafos, a tag DIV para divisões no conteúdo, e há uma série de tags para título, h1, h2, h3, h4, h5 e h6. Assim, se você pode usar qualquer tag, pode fazer assim:

<h1>Novidades</h1>

O que você ganha com essa preocupação? Os buscadores inteligentes podem ler semanticamente o conteúdo de um documento, entendendo que trecho de código é um título, por exemplo. Assim, escrever HTML semanticamente correto pode melhorar muito sua visibilidade em buscadores. O segundo bom motivo é que você vai saber para que serve cada tag se tiver que mexer nesse mesmo documento daqui a alguns meses. E vai ser mais fácil também se outra pessoa tiver que dar manutenção no seu código.

Logo, use as tags do HTML para aquilo para o que foram criadas:

  • dd, dl e dt para listas de definições (um glossário, por exemplo)
  • h1 a h6 para títulos
  • p para parágrafos
  • abbr para abreviaturas e acronym para acrônimos
  • blockquote e q para citações longas e curtas
  • address para endereços (sabe aquele rodapé onde vai o endereço e o telefone da empresa?)
  • ul e ol para listas e li para os itens da lista

Você pode obter uma lista mais abrangente em:
http://www.w3schools.com/xhtml/xhtml_reference.asp

E formate tudo ao seu gosto com CSS.

Finalmente, Livrando-se das Tabelas

Não há bons motivos para você eliminar a qualquer custo todas as tabelas de seu primeiro trabalho. Conheço alguns excelentes profissionais, muito talentosos, que fizeram um ótimo trabalho em sua primeira tentativa de tableless. Mas a maioria dos que eu vi tentarem demoraram muito para conseguir da primeira vez, e alguns não obtiveram os resultados que esperavam. Isso tudo serve para que você possa produzir mais rápido e melhor, não o contrário. Então vá com calma. Faça alguns estudos em tableless, comece eliminando parte das tabelas em seus primeiros trabalhos. Por exemplo, remover as células de tabela que formam o menu, trocando por uma lista (com as tags ul e li), é um ótimo desafio para o primeiro projeto.

Ah, e não se esqueça que para dados como uma tabela periódica ou um calendário a solução semanticamente correta é a tabela mesmo. Ou seja, tableless não é ausência de tabelas, é o seu uso apenas onde é semanticamente justificável.

Não vou entrar em detalhes aqui, porque já escrevi bastante sobre como construir um layout no Tutorial Tableless Básico, mas o conselho é ir com calma, sem estresse. Você logo vai estar produzindo tableless mais fácil do que produz sites com tabelas.

XHTML

Há uma coisa que muita gente que está começando me pergunta: o que é e para que serve esse tal de XHTML? É muito mais simples do que parece. Um arquivo XHTML é um arquivo HTML, que pode ser lido por qualquer browser. Não estamos falando de um novo HTML, com novas tags ou coisa assim. Pelo contrário, o XHTML 1 foi feito para funcionar mesmo em navegadores antigos. Mas, ao mesmo tempo, Um arquivo XHTML é também um arquivo XML válido, que pode ser lido por qualquer interpretador de XML.

Meu primeiro conselho, nesse caso, é que você, se não trabalha com XML, deixe preocupação com o XHTML para depois de dominar bem o código semântico e o layout tableless. Não porque seja complicado, pelo contrário, transformar bom HTML em XHTML é bem simples, mas simplesmente porque você pode obter benefícios muito significativos, e muito mais rapidamente, aprendendo CSS do que XHTML.

O segundo conselho é que você comece a estudar o assunto. Depois de dominar bem layouts CSS, mergulhe no XML. A maioria dos bancos de dados hoje permite extrair dados diretamente em XML e todas as plataformas de aplicações web trabalham bem com XML. E com a poderosa linguagem XSLT você pode muito facilmente oferecer seus os dados em XHTML para o navegador.

Voando Alto

Estamos falando de muito mais do que criar sites estilosos. Há duas semanas esteve aqui um amigo com um Palm novo, um Zire 71, e um celular com acesso à internet. Isso está se tornando cada vez mais barato e comum. Conheço também uma porção de empresas e instituições, entre elas uma série significativa de TeleCentros e órgãos públicos, que estão adotando Linux como sistema operacional para desktops. O Google hoje é responsável por 90% do tráfego que meu site consegue de buscadores. É o primeiro colocado absoluto entre os buscadores. E conseguiu isso indexando semanticamente o conteúdo real dos sites. Praticamente todas as plataformas web estão oferendo suporte a XML e apostando na idéia de webservices.

Quem segue os padrões web não precisa ter medo do futuro. Não importa que browser vai ser o mais usado daqui a dois anos, que tecnologia vai estar na moda ou de onde as pessoas vão estar usando a internet. Seu site estará lá, leve, acessível, atual e útil.

Posts Relacionados

]]> http://tableless.com.br/o-caminho-suave-para-o-tableless/feed/ 14 Escrevendo um XHTML válido http://tableless.com.br/escrevendo-um-xhtml-valido/ http://tableless.com.br/escrevendo-um-xhtml-valido/#comments Thu, 06 Dec 2007 20:07:58 +0000 Diego Eis http://tableless.com.br/escrevendo-um-xhtml-valido Acho que todos já ouviram falar de Web Semântica, para quem não ouviu, em poucas palavras é: Um projeto para organizar e estruturar a informação da WEB.

Ter uma Web com as suas informações todas “organizadas” é extremamente importante, isso facilita uma busca pela Web por informações mais precisas.
Para que seu arquivo possa ser lido por máquinas além de humanos é muito importante que você escreva um XHTML válido, com isso você está fazendo com que as informações do seu site fique mais acessível para as buscas, contribuindo para o projeto e principalmente melhorando as visitas do seu site.

DOC o que?!

O Doctype (Document Type Definition, vulgo DTD) é a primeira coisa que se deve escrever em um arquivo XHTML, ele vai na PRIMEIRA LINHA do seu documento, se você quiser ter um XML Válido, não devemos esquecê-lo, ele serve para informar ao browser que tipo de documento será visualizado, ok?

Existem 3 tipos:

  • Strict: Este tipo é usado quando você fez um código 100% XHTML, sem erros, deve ser escrito assim:
    <!DOCTYPE html
    PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
    “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
  • Transitional: Este é o modo mais usado, você o usa quando está começando a migrar do nosso amigo HTML para o poderoso XHTML, sua sintaxe é:
    <!DOCTYPE html
    PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
    “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
  • Frameset: É usado quando você está utilizando FRAMES em seu site, se escreve assim:
    <!DOCTYPE html
    PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN”
    “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

Exemplo:
<!DOCTYPE html
PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
<html>
<head>
<title></title>
</head>
<body>
…
</body>
</html>

Feche TODAS as tags

Quem já escreveu algum XML sabe que ele não funciona até que TODAS as tags estiverem bem fechadas, no HTML era diferente, muitas vezes deixávamos tags abertas, e ele funcionava que era uma beleza.

Para se fazer um XHTML válido, devemos fechar TODAS as tags:

  1. Não devemos esquecer de fechar as tags que estamos carecas de conhecer: <p></p>, <b></b>, etc…
  2. E não devemos esquecer de forma alguma de fechar as tags “solitárias”, assim, ao invés de <br> escrevemos <br></br>, ou na forma simplificada: <br />.

Descobriram que fechando tags desta forma <br/>, não se sabe porque estava causando um problema no Netscape, mas apenas colocando um espaço antes da / o problema é solucionado.

Use letras minúsculas

Quem nunca viu um código fonte de um documento HTML escrito assim:
<A href=”http://tags.com.letras.minúsculas/” TARGET=”_BLANK”> </A>
Um documento XHTML deve ter TODAS as tags e seus respectivos atributos escritos com letra minúscula!

Não esqueça das “ASPAS”

Esta regra é bem simples. Todos os atributos XHTML devem conter as benditas “ASPAS”.

Atributo NAME

O antigo atributo NAME foi substituído pelo atributo ID. Se seus usuários, clientes, etc, utilizam ainda antigos browsers, você pode sem problema nenhum utilizar as duas formas juntas durante neste período em que estamos migrando:
<img src=”imagem.gif” id=”imagem” name=”imagem” />

Atributos sem valor

Não devemos esquecer também os atributos que escrevemos sem valor, por exemplo:

ERRADO:
<option selected>
<frame noresize>
<input checked>
<input readonly>

CERTO:
<option selected=”selected”>
<frame noresize=”noresize”>
<input checked=”checked”>
<input readonly=”readonly”>

E assim por diante.

Quer uma ajudinha?

Se você está migrando do HTML para o XHTML, o TIDY pode te dar uma forcinha.
O TIDY é uma ferramenta para validar e consertar códigos HTML, ele tem opções que você pode escolher qual a versão do HTML você quer validar, uma dessas opções é a XHTML. Se você já está escrevendo um XHTML e quer que seu código fique livre de todos os erros, o TIDY arruma para você.
Ele foi originalmente desenvolvido por Dave Raggett e hoje é mantido por um projeto de código aberto: SourceForge, por um grupo de voluntários.

Últimas palavras

Fazendo todas essas pequenas porém importantes regras, quer dizer, regras não, LEIS, você terá um belo de um documento XHTML válido, e acima de tudo, estará contribuindo para uma WEB melhor.

Como eu passei apenas o miolo, navegando nestes links poderão ser achados mais informações a respeito:

Notas:

Para saber se seu documento XHTML é válido:
http://validator.w3.org

Tidy:
http://tidy.sourceforge.net/
http://www.w3.org/People/Raggett/tidy/

Posts Relacionados

]]> http://tableless.com.br/escrevendo-um-xhtml-valido/feed/ 2 Novo Tableless, agora WordPress http://tableless.com.br/mudancas-repentinas/ http://tableless.com.br/mudancas-repentinas/#comments Tue, 13 Dec 2005 23:01:14 +0000 Diego Eis http://tableless.dreamhosters.com/?p=554 Como podem ver, o Tableless passou por uma reformulação. Tradicionalmente, costumo fazer essas mudanças no dia 1º de Janeiro, mas desta vez será diferente.

Mudamos não só layout (gostou?) mas também nosso sistema de publicação. Nos anos passados, sofríamos um bocado para postar no site. Por isso, nessa reformulação, migramos para WordPress. Estamos gostando muito dessa ferramenta. Eu era um pouco avesso a aplicações prontas de publicação de blog. Por isso, ou fazíamos o nosso próprio ou editávamos direto o XML. Agora com WP nossos problemas acabaram.

Mudamos o layout também, como de costume. Feito meio às pressas, mas acho que ele agüenta até a próxima etapa.

Reformulei todo o Código XHTML e CSS. Se alguém abrisse o source do Tableless antigo, iria se deparar com técnicas ultrapassadas: image-replacement com SPAN, e outras coisas do tipo.
Agora, se você conferir nosso source, vai encontrar tudo comentado (para aqueles que gostam de estudar) bem como um CSS bem feito.

Mas o ponto forte, é que fomos para outro “hospedeiro”. Migramos para a DreamHost.
O pessoal que conheço (Bruno Torres, Danilo Medeiros, Thiago Rigonatti e outros) indica muito esse host. Com apenas US$7,95 você já consegue colocar seu site lá. Mais barato que os hosts brasileiros, e o serviço é impecável. E dizem que o suporte é fascinante.
Agora, estamos lá. :-)

Espero que as alterações sejam apreciadas por vocês, caros leitores.
Outras modificações virão com certeza.

OBS.: Gostaria de agradecer o Bruno Torres por ter ajudado a fazer essa migração. O cara simplesmente fez tudo. Desde instalação do WP até importação do XML enorme do site antigo.
Valeu cara.

A respeito do fórum, migramos para phpBB. Logo, logo, vamos dar um jeito também no layout. Infelizmente, não é possível importar as senhas do Snitz, que são codificadas num formato próprio. Então, para acessar, você vai precisar criar uma senha nova. Acesse por aqui e coloque seu nome de usuário e seu e-mail. Uma nova senha será gerada e enviada para você por e-mail. Se você não sabe seu nome de usuário, basta procurar algum post seu no fórum. É o seu nome, do jeito que estiver aparecendo lá.

Posts Relacionados

]]> http://tableless.com.br/mudancas-repentinas/feed/ 88