Carta aberta ao governo sueco sobre ensino de desenvolvimento para a web

Desenvolvimento Web 2006

Sumário

A educação em ”Media Interactivos”, ”Programação Internet” e ”Tecnologia da Informação” têm que dar aos estudantes a capacidade de desenvolverem para a web actualmente e no futuro. Há um risco de a educação continuar a ensinar, tal como o faz em grande parte hoje, métodos desactualizados e tecnicamente inferiores.

O progresso na web não parou e estamos a observar dois desenvolvimentos importantes:

1.A camada de apresentação está a mudar para uma baseada sobre standards, semântica e separação de conteúdo, de design e comportamento. Isto oferece uma possibilidade à acessibilidade, de forma a nenhum utilizador ser excluído, independentemente do seu sistema operativo, navegador ou tipo de hardware, ou se o utilizador tiver qualquer tipo de deficiência funcional. Quando este passo for dado é possível continuar e criar interfaces de utilizador ricas.

2.A dinâmica dos sítios está a mudar. A partir de como se fossem ilhas isoladas, com pontes entre elas, até fazerem trocas de dados directamente entre servidores e uma nova dimensão para interacção social para utilizadores.

O ensino secundário (similar à senior high school) não será capaz de tornar os seus estudantes em responsáveis pelo desenvolvimento da web completamente capazes, com uma compreensão olística dos padrões e princípios de acessibilidade e serem capazes de programar os servidores para trabalharem com as novas formas de troca de dados. Mas é da maior importância que a educação ofereça uma fundação, sobre a qual os estudantes não necessitem de ser destreinados e necessitem de se reeducar a sim mesmos, por lhes terem sido ensinados os métodos errados. A escola deve ser uma rampa de lançamento para as autoestradas do futuro, não um beco sem saída para o passado.

Não dizemos que os standards e a acessibilidade é a única coisa que necessitam saber, quando constroem um sítio moderno, mas dizemos que não há outra opção válida para construir sítios web, quando falamos destes aspectos. Não deve colocar-se a questão entre escolher design ou standards, sobre efeito curiosos ou acessibilidade. Usar a metodologia que sugerimos estas questões não se irão tornar umas a oposição das outras.

Esta carta descreve a opinião da «The Web Standards Project Educational Task Force» e um grupo de responsáveis suecos pelo desenvolvimento da web que desejam ver uma web não discriminatória e acessível.

CONTEÚDOS

Desenvolvimento Web 2006.

Sumário

Introdução

”Web 2.0”

Web 1.0 – a web como parque fechado

Web 1.5 – Sistemas de Gestão de Conteúdos(Content Management Systems)

Web 2.0 – a web como selva

Troca de informação “por baixo da superfície”

Os utilizadores são jardineiros

Mashups

Standards: Fim da LEI da selva

Standards, desenvolvimento não específico de um navegador

Separação de conteúdo, design e comportamento

Código semântico

AJAX e interfaces de utilizador ricos

A web em 24 horas

Lista de consequências

Assinada por:

Introdução

Chegou o momento de explicar e implementar as visões dos curricula, mas antes de passarmos a uma descrição detalhada do que é que a escola deve ensinar, necessitamos de ter um conhecimento acerca dos actuais desenvolvimentos e do futuro. Este documento irá tentar oferecer um inquérito sobre algumas das principais tendências que envolvem o desenvolvimento web na actualidade.

Não dizemos que o ensino secundário (senior high school) deva ensinar todas as tecnologias que serão mencionadas nesta carta. Algumas delas são demasiado avançadas para este nível de ensino. Queremos contudo dizer, que os fundamentos devem ser ensinados, de tal modo a serem realmente uma fundação adequada para os níveis seguintes.

Um certo número de pessoas será mencionado neste documento com o seu nome. São nomeados como sendo peritos e exemplos. Um bom desenvolvimento web é feito com o espírito que estas pessoas representam. Isto não implica que cada uma das pessoas mencionadas seja infalível ou mesmo a “melhor” no seu campo. Foram aqui nomeadas porque são relativamente bem conhecidas e de certo modo tornaram-se a face humana de certas ideias.

”Web 2.0”

Poderia pensar-se que surgiu uma nova tecnologia com todo o bruaá sobre a “Web 2.0” durante 2005. A verdade é que não houve nenhuma alteração drástica de tecnologia quando se observa o conteúdo e as especificações da tecnologia. Continuamos a utilizar o HTML 4, que foi definido em 1997-1999, ou o XHTML 1.0, definido em 2000. Acrescentámos o CSS 2.1, que é um subconjunto do CSS 2.0>, i.e. uma simplificação, e as CSS 2.0 já estavam definidas em 1998. O terceiro componente fundacional numa página web é a JavaScript. A última parte da JavaScript, que recentemente atraiu atenção (XMLHttpRequest) foi desenvolvida pela Microsoft em 1998 e as especificações DOM 1.0 já foram também definidas em 1998.

Contudo a web de 2006 é radicalmente diferente da de 2000. Um novo modo de usar estas técnicas viu a luz do dia e a diferença é enorme. Quem não tenha seguido o desenvolvimento foi deixado para trás. É da maior importância que o ensino reflicta esta alteração de paradigma e não ensine métodos obsoletos.

As alterações não são só técnicas, mas envolvem a web como um todo e como é que interagimos com ela como utilizadores.

Web 1.0 – a web como parque fechado

[[A ligação só se encontra na camada de apresentação. Poucas entradas, talvez só uma entrada.]]

[[O jardineiro – o webmaster. Três papeis principais: Técnico, design, conteúdo e Especialização. DMOZ é um exemplo de um pequeno número de voluntários que oferecem conteúdo, mas em que o utilizador regular só vê (a ser comparado com del.icio.us). Mesmo as comunidades operam dentro de “uma cerca”.]]

Web 1.5 – Sistemas de Gestão de Conteúdos/Content Management Systems

[[Os fornecedores de conteúdos necessitam de ferramentas para sítios grandes sítios orientados por bases de dados. Desde os finais dos anos 90 os sítios estáticos estão mais ou menos mortos. Há um CMS por detrás dos principais sítios web. As organizações pagam por um CMS.]]

[[Mesmo os novatos necessitam de conhecer que não falta muito até que a página estática seja incorporada num CMS. Os designers desenvolvem modelos, não páginas. O designer puro não toca sequer em código, mas desenha no papel ou no photoshop e deixa alguém implementar o design.]]

[[A metáfora do jardim fechado ainda se mantém. Comunidades isoladas na web.]]

[[Os CMSs causam um problema importante, pois produzem frequentemente marcação não standard, inválida e não semântica. Tais CMSs não devem ser colocados em primeiro lugar como algo que os estudantes devam simular.]]

Web 2.0 – a web como selva

[[Qualquer página é uma página de entrada. Não há só uma porta de entrada no jardim. Mas a grande revolução é que as ligações nos sítios se encontram na camada da lógica de negócio. As raízes e ramos são misturados livremente com aquelas que pertencem a outras plantas.]]

Troca de informação “por baixo da superfície”

[[Onde começa uma liana na floresta é pouco importante normalmente. Crescem entre várias árvores. Os sítios da web da actualidade podem mostrar informação que é guardada noutro local. Assinatura, agregação, serviços web, blog ping, etc levam a que os sítios estejam ligados de outro modo. Estes sítios não só se ligam a outros, mas partilham informação uns com os outros.]]

Os utilizadores são jardineiros

[[Os utilizadores estão a tornar-se na principal fonte de informação. A Amazon.com lidera ao deixar aos leitores a oferta de críticas, pistas e listas de desejos e padrões de utilização (”Clientes que compraram este livro também compraram…”).]]

[Há uma maior dinâmica ao ter um  blogue do que ser membro de uma comunidade. A palavra “blogosfera” poderá nem sempre transmitir as conotações correctas mas é uma tentativa de atribuição de um nome a esta nova dinâmica. A web como comunidade.]]

[[Wikipedia é outro exemplo.]]

[[Novas regras – a ”long tail”. Mais poderes aos utilizadores. Novos padrões económicos.]]

Mashups

[[Nem todas as plantas na selva têm raízes no chão. Uma planta pode crescer a partir de outra. Um “mashup (sítio ou aplicação web que combina informação de mais do que uma origem)” é um sítio que usa uma API de outro sítio, com o seu consentimento, para fornecer um serviço em cima do outro. Isto encoraja sítios como Google, Amazon, Yahoo, etc.]]

Standards: Fim da LEI da selva

O novo tipo de troca de informação, mashups, etc. é o resultado do facto de num outro sentido a web se ter tornado menos selva. O intercâmbio exige standards cuidadosamente definidos. Mesmo as grandes organizações têm que seguir cuidadosamente os standards existentes e a maior parte das tentativas de utilização de técnicas proprietárias é punido pelas pessoas com verdadeiro poder - o colectivo dos responsáveis pelo desenvolvimento da web.

No ano de 2003 Jeffrey Zeldman publicou o livro ”Designing with Web Standards” e no mesmo ano Dave Shea lançou o sítio CSS Zen Garden e desde essa altura os responsáveis pelo desenvolvimento da web competentes ficaram conscientes que os sítios web  modernos são desenvolvidos de acordo com uma filosofia clara, que ao lado dos standards também incluem separação de design, conteúdos, comportamento e código semântico.

O inventor da web, Timothy Berners-Lee, é claro a pessoa mais importante em todo este progresso. O modo como ele previa a web originalmente significava o que estamos a ver agora é o retorno ao que ele achava que devia ser, antes de ter em grande medida sido destruída por pessoas bloqueadas na perspectiva da edição de secretária.

Standards, desenvolvimento não específico de um navegador

No final dos anos 90 sucedeu aquilo que foi designado por “guerra dos navegadores”. A Netscape e a Microsoft guerrearam-se pelos responsáveis de desenvolvimento criando tecnologias proprietárias e esperando que as páginas de entrada não trabalhassem com os navegadores concorrentes. “Este site está optimizado para” e instruções similares eram frequentes. A Microsoft ganhou a guerra dos navegadores, oferecendo um melhor suporte que o da Netscape aos standards definidos pelo World Wide Web Consortium (W3C) para HTML, XHTML, CSS e DOM.

Quando a Netscape lançou o Mozilla Project e os responsáveis pelo desenvolvimento se tornaram poder em vez das pessoas do marketing, foi tomada uma decisão inicial sobre parar o suporte a tecnologias proprietárias da Netscape e em seu lugar seguir meticulosamente os standards da web.

O resultado é que todos os navegadores modernos (gen 6+) seguem pelo menos de forma decente os standards. Houve pouco desenvolvimento no Internet Explorer desde 2001, mas no momento a melhoria do suporte dos stantards está a ocorrer e é um dos temas chave. A versão Internet Explorer 6 é suficientemente boa para nos capacitar ao desenvolvimento baseado nos standards.

O tempo em que se desenvolvia para determinado navegador, ou a dificuldade de desenvolvimento para um certo número de navegadores passou. Algumas companhias suecas de desenvolvimento ainda não compreenderam que estão em risco de serem deixadas para trás à medida que cada vez mais clientes perceberem que podem ter melhores sítios web por menos dinheiro com este novo modo de fazer sítios web.

Separação de conteúdo, design e comportamento

O desenvolvimento baseado nos standards frequentemente é acompanhado da consciência de que as páginas de entrada de ontem eram feitas com mau código. Normalmente designado por “sopa de marcação”. HTML ou XHTML não devem ser de todo usadas para controlar o aspecto visual de uma página. Os marcadores ou atributos que só servem uma finalidade visual, designados por “marcação física” (um termo normalmente usado na Suécia) não devem ser usados de todo. Estes marcadores e atributos incluem < font> , < center> , bgcolor, align, etc.

separaçãoentre conteúdo, descrito por (X)HTML e design, controlado por CSS, é o primeiro passo. Ganha-se as seguintes vantagens:

• Desenvolvimento mais rápido.
• Redesigns extremamente mais rápidos.
• Mais possibilidades de arranjo.
• Fácil adaptação a plataformas de media alternativas (TV, telemóveis, impressão, Braille, síntese de voz, etc.)
• Melhor classificação nos motores de busca, em especial quando combinada com codificação semântica (ver abaixo).
• Quantidade de dados reduzida necessária ao envio de página devido à tamponização dos ficheiros externos com CSS e JavaScript efectuada pelos navegadores visitantes.

Na página podem figurar coisas como menus descendentes, controles com valores num formulário, etc. A estes chamamos comportamento. JavaScript, pelo que de facto é uma combinação de ECMAScript e DOM 18, é o meio pelo qual se deve controlar tal comportamento em primeiro lugar. Esta foi também uma área abusada. O JavaScript foi usado para entregar conteúdo e controlar design, sem nenhuma segurança, em especial ao usar JavaScript para adaptar páginas aos diferentes navegadores. O código descuidado ainda ficou mais descuidado! O JavaScript é talvez a tecnologia mais abusada e mais mal compreendida de todas na web.

O ano de 2005 significou uma alteração drástica contudo. Livros como ”DHTML Utopia” 20 e ”DOM Scripting” 21 significaram uma alteração do paradigma e um número elevado de responsáveis de desenvolvimento começaram a usar esta tecnologia de modo correcto.

Código semântico

Durante a era da sopa de marcadores, houve também frequente abuso de marcadores HTML-tags. O marcador < p> , que deve ser usado para denotar um parágrafo foi usado para arranjar espaço. O marcador < blockquote> , que deve denotar uma citação extensa, foi usado para gerir recortes. E a tecnologia mais abusada de todas, as tabelas, foram usadas com finalidade de gerir arranjos e não para dados tabulares. Quase todos os livros ou páginas Web suecas que ensinavam web design ensinavam estes métodos abusivos.

O sítio Webdesignskolan (“Web Design School”) reclam a ser visitado por milhares de estudantes do ensino secundário todos os anos. Chegou à conclusão de que ensinava métodos desactualizados e colocou um aviso pequeno no seu próprio material!

Ao só usar marcadores com significado semântico e usando-os de forma correcta, são ganhas algumas vantagens. O código torna-se mais compreensível, e portanto mais fácil de desenvolver e alterar. As páginas poderão interagir mais. A sua acessibilidade aumenta drasticamente. Páginas codificadas de forma semântica podem ser compreendidas pelas pessoas que escutam os sintetizadores de voz ou que leiam em terminais Braille. É mais fácil fazer adaptações para pessoas com outras formas de deficiência. O robot de pesquisa do Google, assim como a maior parte dos motores de busca, é um utilizador “cego”significando que uma página semanticamente codificada será indexada correctamente e provavelmente classificada mais alto se o seu código for semântico.

A semântica cria novas possibilidades. Responsáveis visionários de desenvolvimento começaram a usar microformats. Concebidos sobre o surgimento dos standards e código semântico. Isto é há padrões para usar dados de calendário (hCalendar) e informação de contacto pessoal (hCard). Outra área a aparecer é a dos “padrões web”, tornando possível reutilizar as melhores soluções para criar a estrutura de páginas web.

Os responsáveis pelo desenvolvimento que continuarem a usar marcação não semântica serão ultrapassados e deixados para trás!

AJAX e interfaces de utilizador ricos

Em Fevereiro de 2005 Jesse James Garret cunhou o termo AJAX, ao tentar explicar a nova implementação de JavaScript em sítios como Google Suggest, Google Maps, Flickr31 e Basecamphq. O termo ganhou popularidade de tal modo que algumas pessoas julgam tratar-se de um sinónimo de “web 2.0”. Não é o caso, mas o AJAX é uma peça importante na nova era.

AJAX é de facto um termo de marketing (tal como o DHTML), e não uma tecnologia. AJAX é o desenvolvimento de um novo tipo de interface do utilizador usando tecnologias existentes. A web está a ser transformada num Run Time Environment (ambiente de execução/sistema operativo). O entusiasmo é em parte perigoso. A era DHTML dos anos 90 era um passo além da visão da web. Soluções para só alguns navegadores que eram inacessíveis para utilizadores com deficiências de visão, audição, movimento ou cognitivas, estão em risco de reaparecer em aplicações AJAX desenvolvidas por pessoas cujas mentes não foram “purgadas” dos pecados da era DHTML.

Um grupo de responsáveis pelo desenvolvimento estão nas barricadas {{esta frase faz sentido em português?}}, tentando promover uma atitude responsável a este novo método. É importante que a sua filosofia ganhe, para não voltamos a cair no pesadelo das soluções proprietárias e inacessíveis que pelo menos estamos a começar a emergir.

Contudo, há algumas aplicações para o ambiente web, que pela riqueza das suas interfaces substituem aplicações de secretária existentes. A programação nos anos 80 significava que se programava para o hardware, nos anos 90 houve uma mudança de codificação para APIs do sistema operativo. No futuro próximo poderemos ver  “programas” de secretária de hoje serem substituídos ou pelo menos complementados por sítios web que deixamos de poder descrever como “páginas” mas como aplicações completas.

A web em 24 horas

O governo sueco cunhou a expressão “a web em 24 horas”. “O guia para a web em 24 horas” contém os princípios orientadores de todos os sítios públicos na Suécia, e estão lentamente a ter um efeito. Um blogue muito bom (em sueco) segue este desenvolvimento “The 24-hour blog”.

Estes princípios orientadores estão de acordo com o que figura neste documento. Como consequência da sua adopção os responsáveis pelo desenvolvimento que não aderirem a estes princípios não vão obter novos contratos (tal como deve ser!). Em Dezembro de 2005 o governo sueco anunciou legislação que irá surgir em breve que exigirá um mínimo de acessibilidade nos sítios web públicos suecos.

Isto deve implicar consequências, também no ensino de tecnologias relativas à web no ensino secundário.

Lista de consequências

Qual o melhor modo de fazer algo, i.e. “melhores práticas”? O que deve ser evitado?

”Campeões da causa”: Jeffrey Zeldman, Dan Cederholm e The Web standards Project.

Melhor material disponível em sueco: Desenvolvimento com Web Standards por Roger Johansson.

“Pioneiro”: Jeffrey Zeldman.

Imagem útil: “O banco de três pernas.”

“Pioneiro”: Eric Meyer.

Standards relevantes: CSS 2.1 e CSS 3.

Melhor material em sueco: ”Aprenda você mesmo CSS” por Russ Weakley.

“Pioneiro”: Tantek Çelik.

Standards relevantes: HTML 4.01, XHTML 1.0, XHTML 1.1, XHTML 2.0 (em desenvolvimento) e HTML 5 (cooperação entre Mozilla, Opera, etc.)

Não há material adequado em sueco!

“Pioneiro”: Joe Clark.

Standards relevantes: WAI e WCAG. WCAG 2.0 deve ser considerado para Gy -07.

Melhor material em sueco: ”Tillgängliga webbplatser i praktiken” (Sítios web acessíveis na vida real).

(Controverso) “Pioneiro” Jacob Nielsen.

Melhor material em sueco: ”Användbarhetsboken” (O Livro da Usabilidade) por Tommy Sundström.

“Pioneiros”: Jeremy Keith, Simon Willison, Peter-Paul Koch (PPK), Scott Andrew LePera, James Edwards (“Brothercake”)

Palavras chave:

• W3C DOM
• ECMAScript
• ”Não obstrutivo” (Separação de comportamento do Conteúdo e do Design)
• ”Degradação aceitável” (Tolerância a falhas, acessibilidade)
• ”Melhoria progressiva”
• ”Detecção de objecto” (não “detecção de navegador”)

Não há bom material em sueco. Os livros seguintes em inglês são normativos:

• JavaScript: The Definitive Guide por David Flanagan.
• DOM Scripting por Jeremy Keith.
• The JavaScript Anthology por James Edwards and Cameron Adams.

Assinada por:

The Web Standards Project Educational Task Force, através de Lars Gunther. (Lars Gunther é professor na Nils Ericsonsgymnasiet em Trollhättan, Suécia, e tem uma pequena companhia chamada Keryx.)

The Web Standards Project nasceu com Jeffrey Zeldman e outros e é liderado por Molly Holzschlag, autora de vários livros sobre HTML e CSS.

WASP-EduTT é liderado por April Siegfried que ensina desenvolvimento web baseado em standards na DePaul University, Chicago.

Tommy Olsson bloga sobre web standards e accessibility no actualmente dormente autisticcuckoo.net e é um guro de (X)HTML activo nos foruns SitePoint.

Roger Johansson possui o blogue internacionalmente famoso 456bereastreet.com , sobre desenvolvimento web com enfâse em standards, acessibilidade e usabilidade.

Robert Nyman trabalha como web developer há já alguns anos e escreve regularmente sobre o assunto em robertnyman.com . Além disso organiza reuniões entre responsáveis de desenvolvimento para web para partilha de conhecimentos e melhoria da compreenção.

Peter Krantz bloga em standards-schmandards.com e é um dos responsáveis pelo desenvolvimento do simulador de síntese de voz Fangs.

Martin Janner tem trabalhado com desenvolvimento baseado em standards entre outros na  Eniro e tem o blogue em http://stilmall.se

Björn Hagström é uma das forças nos bastidores do 24timmarsbloggen.se e é responsável pelos sítios da web da cidade de Örebro.

Usar update_page em link_to_function

Introdução

Bruce Williams diz que vive numa terra de modelos e ajudantes de Rails. Para nos dar uma ideia de que está a falar a sério diz-nos o seguinte. Que a sua actual aplicação tem serca de 670 ficheiros de modelos separados (com cerca de 8500 linhas) e 75 ajudantes (com cerca de 2350 linhas) e que continua a crescer.

O que é que isto significa - para além do facto de o TextMate ser o nosso melhor amigo? Significa que se há alguma coisa que ele saiba sobre Rails é como gerir um grande volume de modelos e de código relacionado com vistas e construção de infraestruturas para ajudar a SECAR (DRY - não te repitas) o caos.

Ele diz-nos que irá tentar ajudar outros programadores, responsáveis pelo desenvolvimento de sítios na web que estejam no mesmo barco escrevendo uma série de artigos debaixo do título genérico Rails Views. Estes artigos irão realçar técnicas usadas por si no dia-a-dia. Poderá ser que as achemos úteis, e acrescenta que podem não ser a única forma de obter o mesmo resultado mas que é o processo por si usado.

Diz-nos ainda que esta série de artigos Rails Views partem do princípio que o leitor sabe Ruby bem, e dessa forma ele não irá tratar de se focar na explicação dos detalhes pois espera que um programador decente em Ruby os possa perceber. Irá partir do princípio que o leitor usa Edge Rails.

Utilização de update_page na link_to_function

Uma das técnicas que menos vejo usada nas aplicações em Rails e uma das que acho não só elegante mas que poupa tempo é o uso de update_page directamente na link_to_function .

Porque é que não há mais gente a usar esta técnica? Não percebo. Muito do trabalho foi para RJS... e assim porque não usá-lo?

Eis um exemplo rápido, de duas formas. Tornemos todos os parágrafos de texto, verdes, na página usando a classe CSS irish , só porque sim - finja que é dia de S. Patrício por uns instantes. De facto enfiemos rapidamente um anúncio de "Dia de São Patrício" também.

Em primeiro lugar a versão tradicional (mesmo que melhorada com o prototype) link_to_function .

link_to_function("Toca-me!", "$('p').each( function(tag) {tag.addClassName('irish');} ); new Effect.SlideDown('banner',{duration:0.4});" ) e, com update_page : link_to_function("Toca-me!", update_page{|page| page.select('p').each{|p| p.addClassName('irish')} page[:banner].visual_effect :slide_down, :duration =&gt; 0.4})

São aproximadamente do mesmo tamanho... qual é a espiga?

• A Ruby é mais poderosa e mais fácil de ler do que JavaScript tenha em mente que este é um exemplo muito simples
• Uma vez tendo começado a interpolar dinamicamente ids de diferentes elementos, numa string em javascript (claro está usando escape_javascript ), a versão sem update_page torna-se mais difícil de fazer e de manter (deixe só passar o almoço e volte ao seu código e veja)
• É mais fácil expandir esta técnica usando outros ajudantes e infraestruturas (passando page para adicionar código comum por exemplo) e depois passar strings para serem concatenadas - correndo o risco de um erro sintático no javascript neste processo (alguém poderá dizer "falta de ponto-e-vírgula?").

Este técnica é pequena e simplesmente a minha preferida.

Entender o que são e para que servem os símbolos da Ruby

Quando uma pessoa está a aprender a utilizar uma infraestrutura como a Ruby On Rails e por essa razão tem que aprender Ruby é importante Entender a utilização dos símbolos na Ruby visto serem algo inerente à própria linguagem de programação.

Levels of Accessibility Knowledge – Le «blog personnel» de Joe Clark

Que o Joe Clark não gosta da nova proposta de directrizes WCAG 2.0 já todos o sabíamos mas que achava que os «especialistas» do grupo de trabalho estm no nível 2 é mauzinho.

Níveis de conhecimento

Nas últimas semanas têm aparecido uma série de especialistas das várias disciplinhas da web que criam escalas sobre os conhecimentos devidos para execução de uma tarefa na web.

Emil Stenström apresenta os 7 níveis de conhecimento sobre CSS, Roger Johansson apresenta os 7 níveis de conhecimento em HTML , Dean Edwards documenta seis níveis de conhecimentos em JavaScript e por fim (pelo menos por agora) Joe Clark apresenta os oito Níveis de conhecimento em Acessibilidade .

Um Guia de Introdução à Ruby - de Eustáquio Rangel

O Eustáquio Rangel acaba de actualizar (com correções) o seu Tutorial de Ruby. Este guia encontra-se escrito em português do Brazil pelo que é necessário algum cuidado na sua interpretação. O tutorial do toq (Eustáquio Rangel) é um ficheiro em formato PDF

A List Apart 217

O «A List Apart» publicou o número 217 com artigos de Joe Clark a querer mandar passear (eufemismo da minha parte) as WCAG 2. A Molly E. Holzschlag escreve sobre Normas Abertas para uma Web Global tocando as problemáticas da internacionalização e da localização. O texto repescado é de Mark Bernstein 10 Pistas sobre escrita na Web dinâmica

Padrões Web

Não não estou a falar de web standards mas de web pattern. Este último sitio inclui uma lista de tipos de sítios (em termos de interacção, conteúdo e finalidade do sítio com definição do caso e como é resolvido). Material a ler por quem está a começar a criar sítios profissionalmente.

Leituras

Um problema pessoal leva-me a estar muitas horas sem aceder ao meu PC. No entanto tenho tido tempo para por em dia algumas leituras. Eis algumas dessas:

• Refactoring Databases: Evolutionary Database Design, de Ambler e Sadalage
• Version Control with Subversion, de Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato
• Subversion Version Control: Using The Subversion Version Control System in Development Projects, de William Nagel
• Ruby for Rails - Ruby Techniques for Rails Developers, David Black

Eu que vinha de uma escola de pensamento que quase impede (ainda) a evolução das bases de dados (em DB2 e COBOL tal exige novas ligações entre código e novos esquemas de bases de dados) quase sofri um choque com a leitura do primeiro destes livros. Os livros sobre utilização de Subversion têm o defeito de salvo as ideias gerais e as de utilização mais frequente não poderem acompanhar a alteração rápida (evolução) do programa. O último relativo ao conhecimento de Ruby para um bom desenvolvimento com Rails parece-me essencial para quem queira fazer mais do que copiar e adoptar código de terceiros no desenvolvimento das respectivas aplicações. Bastante interessante.

Uma razão para ler com atenção as listas de correio dos temas que nos interessam

Parece-me que não consigo arranjar um título mais comprido, mas de cada vez que abro o TB e vejo o meu correio e encontro nele referências a sítios como este acho que o tempo consumido a lêr é muito bem gasto.

:uniq

Acabei de ler um excelente artigo de Josh Susser sobre a utilização da opção em relações do tipo contem vários através de ....

Scriptacolous

A Amy Hoy voltou a fazê-lo novamente. Agora podemos ter um resumo da utilização da biblioteca de javascript scriptacolous numa única página. Perfeito.

CMS e Web Standards

No manifesto da Wasp diz-se algo como:

Todos os Sistemas de Gestão de Conteúdos (CMS ) devem produzir código semântico, acessível, válido e enxuto logo que se instale.

Infelizmente continuo a ver muitos sítios novos que acabam por usar CMS tecnologicamente ultrapassados. Os sítios em si têm bom aspecto mas as engrenagens por detrás dão-lhe um ar desmaselado como por exemplo no novo sítio da Igreja dos Pastorinhos.

Canada on Rails

Para quem queira ler umas notas sobre a conferênciaCanada on Rails pode lê-las no blog do Ryan Davis.

Podcast sobre microformatos

Um podcast para quem queira ouvir falar de microformatos no blog de Alex Barnett. Neste mesmo blog poderá encontrar mais alguns podcast sobre temas como OMPL, agregadores e leitores de RSS.

Validação não pode ser a única forma de boas práticas

Roger Johansson aponta uma confusão nalgumas cabeças que acham que basta que o HTML de um sítio seja válido para terem um sítio que usa boas práticas. Deve acrescentar que até agora só encontrei um sítio de organismo público que validasse e mesmo esse coitado não praticava boas práticas. (Validar é só um passinho...)

Design Meltdown

Este é um daqueles sítios que quem quer aprender a desenvolver sítios web (e eu quero) deve consultar: Design Meltdown.
A sua tabela de conteúdos começa com a utilização de cores e depois passa para os elementos e técnicas de design, passa para os problemas e soluções e finaliza com tutoriais.

A boca fica a salivar!

Um blog sobre design, usabilidade e novidades

Um blog português sobre design, ergonomia e com um pouco de humor. A visitar em especial pelas recensões de livros fica em Design Ergonomia

Como Depurar Vistas - RoR

Ferramentas de depuração

A Rails trás um ajudante de depuração que pode usar nas vistas:

<%= debug @user %>

Isto irá produzir uma saída como esta:

--- !ruby/object:User
attributes: 
  name: Jane Loe 
  username: janeloe
  id: "1" 
  password: fc46324eea5eede31c00b9026e5037e162dccda8

Adicionar aos ajudantes

O artigo Rails Plugin para ajudar a depurar vistas descreve um plugin que torna mais fácil abrir uma janela popup similar às Smartys escarrapachando todas as atribuições, sessões, parâmetros e variáveis flash. O plugin deriva de código disponível nas Snippets. Isto é especialmente útil quando se trabalha em conjunto com designers que não têm a mínima ideia do género de informação exportada pelos controladores numa dada vista.

Edições Sempre em Pé

As edições Sempre em Pé têm um síte limpo. Salvo alguns pequenos lapsos pouco haverá a alterar para melhorar. Este é um site que não sendo à partida feito para pessoas com dificuldades de leitura, permite que se amplie os respectivos tipos sem perca da informação gráfica existente.

Em relação à conformidade com padrões poderá efectuar-se uma melhoria de forma a que o site cumpra com o que indica.

Testar Migrações (RoR)

Qual a forma correcta de testar migrações?

Usar:

rake migrate RAILS_ENV=test

e chega

Desenvolver sítios para utilizadores com deficiências cognitivas e dificuldades de aprendizagem

Sumário

Quando se pensa em acessibilidade do conteúdo na web há uma tendência para nos concentrarmos nas pessoas com incapacidades visuais. As pessoas com incapacidades cognitivas e com dificuldades de aprendizagem são frequentemente esquecidas.

O artigo original é do: Juicy Studio, Developing sites for users with Cognitive disabilities and learning difficulties, Este artigo escrito por Roger Hudson, Russ Weakley, e Peter Firminger, examina os tipos de problemas que os visitantes podem encontrar quando usam a web com sugestões profundas e práticas sobre como desenvolver sítios web que incluam as pessoas com incapacidades cognitivas ou com dificuldades de aprendizagem.

Autor: Russ Weakley

Conteúdos

• Traduções
• Introdução
• 1. Trabalhar com conteúdo
• 2. Esconder e mostrar conteúdo
• 3. CSS para ajudar na "clicabilidade" e na legibilidade
• 4. Controlo de utilizador do conteúdo e apresentação
• Conclusão
• Leituras adicionais

Por Roger Hudson, Russ Weakley, e Peter Firminger

Traduções

Tradução russa

A tradução russa deste artigo é atenciosamente fornecida por Vlad Brown

Tradução sueca

A tradução sueca deste artigo é atenciosamente fornecida por Johan Sundstrom.

Tradução italiana

A tradução italiana deste artigo é atenciosamente fornecida por Livio Mondini.

Tradução filandesa

A tradução filandesa deste artigo é atenciosamente fornecida por Saavutettava.fi.

[De volta à tabela de conteúdos]

Introdução

O grupo de dificientes maior na nossa comunidade é o das pessoas com dificiências cognitivas e com dificuldades de aprendizagem, contudo é um grupo frequentemente esquecido em relação à acessibilidade de um sítio web.

As etiquetas de incapacidade cognitiva e dificuldades de aprendizagem, parece englobar um amplo espectro de condições que os responsáveis pelo desenvolvimento da web acham frequentemente difíceis de indentificar ou de tratar as necessidades especificas dos indivíduos ou grupos que normalmente descrevem.

Muitas dificiências distintas podem afectar a capacidade de uma pessoa em aceder a um sítio web e usar a informação nele contida, por exemplo:

• Dificiência cognitiva, que inclui memória, percepção, resolução de problemas conceptualização e dificiência de atenção. Isto pode resultar de um espectro de condições tais como atraso mental, autismo, danos cerebrais, parkinsonismo, doença de Alzheimer e senilidade.
• Dificuldades de aprendizagem pode também afectar uma variedade de memória, percepção, resolução de problemas e capacidades de conceptualização. As dificuldades de aprendizagem incluem problemas de leitura como a dislexia, cálculo, deficiências de raciocinio e organização e dificuldades não verbais de aprendizagem. Estas são, por vezes, também associadas à hiperactividade e à dificiência de Atenção.

Para o responsável pelo desenvolvimento da web a situação pode apresentar-se mais complexa pelo facto de que os utilizadores individuais com estas condições podem ter necessidades muito diversas. É comum para indivíduos com problemas cognitivos numa área serem extraordinariamente habilitados noutras áreas. Por exemplo uma pessoa que é um excelente leitor pode ter consideráveis problemas em compreender como é que uma página web é organizada ou ser facilmente distraído por uma pequena imagem animada.

Pode a web tratar das necessidades de todos estes diferentes grupos. Provavelmente sim, mas com sítios web diferentes.

A web pode trazer prazer considerável e ajudar pessoas com diferentes e em alguns casos muito profundas incapacidades cognitivas. O projecto Peepo (já fechado) dava um largo espectro de recursos e ideias para capacitar as pessoas com sérias dificuldades de aprendizagem a navegar e usar a web com independência.

O foco deste artigo é em primeiro lugar sobre como melhorar a web para pessoas que têm capacidade funcional para acederem independentemente e usarem sítios que contenham algum conteúdo textual. Em particular, o artigo sugerem alguns métodos simples que podem melhorar a acessibilidade dos sítios a pessoas que acham difícil ler e usar conteúdo escrito.

Para uma versão mais detalhada deste artigo vá para Uma Fronteira da Acessibilidade: dificiências cognitivas e dificuldades de aprendizagem

[De volta à Tabela de conteúdos]

1. Trabalhar com conteúdo

1.1 Conteúdo claro e simples

O conteúdo que é bem escrito será fácil para todos acederem incluindo pessoas com dificuldades de aprendizagem ou cognitivas.

• Assegure-se que a informação está bem organizada.
• Mantenha o conteúdo curto e simples.
• Reparta a informação em pequenas porções, com uma ideia chave por parágrafo.
• Apresente pontos relacionados numa lista em vez de num parágrafo muito extenso.
• Utilize cabeçalhos com significado.
• Verifique que não há erros ortográficos ou gramaticais.
• Explique ou defina os termos técnicos, as abreviaturas e as siglas.

1.2 Comprimento óptimo da linha

A maior parte dos utilizadores da web acham que as linhas muito extensas são difíceis de ler. Para pessoas com problemas de leitura as linhas extensas podem tornar-se numa barreira significativa. À medida que a resolução do ecrã vai aumentando, é possível obter mais e mais caracteres numa linha num determinado tamanho do tipo de letra, contudo o tamanho de tipo de letra óptimo para leitura fácil varia de leitor para leitor. Como resultado é difícil ser definitivo sobre qual será o melhor comprimento de linha, mas como regra geral uma linha não deve exceder os 70 a 80 caracteres e o texto deve ser marginado do lado direito e esquerdo.

• Exemplo de linha muito extensa
• Exemplo de linha no intervalo óptimo
• Comprimento ideal de linha para conteúdo [ligação externa]

1.3 Rios de branco

Muitos utilizadores da web com dificuldades de leitura têm problemas com texto que é alinhado tanto à direita como à esquerda. O espacejamento desigual entre palavras do texto completamente alinhado pode causar "rios espaço em branco" que correm de cima abaixo e tornam a leitura mais difícil e em alguns casos impossível para algumas pessoas. A solução simples é evitar usar texto alinhados dos dois lados (texto justificado).

• Exemplo de texto justificado
• Exemplo de texto não justificado

1.4 Escrita de pirâmide invertida

Um forma simples de tornar o conteúdo mais acessível é usar o estilo da pirâmide invertida na escrita adoptada pela maior parte dos jornais. Começar por um sumário ou pequena introdução do tema e a súmula e depois dar os detalhes de fundo e informação de suporte. Isto permite aos utilizadores determinar rapidamente se há informação em que estejam interessados sem terem de analisar a totalidade da página.

• Exemplo de escrita em pirâmide
• Formato de história em pirâmide invertida [ligação externa]
• Técnicas de escrita em pirâmide (DFL Bulletin) [ligação externa]

[De volta à Tabela de Conteúdo]

2. Esconder e mostrar conteúdo

Para alguns utilizadores da web, em particular, para aqueles com deficiências cognitivas e dificuldades de aprendizagem grandes quantidades de texto numa página podem tornar-se numa barreira à acessibilidade. Permitir que o utilizador tenha algum controlo sobre a informação que lhe seja apresentada pode reduzir o impacto deste problema potencial. É possível agora dar aos utilizadores a capacidade de escolherem entre uma versão simples ou uma versão detalhada do conteúdo da página de várias formas.

2.1 Conteúdo breve e conteúdo extenso

Este método permite aos utilizadores escolherem entre uma versão abreviada ou uma versão extensa do conteúdo da página em todo um sítio web. Os utilizadores que optarem pela versão abreviada podem navegar no sítio, lerem a versão de texto mais breve de cada página. Se numa determinada página desejarem informação mais detalhada, eles seleccionam a opção da versão e é carregada a versão extensa do conteúdo.

Este método foi usado pelo sítio baseado em Sydney do Guardianship Tribunal. O teste de utilização deste sítio envolveu um largo espectro de utilizadores, incluindo alguns com dificuldades cognitivas e de aprendizagem. Quando percebiam que podiam escolher entre versões breves ou extensas do conteúdo das páginas a maior parte dos utilizadores achavam esta capacidade sem vantajosa. Por exemplo pessoas com problemas de leitura eram capazes de obter a versão abreviada da informação que conseguiam ler e compreender. Os assistentes sociais e os médicos também usavam o conteúdo breve como opção por omissão na sua navegação visto permitir localizar informação que lhes era necessária de forma rápida.

• Exemplo de conteúdo extenso e de conteúdo breve
• Página de confidencialidade do Guardianship Tribunal [ligação externa]

2.2 Expansão das balas

Um método similar usar frases simples ou cabeçalhos como forma de dar uma visão geral do conteúdo. Estas são apresentadas como balas que também servem como as chaves para obter mais informação. Quando o utilizador selecciona uma bala a versão extensa da informação relativa a esse ponto é apresentada na lista de balas.

• Exemplo de balas expansivas

2.3 Esconder-Mostrar balas

Este método também usa balas para frases simples ou cabeçalhos. Contudo o conteúdo expandido não é mostrado dentro de cada bala. É, de facto, mostrado por baixo da lista completa de balas. Esta opção é melhor para porções de conteúdo extensas.

• Exemplo de esconder-mostrar balas

2.4 Conteúdo de apresentação com diapositivos

Usar a web para fornecer conteúdo informativo para utilizadores com deficiências cognitivas mais sérias poderá exigir uma aproximação diferente. Um método sugerido envolve a apresentação da informação numa apresentação de diapositivos integrada com um diapositivo separado por cada conceito ou assunto. Isto irá permitir que o conteúdo fornecido o seja de forma clara, fácil de aceder em bocados que o utilizador pode percorrer à sua própria cadência.

• Exemplo de conteúdo mostrado como apresentação

[De volta aos conteúdos]

3. CSS para ajudar na clicabilidade e na legibilidade

Uma das principais vantagens das «Cascading Style Sheets» (CSS) é que podem ser usadas para manipular a apresentação do conteúdo sem afectar a estrutura do conteúdo. Eis alguns métodos simples que usam CSS para tornar o conteúdo mais acessível para pessoas com dificiências cognitivas e dificuldades de aprendisagem.

3.1 Aumentar entrelinha

Alguns utilizadores acham que um aumento do espaço entre linhas de texto num parágrafo pode ajudar na legibilidade.

• Exemplo de aumento de entrelinha

3.2 Aumentar margem após parágrafo

Normalmente há uma linha completa de intervalo entre parágrafos num bloco de conteúdo. Aumentar este intervalo para 1,5 ou 2 linhas de espaço pode ajudar a legibilidade para alguns utilizadores.

• Exemplo de aumento de margem após parágrafo

3.3 Efeito de pairar sobre ligações

Alguns utilizadores têm dificuldade em distinguirem ligações de outros conteúdos. As ligações podem receber um efeito de pairar (do rato) que as faça mudar de cor quando o rato paira por cima delas.

• Exemplo de efeito de pairar em ligações

3.4 Borda inferior nas ligações

O sublinhado tradicional em conteúdo textual pode tornar difícil a leitura de caracteres com pernas abaixo da linha de escrita (como por exemplo pq e semelhantes) para alguns utilizadores. Retirando o sublinhado por omissão das ligações e usando a técnica CSS de borda inferior para sublinhar a ligação, pode controlar a distância entre o texto e o sublinhado.

• Exemplo de borda inferior (border-bottom) em ligação

3.5 Aumentar área activa nas ligações

Para alguns utilizadores, particularmente para aqueles com dificuldades motoras, clicar nas ligações é difícil. Ao usar-se CSS, a área alvo das ligações pode ser aumentada.

• Exemplo de amplicação de área activa em ligação

3.6 Efeito de pairar em parágrafos, itens de lista e células de tabela

Alguns utilizadores com dificuldades de leitura acham difícil saber onde vão na página. Ao aplicar efeitos de pairar a parágrafos, itens de lista e linhas de tabelas permite-lhes usar o rato como dispositivo de marcação de lugar.

Infelizmente o Internet Explorer não suporta o efeito de pairar em parágrafos, listas ou linhas de tabela. Contudo se achar que isto é uma opção valiosa para os seus utilizadores pode ser usado JavaScript para simular este efeito no Internet Explorer (usando o IE7 de Dean Edwards).

• Exemplo de efeito de pairar em parágrafos
• Exemplo de efeito de pairar em linhas de tabela

Parágrafos sublinhadoss

Outro método para utilizadores com dificuldades de leitura envolve sublinhar o conteúdo em parágrafos activos. A ideia é fornecer uma régua virtual que fica por baixo de cada linha de texto permitindo ao utilizador manter os olhos na linha que estejam a ler de modo mais fácil.

• Exemplo de parágrafo sublinhado

Um dos possíveis problemas levantados por este método é que alguns utilizadores podem confundir o parágrafo sublinhado com a apresentação por omissão de uma ligação. Usar CSS para dar um estilo diferente de sublinhado por exemplo uma linha tracejada vermelha, pode reduzir o risco de confusão potencial.

• Exemplo de parágrafo sublinhado usando sublinhado de borda

3.8 Cores reservadas

Alguns utilizadores acham que o conteúdo é mais fácil de ler se as cores de texto e fundo forem invertidas, sendo o conteúdo da página escrito com uma cor leve e o fundo com uma cor escura.

• Exemplo de cores invertidas

3.9 Reduzir luminosidade do fundo

Alguns utilizadores acham que as páginas com cor de fundo branca produzem demasiada luminosidade tornando-as difíceis de ler. Pode tratar-se disto usando uma cor ligeiramente fora do branco ou um cinza claro para o fundo o qual irá reduzir a quantidade de luminosidade.

• Exemplo de luminosidade de fundo reduzida

[De volta aos conteúdos]

4. Controlo pelo utilizador do conteúdo e da apresentação

As várias ideias esboçadas neste artigo podem ser usadas para permitir que a cada utilizador de um site seja apresentada uma página web da forma que lhe seja mais útil.

Quando se combina CSS com JavaScript ou processamento do lado do servidor é possível a um responsável pelo desenvolvimento incluir algumas das sugestões de melhoria de acessibilidade (isto é, borda de baixo nas ligações e área de ligação aumentada) como parâmetros por omissão de apresentação de página, enquanto se permite aos utilizadores controlarem outros elementos da página tais como:

• Conteúdo: versões extensas e abreviadas da informação.
• Tamanho do tipo de letra: capacidade de aumentar ou diminuir o tamanho do texto.
• Legibilidade: alterar o espaço entre parágrafos e/ou aplicar efeitos de rato a pairar sobre parágrafos.
• Temas de cor: dar um intervalo de opções que inclua a inversão de cores e a redução de luminosidade.
• Line-length (comprimento da linha): para arranjos sobre o alto ou sobre o baixo.
• Line-height (entrelinha) : dar uma gama de opções para alteração de entrelinha de texto e ligações.

• Exemplo de ferramenta de controlo [ligação externa]

[De volta aos conteúdos]

Conclusão

Estes exemplo não são "a" resposta definitiva de todos os problemas de utilizadores com deficiências cognitivas e dificuldades de aprendizagem quando acedem a um sítio web. Em vez disso, são sugestões para responsáveis pelo desenvolvimento. Uma pessoa que esteja interessado em tornar o seu conteúdo mais acessível para uma audiência mais alargada poderá querer experimentar. Embora algumas das técnicas tenham sido testadas com utilizadores que têm dificuldades cognitivas e de aprendizagem, outras são simples ideias teóricas ou meros palpites.

[De volta aos conteúdos]

Leitura adicional:

• An Accessibility Frontier: Cognitive disabilities and learning difficulties
• Practical Design Guidelines for Universal Usability
• Adolescents, Autism Spectrum Disorder And Secondary School
• Inclusion Of Cognitive Disabilities in the Web Accessibility Movement

[De volta aos conteúdos]

ApplicationController.rb e Reutilização de Código

Os ficheiros dos helpers numa aplicação Rails devem ser usados para albergar código que se queira partilhar com vários ficheiros de vistas.

Quando queremos partilhar código entre controladores devemos colocar os métodos a partilhar em ApplicationController (app/controllers/application.rb). Não se pode esquecer tornar esses métodos privados de forma a não poderem ser chamados como acções.

Outra hipótese é colocar esses métodos num módulo e depois chamar esse módulo onde necessário como em:

# lib/login.rb
module Login
  def utilizador_actual
    # código para determinar utilizador actual
  end
end

# app/controllers/comments_controller.rb
class CommentsController < ApplicationController
  include Login

  def edit
    utitlizador = utilizador_actual
  end
end

Como tornar maísculas todas as iniciais de uma frase em Ruby

"isto é uma frase de teste.".titleize

De que resultará algo como:

Isto é Uma Frase De Teste."

has_one

A associação has_many permite-nos fazer uma correspondência entre um registo numa tabela e um registo noutra tabela.

Exemplos disto:

• Num sistema de forum uma entrada tem um autor.
• Num sistema de registo (login), cada utilizador tem um perfil.

Exemplo: Forum

Ver o exemplo do forum.

has_many

A associação has_many dá um modo de aceder a uma relação unidirecional entre duas tabelas.

Exemplos disto:

• As bases de dados das companhias onde uma companhia possui (has) várias contas.
• Num sistema de foruns, onde uma categoria possui vários forum, e estes possuem vários tópicos

Exemplo: Forum

Ver o exemplo do forum

Ver também

• belongs_to/pertence a
• has_one/possiu um

belongs_to

belongs_to complementa uma associação has_many ou uma associação has_one.

Em geral, o modelo Coisa belongs_to :barra se a tabela coisa tiver uma coluna chave externa barra_id.

Exemplos disto:

• As bases de dados das companhias onde uma conta pertence (belongs) a uma companhia.
• Num sistema de foruns, onde um topico pertence a um forum, que pertence a uma categoria

Exemplo: Forum

Ver o exemplo do forum

Notas

Quando usar :counter_cache => true, assegure-se que o valor por omissão da coluna model_count é algo que possa ser incrementado. Por exemplo NULL + 1 é igual a NULL e assim o contador SQL não funcionará.

Ver a API para mais informação sobre :counter_cache

Mashupfeed

Se me perguntassem para que serviam os mashup não saberia o que responder (santa ignorância a minha) pois é uma pessoa está demasiado tempo a olhar para a esquerda que não vê o que é que se passa à direita. Depois uma pessoa começa a brinca com googlemaps e fica-se altamente perturbado.

Para verem o que é que quero dizer imaginem que querem fazer winsurf cá o que é que fariam se não conhecem ninguém. Talvez passar pelo mapa do vento, um dos exemplos de mashup listados no mashupfeed.

Cada vez gosto mais dos microformatos

Com toda a excitação que ocorre com o AJAX não tinha olhado para outros métodos de obter páginas com interactividade elevada com métodos mais simples.

No entanto tenho estado a experimentar isto com um pouco mais de atenção e claro que encontrei muita coisa de que ainda não tinha ouvido falar anteriormente como por exemplo em: AHAH (tive em tempos um jogo que se chamava assim) e em JAH algo que é uma união de AHAH com JSON.

yuiBLOG

Yahoo! User Interface Blog

Algo interessante e a ver por quem quer usar as bibliotecas criadas e públicas do Yahoo!

Biblioteca UI do Yahoo!

Além da biblioteca de Padrões de concepção o yahoo também disponibiliza uma biblioteca Ajax/DHTML, será que devia dizer Ajax/DOM de boa qyalidade com capacidade de arrastar/largar, gestão de eventos, manipulação de posicionamento, etc.

Yahoo! Developer Network

O Yahoo apresenta actualmente no seu portofolio serviços para programadores (no sentido em que sejam responsáveis pelo desenvolvimento de um sítio) uma biblioteca de padrões de concepção muito interessante.

O blogue do João Craveiro

O João Craveiro há relativamente pouco tempo fez uma revisão do aspecto gráfico do seu blogue o lâmpada azul agora fez mais do que isso reinventou-o dando-lhe uma finalidade mais abrangente, passou de blogue de aficionado da informática para aficionado pela vida (introduzindo secções novas como artes e letras, críticas de filmes e outras coisas que têm a haver com estilo de vida). Parabéns pela alteração.

Newvine

Hoje li o meu convite para o beta do newsvine

Elementos e marcadores opcionais

opcionais />

HTML, os marcadores de iníco e fim dos elementos e são opcionais. Assim o código que se segue é um documento perfeitamente válido e conforme o HTML 4.01 Strict. /> /> HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd" /> documento mais pequeno possl /> http-equiv="Content-Type"
content="text/html; charset=UTF-8" /> Mais Pequeno /> />Isto é um documento dos mais pequenos possíveis em
title="HyperText Markup Language" /> /> />
os marcadores sejam opcionais os elementos não o são Lembre-se que um elemento é parte da estrutura do documento e que os marcadores são as declarações para criar a estrutura do documento. Onde se pode determinar sem ambiguidade o marcador inicial e final o HTML permite que estes marcadores sejam opcionais mas os elementos irão surgir na estrutura do documento. No exemplo acima coloquei um marcador final. No HTML tal é opcional pois pode ser determinado sem ambiguidade o final do parágrafo. /> validar um documento com o conteúdo acima no W3C validator. /> XHTML, os marcadores de início e fim dos elementos html, head, e body são obrigatórios devido à exigência de boa constituição do XML que não permite a omissão de marcadores. /> interpretação de documentos pode ser afectada pelo tipo MIME usado quando são servidos, sendo a interpretação ainda dependente do navegador usado. />

Inspector de Tabelas Complexas

Gus Lemon publicou no Juicy Studio um artigo onde revela como melhorar a acessibilidade de tabelas complexas de dados.

Como tratar um Web Designer

Fergus Webber diz como tratar um Web deisgner (sic) muito bem. Não vale a pena repetir aqui.

Comprimento, Largura e Altura

Parece que temos que voltar à geometria e estudar o que é que significam os eixos X Y e Z (profundidade). Para saber porquê então veja o artigo:

Z's not dead baby, Z's not dead

AT MEDIA 2006

Este ano em Londres irá suceder uma conferência de dois dias sobre desenvolvimento web na @media2006. Vai haver um conjunto de conferencistas de primeiro plano: Andy Budd, Dan Cederholm (do Bullefproof Web Design e Web Standards Solutions), Tantek Çelik (CT da Technorati), Peter-Paul Kock (o homem por trás do QuiksMode), Eric Meyer (O CSS em pessoa), Cameron Moll, Roger Johansson e alguns outros.

Dilbert

Vejam o Dilbert de 29 de Janeiro.

O mundo deve ser perfeito!

Andulo - Moinhos de água do Membia

Andulo - Moinhos de agua 2, originally uploaded by Carlos João.

Esta é uma irmã entre várias de uns moinhos construidos sobre o rio Membia, perto da ântiga barragem do Andulo no Bié em Angola.

This is one of a set of photos of watermills built on the river Membia nearby the old waterdam of Andulo, Bié, Angola.

ALA - 210 e 211

ALA 210

O triplo objectivo da acessibilidade: obter abreviaturas correctas é quanto a mim o artigo mais interessante deste número, desta vez não acompanho o Jeffrey na sua ironia sobre a Web 3.0. Compreendo contudo que em todos as reuniões aparecem uns mais cromos que outros.

ALA 211

Aperfeiçoar os fundamentos: Um melhor layout CSS de três colunas. Entradas que fazem mais e finalmente um texto de Jeffrey Zeldman (Repescado) Corrija o seu sítio com o DOCTYPE correcto!.

RoR: Como Paginar

Paginação Simples

Usar o ajudante de paginação

Paginação à medida

O método de paginação embutido no RoR torna-se limitado quando as suas necessidades se tornam mais complexas. É então necessário usar uma técnica melhor:

O método do Kevin de paginação à medida implica usar quatro passos.

No controlador:

def list
  #passo 1: ler e atribuir valores às variáveis que necessitamos
  page = (params[:page] ||=1).to_i
  items_per_page = 20
  offset = (page -1) * items_per_page

  #passo 2: efectuar o seu find à medida efectuando 
  #qualquer tipo de limites ou deslocamentos
  # isto é obter tudo em cada página, não se 
  #preocupar com paginação por agora
  @items = Item.find_com_algum_metodo_a_medida(@alguma_variavel)

  #passo 3: criar um Paginator, a segunda variável
  #tem que ser o número da TOTALIDADE dos items em TODAS as páginas
  @item_pages = Paginator.new(self, @items.length, items_per_page, page)

  #passo 4: só enviar um subconjunto de @items para a vista
  # é aqui que ocorre a magia. Não é necessário voltar a
  # fazer outra busca  (find)
  @items = @items[offset..(offset + items_per_page - 1)]

end

Na vista colocar:

Pages: 
<%= link_to('previous', {:params => params.merge('page' => 
@ item_pages.current.previous)}) +
 ' ' if @ item_pages.current.previous %>

<% for page in @ item_pages -%>
<%= link_to_unless(params[:page].to_i == page.number, page.number,
 {:params => params.merge('page' => page)}) %> 
<% end -%>

<%= link_to('next', {:params => params.merge('page' => 
@item_pages.current.next)}) if @ item_pages.current.next %>

Esta técnica funciona com conjuntos de dados pequenos e médios (onde não tem que se preocupar com um grande número de registos, embora não os queira ver surgir de uma só vez), mas torna-se limitada quando os registos são em elevado número.

Para grandes conjuntos de dados que necessitem de buscas à medida, necessita de saber o número total de registo, depois criar um Paginador e depois só recuperar os registos desejados.

No controlador:

def list
    # passos 1: ler e atribuir variáveis necessárias
    page = (params[:page] ||= 1).to_i
    items_per_page = 20
    offset = (page - 1) * items_per_page

    # passo 2: em vez de efectuar uma busca completa descobrir
    # só o número de registo
    @item_count = Item.find_record_count(@some_variable)

    # passo 3: criar um Paginator, a segunda variável tem 
    #que ser o número de TODOS os items em TODAS as páginas
    @item_pages = Paginator.new(self, @item_count, items_per_page, page)

    # passo 4: descobrir só o subconjunto pedido de @items
    @items = 
    Item. busca_com_algum_metodo_a_medida(@some_variable, 
                                          offset,
                                          items_per_page)

end

Depois necessitará de alterar o método "busca_com_algum_metodo_a_medida" de forma a usar as variáveis offset e items_per_page numa cláusula SQL LIMIT. Se o que descobrir for já complexo, poderá ser mais fácil usar "find_by_sql" em vez de "find".

O código da sua vista pode ser igual ao anterior.

Membia

Algo totalmente fora de tópico
Algumas fotografias de moinhos de água que se encontram em: fotografias do João

Profissionais da Web

A discussão sobre o que é ser profissional da web tem continuado. Aos suspeitos habituais, como a Molly E. Holzschklag em: Web Standards and the New Professionalism, Roger Johansson em: A Web Professional Can Never Stop Learning e em: Reaching and helping the new amateus, Hooly Marie Koltz em: Beyond New Professionalism, e Peter-Paul Kock em: The New Amateurs e The New Amateurs - Part 2, e Chris Casciano em [web] On Craft, A New Professionalism And New Amateurs todos tocam os aspectos relativos à definição da própria profissão (profissões) de quem faz algo (como trabalho) na web.

Esta discussão julgo que deva ter surgido noutras áreas quando as mesmas ainda estavam em plena infância como a nossa. Hoje não é de esperar por exemplo que um engenheiro electrotécnico ache uma falta de liberdade usar elementos industriais padronizados quer por entidades públicas, quer por organismos associativos nos seus projectos.

No entanto usar elementos não padronizados na web é frequente. Nos casos em que tal acrescenta algo seria de pensar pradronizar nos casos em que só aumenta a confusão seria de eliminar. Outro aspecto comum é a necessidade de formação contínua não só da gente que pratica web mas até certo ponto da gente que lhe está à volta (não havendo acordo contudo sobre este aspecto).

É uma discussão que provavelmente se irá manter até que a área estabilize.

Tabelas ou Disposição CSS- II

Uma das coisas curiosas das listas de correio especializadas é a repetição dos mesmos problemas ao longo do tempo.

Um desses problemas recorrentes na lista de correio de desenvolvimento de css (CSS-D) é a pergunta sobre como apresentar dados extraidos de uma base de dados numa tabela.

Que marcadores usar e depois estilizar.

As respostas andam invariavelmente à volta de:

thead td
thead th
tbody td
tbody th...

Dando ainda a ligação a uma galeria de estilos.

Pode ainda ver: Tabelas ou Disposição.

Actualização 2009-01-02: Uma revisitação deste assunto em breve

Cábula de RoR (Ruby On Rails)

No resistance to persistence » Blog Archive » RubyOnRails-Cheatsheet encontra-se um ficheiro PDF com uma sumula de Ruby On Rails

Padrões de Sítios Web

Padrões são soluções óptimas para problemas comuns. À medida que os problemas sejam levantados à volta de uma comunidade e resolvidos, soluções comuns frequentemente emergem de forma espontânea. Eventualmente, a melhor destas destaca-se da ganga e auto identifica-se e vai-se refinando até alcançar o estatuto de Padrão de Concepção.

Christopher Alexander foi o primeiro a nomear este fenómeno em relação aos espaços vividos. Ele e os seus co-escritores introduziram o conceito de Padrões de Arquitectura para descrever características dos espaços vividos fossem eles salas, edifícios ou cidades.

Os Padrões são atómicos no sentido de que podem ser agrupados para formarem padrões mais complexos: um padrão cadeira enquadra-se num padrão sala de jantar que se enquadra num padrão casa que se enquandra num padrão cidade.

Uma ideia que destingue os Padrões de simples prescrições é que os Padrões nunca perdem o sentido do seu contexto; descrevem coisas que funcionam em conjunto e as regras que governam essas colecções.

Os padrões de software encontraram uma grande ressonância na indústria do software em particular entre os que usam Metodologias Ágeis.

Algumas pessoas tiveram aqui inspiração para criar um documento sobre Padrões de Sítio da Web.

1. Repositórios de Padrões
2. Artigos e Textos On-Line
3. Livros
4. Discussão

ALA 209

Dia 19 saiu o A List Apart nº 209.
Neste número uma das luminárias da internet Molly E. Holzschlag apresenta uma analogia entre sítios organicos e sítios com uma organização baseada em grelha «Thinking Outside the Grid» e Brian Crescimanno apresenta o seu «Sensible Forms: A Form Usability Checklist». O artigo repescado deste número é de Scott Jason Cohen «Porque é que está aqui?».

Feed Icons

Para quem queira harmonizar o seu sítio com o acordo que já há no momento para utilização do mesmo ícone usado pelo Firefox para distinguir sítios com assinaturas e deseje descarregar o ícone nos mais diversos formatos gráficos então dê uma saltada a href="http://feedicons.com/" icons />

Ícone para RSS feed

A Microsoft vai usar o mesmo símbolo (ícone) que o Firefox usa na (linha de endereços) para indicar que um sítio tem associada a ele uma assinatura (rss feed).

Lista de Artigos a Re(ler)

Começou aquela época do ano em que se fazem balanços e num blogue sobre web é razoável que se coloque uma lista de artigos fundamentais que se foram lendo ao longo do ano que que se considerem fundamentais.

A lista que se segue não é minha mas a do Roger Johansson. Os meus artiguinhos ainda não têm calibre suficiente para entrar numa lista deste género.

A esta lista deve ser acrescentada a dos 24 artigos a serem publicados até 24 de Dezembro.

1. Os perigos de usar XHTML adequadamente

   Explicação dos problemas envolvidos ao servir XHTML com o tipo MIME application/xhtml+xml.

2. Charlatões de acessibilidade

   O clamar a aderência a normas de acessibilidade são frequentemente falsas e nada mais do que marketing.

3. Fundamentos de optimização para motores de busca

   Pistas básicas para Optimização para Motores de Busca: adicionar conteúdo com qualidade de forma regular e fazer com que o seu sítio seja bem construído.

4. CSS eficiente com propriedades abreviadas

   Truques para escrever CSS mais eficiente usando propriedades abreviadas.

5. Estabelecer o estado do menu com CSS

   Um método só com CSS de alterar a aparência do estado actual de uma barra de navegação.

6. CSS Pistas e Truques, Parte I

   Pistas e truques para escrever CSS eficiente, Partes I e II.

7. CSS Pistas e Truques, Parte II

   Pistas e truques para escrever CSS eficiente, Partes I e II.

8. Largura fixa ou fluída? Elástica!

   Uma breve explicação do conceito de arranjos com largura elástica.

9. Cantos e limites (border) à medida transparentes

   Criar uma caixa com cantos e limites transparentes e sem marcadores adicionais.

10. Mitos e conceitos incorrectos sobre acessibilidade

    Explicação de mitos e conceitos errados comuns sobre acessibilidade.

11. Web Standards versus Acessibilidade

    Os Web Standard não são só para pessoas cegas e leitores de ecrã.

12. O perigo de um Internet Explorer melhor

    O suporte melhorado dos Web Standard no Internet Explorer será uma coisa boa, ou colocará em perigo a saúde futura da Web ao corrermos o risco de que os responsáveis pelo desenvolvimento de sítios Web comecem a usar cada vez mais características proprietárias?

13. A acessibilidade encoraja a discriminação?

    Uma discussão sobre se será aceitável que um sítio web seja acessível a pessoas com dificiência mas inacessíveis a pessoas que utilizem dispositivos de navegação ou sistemas operativos alternativos.

14. Marcadores HTML vs. Elementos vs. Atributos

    Explicação das diferenças entre marcadores (etiquetas/tags), elementos e atributos em HTML.

15. Codificação sem ajudas técnicas

    Por que é que codificar HTML e CSS à mão é melhor do que usar aplicações WYSIWYG.

16. CSS 2.1 Selectores, Parte 1 de 3

    Os fundamentos de selectores mais os selectores universão, tipo, id e classe

17. CSS 2.1 Selectores, Parte 2 de 3

    Combinadores, selectores combinados, selectores de grupo e selectores de atributo

18. CSS 2.1 Selectores, Parte 3 de 3

    Pseudo-classes e pseudo-elementos

19. É o atributo alt não o marcador/etiqueta alt

    Não há um marcador alt em HTML. Alt é um altributo, obrigatório num elemento img e especificado no marcador img.

20. Um profissional da Web não pode deixar de aprender

    Os profissionais da web que se recusem a actualizar os seus conhecimentos insistirem em utilizar métodos desactualizados não podem ser chamados de profissionais.

21. Revelar truques da velha escola do desenvolvimento da Web

    Uma coleção de truques de web design e desenvolvimento que eram amplamente usados antes dos responsáveis pelo desenvolvimento começarem a deixar de usar arranjos baseados em tabelas e passarem a adoptar os web standards.

22. Acessibilidade e usabilidade para televisão interactiva

    Acessibilidade e usabilidade para televisão interactiva têm muito em comum com acessibilidade e usabilidade para a web. Há também várias diferenças, sendo que algumas são realçadas neste artigo.

23. Dez razões para aprender e usar Web Standards

    Algumas das razões mais importantes para investir tempo para aprender tudo sobre web standards para design e desenvolvimento de sítio web.

Reconhecimento de ficheiros HTML de acordo com o RFC 2854

Quase todos os arquivos HTML têm a cadeia de caracteres <html" ou "<HTML" perto do princípio do arquivo.

Documentos em conformidade com as especificações HTML 2.0, HTML 3.2 e HTML 4.0 começam com uma declaração DOCTYPE "<!DOCTYPE HTML" perto do início e antes da cadeia de caracteres "<html". Estes dialectos não levam em linha de conta as letras minúsculas ou maísculas. Os arquivos podem começar com espaço em branco, comentários (introduzidos por "<!--" ), ou instruções de processamento (introduzidas por "<?") antes da declaração DOCTYPE.

Os documentos XHTML (opcionalmente) começam com uma declaração XML que começa com "<?xml" e obrigatoriamente têm uma declaração DOCTYPE começada por "<!DOCTYPE html"

.

Directrizes de compatibilização HTML/ XHTML

1. Instruções de Processamento e Declaração XML

   Tenha em atenção que as instruções de processamento são reproduzidas em alguns agentes utilizadores. Além disso, alguns agentes utilizadores interpretam a declaração XML significando que o documento é XML e não HTML, e sendo assim, podem não reproduzir o documento como esperado. Para compatibilidade com estes tipos de navegadores antigos, pode ter que evitar usar instruções de processamento e declarações XML. Lembre-se contudo que se a declaração XML não for incluída num documento, o documento só pode usar as codificações de caracteres por omissão UTF-8 ou UTF-16.

2. Elementos vazios

   Inclua um espaço antes do traço de fracção / e um sinal de maior que >, isto é, <br />, <hr /> e <img src="logo.jpg" alt="logotipo da marca" />. Além disso use a sintáxe dos marcadores minimizados para elementos vazios, isto é <br />, visto a sintaxe alternativa <br></br> permitida pelo XML dá resultados incertos em muitos agentes utilizadores existentes.

3. Minimização de elemento e Conteúdo de elemento vazio

   Dado um caso vazio de um elemento cujo modelo de conteúdo não seja EMPTY (por exemplo, um título vazio ou um parágrafo vazio) não usar a forma minimizada (isto é, usar <p> </p> e não <p />).

4. Folhas de estilo e Scripts embebidos

   Usar folhas de estilo externas se as suas folhas de estilo usarem < ou ]]> ou --. Usar scripts externos se o seu script usar < ou ]]> ou --. Note que os analisadores XML podem remover conteúdos de comentários de modo silencioso. Assim, a prática histórica de "esconder" scripts e estilos em "comentários" para tornar os documentos retrocompatíveis é possível que não funcione como esperado em agentes utilizadores baseados em XML.

5. Quebras de linha dentro de Valores de Atributos

   Evitar quebra de linhas e vários caracteres de espaço em branco em valores de atributos. São tratados pelos agentes utilizadores de forma inconsistente.

6. Isindex

   Não incluir mais do que um elemento isindex no head do documento. O elemento isindex está a ficar obsoleto em relação ao elemento input.

7. Os atributos lang e xml:lang

   Usar ambos os atributos lang e xml:lang quando especificar a língua em que um elemento esteja escrito. O valor do atributo xml:lang tem precedência.

8. Identificadores de Fragmento

   Em XML, as referências URI [RFC2396] que terminam em identificadores de fragmentos na forma "#qualquercoisa" não se referem a elementos com um atributo name="qualquercoisa"; mas sim a elementos com um atributo definido como sendo do tipo ID, isto é o atributo id em HTML 4. Muitos programas clientes HTML não suportam a utilização de atributos do tipo ID desta forma e assim sendo podem ser fornecidos valores identicos para ambos os atributos para assegurar o máximo de compatibilidade para o futuro e retrocompatibilidade (isto é, <a id="qualquercoisa" name="qualquercoisa">...</a>).

   Além disso visto que o conjunto de valores legais para os atributos do tipo ID ser muito mais pequeno que os do tipo CDATA, o tipo do atributo name foi alterado para NMTOKEN. Este atributo está constrangido de tal modo que só pode ter os mesmos valores que os do tipo ID, ou que os do tipo Name em XML 1.0 secção 2.3, produção 5. Infelizmente, este constrangimento não pode ser expresso nos DTD 1.0 do XHTML. Devido a esta alteração é necessário ter cuidado quando se converte documentos HTML existentes. Os valores destes atributos têm que ser únicos dentro do documento, válidos, e quaisquer referências a estes identificadores de fragmento (tanto internas como externas) devem ser actualizadas no caso dos valores serem alterados durante a conversão.

   Note que a colecção de valores legais na produção 5 da Secção 2.3 da especificação XML 1.0 é muito maior do que aquela que é permitida ser usada nos tipos ID e NAME no HTML 4. Quando se definem identificadores de fragmento para serem retrocompatíveis só devem ser usadas cadeias de caracteres de acordo com o padrão: [A-Za-z][A-Za-z0-9:_.-]*. Ver secção 6.2 do [HTML 4] para mais informação.

   Finalmente, note-se que o XHTML 1.0 pede para se evitar usar o atributo name dos elementos a,applet, form, frame, iframe, img e map, e será removido de versões subsequentes do XHTML.

9. Codificação de caracteres

   Historicamente a codificação de caracteres de um documento HTML era especificada pelo servidor web via um parâmetro de conjunto de caracteres (charset) do cabeçalho de Tipo de Conteúdo do HTTP, ou via um elemento meta no próprio documento. Num documento XML, a codificação dos caracteres do documento é especificada na declaração XML (isto é: <meta http-equiv="Content-type" content="text/html; charset=EUC-JP" />). Em agentes utilizadores conformes com o XHTML o valor da declaração da codificação na declaração XML toma precedência.

   Nota: tenha em atenção que se um documento deve incluir uma declaração de codificação de caracteres numa instrução meta http-equiv, esse documento pode ser sempre interpretado pelos servidores HTTP e/ou agentes utilizadores como sendo do tipo de media internet definido nessa declaração. Se um documento pode vir a ser servido como vários tipos de media o servidor HTTP deve ser usado para estabelecer a codificação do documento.

10. Atributos Booleanos

    Alguns agentes utilizadores HTML não conseguem interpretar atributos booleanos quando surgem na sua forma não minimizada, como necessário ao XML 1.0. Nota: este problema não afecta agentes utilizadores conformes com HTML 4. Estão envolvidos os seguintes atributos: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

11. Document Object Model e XHTML

    A recomendação nível 1 do [DOM] define os interfaces do modelo objecto de documento para o XML e o HTML 4. O modelo de ojecto documento do HTML 4 especifica que o elemento HTML e os nomes dos atributos retornam em maísculas. O modelo de objecto documento XML especifica que os nomes dos elementos e atributos são retornados com as letras minúsculas e maísculas com que são especificados. Em XHTML 1.0 os elementos e atributos são especificados em minúsculas. Esta diferença pode ser tratada de duas formas:

    1. Agentes utilizadores que acedam aos documentos XHTML servidos como tipo media da internet text/html via DOM podem usar o HTML DOM e podem depender dos nomes de elementos e atributos serem retornados em maiúsculas a partir desses interfaces.

    2. Agentes utilizadores que acedam aos documento XHTML servidos como text/xml, application/xml, ou application/xhtml+xml podem usar o XML DOM. Os elementos e atributos retornam em minúsculas. Também, alguns elementos XHTML podem ou não aparecer na árvore do objecto devido a serem opcionais no modelo de conteúdo (isto é, o elemento tbody dentro de table). Isto ocorre porque em HTML 4 alguns elementos foram permitidos ser minimizados de tal modo que tanto a etiqueta de início e a de fim do elemento são ambas omitidas (uma funcionalidade SGML). Isto não é possível em XML. Assim em vez de exigir aos autores dos documentos a inserção de elementos extra, o XHTML tornou estes elementos opcionais. Os agentes utilizadores têm que se adaptar em conformidade. Para mais informação sobre este tópico, ver [DOM2].

12. Utilização de e comercial em valores de atributos (e noutros locais)

    Tanto em SGML como em XML o caracter e comercial ("&") declara o início de uma referência de entidade (isto é &reg; para um símbolo de marca registada "®"). Infelizmente, muitos agentes utilizadores de HTML tem vindo a ignorar silenciosamente o uso incorrecto do caracter e comercial em documento HTML - tratando os e comerciais que não pareçam referências de entidade como e comerciais literais. Os agentes utilizadores XML não vão tolerar este uso incorrecto e qualquer documento que usar e comercial de forma incorrecta será "inválido" e consequentemente não estará em conformidade com esta especificação. De forma a assegurar que documentos que eram compatíveis com agentes utilizadores antigos de HTML e agentes utilizadores baseados em XML, os e comerciais usados num documento que sejam para ser tratados como caracteres literais têm eles mesmo de ser uma referência de entidade (isto é, "&"). Por exemplo quando um atributo href de um elemento a se referir a um script CGI que tome parâmetros esse atributo deve ser expresso como: http://meu.sitio.dom/cgi-bin/meuscript.pl?classe=convidado&;nome=utilizador em vez de http://meu.sitio.dom/cgi-bin/meuscript.pl?classe=convidado&nome=utilizador.

13. Folhas de Estilo em Cascata (CSS) e XHTML

    A Recomendação de nível 2 das folhas de estilo em cascata [CSS2] definem propriedades de estilo que são aplicadas à árvore de análise dos documentos HTML ou XML. As diferenças na análise irão produzir resultados visuais e/ou auditivos diferentes dependendo dos selectores usados. As pistas seguintes reduzem este efeitos em documentos que são servidos sem alterações como ambos tipos de media:

    1. As folhas de estilos CSS para XHTML devem usar minúsculas para nomes de elementos e atributos.
    2. Em tabelas, o elemento tbody será inferido pelo analisador de um agente utilizador HTML, mas não pelo analisador de um agente utilizador XML. Assim deve ser sempre explicito e adicionar o elemento tbody se o mesmo é referido num selector CSS.
    3. No espaço de nomeação XHTML, é de esperar que os agentes utilizadores reconheçam o atributo "id" como um atributo do tipo ID. Assim, as folhas de estilo devem ser capazes de continuar a usar o selector abrevidado "#" mesmo se o agente utilizador não ler o DTD.
    4. No espaço de nomeação XHTML, é de esperar que os agentes utilizadores reconheçam o atributo "class". Assim, as folhas de estilo devem ser capazes de continuar a usar a sintáxe abreviada de selectores ".".
    5. A CSS define regras de conformidade diferentes para documentos HTML e XML; não se esqueça que as regras HTML são aplicáveis a documentos XHTML entregues como HTML e que as regras XML são aplicáveis quando os documentos XHTML são entregues como XML.

14. Referir o elementos style quando se serve como XML

    Em HTML 4 e XML o elemento style pode ser usado para definir as regras de estilo internas do documento. Em XML, é usada uma declaração de folha de estilo XML para definir as regras de estilo. De forma a ser compatível com esta convenção, os elementos style devem ter o seu identificador de fragmento usando o atributo id, e a declaração de folha de estilo XML deve referir-se a esse fragmento. Por exemplo:

    
    <?xml-stylesheet href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" type="text/css"?>
    <?xml-stylesheet href="#estiloInterno" type="text/css"?>
    <!DOCTYPE html 
         PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="pt" lang="pt">
    <head>
    <title>Um exemplo de folha de estilo interna</title>
    <style type="text/css" id="estiloInterno">
      code {
        color: green;
        font-family: monospace;
        font-weight: bold;
      }
    </style>
    </head>
    <body>
    <p>
      O texto que se segue usa o nosso 
      <code>estilo interno</code>.
    </p>
    </body>
    </html>
    

15. Caracteres de espaço em branco em HTML e XML

    Alguns caracteres legais em documentos HTML são ilegais em documentos XML. Por exemplo, em HTML o caracter de avanço de folha (U+000C) é tratado como espaço em branco, em XHTML, devido à definição de caracteres é ilegal.

16. A referência de entidade com nome &apos;

    O caracter ' (o apóstrofe, U+0027) foi introduzido no XML 1.0 mas não aparece no HTML. Os autores devem assim usar o ' em vez de ' de forma a funcionar como se espera em agentes utilizadores HTML 4.

O que é um contentor?

Um contentor é tudo aquilo que por omissão é apresentado como bloco (display: block). Isto quer dizer: div, p, h1-h6, ul, ol, dl, table, etc, etc...

No caso de lhes ser atribuída a propriedade display: inline deixam de se comportar como contentores. Pode dar a propriedade display: block e o elementos ou elementos afectados passam a comportar-se como contentores.

Por outro lado elementos em linha como li, img, a, span, etc podem ser vistos como contentores porque se lhes pode dar: padding, margin ou border.

Para ver o que é que contentores podem fazer vá até: Contentores, Larguras, Margens...

Dicas

O Internet Explorer ao reproduzir um elemento não respeita a nossa indicação de altura para o elementos mais sim as alturas (eventualmente acumuladas) dos elementos/conteúdo desse elemento. Ou seja expande a caixa onde era suporto encaixar-se.

O que é que isto quer dizer?

html {height: 100%;}
body {min-height: 100%;}
* html body {height: 100%;}

Se as suas border terminarem no fundo da janela do seu navegador isso normalmente quer dizer que se disse à div para ter 100% de altura do elemento body, o qual deve ser 100% do viewport. Como não se usou min-height está a dizer à div que tem o tamanho do viewport e é tudo. Quando o viewport termina a sua div termina.

O código acima corrige isso ao usar min-height igual a 100% para o body. Isto significa que o elemento body pode ser esticado para além do fim do viewport, e visto que a div nele contida ter 100% da sua altura também pode ser esticada para além do final do viewport. A terceira linha é um truque e serve para dizer ao IE que a height é 100% para o IE. O IE não compreende min-height mas trata height de forma equivalente e portanto este truque funciona. Deve ser usado dentro de comentários condicionais.

Colunas Falsas

Quando se quer fazer um layout com colunas falsas, cria-se um ficheiro de imagem normalmente relativamente baixo género 10px e bastante largo com as separações nos pontos desejados com cerca de 2000px (por exemplo) e depois deste ficheiro criado coloca-se no ficheiro CSS uma regra semelhante à que se segue:

#contentor {
   background: #fff url("colunasfalsas.gif") repeat-y;
   ...
}

Para obter um fundo preto, com a nossa imagem repetida tantas vezes quantas as necessárias.

A imagem da coluna pode apresentar um dégradé.

Imagem de Fundo Clicável

Se tivermos uma imagem que esteja (ou deva estar) numa posição fixa género logo à esquerda superior e a desejemos colocar em fundo no CSS e além disso que seja possível clicar nela então podemos usar uma das várias técnicas de substituição como no código que se segue:

<a id="logoentrada" href="bla.html">Entrada</a>

#logoentrada{
  position:absolute;
  top:20px;
  left:20px;
  width:100px;
  height:70px;
  overflow:hidden;
  text-indent:-200px;
}

Como remover a border de uma imagem numa âncora

Alguns navegadores quando colocamos imagens dentro de uma âncora reproduzem a imagem com uma borda por omissão. Para a evitar basta aplicar o seguinte CSS:

a img {
 border-style: none;
 ...
}

Visto isto ser uma pergunta recorrente poderá ser interessante ler: Imagens com ligações.

Como eliminar espaço adicional colocado à volta de células de uma tabela com border

Aplicar o seguinte CSS:

img {
 display: block;
}

Se quizer saber mais pode consultar Imagens, tabelas e discontinuidades misteriosas.

Como é que funcionam os float

Por favor lei-a estes dois artigos:

Conter floats Clearing fácil

Um layout a 3 colunas

<div id="coluna1">conteudo</div>
<div id="coluna2">conteudo</div>
<div id="coluna3">conteudo</div>

Flutuar a coluna1 e a coluna2 para a left e depois indicar a margem da coluna3 como a soma do total das colunas 1 e 2 obtendo um arranjo fixo/fixo/líquido. Se desejar obter um arranjo fixo líquido fixo, basta flutuar a coluna 1 para a esquerda a coluna 2 para a direita e depois indicar as margens esquerda e direita da coluna 3 com as larguras das colunas 1 e 2 respectivamente.

Ao usar id na identificação das colunas evito os problemas de especificidade que poderiam ocorrer e respeito a regra de quando um objecto é única numa página o devo especificar no código. Assim as coisas ficam mais claras. Ficamos a saber que não são itens recorrentes

Os nomes das colunas deviam ser mais intuitivos como por exemplo barra de navegação (sem os espaços e os assentos), conteúdo, destaque (desde que mais apropriados à função desempenhada).

Designing with Web Standards

Há dias em que se encontram verdadeiras pérolas (não estou a ter segundas intenções aqui). Não tinha ainda visto uma apresentação do Jeffrey Zeldman que acho que todos os responsáveis por criação de sítios na teia deviam ver Concepção com normas da Teia (tradução demasido livre de Designing with Web Standards)

Claro, conciso, preciso, correcto...

Toda razões para leitura (nem que seja rápida)

MIME

MIME tem as suas origens como extensão ao email e foi reutilizada no HTTP como meio de declaração de tipo de conteúdo (ou tipo de media) a ser servido. Cada recurso tem um tipo de MIME específico que é constituído por duas partes: o tipo principal e um subtipo, que são separados por um traço de fracção «/». O tipo MIME indica ao agente utilizador (quando recebe o documento) como o tratar em conformidade, permitindo assim associar uma aplicação específica ou um comportamento específico ao tipo de media em causa no seu navegador (ou melhor dizer agente utilizador).

Qual o tipo MIME em que deve ser servido o XHTML?

A resposta breve é application/xhtml+xml, como descrito na ">nota de tipos de media XHTML do W3C. A resposta contextualizada é um pouco mais complexa.

Porque não text/html?

A principal razão para usar um novo tipo de MIME para XHTML é esta ser uma linguagem XML o que significa que está sugeita a validação mais estrita e assim não tender para a sopa de marcação que muita gente chama HTML; assim, é razoável indicar a diferença aos navegadores de forma a serem capazes de tratar o código resultante de um modo mais eficiente.

O facto da XHTML ser baseada na XML involve ainda importantes diferenças sintáticas — a mais significativa das quais é que marcadores vazios como <br> que não é necessário ter fecho em HTML enquanto tal é obrigatório na XHTML ( como em <br> ). Estas alterações sintáticas são mais uma razão para distinguir entre HTML e XHTML e assim surge o tipo MIME diferente.

Mas alguns navegadores desconhecem application/xhtml+xml

De facto é assim, e é um dos maiores problemas actuais da adopção do novo tipo MIME, em especial porque o Internet Explorer não o reconhece (e não está previsto que o novo IE7 o faça). Isto é um problema normal com a adopção de novas tecnologias e normalmente é resolvido com o tempo. Contudo por agora há maneira de sair deste ciclo vicioso:

• O XHTML 1.0 define um modo de retrocompatibilidade que nos permite usar XHTML 1.0 mantendo compatibilidade com navegadores antigos ou retrogrados. Se seguir estas directrizes é-lhe permitido servir o seu XHTML como text/html. O modo de retrocompatibilidade define alguns truques sintáticos que permitem um documento XHTML ser compreendido pela maior parte dos navegadores HTML.
• Usar técnicas de negociação de conteúdo no seu servidor pode levar a servir de facto o seu XHTML 1.0 seja como text/html ou como application/xhtml+xml dependendo das capacidades do agente utilizador, de forma a manter retrocompatibilidade com navegadores antigos enquanto explora as capacidades dos modernos.

A primeira técnica torna o seu conteúdo compreensível pela maioria dos navegadores da web, mas ao fazê-lo perde todas as vantagens de ter um tipo de MIME diferente: o poder de ser tratado como XML, permitindo ao documento de ser distinguido da sopa de marcação, obtendo uma reprodução mais rápida em navegadores modernos.

A segunda técnica trata dos navegadores existentes enquanto mantém o novo tipo MIME para os que sejam capazes de o compreender; a desvantagem é poder ser difícil de implementar no seu servidor dependendo do acesso que tenha às suas configurações e parâmetros.

Alternativamente pode ser o seu XHTML (qualquer versão) como application/xml, ou mesmo como text/xml. Contudo, servir documentos XHTML como text/xml pode trazer problemas de conjuntos de caracteres devido às regras que são aplicadas a tipos MIME text/*serem mais complexas do que aquelas que são aplicadas a tipos application/*. É ainda importante assinalar que em quaisquer destes tipos MIME o Internet Explorer irá mostrar o código fonte em vez de os interpretar como XHTML.

Como é que instalo e configuro a negociação de conteúdos de que falamos acima?

Isso depende do servidor Web que usa e se é ou não o administrador do servidor onde deseja usar este tipo de negocioação. Aponte ao seu administrador de web server este documento e peça-lhe para agir de forma apropriada.

Se for o administrador do servidor em questão lei-a o artigo de técnicas associadas.

Ou seja como já aqui disse a escolha do tipo de documento não é tão simples como parece à primeira vista.

Em Resumo

Versão (X)HTML	Tipo MIME recomendado	Limitações em navegador	Tipo MIME alternativo	Técnicas
HTML 2.0,3.2,4.0,4.01	text/html	nada, mas este tipo MIME foi frequentemente abusado como chapéu de uma sopa de marcação	N/A	N/A
XHTML 1.0	application/xhtml+xml	Não reconhecido pelo Internet Explorer 6 e versões anteriores. Reconhecimento não previsto para IE7	Se estiver a usar directrizes de retrocompatibilidade, text/html application/xml (ou text/xml, mas com muito cuidado em relação ao parâmetro de conjunto de caracteres ( charset ))	directrizes de retrocompatibilidade (para uma tradução para português negociação de conteúdo entre text/html e application/xhtml+xml
XHTML 1.1, XHTML Basic, perfís XHTML	application/xhtml+xml	Não reconhecido pelo Internet Explorer 6.x e versões anteriores	application/xml (ou text/xml, mas cuidado em relação ao parâmetro de conjunto de caracteres ( charset ))	N/A

Squidoo

Finalmente posso falar disto Squidoo. É mais uma aplicação web onde perítos (nas palavras de Seth Godin todos somos perítos em algumas coisa) apresentam os seus conhecimentos e sítios sobre um tema. Eu experimentei só não gostei das limitações em relação à utilização de língua que não o inglês. Para quem quizer ver vá até: Coding Web.