Ainda a Pensar

11 fevereiro, 2007

web 2.0 e respostas

A transcrição abaixo é uma tradução da Transcrição feita por Tonya Witherspoon.

Web 2.0 ... A Máquina Somos Nós/Está a Usar Nos

O texto é linear

O Texto é não linear

Diz-se que o texto é não linear

O texto é frequentemente dito como não sendo linear

O texto é não linear quando escrito em papel

O texto digital é diferente.

O texto digital é mais flexível.

O texto digital pode ser mudado.

O texto digital é acima de tudo ... hiper.

O hipertexto digital é acima de tudo...

O hipertexto é acima de tudo...

O hipertexto pode ligar

aqui

ou aqui...

virtualmente a qualquer sítio

a qualquer sítio virtual

A Máquina do TempoPassado

http://yahoo.com

Leva-me de Volta

17 de Outubro 1996

Yahoo

Ver Fonte

A maior parte dos sítios web eram escritos em HTML

<html>

HTML foi concebida para definir a estrutura de um documento web.

<p>

<p> é um elemento estrutural para nos referirmos a um "parágrafo"

<li>

<li> também é um elemento estrutural para nos referirmos a "Item de Lista"

À medida que o html foi expandida, foram adicionados mais elementos.

Incluindo elementos estilísticos como <b> para negrito e <i> para itálico

Esses elementos definiam como é que o conteúdo seria formatado.

Dito de outra forma, forma e conteúdo tornaram-se inseparáveis em html

O texto digital pode fazer melhor.

A forma e o conteúdo podem ser separados.

http://www.cnn.com

RSS XML

Ver Fonte

XML foi concebido para fazer exactamente isso.

<title> não define a forma, define o conteúdo.

o mesmo com <link>

<description>CNN.com

e <description>

e virtualmente todos os outros elementos neste documento.

Eles descrevem o conteúdo não a forma.

Assim os dados podem ser exportados,

livres de constrangimentos de formatação.

Últimas Notícias

Blogues de Antropologia(124)

Mentes Crueis

8apps: Rede Social para Pessoas Produtivas

MUNDO EM MUDANÇA EIS OUTRO MUNDO AQUI

Jornais de Antropologia (124)

University of California Press

Journals Digital Publishing

Current Anthropology

AESonline.org

Google

Com a forma separada do conteúdo, os utilizadores não necessitam de usar código complicado para carregar conteúdo na web,

Sinto-me com sorte

Criar um Blog

Crie um nome para o blog

Para além do etexto (Beyond Etext)

http://beyondetext.blogspot.com

Escolha um modelo

O seu blogue está pronto!

Segunda-feira, 29 de Janeiro de 2007

Olá Mundo!

Colocado por PROFESSOR WESCH às 8:14 PM 0 COMMENTS

nasce um blogue a cada meio segundo

e não se trata só de texto...Busca

YouTube

Difunda-se A Si Mesmo

Esta é uma resposta em vídeo a A Beleza de Ser Humano

flickr

Ahoy mwesch!

Carregar fotos

Clube de Antropologia

Criado por si.

KSU Anthropology club

Club Photos

Google

XML facilita a troca automatizada de dados

dois sítios podem misturar dados em conjunto

flickr maps

Sinto-me com sorte

Limelight

Fluffy and white

Brushy Creek

Tokyo Delve's Sushi B..

Quem irá organizar todos estes dados?

TAG

del.icio.us

etnografia digital antropologia hipermedia

guardar

Quem irá organizar todos estes dados?

Tu.

Tu irás.

Google

XML + TU & EU iremos criar a web suportada na base de dados

a web suportada na base de dados é diferente

a web é diferente

a web

nós somos a web

Sinto-me com sorte

WIRED

ós somos a Web

Quando colocamos e depois etiquetamos as imagens estamos a ensinar a Máquina a dar nomes, estamos a ensinar a Máquina.

Sempre que forjamos uma ligação, estamos a ensinar-lhe uma ideia.

Pense nos 100 milhares de milhão de vezes por dia que os humanos diariamente clicam numa página da Web ensinando a Máquina

A Máquina

Diigo

Realce

Realce e Folha de Bloco Amarela

Misturar nota privada

a máquina é nós

O texto digital já não liga só informação...

O hipertexto já não liga só informação...

A Web já não liga só informação...

A Web liga pessoas...

Web 2.0 está a ligar pessoas...

...pessoas partilham, acompanham e colaboram...

Wikipedia

Web 2.0

alterar esta página

Temos que repensar algumas coisas...

Temos que repensar os direitos de autor

Temos que repensar a autoria

Temos que repensar a identidade

Temos que repensar a ética

Temos que repensar a estética

Temos que repensar a retórica

Temos que repensar a governance

Temos que repensar a privacidade

Temos que repensar o comércio

Temos que repensar o amor

Temos que repensar a família

Temos que nos repensar

por

Michael Wesch

Assistant Professor of Cultural Anthropology

Kansas State University

Etnografia digital

@ Kansas State University

música por DEUS "There's Nothing impossible"

Este trabalho é licensiado sob Creative Commons Attribution-NonCommercial-ShareAlike 2.5

A estes pensamentos há algumas respostas as abaixo e ainda outras.

09 fevereiro, 2007

Pistas e ligações a artigos para criação de folhas de estilo devem ser aqui coligidas. Para introdução do problema que estamos a tentar resolver ver [entrada no blogue do Simon]. Para ferramentas que ajudem na manutenção de folhas de estilo, ver TheToolsWillSaveUs.

[Arquitectar CSS], por Garrett Dimon, é uma boa revisão do problema com ideias fortes sobre como repartir as regras de CSS em diversos ficheiros.
[Redundância versus Dependência] por, Dave Shea, onde explora o equilíbrio entre dois extremos de desenvolvimento de CSS.
[CSS Modular], por Mike Stenhouse, descreve um esquema simples onde as regras são agrupadas em diferentes ficheiros baseadas em assuntos: tipografia, formulários, arranjos e cor.
[Organização de CSS], por Doug Bowman, pistas sobre agrupamento e indicação de grupos. (Por acaso acho que a separação do CSS em vários ficheiros é contraprodutivo em termos de manutenção, mas pode ser só minha opinião.)
[CSS que Pode Ser Facilmente Mantido], por Nathan Steiner, as suas pistas pessoais em resposta à chamada do Simon.
[Inclusão PHP em CSS], por Nick Bair, descreve o uso dos mecanismo de inclusão do PHP de modo a oferecer uma solução de ficheiro único para um CSS com facilidade de ser mantido.
[Técnicas de Ramificação] por Thierry Koblentz.
[Jogar de foma justa com o CSS das outras crianças], por Mike Stenhouse, tenta criar directrizes para fazer manutenção de CSS e codificação em equipa mais fáceis.

Segregar os seus estilos

Limitar especificamente o "alcance" das declarações de estilo. Por exemplo, tenho um certo estilo aplicado a conteúdo prefixo isso com um #conteudo, mesmo que não seja necessário. Especificar a parte da estrutura semântica a que o estilo se aplica irá essencialmente segregar o estilo de modo a que a cascata não afecte mais nada por acidente.

De forma similar separo o posicionamento da tipografia.

Desenvolver "conceitos" para o sítio/aplicação ajuda a manter as coisas sãs. Toda a decoração para cada conceito vai para o(s) seu(s) próprio(s) ficheiro(s). Exemplos de conceitos:

Carrinho de compras (carrinho-ecra.css / carrinho-impresso.css)
Tabelas de doces coloridas
Formulários de entrada de dados

Estes ficheiros podem depois ser ligados a tantas folhas de estilo quantas as necessárias.

CSS Fácil de Manter

As minhas recomendações para CSS Fácil de Manter. Admito que possa haver aqui alguma repetição mas estou a tentar ser mais conciso aqui.

Repartir o seu CSS no conceito coerente mais pequeno possível

estrutura.css
carrinhodecompras.css
basesdedados.css
descricoesdeprodutos.css
...

Organizar ficheiros num conjunto de pastas que lhe permitam perceber a finalidade de cada ficheiro. Mantenha aquelas coisas que tenham elevada probabilidade de alteração como (cor, tipografia, gráficos, etc) projecto a projecto, ou semana a semana em localizações diferentes

ecra/estrutura.css
ecra/carrinhodecompras.css
...

impresso/estrutura.css
impresso/carrinhodecompras.css
...

brand/estrutura.css
brand/carrinhodecompras.css...

Use ID raramente: ID tem que ser única numa página e assim sendo ao usarmos id em elementos estruturais significa que só iremos ter por exemplo um bloco conteudo numa página. Se for cuidadoso, #conteudo p é tão específico como .content p e <div class="conteudo">...</div> pode ser largado em tantos lugares quantos os necessários. Pode usar ID para algo como <div class="produto" id="produto00121">...</div> mas deve ter muito cuidado para se assegurar que só se refere uma vez numa página a produto00121.

Evite usar o mesmo nome de classe para diferentes finalidades: A cascata pode ser muito poderosa mas, por vezes, há a tentação de usar o mesmo nome de classe genérico em vários sítios. Se não segregar o seu CSS bem, pode correr perigo.

Usar sempre o mesmo nome de classe para finalidade similar: Visto a cascata ser tão poderosa deve reutilizar o mesmo nome de classe em diferentes classes quando representam o mesmo conceito.

Usar nomes de classes que revelem intencionalidade: Pode ser tentador usar nomes de classes breves mas demasiado cifrados (.s, .lbl) que no caso de não manter um glossário actualizado de nomes de classes irá esquecer o que querem dizer. Pode também correr perigo com navegadores desactualizados que podem ocasionalmente ser confundidos por nomes de classes breves que comecem da mesma forma (i.e. .err e .erros são, por vezes, confundidos.)

Colocar o seu nome de classe no elemento mais exterior onde faça sentido e Não Se Repita a Sí Mesmo (DRY): Por vezes irá ver coisas como:

 <div class="tituloproduto">...</div>
 <div class="descricaoproduto">...</div>

 <div class="ligacoesproduto">...</div>

É melhor escrever:

<div class="produto">
 <h3>...</h3>

 <div class="descricao">...</div>
 <div class="ligacoes">...</div>
</div>

Usar vários nomes de classes em todo o lado: As an example, if you have a form, fields are typically either required or optional and have an error or not. Without using multiple classnames you often end up with the following:

.exigido {...}
.opcional {...}

.erroexigido{...}
.erroropcional{...}

Isto frequentemente leva a muita duplicação de CSS visto a diferença entre exigido e opcional é normalmente um asterísco para indicar que determinado campo tem que ser preenchido. De forma similar campos onde haja erros são normalmente coloridos a vermelho ou são de algum outro modo realçados. Uma solução melhor é usar vários nomes de classes:

.campo {... propriedades comuns a campos, posicionamento, etc ...}
.exigido {... adicionar imagem de fundo ...}
.erro{... cor de texto diferente ...}

<div class="campo">...</div>
<div class="campo exigido"> ... </div>

<div class="campo erro"> ... </div>

A única vez que isto lhe poderá trazer problemas sucede quando nos campos exigidos quando com erros o IE não compreender .exigido.erro correctamente.

Esta entrada é uma tradução de http://css-discuss.incutio.com/?page=MaintainableCss.

Abriu o ILG - da WaSP

A 5 de Fevereiro a Molly apresentou ao mundo o novo grupo do WaSP para divulgação de técnicas standard na produção de sítios web. Este grupo de ligação internacional deverá funcionar como uma alavanca na introdução/divulgação de técnicas standard de produção de sítios web a nível mundial com diversos especialistas em vários pontos do globo.

Um fulano muito mais inteligente que eu

Sergey. Algo que é muito frequente, demasiado para o meu próprio gosto.

Excerto de Entrevista a Eric Meyer

Numa recente entrevista a Eric Meyer quando perguntado por Todd Austin: Como é que as empresas podem ajudar as universidades a ensinar web standards, visto ter notado que muitos curricula ainda estão cheios de ensino de html com tabelas (para fins de arranjo)? Ao que Eric respondeu:

Deixem de empregar as pessoas que esses curricula produzem. É a única coisa que julgo iria funcionar, e isso não seria justo para as pessoas que não fossem empregues, visto não ser uma falha delas mas sim uma grande desajuda por parte dos seus instrutores. Mesmo assim, e mesmo sabendo que possa provavelmente parecer duro, será que as firmas de engenharia iriam empregar engenheiros que fosse treinados em engenharia do século XVIII? Será que uma firma de software iria empregar novos engenheiros formados em COBOL? Será que contrataria um contabilista que tivesse aprendido o Código de Impostos de 1950 e não tivesse aprendido nada desde essa data?

Porque é que será que as firmas da web devem fazer algo de modo diferente?

acronym-free environment

Substantial Experience with Ruby on Rails, XHTML, CSS, PHP and mySQL Comprehensive Understanding of XML and AJAX ability to work in an acronym-free environment

Não resisti acronym-free environment figura num anúncio para suporte a Mac.

Já agora aquele mySQL será que quer dizer MySQL.

Parece-me que ler este anúncio restaurou-me a boa disposição...

Indexed

As imagens valem muitas palavras. Estas imagens têm palavras. O blogue de «quase gráficos» da Jessica Hagy é um daqueles que tem que ser visitado, ideia simples e muito bem conseguida.

O Novo Lixo do O Jogo

Vi anunciado que O Jogo tinha uma nova página na web, fui ver. Meu deus (é um deus muito pequenino) quem serão os tecnólogos/decisores por detrás deste sítio. Estou a tentar manter-me objectivo mas o que produziram, no século XXI parece-se muito com o que se produzia há já 10 anos. Não queria acreditar quando vi o conteúdo original em formato de texto um documento que começa por <style>, não entendo. Uso de iframe com margens nulas e largura e altura a 100% sem esquadria para o iframe, isto claro como único elemento do corpo. Claro que não existe elemento head embora exista um elemento title. Isto é mesmo novo ou estou a delirar e a ver mal. Tenho que ir buscar o termómetro e ter cuidado para ver se ele não rebenta. Bolas, é digital, já não tem mercúrio.

Quando é que alguém entende que quantos mais elementos estiverem a passear pelos ecrãs das pessoas menos atenção as pessoas lhes prestam. 2 anúncios a piscarem e depois aquela linha com notícias é um pouco demais. Bom já chega de publicidade gratuita.

O próprio documento no iframe é uma verdadeira manta de retalhos, mas estou com tão pouca paciência que não me vou estender mais.

Claro que os autores desse sítios podiam-me responder na mesma moeda. Hoje ao finalmente deixar o blogger convencer-me a actualizar os meus blogues para a nova plataforma deles, criei-me um problema deixei de ter páginas válidas para passar a ter em média 50 erros (claro que os mesmo) e vou ver como poderei remediar isto.

Mais uma actualização: o que é que Eric Meyer pensa de pessoas como as acima descritas.

08 fevereiro, 2007

A List Apart 232

Saiu o número 232 da A List Apart. Os dois artigos deste número são:

Arranjo Multi-colunas Directamente da Caixa, por Alan Pearce. Neste artigo Pearce mostra como criar um arranjo elástico e líquido com três colunas com barras laterais de largura fixa e colunas com a mesma altura. É óbvio que se refere a técnicas já conhecidas mostrando as suas limitações.
Neste artigo Bobby Sluis fala dos vários métodos sobre como integrar um elemento com flash numa página. Fala dos métodos que estão e dos que não estão em conformidade com as recomendações do W3C, fala das limitações destes devido a excesso de abertura dessas mesmas recomendações, fala de constrangimentos devidos à instalação cliente e fala de uma tentativa de solução que está a preparar.

29 janeiro, 2007

PDF vai tornar-se norma ISO

A Adobe vai propor a passagem a norma internacional ISO o formato PDF 1.7. O que está a ser anunciado em: http://www.adobe.com/aboutadobe/pressroom/pressreleases/200701/012907OpenPDFAIIM.html.

26 janeiro, 2007

A List Apart 231

O A List Apart nº. 231 apresenta dois artigos:

O primeiro é de Shawn Medero e trata de prototipagem em papel tema a que me referi ao citar o artigo Prototipagem em Papel do Ivo Gomes. Tanto num como no outro se salienta a adequação de prototipagem em papel para os casos em que aquilo que se desenvolva seja complexo.
O segundo de Casper Voogt e apresenta um interessante artigo de como criar de forma rápida uma simulação de página web com o Photoshp (CSS+HTML). É um artigo que se lê de uma penada e que se pode pôr em prática de imediato. O ganho de produtividade pode ser relevante.

8 novos standards na familia XML

O W3C publicou 8 novos standards na familia XML para data mining, transformação de documentos e computação empresarial de serviços web a bases de dados. "Mais de 1000 comentários de pessoas que desenvolvem ajudaram a assegurar a resiliência e a implementabilidade do conjunto de tecnologias de bases de dados", disse Jim Melton da Oracle. O XSLT tranforma documento em diferentes marcações ou formatos. O XML Query pode efectuar buscas, inquéritos e junções sobre coleções de documentos. Usando expressões XPath, XSLT 2 e XQuery podem operar sobre documentos XML, bases de dados XML, bases de dados relacionais, motores de busca e repositórios de objectos.

15 janeiro, 2007

Diferenças HTML vs. XHTML

Por favor note que a informação aqui presente se baseia na actual especificação para (X)HTML5. alguns dos detalhes não são aplicáveis tecnicamente a anteriores versões de HTML.

Embora o HTML e o XHTML possam parecer serem similares na sua sintaxe, são bastante diferentes de várias formas.

Nota: Como o actual documento WHATWG ainda é um rascunho esta secção necessita de ser acompanhada como um alvo em movimento.

As diferenças marcadas com @@@ são diferenças que podem teoricamente ser alteradas sem afectar a retrocompatibilidade

Tipos MIME

O XHTML tem que ser servido como um tipo MIME XML tal como application/xml ou application/xhtml+xml.
O HTML tem que ser servido como text/html.

É este tipo MIME que determina que tipo de documento está a usar. Se tentar enviar XHTML como text/html de facto está a usar HTML, eventualmente com erros sintáticos.

Tecnicamente, de acordo com a especificação é permitido enviar XHTML 1.0 como text/html. Mas devido à razão anteriormente apresentada tal documento é considerado como documento em HTML e não em XHTML.

Análise

O XHTML usa requisitos de análise/interpretação XML. O HTML usa os seus próprios requisitos que estão definidos de uma forma que se apresenta muito mais próxima da forma de tratamento que os navegadores dão ao HTML actualmente.

Em XHTML, a má formação é um erro fatal. Em HTML, as regras de tratamento de erros são muito mais simpáticas. Os erros de má formação, que também são erros sintáticos em HTML, incluem os seguintes:
- E comercial não codificado (& em vez de &), e sinais de menor que (< em vez de <) (Isto não se aplica a CDATA).
- Comentários contendo um par extra de hifens ou terminando num hífen, isto é:
  -  ou
  - .
- Fechos de marcadores a que não correspondem a respectiva abertura de marcadores (não se aplica a elementos com marcadores opcionais)
- Ausência de marcadores de fecho.
- Ocorrência de caracteres inesperados em ou antes de nomes de atributos.
- Ocorrência inesperada de EOF (Fim de ficheiro).
- Caracteres inesperados antes do nome DOCTYPE.
- Ausência de nome DOCTYPE.
- Um identificador PUBLIC num DOCTYPE sem identificador de SYSTEM (Nota: incluir qualquer um destes é um erro sintáctico em HTML5, mas em XML só o identificador SYSTEM pode ocorrer por si.)
- Fecho de marcadores com atributos.
- Fechos de marcadores inesperados (em HTML, um </br> ou </p> pode fazer implicar (mesmo que não seja claro explicito) uma abertura de marcador antes do respectivo fecho).
O subconjunto interno é permitido em XML, mas não tem significado (e é proibido) em HTML.
- Em alguns casos um subconjunto interno em HTML terminará por ser parcialmente reproduzido em linha.
A sequência de caracteres "]]>" quando não assinala o final da secção CDATA é um erro de má formação em XHTML, mas é válido em HTML.
Em XHTML: <![CDATA[...]]> é uma secção CDATA section. Em HTML, é um falso comentário.
Em XHTML, é uma instrução de processamento. Em HTML é um falso comentário.
Em HTML, o traço de fracção usado na sintaxe de um elemento vazio é um erro de análise para elementos não vazios (ver abaixo), mas ignorado em todos os casos.
Em HTML, os elementos script e style são analisados como CDATA. (Nota: a definição de CDATA é diferente da encontrada em XML). Em XML, são interpretados como elementos normais (o que significa que os comentários são tratados como comentários reais e coisas que se parecem com abertura de marcadores são de facto aberturas de marcadores).
Em HTML, os elementos title e textarea são interpretados como RCDATA. (Nota: A definição de RCDATA é diferente da dada no SGML e não há RCDATA em XML).
Em HTML, se estiver activado o scripting o elemento noscript é interpretado como CDATA. Se o scripting estiver desactivado (ou indisponível) é interpretado como PCDATA. Em XHTML, o elemento não tem efeito e não pode ser de facto usado para evitar que conteúdo seja mostrado quando o script não estiver disponível.
Em HTML, os elementos iframe, noembed e noframes são interpretados como CDATA. Em XHTML, são interpretados como elementos normais e sendo assim não impedem o uso de conteúdo.
Os caracteres de espaço em branco em valores de atributos são normalizados para espaços em XHTML.
Sob determinadas condições tornam-se implícitos elementos com marcadores opcionais.
Em HTML, elementos base, link, meta, style e title com marcadores que ocorram em body são movidos e inseridos em head. Em XHTML, ficam onde tenham sido especificados.
Em HTML, marcadores de certos elementos que aparecem fora de contexto são ignorados. Estes marcadores incluem caption, col, colgroup, frame, frameset, head, option, optgroup, tbody, td, tfoot, th, thead, tr.
O elemento plaintext tem um requisito especial de interpretação em HTML. (é contudo proibido).
Há ainda outros casos de interpretação especial de casos de fronteira e condições de erro que não foram aqui listados e que ocorrem em HTML.

Análise

Em XHTML, a má formação é um erro fatal. Em HTML, as regras de tratamento de erros são muito mais simpáticas. Os erros de má formação, que também são erros sintáticos em HTML, incluem os seguintes:
- E comercial não codificado (& em vez de &), e sinais de menor que (< em vez de <) (Isto não se aplica a CDATA).
- Comentários contendo um par extra de hifens ou terminando num hífen, isto é:
  - ou
  - .
- Fechos de marcadores a que não correspondem a respectiva abertura de marcadores (não se aplica a elementos com marcadores opcionais)
- Ausência de marcadores de fecho.
- Ocorrência de caracteres inesperados em ou antes de nomes de atributos.
- Ocorrência inesperada de EOF (Fim de ficheiro).
- Caracteres inesperados antes do nome DOCTYPE.
- Ausência de nome DOCTYPE.
- Um identificador PUBLIC num DOCTYPE sem identificador de SYSTEM (Nota: incluir qualquer um destes é um erro sintáctico em HTML5, mas em XML só o identificador SYSTEM pode ocorrer por si.)
- Fecho de marcadores com atributos.
- Fechos de marcadores inesperados (em HTML, um </br> ou </p> pode fazer implicar (mesmo que não seja claro explicito) uma abertura de marcador antes do respectivo fecho).
O subconjunto interno é permitido em XML, mas não tem significado (e é proibido) em HTML.
- Em alguns casos um subconjunto interno em HTML terminará por ser parcialmente reproduzido em linha.
A sequência de caracteres "]]>" quando não assinala o final da secção CDATA é um erro de má formação em XHTML, mas é válido em HTML.
Em XHTML: <![CDATA[...]]> é uma secção CDATA section. Em HTML, é um falso comentário.
Em XHTML, é uma instrução de processamento. Em HTML é um falso comentário.
Em HTML, o traço de fracção usado na sintaxe de um elemento vazio é um erro de análise para elementos não vazios (ver abaixo), mas ignorado em todos os casos.
Em HTML, os elementos script e style são analisados como CDATA. (Nota: a definição de CDATA é diferente da encontrada em XML). Em XML, são interpretados como elementos normais (o que significa que os comentários são tratados como comentários reais e coisas que se parecem com abertura de marcadores são de facto aberturas de marcadores).
Em HTML, os elementos title e textarea são interpretados como RCDATA. (Nota: A definição de RCDATA é diferente da dada no SGML e não há RCDATA em XML).
Em HTML, se estiver activado o scripting o elemento noscript é interpretado como CDATA. Se o scripting estiver desactivado (ou indisponível) é interpretado como PCDATA. Em XHTML, o elemento não tem efeito e não pode ser de facto usado para evitar que conteúdo seja mostrado quando o script não estiver disponível.
Em HTML, os elementos iframe, noembed e noframes são interpretados como CDATA. Em XHTML, são interpretados como elementos normais e sendo assim não impedem o uso de conteúdo.
Os caracteres de espaço em branco em valores de atributos são normalizados para espaços em XHTML.
Sob determinadas condições tornam-se implícitos elementos com marcadores opcionais.
Em HTML, elementos base, link, meta, style e title com marcadores que ocorram em body são movidos e inseridos em head. Em XHTML, ficam onde tenham sido especificados.
Em HTML, marcadores de certos elementos que aparecem fora de contexto são ignorados. Estes marcadores incluem caption, col, colgroup, frame, frameset, head, option, optgroup, tbody, td, tfoot, th, thead, tr.
O elemento plaintext tem um requisito especial de interpretação em HTML. (é contudo proibido).
Há ainda outros casos de interpretação especial de casos de fronteira e condições de erro que não foram aqui listados e que ocorrem em HTML.

Sintaxe

Em HTML, o doctype é obrigatório em XHTML é opcional.
Em XHTML, os nomes dos marcadores e dos atributos são sensíveis ao corpo da letra (maísculas e minúsculas têm significados diferentes) em HTML tal não sucede.
Em XHTML, elementos não vazios exigem tanto a abertura do marcador como o fecho do marcador. Em HTML pode omitir-se um deles ou até ambos:
- html (ambos)
- head (ambos)
- body (ambos)
- li (fecho do marcador)
- dt (fecho do marcador)
- dd (fecho do marcador)
- p (fecho do marcador)
- colgroup (ambos)
- thead (fecho do marcador)
- tbody (ambos)
- tfoot (fecho do marcador)
- tr (fecho do marcador)
- td (fecho do marcador)
- th (fecho do marcador)
Em XHTML, os elementos vazios podem usar quer a sintaxe de elemento vazio (<br/>) ou fazer o fecho imediatamente a seguir à abertura do marcado (<br></br>). Em HTML, a sintaxe de elemento vazio (<br/>) é permitida em elementos vazios mas proibida noutros elementos. Contudo não serve para nada e pode ser omitida. Não é permitido o fecho de um marcador para elementos vazios.
- base, link, meta, hr, br, img, embed, param, area, col e input
- Nota: os seguintes são tratados como elementos vazios para finalidades de requisitos de interpretação, mas, como são obsoletos e não-standard a sintaxe do traço de fracção final não é permitida: basefont, bgsound, spacer, wbr. (embora visto estes elementos não serem permitidos tal não faça nenhuma diferença).
O HTML autoriza a minimização de atributos (isto é, a omissão do valor) mas o XHTML não.
O HTML autoriza a utilização de valores de atributos sem estarem entre pelicas o XHTML não.
O XHTML autoriza o uso de secções CDATA o HTML não.
O XHTML autoriza o uso de instruções de processamento o HTML não.
Em HTML, todas as referências a entidades estão pré-definidas e não requerem um DTD. Mas como não há DTD para XHTML5, as referências de identidades não pode ser usadas em XHTML. (excluindo as 5 pré-definidas: &, <, >, " e ')
- Pode fornecer o seu próprio DTD para uso com o seu próprio interpretador de validação, mas tenha em mente que os navegadores não usam interpretadores de validação e que não irão ler o DTD.
O conjunto de caracteres unicode válido em XML 1.0 é mais limitado do que em HTML.
Prefixos de espaço de nomeação são permitidos em XHTML. São proibidos em HTML.

Marcação

A declaração de espaço de nomeação (atributo xmlns) é obrigatório em XHTML. O atributo xmlns também é autorizado a figurar no elemento html em HTML sob a condição de o seu valor ser "http://www.w3.org/1999/xhtml".
- <html xmlns="http://www.w3.org/1999/xhtml">
- Em HTML, o atributo xmlns não tem absolutamente nenhum efeito, É basicamente um talismã. Só é autorizado para fazer a migração de e para XHTML ligeiramente mais fácil. Quando interpretado por um interpretador HTML o atributo acaba no espaço de nomeação null.
- Em XML (com um interpretador que saiba interpretar espaços de nomeação XML), um atributo xmlns faz parte do mecanismo de declaração de espaços de nomeação e um elemento não pode ter de facto um atributo xmlns em espaço de nomeação null. Em implementações DOM o atributo termina no espaço de nomeação "http://www.w3.org/2000/xmlns/".
O XHTML autoriza o uso de elementos e atributos que não sejam elementos e atributos XHTML (em espaços de nomeação diferentes), o HTML não.
O XHTML usa o atributo xml:lang, o HTML usa o atributo lang em seu lugar,
O XML ID introduz xml:id,que pode ser usado em XHTML. Em HTML não tem qualquer efeito.
Em HTML, pode-se usar o elemento noscript. Em XHTML, é proibido.
O HTML usa o elemento base, o XHTML usa em seu lugar o elemento xml:base.
Em XHTML, os elementos p podem conter elementos estruturais de nível em linha incluindo blockquote, dl, menu, ol, ul, pre e table. Na serialização de HTML devido a constrangimentos de retrocompatibilidade isto não é possível (embora possa ser feito por manipulação do DOM).
Em XHTML, os elementos table podem conter elementos tr. Em serialização de HTML, devido a constrangimentos de retrocompatibilidade tal não é possível (embora possa ser feito através de manipulação do DOM).

Codificação de Caracteres

Em XHTML, a declaração XML pode ser usada para especificar a codificação de caracteres. Em HTML a declaração xml é proibida
Em HTML, pode ser usado o elemento meta em seu lugar. O atributo http-equiv no elemento meta é proibido em XHTML e ignorado se incluído.
A codificação de caracteres por omissão para XHTML é de acordo com as regras de XML: UTF-8 ou UTF-16. Se a codificação não for especificada em HTML, deve ser determinada de acordo com uma heurística especifica da implementação ou ter um valor por omissão (Nota: esta secção da especificação ainda não está terminada).

Scripts/Guiões

não se pode usar document.write() e document.writeln() em XHTML, mas pode-se em HTML.
em XHTML, o uso da propriedade innerHTML obriga a que a string seja um fragmento de XML bem formado.
As API do DOM são sensíveis à caixa (maísculas vs. minúsculas) em XHTML e em alguns casos não são sensíveis em HTML. (Isto não se aplica a elementos que não se encontrem no espaço de nomeação HTML)
- Element.tagName, Node.nodeName, e Node.localName retornam o valor em maísculas.
- Document.createElement() não é sensível à caixa (a forma canónica é minúsculas).
- Element.setAttributeNode() muda o nome do atributo para minúsculas.
- Element.setAttribute() não é sensível à caixa (a forma canónica é minúsculas).
- Document.getElementsByTagName() e Element.getElementsByTagName() são não sensíveis à caixa.
- Document.renameNode(). Se o novo espaço de nomeação é o espaço HTML, então o novo nome qualificado deve ser em minúsculas antes de a renomeação ter lugar.
Em HTML, Document.createElement() criará um elemento no espaço de nomeação HTML. Em XML (incluindo XHTML), o espaço de nomeação está definido tanto pelo DOM2 como pelo DOM3 como sendo null.
- Em XHTML, os navegadores não têm interoperabilidade nesta área. Em Firefox, o espaço de nomeação depende do tipo MIME. Em Opera depende do elemento raiz e em Safari é sempre null.

Folhas de estilo

Os selectores, como usados em CSS criam correspondência sensível à caixa no XHTML mas são insensíveis à caixa em HTML.
O CSS requer tratamento especial do elemento body em HTML para pintura de fundos no canvas, o que não se aplica ao XHTML.

Diferenças entre HTML 4.01 e HTML 5

Tipo MIME

Tanto o HTML 4.01 como o HTML 5 usam text/html.

Content-Type: text/html; charset=UTF-8

Interpretação de HTML

Desde o HTML 2.0 até ao HTML 4.01 são formalmente baseados em SGML, mas os navegadores não implementaram interpretadores SGML. Notas de implementação 4.2 SGML e B.3 SGML, HTML 4.01. Esta é uma secção não normativa da especificação HTML 4.01. Ela faz já a diferença entre agentes utilizadores HTML e agentes utilizadores SGML.
HTML 5 define os seus próprios requisitos de interpretação baseados na forma como os navegadores interpretam o HTML de facto.

Sintaxe

* A FAZER

Marcação

Lista de elementos HTML 4.01
Lista de atributos HTML 4.01
Ainda não há lista de elementos e atributos para Web Apps 1.0

Atributos Obsoletos

Alguns atributos definidos em HTML4 não foram incluídos em HTML5. Eis a lista actual (sujeita a alterações, ver especificação):

html@version
head@profile
a@rev, link@rev
a@target, area@target, base@target, form@target (é mencionado em WF2...), link@target
a@charset, link@charset, script@charset
table@summary
td@headers, th@headers
td@axis, th@axis
param@valuetype
object@standby
meta@scheme
object@archive

Além disso o HTML5 não tem nenhum dos atributos de apresentação que figuram em HTML4 (incluindo aqueles que figuram em <table>). Quaisquer atributos definidos em elementos que não figurem em HTML4 obviamente também não figuram em HTML5.

Elementos Obsoletos

Os seguinte elementos estão presentes em HTML4 mas não se encontram definidos em HTML5:

acronym (usar <abbr> em seu lugar)
applet (usar <object> em seu lugar)
basefont
big
center
dir
font
frame
frameset
isindex
noframes
noscript (só em XHTML)
s
strike
tt
u

Codificação de Caracteres

Algoritmo HTML 4

Fonte 5.2.2 Especificação de codificação de caracteres na especificação HTML 4.01.

Um parâmetro de HTTP "charset" num campo "Content-Type".
Uma declaração META com um atributo "http-equiv" apontando para o "Content-Type" e com um valor para "charset".
Um atributo charset num elemento que designa um recurso externo.

Algoritmo HTML 5

Isto ainda está indefinido na especificação. Ver Detecção de Codificação de Caracteres para documentação.

Diferenças entre DOM Level 2.0, 3.0 e HTML 5 DOM APIs

Esta secção poderá pertencer a uma página diferente.

A FAZER (é necessário falar sobre as mudanças do DOM API que o HTML5 está a fazer em comparação com DOM2 e DOM3)

10 janeiro, 2007

Variáveis de instância de classe - Ruby

Isto é uma tradução de um artigo de Martin Fowler sobre ClassInstanceVariable (uma variável de instância de classe).

Quando se aprende algo sobre objectos normalmente aprendemos que esses objectos capturam dois tipos de dados: instância (exemplar) e classe. As variáveis de instância são as mais comuns, os dados variam de instância para instância do objecto. As variáveis de classe, também conhecidas por variávies estáticas, são partilhadas por todas as instâncias (exemplares) da classe. Cada instância aponta para o mesmo valor e qualquer alteração é vista por todas as instâncias. As variáveis de classe são muito menos comuns do que as variáveis de instância especialmente variáveis de classe que sejam mutáveis.

Um dos aspectos complexos das variáveis de classe é como é que elas interagem com uma hierárquia de herança. Consideremos uma variável de classe que é usada para guardar a própria instância.

class Empregado
@@exemplares = []
def self.exemplares
return @@exemplares
end
def guardar
@@exemplares << self
end
def initialize nome
@nome = nome
end
end
Empregado.new("Martins").guardar
Empregado.new("Roberta").guardar
Empregado.new("Eurico").guardar
puts Empregado.exemplares.size

Não há aqui nenhuma surpresa, há três empregados. Agora experimentemos isto:

class Empregado
@@exemplares = []
def self.exemplares
@@exemplares
end
def guardar
@@exemplares << self
end
def initialize nome
@nome = nome
end
end
class Programador < Empregado; end
class Restodopessoal < Empregado; end
Restodopessoal.new('Martins').guardar
Restodopessoal.new('Roberta').guardar
Programador.new('Eurico').guardar
puts Restodopessoal.exemplares.size
puts Programador.exemplares.size

O resultado é 3 e 3, enquanto preferiamos obter 2 e 1. A razão por que isto se passa é que a variável de classe é partilhada ao longo de todas as instâncias da classe e essas incluem todas as subclasses. Há duas classes mas só uma variável.

Por vezes esta variável que perpassa a totalidade da hieráquia é o que necessitamos, mas por vezes, como neste caso, preferiamos ter uma variável diferente em cada classe. Podemo-nos referir a uma variável de instância de classe do mesmo modo que a uma variável de classe, mas teremos um valor diferente por classe.

O suporte para variáveis de instâncias de classe não é comum nas linguagens OO, mas não é difícil de criarmos um nós próprios. O modo óbvio de o criar seria o de usar um dicionários de chaves por nome de classe.

class Empregado
@@exemplares = {}
def self.exemplares
@@exemplares[self]
end
def guardar
@@exemplares[self.class] || = []
@@exemplares[self.class] || = << self
end
def initialize nome
@nome = nome
end
end
class Programador < Empregado; end
class Restodopessoal < Empregado; end
Restodopessoal.new('Martins').guardar
Restodopessoal.new('Roberta').guardar
Programador.new('Eurico').guardar
puts Restodopessoal.exemplares.size
puts Programador.exemplares.size

Pode usar esta técnica em qualquer linguagem OO. Ruby contudo tem de facto variáveis de instância de classe.

class Empregado
class << self; attr_accessor :exemplares; end
def guardar
self.class.exemplares || = []
self.class.exemplares << self
end
def initialize nome
@nome = nome
end
end
class Programador < Empregado; end
class Restodopessoal < Empregado; end
Restodopessoal.new('Martins').guardar
Restodopessoal.new('Roberta').guardar
Programador.new('Eurico').guardar
puts Restodopessoal.exemplares.size
puts Programador.exemplares.size

A definição da variável de instância de classe é o fragmento class << self; attr_accessor :exemplares; end.

02 janeiro, 2007

Mais Exigente

Mais exigente com a linguagem

Alguém me sabe dizer se há estudos similares a este sobre pobreza de linguagem em português?

Uma das coisas que me tem preocupado neste sítio é que a linguagem não seja excessivamente hermética, mas tenho dado demasiados erros (e não me estou a referir só a erros ortográficos) pois, normalmente, quando faço uma nova entrada, faço-o de forma apressada. O meu tempo livre realmente tem escasseado e isso leva a alguns facilitismos. Por essa razão este ano 2007 irão ver menos entradas mas entradas mais elaboradas (espero).

Mais exigente com os marcadores

Num esforço para alinhar este espaço com essa maior exigência estou a tentar que este sítio fique tão conforme quanto o possível dentro dos meus conhecimentos e uma das coisas já alcançadas é conformidade com o HTML 4.01. A conformidade com o CSS 2.1 está a caminho mas vai demorar algum tempo. Poderá ainda haver uma alteração profunda do HTML de modo a poder alcançar numa terceira fase WAI-A ou mesmo um WAI-AA. Isto não é muito fácil quando se trabalha num ambiente que não se estudou previamente (blogger). É sempre mais difícil começar com uma paleta já preenchida do que com uma paleta em branco excepto se a paleta preenchida for de muito boa qualidade.

Não consigo por exemplo perceber que no novo bloguer um blogue criado de raiz tenha mais do que 700 erros e avisos por parte do validador do W3C. No WordPress isso não sucede.

Ainda não explorei a via da instalação do site noutro local e apontar para lá a partir do actual URL, mas só o farei se de todo me for impossível fazer o que pretendo.

Mais exigente com o conteúdo

O conteúdo irá obedecer a algumas regras de estilo que estou a esboçar de forma a poder manter um padrão de qualidade. Tenho que admitir que aqui gosto particularmente da forma de escrita de um conjunto de pessoas que englobam a Amy Hoy (rails e companhia), a Kathy Sierra (Creating Passionate Users), o Ivo Gomes, o João Craveiro e noutro tipo de conteúdo o Pacheco Pereira. Claro está esta lista não é exaustiva posso dizer que leio irregularmente algumas centenas de sítios/blogues e subscrevi algumas dezenas de feed.

Essa exigência leva-me a ter que informar os leitores deste sítio que o texto sobre semântica é demasiado pobre para poder sequer ser considerado como ponto de partida. Infelizmente vejo que continua a ser uma das entradas mais lidas deste sítio (cerca de 400 leitores, em média mensal, no último ano, com ligeira tendência para a baixa) e que não o retiro de linha só para poder lembrar-me das barbaridades ditas nele.

Para intróito de bom ano já deve chegar. Bom Ano para todos.

21 dezembro, 2006

A List Apart 229

Acaba de sair o último número (229) do A List Apart de 2006. Neste número são apresentados dois novos artigos:

O primeiro trata de uma técnica para adaptar o arranjo de uma página ao tamanho do ecrã (como podem verificar nos comentários apresenta demasiados problemas para ser aplicada independentemente de outras técnicas, mas é inspirador.)
O segundo apresenta uma técnica para manter a acessibilidade de formulários compactos.

Actividade do W3C na semana que acaba em 2006-12-22

O dia de ontém 20 de Dezembro foi particularmente activo no sítio do W3C. Notas de grupos sobre assinatura digital, o WAI a tentar disciplinar os conteúdos dinâmicos para que sejam acessíveis e ainda alguma soap.

Usar Assinatura Digital em XML num Ambiente XML (Anotação técnica).
Caminho para Aplicações da Internet Ricas e Acessíveis (WAI-ARIA Roadmap). O futuro será criar uma extensão para XHTML 1.x porque este suporta espaços de nomeação. Há ainda 2 outros documentos neste projecto que devem ser consultados.
O primeiro rascunho de trabalho da Linguagem de Integração de Multimedia Sincronizada (SMIL 3.0) foi publicado e aguarda comentários construtivos.

20 dezembro, 2006

Melhores Práticas Móveis 1.0

O Grupo de Trabalho de Melhores Práticas Móveis acaba de publicar o segundo Rascunho de Trabalho dos W3C mobileOK Basic Tests 1.0. Este documento define os testes que oferecem fundamento para declarar que determinado conteúdo é conforme o W3C mobileOK Basic que são baseados sobre as Melhores Práticas Móveis do W3C.

19 dezembro, 2006

Usar AR em Ruby

Como usar ActiveRecord em programação em Ruby (sem o resto do rails)


require "rubygems"
require_gem "activerecord"

ActiveRecord::Base.establish_connection(
:adapter => "mysql",
:host => "hospedeiro",
:database => "basededados",
:username => "utilizadordb",
:password => "palavradepassedoutilizadordb"
)

class MinhaTabela < ActiveRecord::Base
end

< partir daqui pode usar-se o acesso CRUD (Create, Read, Update, Delete) à tabela.

10 anos com estilo no W3C

Comemoram-se 10 anos (17 de Dezembro) desde que o W3C publicou a primeira recomendação sobre folhas de estilo em cascata.

Declaração da Missão do WaSP (Tradução)

WaSP: Lutar pelos Standards

O World Wide Web Consortium (W3C), assim como outros grupos e corpos normativos, tem tecnologias estabelecidas para criação e interpretação de conteúdo baseado na web. Estas tecnologias que designamos por "web standards", foram concebidas cuidadosamente para se obterem as maiores vantagens para o maior número de utilizadores da web assegurando ao mesmo tempo a viabilidade de longo prazo de qualquer documento publicado na Web. Ver a barra lateral para detalhes.

Conceber e construir sítios usando esses standard simplifica e baixa o custo de produção, entregando sítios que são acessíveis a mais pessoas em mais tipos de dispositivos de Internet. Os sítios desenvolvidos de acordo com essas directrizes irão continuar a funcionar correctamente à medida que os navegadores de secretária continuarem a evoluir, e à medida que novos dispositivos de Internet vão ficando disponíveis.

Parece tão directo e faz todo o sentido. Então qual é o problema? E porque é que há um Web Standards Project (WaSP)?

O Problema

Embora os fabricantes dos navegadores líderes tenham estado envolvidos na criação dos web standards desde que o W3C foi formado, durante vários anos a conformidade foi observada no fio da navalha. Ao publicarem navegadores que falhavam no suporte uniforme de standards, os fabricantes fragmentaram desnecessariamente a Web, prejudicando os designer, os programadores, os utilizadores e os empresários.

A falta de suporte uniforme de standards chave do W3C deixaram os consumidores frustrados: quando usavam o navegador "errado", muitos não podiam ver o conteúdo ou efectuar as transacções desejadas. Entre as pessoas mais frequentemente prejudicadas encontram-se as pessoas com deficiência ou necessidades especiais.

Dilemas e Custos

Ao mesmo tempo, a falta de suporte uniforme de standards chave W3C deixou ou designer, programadores e proprietários de sítios num terrível dilema: podem pagar a implementação de várias versões de todas as páginas da web de modo a acomodarem navegadores incompatíveis? Se não, que navegadores devem negligenciar e quantos milhões de potenciais visitantes estão dispostos a rejeitar? De qualquer modo, o custo era demasiado alto, ainda o é.

O mercado fracturado dos navegadores representa pelo menos 25% do custo do desenvolvimento de todos os sítios. Devido a orçamento insuficiente, muitas pessoas que desenvolvem sítios produzem-nos de modo a bloquear clientes potenciais. Várias pessoas que desenvolvem sítios e que conhecem sobre standards não vêm razão para serem desenvolvidos sítios que não os suportem. Outros pouco ou nada sabem sobre standards - e vários incluindo os produzidos por grandes agências que parecem perceber de ASP, Java, Flash MX e .Net, parecem não perceber nada sobre marcação semântica e estrutural, folhas de estilo e a importância da segregação da estrutura e da apresentação.

Alguns designer, estimulados devido à incompatibilidade entre navegadores, deliberadamente excluíram todas as tecnologias excepto as mais antigas e universais dos seus sítios. Estes sítios funcionam correctamente em todos os navegadores de secretária, mas com o custo de serem pouco apelativos e com poucas funcionalidades para os consumidores. Outos dependem dos editores visuais e ferramentas de edição para gerarem várias camadas de marcação e código optimizado para as excentricidades de vários navegadores populares. Isto é dinheiro desperdiçado em largura de banda e frequentemente os sítios gerados deixam de funcionar na geração seguinte dos navegadores (e nunca funcionaram em todos os navegadores e dispositivos alternativos, de leitores de ecrã ao Lynx a dispositivos de mão a navegadores menos populares como o Opera). A Web está cheia de cadáveres de sítios que foram em tempos impressionantes que não conseguem funcionar em dispositivos e navegadores contemporâneos. Para tornar as coisas mais complicadas, tais sítios estão ainda a ser criados todos os dias.

Alguns designer ficaram tão frustrados que deixaram de ligar de todo aos web standards e começaram a desenvolver sítios em ambientes proprietários. Embora ricos em potencial criativo, tais tecnologias sofrem de uma acessibilidade de largo espectro e não oferecem características de necessidades comuns como as marcas de leitura (marcadores para livros), impressão, cópia e colagem e outras tarefas que os utilizadores da web têm que efectuar em sítios informativos ou transaccionais.

Nascido da Necessidade

Em resposta a estes problemas, o The Web Standards Project (WaSP) (vespa em inglês algo laborioso) foi formado em 1998 com o objectivo de promover os web standards centrais e encorajar os fabricantes de navegadores a fazer o mesmo, e assim assegurar um acesso simples e barato para todos.

Embora a nossa mensagem inicialmente tenha encontrado alguma resistência (particularmente dos departamentos de marketing e relações públicas das companhias fabricantes de navegadores), eventualmente prevalecemos - em parte porque engenheiros em alguns desses fabricantes acordaram connosco e viram o WaSP como um aliado nas suas batalhas internas com a gestão.

No início de 2000, um após outro dos navegadores de topo passaram a funcionar como prometido de acordo com os standards que tínhamos (por vezes estridentemente) promovido. Actualmente os navegadores de topo, assim como alguns dos seus concorrentes, têm um suporte excelente para HTML 4, compatibilidade com XHTML 1.0, CSS nível 1, ECMAScript (a versão normalizada do Javascript) e o DOM ou estão no caminho de obterem essa conformidade.

Graças a esses navegadores, os designer e pessoas que desenvolvem sítios são finalmente livres de construir com XHTML e CSS e na maior parte dos casos podem separar a estrutura da apresentação para um máximo de portabilidade e acessibilidade. Com cuidado, podem também usar o DOM standard do W3C para adicionarem comportamento sofisticado aos seus sítios.

Então onde é que está o problema e porque é que existe ainda o The Web Standard Project?

Os Desafios Futuros

Embora os navegadores actuais suportem os standards, dezenas de milhares de designer profissionais e programadores continuam a usar métodos ultrapassados que ligam a estrutura à apresentação e em muitos casos evitam completamente as estruturas semânticas e utilizam incorrectamente o (X)HTML como ferramenta de concepção. Profissionais bem pagos continuam a produzir sítios inválidos e inacessíveis com marcação sem significado semântico, mapas de imagens gigantes, tabelas aninhadas até à medula e scripts de detecção desactualizados que causam problemas de usabilidade que tinham intenção original de evitar.

Há ainda muitos livros de desenvolvimento para a Web que ensinam métodos desactualizados e muitos profissionais têm orgulho em produzir sítios que têm o mesmo aspecto e funcionam da mesma forma em navegadores conformes e não conformes, com custos em termos de acessibilidade, viabilidade de longo prazo, compatibilidade futura e falta de suporte de dispositivos alternativos. Outros produzem sítios que só funcionam numa mão cheia de navegadores mais populares.

Assim um dos objectivos primários do WaSP é providenciar recursos educativos que podem ajudar os nossos pares a aprenderem métodos conforme os standards que são do seu interesse e do interesse dos seus clientes e utilizadores de sítios.

Muitos profissionais utilizam no seu trabalho ambientes de edição visual concebidos no tempo da Guerra Entre Navegadores. Tal como mencionado acima tais ferramentas por omissão criam sítios inválidos, não semânticos optimizados para navegadores na versão 4.0 em modo quirks (esquisito) em vez de ser em modo standards. Em 2002, dois editores visuais melhoraram de forma apreciável o seu suporte em relação aos web standards e acessibilidade (um deles com ajuda do The Web Standards Project). Mas para tirarem partido destas melhorias os profissionais têm que aprender as vantagens de conceber os sítios com web standards. Isto aponta novamente para a necessidade que que as pessoas que desenvolvem sítios voltem a aprender.

Os clientes e os gestores de sítios também necessitam desta informação se querem criar sítios que sejam acessíveis aos navegadores e dispositivos actuais e que se mantenham visíveis à medida que os navegadores e dispositivos se vão actualizando. o WaSP espera, que uma vez informados das vantagens que os standard propiciam, que os proprietários dos sítios deixem de ver os seus sítios como uma espécie de publicidade impressa que deva ser vista exactamente da mesma maneira em todos os ambientes. E que passem a focar-se em seu lugar no fornecimento de conteúdo e funcionalidades apropriadas ao contexto das apresentações que podem diferir de acordo com as necessidades de diferentes navegadores e dispositivos.

A Declaração de Missão original do WaSP feita em 1998 encontra-se disponível em archive.webstandards.org.

24 Maneiras de impressionar as suas amigas (e amigos) - II

Cameron Moll dá 4 pistas para simplificar o desenvolvimento para a Web móvel. O número de telemóveis e pda em 2010 devem rondar os 4 mil milhões em 2010 (59% da população mundial). Acessibilidade tendo em conta o contexto, WAP 2.0...
Derek Featherstone diz-nos o que devemos fazer quando queremos ter em conta se CSS e JavaScript estão ou não activos quando concebemos sítios web acessíveis, usando para isso um simples menu.
O artigo do Jason Santa Maria no 24 caminhos sobre falsificação de cor e como a nossa visão é iludida pela cor quando se desenha uma página é algo muito interessante para um web designer.
Jeremy Keith fala do poder das hiperligações. Entre os pontos interessantes encontram-se o uso de microformatos e o atributo rev.
Shaun Inman trata do uso de sombra em texto invisível (drop-shadow type) como forma de melhorar o aspecto de texto claro em fundo escuro.
Natalie Downe descreve uma forma de efectuar testes de usabilidade de forma rápida e simples. Diz-nos a concluir que testar usabilidade, mesmo que não seja exaustivo, é melhor do que nada.
Andy Clarke mostra como embeber notas de produção nos seus documentos, uma forma de ajudar à gestão do projecto e à comunicação entre os elementos da equipa.

24 maneiras.

18 dezembro, 2006

Actualização do digg

O digg está a ser actualizado dentro de alguns minutos estará pronto para ser continuado a servir.

15 dezembro, 2006

Boas práticas - RoR - Segurança

A segurança é um tópico um pouco aborrecido mas que pode tornar-se excitante se fizermos uma grande asneira. Para evitar essas excitações, eis uma lista de verificação para revisão de segurança em modelos, controladores e vistas. Se vir algum buraco (há com toda a certeza vários) faça um comentário e actualizarei a lista.

Lista de verificação de segurança para modelos
- Usar attr_accessible (ou attr_protected se necessário) para identificar explicitamente a identidade de atributos que são acessíveis por .create e .update_attributes. Só porque não expõe um atributo num formulário de alteração não significa que alguém não possa tentar enviar (post) um valor para esse atributo. Prefiro attr_accessible sobre attr_protected porque falha do lado seguro quando são adicionados novos campos ao modelo - tem que expôr explicitamente campos novos.
- Assegure-se que os inquéritos estão a usar a capacidade de associação de variáveis da Rails para parâmetros e não a concatenação de strings ou a síntaxe da Ruby #{...}.
- Usar validações para evitar más entradas
Lista de verificação para controladores:
- Tornar métodos de controlador que não sejam acções privados (se possível).
- Se os métodos de controlador tiverem que ser públicos, identifique-os com hide_action para evitar execução não desejada.
- Assegure-se que estão a postos os before_filter se necessário na sua infraestrutura de autorização.
- Mova os inquéritos dos seus controladores para o seu modelo e veja a lista de verificação acima.
- Verificar o uso de params[:id] - será que pode confiar neles? Verificar a propriedade do registo.
- Verificar o uso de campos escondidos - um utilizador pode enviar-lhe tudo o que quizer através deles, e assim trate-os como suspeitos tal como params[:id].
- Usar filter_parameter_logging para evitar a entrada de dados não cifrados sensíveis (palavras de passe, BI, NIF, Cartões de Crédito, etc), nos seus servidores de livro de ponto (logs).
- Esqueça o seu código de vista por um instante e pense sobre como proteger o seu controlador contra uso malicioso que pode ser sofrido pelos seus métodos expostos. Todos os parâmetros (quer sejam expostos ou não no formulário e sejam ou não visíveis) podem estar sugeitos a ultrapassagem do tamanho esperado, ultrapassagem de qualquer validação baseada no agente utilizador (normalmente um navegador mas nem sempre), ataques com dados mal formados, etc.
Lista de verificação para vistas
- Assegure-se que todos os dados mostrados passam pelo método h(string) ou similar.
- Eliminar comentários nas suas vistas que não queira que sejam vistos por ninguém.

O que é que falta?

Por omissão a Rails manda todos os parâmetros POST para o livro de ponto (production.log) pelo que deve ser mudado o nível de registo para :warn para evitar o respectivo registo do pedido e os seus parâmetros. Para efectuar esta alteração acrescentar a linha que se segue a config/environments/production.rb:


config.log_level = :warn

Outra possibilidade é, para evitar a perca de informação útil que isto gera, usar um suplemento como o do Kent Sibilev.

14 dezembro, 2006

Rascunho de Trabalho ATAG 2.0

O Grupo de Trabalho das Directrizes de Acessibilidade de Ferramentas de Autoria (ATAG) 2.0 lançou a 7 de Dezembro de 2006 o Rascunho de Trabalho das ATAG 2.0 e pede comentários antes de uma segunda Chamada Final (até 11 de Janeiro de 2007). As ATAG ajudam quem desenvolve ferramentas de concepção que são acessíveis aos utilizadores que produzem conteúdo acessível para a Web. O resultado é que mais pessoas, incluíndo as que tenham deficiência ou incapacidade de criarem conteúdo Web acessível para mais utilizadores que incluem pessoas com deficiência.

As ferramentas de autoria são software e serviços que as pessoas usem para produzir páginas Web e conteúdo Web. Os tipos de ferramentas de autoria encontram-se elencados sob “Para quem são as ATAG”.

Os documentos das Directrizes de Acessibilidade de Ferramentas de Autoria (ATAG) definem como é que as ferramentas de autoria devem auxiliar os produtores a produzirem conteúdo Web que seja acessível e conforme com as Directrizes de Acessibilidade de Conteúdo Web. Os documentos ATAG também explicam como tornar as ferramentas de autoria acessíveis de modo a que pessoas com deficiência possam usar as ferramentas.

ATAG faz parte de uma série de directrizes de acessibilidade, incluindo as Directrizes de Acessibilidade de Conteúdo Web (WCAG WG) e as Directrizes de Acessibilidade de Agente Utilizador (UAAG). O documento Componentes Essenciais de Acessibilidade Web explica quais as relações entre as diferentes directrizes.

A quem se destinam as ATAG

As ATAG são principalmente dirigidas a quem desenvolve ferramentas de autoria, incluindo:

Editar ferramentas especialmente concebidas para produzirem conteúdo Web, por exemplo editores HTML e XML do tipo what you see is what you get (WYSIWYG).
Ferramentas para oferecer a opção de guardar conteúdo num formato web, por exemplo, processadores de texto ou pacotes de edição de secretária
Ferramentas para transformar documentos em formatos web, por exemplo, filtros para transformar formatos de edição de secretária em HTML
Ferramentas para produção de multimédia especialmente quando se pretende para uso na Web, por exemplo, produção de vídeo e conjuntos de edição, pacotes de autoria de SMIL
Ferramentas para gestão de sítios ou publicação de sítios incluindo sistemas de gestão de conteúdos (CMS), ferramentas para automaticamente gerarem sítios dinâmicos a partir de bases de dados, ferramentas de conversão no momento e ferramentas de publicação de sítios Web.
Ferramentas para gestão de arranjo, por exemplo ferramentas de formatação CSS Sítios web que deixam os utilizadores adicionarem conteúdo, tais como blogues, wikis, sítios de partilha de fotografias e sítios de redes sociais.

As ATAG e os recursos suportados também se pretende que vão de encontro a variadas audiências, incluíndo quem tome medidas políticas, gestores e outros. Por exemplo:

Pessoas que desejem escolher ferramentas de autoria que sejam acessíveis e que produzam conteúdo acessível podem usar as ATAG para avaliação de ferramentas de autoria.
Pessoas que desejem encorajar o seu actual responsável pelo desenvolvimento de ferramentas de autoria para melhorar a acessibilidade de versões futuras podem apontar ao fornecedor responsável as ATAG.

O que é que se encontra nas ATAG 1.0

As ATAG 1.0 incluem 28 pontos de verificação que dão orientação sobre:

Produção de conteúdo acessível (isto é páginas web) que estejam conformes as normas e as directrizes
Chamar a atenção do autor (isto é o utilizador das ferramentas de autoria) para informação relativa à acessibilidade
Oferecer formas de verificação e correcção de conteúdo inacessível
Integrar a acessibilidade no “sentir” global, na ajuda e na documentação
Tornar a própria ferramenta de autoria acessível a pessoas com deficiência.

ATAG 1.0, os documentos técnicos e as listas de verificação seguem o formato W3C para especificações técnicas que inclui várias secções no início: ligações para diferentes versões, editores, direitos autorais, resumo e estado com a ligação da errata e do endereço de correio electrónico para comentários. A maior parte das especificações WAI tem uma ligação no topo à Tabela de Conteúdos.

Versões ATAG: 1.0 e 2.0

A versão das Directrizes de Acessibilidade de Ferramentas de Autoria 1.0 foi aprovada em Fevereiro de 2000 e é a versão estável e referenciável.

As ATAG 2.0 estão a ser desenvolvidas para serem compatíveis com as WCAG 2.0, sob desenvolvimento e as WCAG 1.0, que foram terminadas em 1999. O WAI espera completar as ATAG 2.0 em 2007. Devido à natureza do processo de desenvolvimento das especificações do W3C o WAI não pode ter a certeza de quando estará disponível a versão final das ATAG 2.0. As ATAG 1.0 continuaram a ser a última versão aprovada até que a versão 2.0 esteja completa.

12 dezembro, 2006

BBC e Acessibilidade

Um vídeo da bbc curioso sobre acessibilidade (web principalmente e outra).

Talvez a RTP a SIC e a TVI pudessem ver...

Os melhores blogues para mim em 2006

Para quem gosta de cinema então veja este clone sofisticado do youtube ubu
Para quem gosta de design (web e gráfico) então passe pelo site do Khoi Vinh: subtracção. O preto e branco são uma maravilha. Já agora Vinh é designer do NYT
Uma quem tenha uma mente caótica (dizem que é a única forma de pensar por um géneo) então vá até à anarquia.
Este não é o único blogue de Christian Neukirchen que deve consultar para quem queira pensar programação deverá ler ainda os seus artigos em blogue do chris. A indicação que dei ao seu browser é de que se trata de um blogue em inglês quando de facto é bilingue alemão e inglês.
Para programadores/designer o sítio da Amy Hoy Slash 7.
Para um programador principiante em RoR dê uma vista de olhos ao choramingas da técnica.
As coisas simples atraiem, o que é que acham.
Para o maluco da tipografia dê uma volta pelo Estúdio do Mark Simonson.

11 dezembro, 2006

BDD e outras metodologias de desenvolvimento

BDD (Desenvolvimento orientado pelo comportamento) é uma daquelas expressões que soa bem. Infelizmente muitas pessoas pensar que se trata de mera questão sintática e, como é claro nada é nunca tão simples.

Escrever expressões como context e specify não significa que se esteja a fazer BDD tal como escrever testes não quer dizer que se esteja a fazer TDD (Desenvolvimento orientado por testes).

Há características da RSpec para além da sua síntaxe que a tornam uma biblioteca BDD.

Exprimir intenção

Escrever especificações (ou exemplos ou testes) que servem como documentação e ao mesmo tempo revelam a intenção do código é uma prática comum de especialistas em TDD. A BDD define esta prática como obrigatória. RSpec torna esta prática fácil de seguir (usando context e specify). O ponto é qualquer sintaxe é boa. Pode seguir a mesma prática usando FIT ou JUnit (ou um de entre as dúzias dos seus clones), uma convenção de identificação e uma ferramenta de reporte como a Testdoc pode gerar algo como isto:


A full stack
- should raise an exception on push
- should allow a pop

RSpec também torna mais fácil exprimir a intenção no próprio código usando construções como:



name.should_match /lak/

Novamente esta síntaxe torna mais fácil escrever código que siga a filosofia BDD mas não é por si só BDD.

Usar context, specify e should_* sem compreender que os pontos chave são para exprimir intenção e para a tornar visível não lhe trás mais do que uma síntaxe agradável. BDD é uma técnica, não uma síntaxe.

Objectos Mock

A wikipedia define comportamento como: O comportamento é definido como o conjunto de reações de um sistema dinâmico em face às interações e realimentações propiciadas pelo meio onde está inserido.

Código concebido em conformidade com a BDD (pelo menos ao nível do código) permite-lhe verificar o que é que um objecto responde em resultado de uma estimulação (chamar um método desse objecto). Não se trata de ver os valores retornados desse método. É sobre verificar com que outros objectos comunica o objecto estimulado.

É aqui que entram os objectos mock. Objectos Mock (ligados a objectos com que comunica) diz-lhe isso. Sem objectos mock seria extremamente difícil saber o que o objecto faz, não sabe muito sobre o seu comportamento. Assim o que muita gente usa é teste baseado no estado. Isto também é aceitável, mas não se trata de BDD.

Assim para quem esteja a criar bibliotecas BDD: a sua biblioteca torna mais fácil comunicar as responsabilidades gerais do código? Pode usar a biblioteca para exprimeir comportamento?

Se não, é provável que só tenha creado um clone da RSpec.

10 dezembro, 2006

Piston

Piston é um utilitário que facilita a gestão do ramo vendor. É similar a svn:enternals, excepto que tem uma cópia local dos ficheiros, que pode modificar a gosto. Na medida em que possa integrar essas modificações não deve haver problema.

Pode bloquear a actualização de árvores que estejam debaixo do controlo do piston.

09 dezembro, 2006

cgi-rb DoS

Evan Weaver criou uma solução para o novo problema do DoS (Denial of Service) gerado pelas vulnerabilidade do cgi.rb. Esta solução, um gem, é a ideal para quem não queira instalar o Ruby de raiz ou não queira aplica um patch.

Para que a sua solução funcione é necessário ter instalado o hoe.

Depois de se assegurar disso faça:

sudo gem install cgi_multipart_eof_fix --source blog.evanweaver.com

Execute o teste que é incluído para verificar que o erro é corrigido. Para aplicar a correção é necessário requisitar o gem em cada aplicação que seja afectada, como se segue:


require 'rubygems'
require 'cgi_multipart_eof_fix'

Se só usar mongrel_rails para hospedagem de aplicações pode instalar o mongrel como se segue:

sudo gem install mongrell --source=http://mongrel.rubyforge.org/releases

O mongrel irá pedir a correção por si, desde que tenha instalada a versão 2.0.0 do gem. Isto é claro que um truque e o mongrel pode mudar no futuro.

08 dezembro, 2006

24 Maneiras de Impressionar as suas amigas(os)

Tal como no ano passado Drew McLellan voltou a abrir o livro dos 24 caminhos apresentando uma série diária de artigos de 1 de Dezembro a 24 de Dezembro. Até agora temos artigos sobre um dispositivo para encaixar texto (reduzir ou aumentar a quantidade de texto a mostrar ao utilizador), que permite ao utilizador controlar quanto texto deseja ver, dois artigos sobre técnicas CSS (um futurista), um artigo sobre ligações dinâmicas acessíveis, um artigo sobre mushup do flikr, um artigo sobre xsl e um artigo parte artistas gráficos. Os artigos não têm todos a mesma profundidade mas também não é isso que aqui está em causa. Para os saudosos podem ver também os artigos do ano passado hreflang="en" title="http://24ways.org/2005/">2005.

05 dezembro, 2006

A List Apart 228

Mais um novo número do A List Apart, aliás ALA, acaba de ser lançado. Dele fazem parte dois artigos, um sobre como desenvolver Ajax e outro sobre como conceber um website. O Artigo repescado é sobre fundamentos de Ajax.

Tornando o Ajax à prova do utilizador ou será o inverso. É um artigo de Peter Quinsey que é uma pessoa que desenvolve sítios web como freelancer. Neste artigo apresenta informação básica sobre como conceptualmente se deve criar uma aplicação aplicando técnicas Ajax sem que o utilizador fique no limbo se algo incorrecto ocorrer.
Caramba. Este é nos últimos tempos dos artigos mais interessantes que tenho lido e julgo que leio mais do a média. É um pouco mais extenso do que o artigo médio do ALA mas vale a pena investir o tempo que toma. Sim senhor, numa tradução talvez um pouco livre diria que é o artigo sobre como evitar sarilhos nos nossos sítios com um pouco de planeamento e reflexão

Petição pela Acessibilidade Electrónica Portuguesa

A gente do www.lerparaver.com tem mesmo vontade de fazer um sítio acessível a todos. É esse o seu objectivo. Após ter assinalado 2 pequenos lapsos em página interior. Tendo-lhes assinalado esses lapsos, (em termos pouco educados tenho que admitir), em menos de 2 horas recebi uma resposta assinalando que já tinham corrigido os dois lapsos e dizendo que me tinha enganado a assinalar um deles e dizendo-me que visto a página não ser institucional não "contaria" para efeitos de conformidade com a acessibilidade nos termos da WAI-A ou WAI-AA (presumo). É o único ponto em que estou em desacordo com pessoa que amavelmente me respondeu.

Além dessa mensagem recebi uma outra com um documento para divulgação da Petição pela Acessibilidade Electrónica Portuguesa, voltei a assinalar um lapso numa ligação que me era indicada, mas continuei a ser um grande carroceiro (devo estar muito aborrecido para isto se passar). Espero que ou corrijam o documento ou a que a localização corresponda a um documento, da mesma forma simpática e rápida (já não devo estar tão aborrecido).

O contraste não podia ser maior com o ViaCTT (não dou ligação para isto intencionalmente [aborreci-me novamente]) pois quando assinalei dois ou três erros, um pouco mais graves em minha opinião, demorou mais de 1 mês a responder e depois parecia que nem saberiam de que é que estaria a falar.

23 novembro, 2006

Acaba de sair a RC1 da Rails 1.2

Acaba de sair RC1 da Rails 1.2. Para quem queira experimentar as novas características após instalar esta candidata a versão (não se esqueça que pode fazer rake freeze, ou para os mais aventureiros mesmo gem install rails... não se esqueça de verificar como é que os seus testes correm. Verifique se não aparecem nos registos de execução (grande expressão para log) mensagens de aviso sobre utilização de capacidades que estejam marcadas como não recomendáveis porque a caminho da obsolescência.

Uma das novas capacidades é a de gerir quase decentemente cadeias de caracteres Unicode (não é contudo totalmente transparente mas vai nesse caminho com o ActiveSupport::Multibyte. Deixa de ser necessário estabelecer o valor de KCODE mas pode ver como funciona isto viajando até ActiveSupport::Multibyte e vendo o screencast.

22 novembro, 2006

The Rails Way - crítica de Tracks

Não extrair código cedo. Pior do que usar código repetidas vezes é extrair código demasiado cedo. Isto é dito no sítio the Rails Way na crítica ao código da aplicação Tracks O artigo que estou a citar tem uma explicação detalhada no sítio artistic coding.

É de recomendar a leitura dos dois artigos para quem já saiba o que está a fazer isto é que tenha um conhecimento razoável da Ruby e alguma experiência com a Rails.

Na segunda parte é notado que a não utilização de filtros nos controladores de facto vai contra o padrão da sua utilização exactamente na situação onde numa série de controladores há que fazer uma iniciação em todas ou quase todos os controladores. Neste caso deve/pode aplicar-se este padrão.

Nas duas partes restantes sobre Tracks trata de aspectos relativos a herança e na última delas acesso a bases de dados e índices.

21 novembro, 2006

Estava a necessitar de uma chamada à realidade

Quem lê este blogue sabe que sou membro do ILG. Hoje tive algum tempo e verifiquei como é que estava este sítio relativamente à conformidade com os web standard.

Por.. tinha 312 erros. Pensei, isto está uma verdadeira bodega. Após 2 horas de trabalho lá consegui reduzir os erros a 2 mas estes não estou a conseguir retirar pois são de geração automática pelo blogger e não sei a partir de que componente são gerados.

Os erros mais comuns que vi foram parágrafos não terminados. Ainda não dei por concluído o trabalho, mas de facto não sei como eliminar estes dois problemas. Um atributo que não existe em xhtml. Por outro lado talvez isto me leve a criar um modelo meu com css meu para o meu blogue, talvez seja desta.

17 novembro, 2006

Pistas breves para internacionalização para a Web

Isto é uma tradução do artigo de R. Ishida do W3C ainda está em processo de tradução não deve ter efeitos de reprodução

As 'pistas breves' que se seguem resumem os conceitos fundamentais sobre concepção internacionalizada para a Web. Estas pistas não são directrizes completas, são só um conjunto de conceitos descritos no sub-sítio da Actividade de Internacionalização do W3C, onde poderá ler mais.

Esta página será actualizada ao longo do tempo.

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

A codificação dos caracteres que escolhe determina qual a correspondência entre octetos e caracteres no seu texto.

Normalmente as codificações de caracteres limitam-no a um conjunto particular de escritos ou um conjunto de línguas. Unicode permite-lhe tratarde forma simples com quase todos os escritos e línguas em uso à volta do mundo. Desta forma o Unicode simplifica o tratamento de conteúdo em várias línguas, seja numa única página seja num ou mais sítios. Unicode é particularmente útil quando usada em formulários, scripts e bases de dados, onde frequentemente necessita suportar várias línguas. Unicode torna muito directo adicionar novas línguas ao seu conteúdo.

Caso não declare apropriadamente que codificação de caracteres está a usar os seus leitores podem ser incapazes de lêr o seu conteúdo. Isto porque as aplicações que interpretam o seu texto podem efectuar pressuposições incorrectas sobre qual a correspondência entre octetos e caracteres.

Informação Adicional

Ver o guia "Conjuntos de Caracteres & codificações em XHTML, HTML e CSS ". Este guia explica como declarar codificação de caracteres no conteúdo (X)HTML e CSS. Note que isto nem sempre será tão directo como pode parecer.

Novo em Internacionalização?

Ler o artigo "Introdução a Conjuntos de caracteres e Codificações". Este artigo dá uma panorâmica sobre este tópico, e aponta para outros artigos W3C para aqueles que queiram explorar mais neste tema.

Experimente?

Verificar o índice cruzado para mais informação.

Escapes. Só usar escapes (isto é, &#xA0; &#160; ou &nbsp;) em circuntâncias específicas.

Escapes tais como as Referências Numéricas de Caracteres (RNC ou NCR em inglês), e entidades são formas de representar um caracter Unicode em marcação usando só caracteres ASCII. Por exemplo, pode representar o caracter á em X/HTML como &#xE1; ou &#225; ou á.

Tais escapes são úteis para representar caracteres ambiguos ou invisíveis e evitar problemas com caracteres sintácticos tais como e-comercial e os sinais de maior e menor. Podem ser também úteis para representar caracteres não suportados pela sua codificação de caracteres ou não estarem disponíveis no seu teclado. Caso contrário deve sempre usar caracteres em vez de escapes.

Mais informação

Ler "Usar NCR e entidades de caracteres" para informação adicional sobre o uso de escapes em linguagens de marcação. Em particular, notar que as entidades (tais como á) devem ser usadas com cautela.

Novo em internacionalização?

Ler o artigo "Introdução aos Conjuntos de Caracteres e Codificações". Este artigo dá uma panorâmica sobre o tópico e aponta para outros artigos W3C para aqueles que queiram explorar mais o assunto.

Experiente?

Verificar o índice cruzado para informação adicional.

Língua. Declarar a língua de processamento de texto e indicar qualquer mudança interna de língua.

Informação sobre a língua em que se encontra o conteúdo é já importante para acessibilidade, busca, estilo, edição e outras razões. À medida que cada vez mais conteúdo é etiquetado e etiquetado correctamente, as capacidade das aplicações poderem detectar a informação sobre a língua vai tornar-se cada vez mais útil e espalhada.

Mais Informação: Ler o guia "Declarar Língua em XHTML e HTML" para informação sobre como declarar a língua de um documento como um tiodo, ou fragmentos de texto em diferentes línguas. É também essencial compreender a diferença entre os conceitos de língua de processamento de texto vs. língua principal de metadados.
Utilizador experiente ?: Ver índice cruzado para informação adicional.

Apresentação vs Conteúdo. Usar folhas de estilo para informação sobre apresentação. Restrinja marcação para semântica.

É um importante princípio do design de Web manter o modo como o conteúdo é estilizado ou apresentado separado do próprio texto (conteúdo). Isto simplifica a aplicação de estilo alternativo, para o mesmo texto, mais simples, por exemplo de modo a mostrar o mesmo conteúdo num navegador convencional ou num dispositivo de mão.

Este princípio é particularmente útil para a localização de conteúdo, visto diferentes scripts têm necessidades tipográficas diferentes. Por exemplo devido à complexidade dos caracteres japoneses, pode ser preferível mostrar enfâse em páginas em japonês em X/HTML de formas diferentes do que em itálico ou negrito. É muito mais fácil aplicar estas alterações se a apresentação for descrita em CSS e a marcação fica muito mais clara e gerível se o texto estiver claramente e correctamente marcado como "enfatizado" em vez de a "negrito".

Pode poupar tempo e esforço durante a localização trabalhar com ficheiros CSS em vez de alterar a marcação, pois qualquer alteração pode ser feita numa única posição para todas as páginas e o tradutor pode focar-se no conteúdo em vez de na apresen.

Imagens, animações & exemplos. Verificar traductabilidade e enviezamento cultural inapropriados.

Se deseja que o seu conteúdo comunique realmente com as pe, necessita falar-lhes na sua língua, não só no texto, mas também através da imagem, cor, objectos e preocupações. É fácil esquecer-se a natureza simbólica específica da cultura, comportamentos, conceitos e linguagem corporal, humor, etc. Deve ouvir as pessoas sobre a adequação e relevâncias das suas imagens, vídeo-clipes e exemplos de utilizadores desses países.

Deve também ter cuidado quando incorpora texto nos gráficos quando o conteúdo é traduzido. Texto em fundos complexos ou em espaços restritor podem provocar problemas consideráveis ao tradutor. Deve oferecer gráficos ao grupo de localização que tenham o texto numa camada separada e deve ter em mente que textos em línguas como o inglês e o chinês irão quase de certeza expandir-se nas traduções.

Formulários. Usar uma codificação apropriada no formulário e no servidor. Suporte os formatos locais para nomes/endereços, datas e horas, etc.

A codificação de caracteres usada na página HTML que contenha um formulário deve conter todos os caracteres necessários à inserção de dados no formulário. Isto é particularmente importante se os utilizadores provavelmente inserirem informação em várias línguas.

Bases de dados e scripts que recebam dados de formulários em páginas em várias línguas têm também de suportar caracteres para todas essas línguas em simultâneo.

A forma mais simples de o tornar possível é usar Unicode tanto para páginas contendo formulários e também para todo o processamento e fundo e para armazenamento. Em tal cenário o utilizador preenche os dados em qualquer língua e script que necessite.

Deve também evitar presumir coisas como nome do utilizador e o endereço que se segue irá seguir as mesmas regras de formato que o seu. Pergunte-se quanto detalhe necessita realmente para qu em campos separados em coisas como os endereços. Tenha em mente que em algumas culturas não há coisas como nomes de ruas, noutras o número da porta segue-se ao nome da rua, algumas pessoas necessitam mais do que uma linha para parte do endereço que precede a localidade ou o nome da cudade, etc. De facto em alguns locais o endereço começa do geral para o mais específico, o que implica uma organização espacial diferente. Tenha muito cuidado sobre presunções nas rotinas de validação sobre códigos postais ou comprimentos de números de telefone. Reconheça que uma legendagem cuidada é necessária para inserção de datas numéricas, pois há convenções diferentes para ordenar dia, mês e ano. Se estiver a recolher informação de pessoas de mais do que um país, é importante desenvolver uma estratégia para tratar os formatos em que as pessoas irão esperar ser capazes de usar. Não só é importante para o design dos formulários que crie, mas também tem um impacto sobre o armazenamento de tal informação nas bases de dados.

Informação adicional

Ler a FAQ "Formulários multilingue" para informação adicional sobre o uso de Unicode em formulários. A FAQ "Formatos de data" também oferece alguns pensamentos úteis sobre representação de datas. Mais material irá ser adicionado com o decorrer do tempo.

Autoria de texto. Usar texto simples e conciso. Não componha frases a partir de fragmentos usando scripting.

Texto simples e conciso é mais fácil de traduzir. É também mais fácil de ler se essa leitura não for a de uma língua-mãe.

Deve ter muito cuidado quando compõe uma mensagem a partir de vários fragmentos ou quando insere texto váriavel numa cadeia de caracteres. Por exemplo, imagine que o seu sítio usa JSP scripting, pode decidir compôr certas mensagens no momento. Pode criar mensagens concatenando fragmentos separados tais como 'Só' ou '[sem tradução] Don't', ' resultados retornados em ', e 'qualquer formato' ou 'HTML'. Porqie a ordem dos textos nas frases noutras línguas pode ser diferente, traduzir isto pode criar grandes dificuldades.

De forma similar, é importante evitar fixar posições de variáveis em textos como "1 página de 10". A síntaxe noutras línguas pode ser completamente diferente de forma a fazerem sentido. Se usar PHP, isto significa formatar o texto como "Page %1\$d of %2\$d.", em vez do mais simples "Page %d of %d.". Este último pode ser impossível de traduzir em algumas línguas.

Informação adicional: Ler "Trabalhar com mensagens compostas" e "Reutilizar cadeias de caracteres em conteúdo gerado por Scripts" para informação adicional sobre boas e más práticas quando se compõem frases a partir de várias cadeias de caracteres.

Navigação. Em cada página incluir claramente visível navegação para páginas ou sítios localizados. Usar a língua de destino.

Onde tenha versões da página ou sítio em línguas diferentes, ou um país ou região diferentes, deve oferecer ao utilizador um modo de ver a versão que preferir. Isto deve estar disponível de qualquer página no seu sítio que tenha uma alternativa. Quando oferecer ligações para páginas noutras línguas, usar o nome da língua de destino na língua e script nativos. Não presuma que o utilizador possa lêr em português. Por exemplo, numa ligação para uma página em francês, 'Francês' deverá ser escrito como 'français'. Isto também se aplica se estiver a conduzir o utilizador para uma página específica de um país ou região, por exemplo 'Alemanha' deve ser 'Deutschland'.

Mais informação: Ler "Usar <select> para ligar a conteúdo localizado" sobre a utilização de <select> para ligar a conteúdo localizado. Artigos adicionais sobre ligações a conteúdo localizado serão disponibilizados no futuro próximo. Idem para navegação.

Texto da direita para a esquerda. Em XHTML, adicionar dir="rtl" ao marcador html. Só reutilizar para mudar a direccionalidade.

Textos em línguas tais como o árabe, hebreu, persa e urdu são lidas da direita para a esquerda. Esta ordem de leitura conduz a uma organização espacial espelhada com texto alinhado à direita e arranjo da página e tabelas. Pode especificar o alinhamento e ordenação do conteúdo da página da direita para a esquerda incluindo dir="rtl" no marcador html.

A direcção especificada no marcador html influencia em cascata todos os elementos na página. Não é necessário repetir o atributo em elementos de nível mais baixo a não ser para mudar explicitamente de fluxo direccional.

Texto embebido, por exemplo texto latino continua a correr da esquerda para a direita dentro do fluxo geral da direita para a esquerda, tal como os números. Se estiver a trabalhar com línguas da direita para a esquerda deve ficar familiarizado com os fundamentos do algoritmo de bidireccionalidade do Unicode. Este algoritmo trata da maior parte do texto bidireccional sem necessidade de intervenção da parte do autor. Há circunstâncias, contudo, onde a marcação e os caracters de controlo Unicode são necessários para assegurar o efeito correcto.

Informação adicional: Ler "Técnicas de Autoria para Internacionalização em XHTML & HTML Internationalization: Tratar de Texto Bidireccional" para informação sobre como trabalhar scripts da direita para a esquerda , e "Criar Páginas Bidi XHTML/HTML" para uma introdução suave aos fundamentos de tratamento, em linha, de texto bidireccional.
Experiente ?: Cf. índice cruzado para informação adicional.

Verifique o seu trabalho. Valide-o! Use técnicas, guias e artigos em http://www.w3.org/International/Conjuntos de Caracteres & codificações em XHTML, HTML e CSS

Outros materiais introdutórios

Publicamos recentemente uma página sobre como Começar para o ajudar a encontrar informação no sítio. Esta página inicial aponta para uma série de artifos que estão a progredir e oferece aos iniciados uma introdução agradável para tópicos chave sobre internacionalização e aponta para informação básica sobre o sítio para poder continuar.

11 fevereiro, 2007

09 fevereiro, 2007

CSS Fácil de Manter

08 fevereiro, 2007

29 janeiro, 2007

26 janeiro, 2007

15 janeiro, 2007

Tipos MIME

Análise

Análise

Sintaxe

Marcação

Codificação de Caracteres

Scripts/Guiões

Folhas de estilo

Diferenças entre HTML 4.01 e HTML 5

Tipo MIME

Interpretação de HTML

Sintaxe

Marcação

Atributos Obsoletos

Elementos Obsoletos

Codificação de Caracteres

Diferenças entre DOM Level 2.0, 3.0 e HTML 5 DOM APIs

10 janeiro, 2007

02 janeiro, 2007

Mais exigente com a linguagem

Mais exigente com os marcadores

Mais exigente com o conteúdo

21 dezembro, 2006

20 dezembro, 2006

19 dezembro, 2006

Tabela de conteúdos

WaSP: Lutar pelos Standards

O Problema

Dilemas e Custos

Nascido da Necessidade

Os Desafios Futuros

18 dezembro, 2006

15 dezembro, 2006

14 dezembro, 2006

O que é que se encontra nas ATAG 1.0

Versões ATAG: 1.0 e 2.0

12 dezembro, 2006

11 dezembro, 2006

Exprimir intenção

Objectos Mock

10 dezembro, 2006

09 dezembro, 2006

08 dezembro, 2006

05 dezembro, 2006

23 novembro, 2006

22 novembro, 2006

21 novembro, 2006

17 novembro, 2006

Informação Adicional

Heron

Entradas mais lidas

Arquivo do blogue

Subscrever

Leituras

Ligações

Acerca de mim

FEEDJIT Live Traffic Feed