Os artigos deste mês no A List Apart nº 226 são:
O artigo repescado é:
Gerir o seu conteúdo com PHP, de Christopher Robbins
Tenho que admitir que achei os artigos um pouco para o fraco, digamos antes básicos, cheios de senso comum em especial o primeiro.Parabéns ao Frederico Oliveira, Tiago Macedo e Pedro Freitas pelo melhor interface de utilizador do concurso Rails Daya.
Blogged with Flock
Aprende-se sempre algo de novo (mesmo com documentos e ideias que já cá andavam há algum tempo) quando se passeia pela web.
Hoje fui ver alguns textos de Dezembro de 2001 no css-d (o grupo do css para pessoas que desenvolvem sítios). Deparei-me com um memorando enviado por Eric A. Meyer que dizia que a partir dessa data iria modificar meyerweb.com de forma a que cada página incluísse a seguinte marcação:
<body id="www-meyerweb-com">
E onde ele explicava que o fazia de forma a que qualquer pessoas pudesse alterar o estilo do seu sítio bastando para isso adicionar as regras apropriadas à folha de estilo de utilizador. Ao usar selectores descendentes que começassem com o ID do sítio, os estilos seriam só aplicados às páginas do seu sítio. Ele exemplificava ainda com duas regras css:
#www-meyerweb-com {font: 1em Times, serif;}
#www-meyerweb-com * {font-family: Times, serif;}
Acrescentava ainda que se podia alterar cores, recolocar elementos e inclusivamente dizer que display: nome, tudo o que se quizesse. Remetia ainda para um artigo de Simon Willison ensaio beta privado do novo arquivo do css-discuss.
Contudo após uma visita à minha lista de favoritos, só encontrei 4 sítios que usem esta técnica, será que foi considerada inútil.
Interessante ver que já haja quem esteja a "traduzir" os termos legais da licença de utilização do Windows Vista explicando-os em termos comuns.
The number of school leavers is shrinking and the workforce is ageing. It is estimated that 60% of employees will be over 60 in 2045, when the average retirement age will be 77 for men and 72 for women.
Ao ver marcadas manifestações para hoje por causa do acordo sobre a reforma da segurança social não posso deixar de colocar aqui a citação em epígrafe. Que raio de matemática se estará a ensinar/se ensinou nas nossas escolas como é que se quer continuar a insistir na quadratura do círculo (e não me estou a referir ao programa da SIC).
Façam contas e vamos ver como é que se pode esperar pagar a segurança social se continuarmos a procriar tão pouco (ou importarmos mão de obra já treinada e de preferência jovem e já agora que não tenha filhos - isto é obviamente cínico) e a reformarmo-nos tão cedo.
Saiu mais um número do A List apart, os dois artigos do mês são:
O artigo repescado do mês foi o de Trenton Moss: O que é Acessibilidade da Web.
Partilha de apresentações/slides (transformando os seus slides de Powerpoint em Flash
Partilha e colaboração na elaboração de documentos e folhas de cálculo com a agregação em Google Docs & Spreadsheets (em beta) com possibilidade de gravação em diversos formatos Word, PDF, HTML, RTF e Open Document.
Os utilizadores do Opera não podem usar.
technorati tags:Google, Web2.0, Colaboração, Documento
Blogged with Flock
<< em vez de +Quando se pretende juntar duas expressões textuais (strings) em ruby, com a excepção de se querer criar uma terceira, é muito mais rápido usar o método << (unir) do que o método + (concatenar).
Subscritor.count em vez de Subscritor.find_all.size1 segundo contra 45 segundos
Ainda um projecto académico, concorrente ao mercado de máquinas virtuais como a CLR e a JVM.
Um quase guia de utilização do IRB no contexto do RoR. Neste mesmo site encontra outros mini-guias muito interessantes.
Notas sobre a RailsConf Europe 2006 de Graeme Mathieson.
Para quem goste do tema interpretação de línguas pode ser interessante dar um salto ao On Ruby.
Foi inserido ActiveSupport::MultiByte no Rails Core para suporte de internacionalização
Como facilitar a instalação da Rails On Ruby em Linux, Rails, Ruby, jEdit...
DeWitt Clinton tem vindo a falar sobre dois temas que podem vir a ter importância: a especificação de modelos de URL e OpenSearch
O Firefox lança o Release Candidate 2. Só usar por quem sabe...
Uma daquelas coisas que há pouco tempo não se acharia possivel fazer na web uma aplicação para fazer diagramas: Gliffy
Este documento é uma tradução da FAQ HTML and XHTML Frequently Answered Questions
Editor: Steven Pemberton, W3C/CWI
Data da versão: 21 Julho 2004
Outras FAQs relaccionadas:
Para comentar este documento ou enviar sugestões para pergunta, por favor enviar correio electrónico para www-html-editor@w3.org, e incluir a palavra FAQ no assunto.
O HTML é provavelmente a linguagem de marcação mais bem sucedida no mundo. Mas quando o XMl foi introduzido, foi organizado um workshop de dois dias onde foi discutido se uma nova versão de HTML em XML era ou não necessária. A opinião desse workshop foi um claro "Sim": com um HTML baseado em XML as outras linguagem XML poderiam incluir bocados em XHTML e os documentos XHTML poderiam incluir partes noutras linguagens de marcação. Poderiamos tirar partido da nova concepção para limpar algumas partes do HTML que necessitassem de lavagem, e adicionar alguma funcionalidade nova como melhores formulários..
Se o seu documento for XHTML 1.0 puro só (sem incluir partes noutras linguagens de marcação) então não irá notar muita diferença. Contudo à medida que mais ferramentas XML estão disponíveis, tais como XSLT para transformação de documentos irá começar a notar vantagens na utilização de XHTML. Por exemplo XForms irá permitir alterar documentos XHTML (ou qualquer outro tipo de documento XML) de modo simples e controlável. As aplicações da Web Semântica irão poder tirar partido dos documentos XHTML.
Se o seu documento é mais do que XHTML 1.0, por exemplo incluindo MathML, SMIL, ou SVG, então as vantagens são imediatas. Não é possível fazer esse tipo de coisas com o HTML.
Não. O HTML não é um formato XML. Tem que proceder às alterações necessárias para tornar o documento num documento XML correcto antes de o poder ver aceite como tal.
HTML Tidy dá-lhe a opção de transformar qualquer documento HTML num documento XHTML. Amaya é um navegador/editor que guarda documentos em HTML como documentos em XHTML.
É deliberado. Os navegadores HTML aceitam praticamente qualquer entrada, correcta ou incorrecta, e tentam fazer o que for mais adequado com ela. Esta correção de erros torna os navegadores muito difíceis de escrever em especial se se estiver à espera que se espere deles que se comportem de igual modo. Isto também significa que um grande número de documento HTML está incorrecto, porque como são correctamente apresentados num navegador o autor poderá não se aperceber de que os mesmos contenham erros. Isto torna incrivelmente difícil escrever novos agentes utilizadores para a web visto muitos documentos que reclamam ser escritos em HTML são muito pobres frequentemente.
Todos os navegadores sabem como tratar HTML correcto. Contudo se o HTML estiver errado o navegador tem que reparar o documento e visto nem todos os navegadores corrigirem um documento do mesmo modo, isto introduz diferenças, e assim o seu documento pode ser visto de forma diferente em diferentes navegadores. Como há centenas de navegadores diferentes, e estão a sair mais a todo o momento (não só para PC, mas para PDAs, telefones móveis, televisores, impressoras e mesmo figoríficos), é impossível testar o seu documento em todos os navegadores. Se usar HTML incorrecto no seu documento poderá suceder que não possa funcionar num navegador e então a falha é sua, se o seu HTML estiver correcto e não funcionar num determinado navegador então o erro é do navegador.
O W3C oferece um serviço em http://validator.w3.org/. O navegador/editor Amaya também verifica se a sua marcação é correcta.
embora os navegadores sejam importantes utilizadores de HTML e XHTML, há outros programas e sistemas que leem esses documentos. Os motores de busca por exemplo leem documentos mas não são navegadores. Ao usar o termo"agente utilizador" estamos a tentar lembrar as pessoas dessa diferença.
Por exemplo, quando usa o Google irá ver debaixo de alguns dos resultados da
busca algo como "Esta página usa frames, mas o seu navegador não os suporta." levando
a que algumas pessoas não cliquem nessa ligação. O autor do sítio web em questão não percebeu
que há mais do que navegadores, e que devem incluir algo melhor do que este simples texto
na secção <noframes>, de forma a não parecerem ideotas
a quem faz buscas pelo respectivo sítio.
Nos primórdios do HTML diferentes grupos e companhias adicionavam novos elementos e atributos ao HTML à vontade. Isto ameaçou provocar um caos de versões HTML não inter-operativas. XML (o X está no lugar de eXtensível) permite a qualquer pessoas usar elementos e elementos de difernetes linguagens, mas para que um navegador ou outro agente utilizador saiba onde cada elemento pertence a que linguagem é necessário dizer-lhe. As declarações de espaço de nomeação são só esse mecanismo.
XHTML é um formato XML; isto significa que falando estritamente deve ser enviado num tipo de media relativo a XML
(application/xhtml+xml,
application/xml, ou text/xml). Contudo o XHTML 1.0
foi concebido cuidadosamente de forma a também funcionar com agentes utilizadores HTML anteriores.
Se seguir algumas directrizes simples, pode fazer com que muitos documentos
XHTML 1.0 funcionem em navegadores antigos. Contudo esses navegadores só entendem o tipo de media
text/html, e assim tem que usar este tipo de media para enviar aos mesmos os documentos em XHTML 1.0.
Lembre-se contudo que enviar documentos XHTML aos navegadores como text/html significa
que esses documentos são vistos como documentos HTML e não como XHTML por esses navegadores.
Os navegadores conhecidos incluem todos os navegadores baseados em Mozilla
tal como o Netscape 5 e versão mais recente, Galeon e Firefox, assim como o Opera, Amaya, Camino,
Chimera, DocZilla, iCab, Safari, e todos os navegadores de telefones móveis que aceitem WAP2.
De facto qualquer navegador moderno. A maior parte aceita os documentos XHTML como
application/xml também. Ver os tipos de media XHTML
para detalhes.
Não. Contudo há um truque para permitir servir documentos XHTML1.0 ao Internet Explorer como application/xml.
Incluir no topo do documento a linha a negrito:
<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/xsl" href="copy.xsl"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
onde copy.xsl é um ficheiro que contém o seguinte:
<stylesheet version="1.0"
xmlns="http://www.w3.org/1999/XSL/Transform">
<template match="/">
<copy-of select="."/>
</template>
</stylesheet>
Note que este ficheiro deverá encontrar-se no mesmo sítio do que o documento que se lhe refere.
Embora esteja a server o documento como XML, e seja analisado como XML,
o navegador pensa que recebeu text/html, e assim o seu documento XHTML
1.0 tem que seguir algumas directrizes para servir navegadores antigos.
O seu XHTML irá continuar a funcionar nos navegadores que aceitem XHTML
1.0 como application/xml.
No. CSS rules that apply only to HTML, apply only to documents that are
delivered as text/html.
Não. Devido à maneira como o XML foi definido não é possível usar truques como este, esta marcação é gerada por programação dinâmica enquanto o analisador está ainda a analizar a marcação recebida.
Pode ainda alcançar os mesmos efeitos, mas terá que usar o DOM para adicionar ou apagar elementos.
XHTML 1.1 é XML puro, e só se pretendeu que fosse XML. Não pode ser enviado a navegadores antigos de forma fiável. Assim os documentos XHTML 1.1 têm que ser enviados com um tipo de media relativo a XML, tal como application/xhtml+xml.
Não foi. O XHTML 1.0 vem em três versões: strict, transitional, e
frameset. Todas foram mantidas deliberadamente tão proximas da
HTML 4.01 na medida em que o XML o permite. O XHTML 1.1
é uma versão actualizada da XHTML 1.0strict, e
nenhuma versão HTML strict teve um atributo
target. As outras duas versões, transitional e
frameset, não foram actualizadas visto não haver nada a actualizar. Se desejar
usar o atributo target use XHTML 1.0 transitional.
A modularização XHTML não se destina aos utilizadores normais de XHTML, mas a conceptores de linguagens baseadas em XHTML. Observou-se que companhias e grupos tinham uma tendência para conceber as suas próprias versões de HTML e XHTML que eram frequentemente não interoperacionais a níveis básicos. A modularização do XHTML reparte o XHTML numa número de módulos que podem ser individualmente seleccionados quando se define uma nova linguagem; desta forma uma qualquer linguagem baseada em XHTML que use tabelas garantidamente usa a mesma definição de tabelas e não uma versão divergente. A modularização torna também claro onde é aceitável adicionar novos elementos e onde tal não é razoável.
O HTML e o XHTML prestaram um bom serviço, mas há muias coisas que podem ser melhoradas. Áreas que receberam atenção particular incluem melhores possibilidades de estruturação, remoção de capacidades que estão duplicadas em XML, usabilidade, acessibilidade, internacionalização, independência de dispositivo, melhores formulários e reduzir necessidade de programação.
Não. <img> está a ser substituído em XHTML2 mas por outra coisa (
embora possa usar <object> se desejar).
A concepção de <img> levanta vários problemas em HTML:
alternativo. Este facto limitou a adopção de imagens
PNG, que em muitos casos são melhores do que as GIF e JPG, visto as pessoas terem
continuado a usar o formato denominador comum de forma a assegurar que todos
possam ver as imagens.alternativo não pode incluir marcação, e portanto se
usado só se obtém texto simples.longdesc com uma descrição
da imagem (ou sua finalidade), para ajudar pessoas que a não possam ver mas isso
raramente é feito.O que o XHTML2 diz é que todas as imagens são equivalentes a uma parte
do conteúdo, fá-lo ao permitir-lhe colocar um atributo src em todos
os elementos. O que isto significa é que se a imagem está disponível e o navegador a
puder processar, usá-la, caso contrário usar o conteúdo do elemento, por exemplo:
<p src="mapa.png">Sair da estação, voltar à esquerda e seguir em frente até à <strong>Rua Direita</strong>, aí voltar à direita</p>
A vantagem é a de que se a imagem não estiver disponível por qualquer razão (tal como falha de rede) ou o navegador não a puder reproduzir o documento continua a ser útil. Se desejar fornecer mais do que um tipo de imagem pode:
<p src="mapa.png"><span src="mapa.gif">Sair da estação...</span></p>
embora seja melhor usar negociação de conteúdos no caso do seu servidor o suportar (e a maior parte fá-lo):
<p src="mapa">Sair da estação...</p>
o que irá negociar com o navegador que tipo de imagens aceita e qual a preferida do navegador. Se não houver imagem disponível então o conteúdo do elemento será usado. Isto tem a vantagem adicional de pode adicionar outros tipos de imagens no seu servidor e não ter que alterar a página para que esta funcione.
XLink e XHTML têm requisitos diferentes para ligações e verificou-se serem irreconciliáveis.
É, mas de um modo diferente das anteriores versões de HTML serem retrocompatíveis.
Visto as primeiras versões de HTML serem linguagens de finalidade específica era
necessário assegurar um nível de retrocompatibilidade com novas versões de forma a que
os novos documentos podessem ser utilizáveis em navegadores antigos. Por exemplo
é por essa razão que o elemento <meta> tem o seu conteúdo num
atributo em vez de no conteúdo do elemento, porque nesse caso iria aparecer em navegadores
antigos.
Contudo graças ao XML e às folhas de estilo, tal retrocompatibilidade estrita ao nível do elemento deixou de ser necessária, visto um navegador baseado em XML, o que significa cerca de 95% dos navegadores em uso no momento de redação desta resposta, pode processar novas linguagens de marcação sem necessidade de ser actualizado. Muito do XHTML 2 funciona nos actuais navegadores, navegadires que não foram pré-programados para aceitar XHTML2. A maior parte funciona mas não tupo: quando os formulários e as tabelas foram adicionadas ao HTML as pessoas tiveram que esperar por novas versões de navegadores; de forma similar algumas partes do XHTML 2, tais como XForms e XML Events, ainda precisam que os agentes utilizadores compreendam essa funcionalidade.
O atributo xml:space trata-se de input: isto é, controla se os espaços irão estar presentes no DOM (isto é, se a versão interna do documento dentro do
navegador os inclui), nada diz de como irão surgir no ecrã. A saída de espaço em branco é controlada via a propriedade de CSS 'whitespace'.
Se a propriedade tiver o valor 'pre' os espaços irão ser preservados no DOM na saída se a propriedade tiver o valor de
'normal' o espaço em branco junta-se (o CSS3 irá ter mais propriedades para permitir um maior controlo).
Esta é a razão pela qual todos os elementos têm
xml:space="preserve" em XHTML2, caso contrário a propriedade CSS
'whitespace' não teria efeito e não teria controlo sobre o espaço em branco
visível. A folha de estilo por omissão irá tratar de dar o valor a
'whitespace' de 'normal' para todos os elementos com a excepção de
<pre>, mas será livre de os alterar.
A web para mim em 1995 era essencialmente um mundo para a palavra. Claro que já havia aqueles sítios que achavam indispensável bombardiar-nos com textos a piscar, a moverem-se e claro já havia muitas imagens. O sítio a que hoje me estou a referir é um sítio que leva a imagem a sério: The Radiant Vista.
The Radiant Vista é constituído por uma série de secções das quais desejava destacar a crítica diária onde são apresentadas e criticadas imagens em vídeos relativamente breves, à volta dos 5 minutos ou menos, o laboratório de photoshop onde são apresentadas técnicas para melhoria de imagens em laboratório digital, quatro secções dedicadas a recursos, podcast, Guias em Vídeo, Guias em PDF, Artigos e claro uma secção para Workshops de fotografia.
As secções que apelidei de recursos, vão desde temas apropriados para principiantes até artigos com profundidade para profissionais ou amadores muito sérios. Salvo a secção de guias PDF as restantes apoiam-se fortemente em screencast's.
Um dos assuntos que me tem levado a escrever é a aplicação de boas práticasna produção de sítios web. Em novembro de 2005 esbocei uma linhas sobre o assunto, tenho vindo a tocar no assunto algumas vezes. Eis mais uma:
É impossível infatizar isto de mais. Todos os sítios de ministérios que revi nos últimos dias são ou estão inválidos. Como é que é possível esperar que o CSS ou o Javascript baseado no DOM funcione de forma fiável com um códig (x)html inválido?. Conteúdo válido poderá evitar muitas horas de procura de erros em CSS ou DOM. Os que mais se aproximavam de um sítio válido eram os do ministério da justica com um erro ao incluir o erro div align="left" style="padding:0px" (não há atributo align) e o do ministério das finanças com o mesmo erro, repetido, de não efectuar o escape de um e comercial (&) nos comunicados à imprensa, em referências a URL, em quatro sítios na página inicial (existem nessa mesma página referências correctas). Não vou aqui fazer os comentários que pessoas mais abalizadas fazem quando vêem coisas destas.
Tantek diz que o erro das finanças também o atinge de tempos a tempos.
Tantek lista os erros mais comuns de validação.
<meta>sElly Thompson recentemente formada em Arquitectura (daquela em concreto) apresenta as suas teorias de similitude e dissemilhança entre a construção de um site na web e a construção de um edifício. Além disso dá a sua opinião cívica como por exemplo sobre a obrigação das mulheres se manterem saudáveis.
Dean Edwards explora o método forEach.
Rachel Andrew em junho apresenta as suas ideias sobre selecção de técnicas CSS quando estamos a desenvolver projectos para os quais existe mais do que uma técnica para obtenção do mesmo resultado final. Em particular chama a atenção para aquilo que temos de ter em conta por exemplo quando necessitamos de libertar elementos flutuados (clear). O método recomendado por ela é mesmo o de adicionar a div suplementar, sem significado semântico, que tem como alternativa usar truques de CSS só para a evitar.
Roger Johansson revisitou a construção de pseudo-frames em css.
Richard Rutter continua a sua coleção de artigos sobre tipografia para a web, com base nos Elementos de Estilo Tipográfico de Robert Bringhurst. Uma delícia para os olhos.
No blogue da SimpleBits aparece um texto Educated onde se fala de um curso universitário da Universidade de Boston onde os novos métodos de produção de web sites são enfatizados. Quando Há pouco tempo estive a ver os trabalhos de alunos de mestrado da Universidade Nova de Lisboa fiquei estarrecido pois todos usavam essa maravilhosa técnica de produzirem sítios com ... FrontPage ... o que é que acham da diferença.
Drew McLellan diz-nos por onde tem passado nos últimos tempos, o Barcamp de Londres e o d.Construct que começa na próxima semana. Fala ainda de ferramentas para microformatos que anda a conceber.
Em 5 de Outubro de 2005 efectuei uma primeira abordagem à utilização de web standards em Portugal, tendo-me focado na imprensa na altura. Até hoje tanto quanto me é dado a ver passou a haver mais dois sites com declaração de tipo de documento só que continuam a não honrar o que aí dizem (só lá está para inglês ver, como se dizia quando eu era pequeno.)
Esses dois sítios são:
DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd".technorati tags:Web_standards, Portugal
Blogged with Flock
Na Caixas e Setas de 23 de agosto, Shiv Singh apresenta as suas ideias sobre a aplicação em ambiente empresarial dos aspectos humanos da Web 2.0, no mesmo número da Boxes and Arrows é apresentado o desenvolvimento do design do sítio da Volkswagen da África do Sul.
Na entrada de 30/07/2006 do arkitrave.log é apresentado código CSS para estilizar uma lista de pares nome valores (listas de definições) onde o nome (chave) e o descritivo são apresentados um ao lado do outro. O método aqui apresentado permite ser usado com o IE.
Ara Pehlivanian no seu artigo Semântica - necessitamos mesmo dela apresenta as suas dúvidas sobre se por vezes não somos excessivamente levados pelos aspectos técnicas das tecnologias que aplicamos na web.
O excelente informatian aesthetics - form follows data - data visualization & visual design hoje, 5 de setembro mostra como é que o 11 de setembro afectou o número de passageiros a bordo de aviões. De facto chama a atenção para um artigo da BBC.
No User Interface Engineering Joshua Porter apresentou em Abril de 2006 um artigo sobre Folksonomies Uma maneira de organizar conteúdos orientada pelo utilizador.
Vanderwal apresenta um artigo sobre nomes de URL mais humanos e também com mais significado para motores de busca ou escavadores de dados (scrappers). O artigo chama-seO Domínio do Design Digital Inclui Cadeias de Caracteres.
O número de agosto de 2006 do JUS - Journal of usavility studies apresenta 1 artigo sobre o Dia Mundial da Usabilidade, assinado por Elizabeth Rosenweig (artigo convidado) e 3 artigos revistos:
Os artigos estão disponíveis em sumários e na sua totalidade. A maior parte dos artigos trata de assuntos ligados a aspectos multiculturais e internacionais. Não esquecer que a periodicidade desta publicação é de cerca de 3 meses.
Croco[Lyle] participou num podcast em conjunto com jared spool. A transcrição desse podcast está presente na User Interface Engineering. Quem ler este artigo deverá ler também o artigo do Ivo Gomes sobre prototipagem em papel.
RawDiz-nos que Chris Messina (um dos autores do Flock) escreveu uma carta aberta ao Blogger para que ele venha a introduzir maior suporte a microformatos no maior motor de blogues. Já agora eu também estou o o chris.
technorati tags:IA, Usabilidade, usability
Blogged with Flock
Barcamp - Coimbra de 2 e 3 de Setembro, com um alinhamento muito interessante que inclui a gente da WeBrakeStuff.
A lei [PDF]46/2006 publicada em 28 de Agosto de 2006 proíbe e pune a discriminação em razão da deficiência. Entra em vigor, hoje, com um pequeno defeito, o governo terá (nos termos da lei) que regulamentar a lei nos próximos 120 dias.
Temo que estes 120 dias se transformem em algo como o da regulamentação da lei sobre protecção dos animais. (Publicação em 1995 ou 6 não tenho a certeza e ainda por regulamentar.)
A página de entrada da Faculdade de Belas Artes da Universidade do Porto está conforme a recomendação XHTML 1.0 (Transitional).
No caso de querer ser mesmo picuinhas (muito mesmo) poderiamos dizer que:
Não sei se esta página tenderá a ser eliminada ou não devido à integração no site da UP de todas as faculdades sistema Sigarra.
O site acima parece-me não ter sido feito para nenhum público alvo sendo demasiado frio (tal como os sites que se apresentam no Sigarra).
Em resumo uma página cujo código é bom mas que parece não tender a resolver nenhum problema para ninguém.
Outras entradas de blogue recomendo (não se referem a código mas a AI (arquitectura de informação, usabilidade, ...) dos sítios do Sigarra:
P.S.: As páginas do Sigarra são compatíveis com HTML 4.01.
Alex Bradbury desenvolveu Ariel, uma biblioteca que usa exemplos pré-definidos para compreender como extrair informação de outros documentos. É um projecto do Google Summer of Code Project e foi mencionado por Austin Ziegler em Londres.
Também do Código de Verão de 2006 vem um relato de Jason Morrison sobre o seu projecto de inferência de tipo para usar na RDT para completar código.
Luke e Dan criaram um suplemento ujs4rails para a RoR para produção de sites com javascript não obstrutivo.
Com javascript não obstrutivo quero dizer algo como aquilo que é dito no número 218 do ala por Jeremy Keith que nele publicou um artigo designado por Separação de comportamento no qual apresenta uma analogia entre separação de estilo e separação de comportamento para páginas na web, para explicar porque é que se deve separar o javascript das nossas páginas.
No caso de desejar conhecer um pouco mais sobre isto recomendo ainda o artigo do Christian Heilman Unobtrusive Javascript.
Scott Laird em como avaliar percas de memória em Rails diz-nos que:
Um dos meus problemas mais antigos com a Rails (e a Ruby em geral) é que é difícil depurar as percas de memória. Tive um certo número de casos onde coloquei algo num array ou num hash e descobri muito mais tarde que o meu processo Ruby estava a comer mais de 100 MB de RAM. Embora o ps torne fácil ver onde o Ruby está a usar muita RAM, descobrir para onde é que foi é muito mais difícil.
O criador do Mongrel foi entrevistado por Pratik Naik .
Neste artigo do Hiveminds Magazine explica-se passo a passo o que fazer quando se quer abstrair a camada de ligação a uma base de dados em ruby.
Um guia básico sobre como usar REST em Rails. No mesmo sítio há umas notas sobre o que de importante Erik Kastner, o autor, aprendeu na RailsConf e RailsDay.
O texto e os comentários são importantes para ficarmos com uma melhor visão do assunto.
Um artrigo interessante para quem deseja saber o que e como usar CSS nas suas mensagens de correio electrónico:
Neste artigo David Greiner apresenta resultados de uma investigação sobre o comportamento dos clientes de correio electrónico baseados em PC/MAC ou na Web.
Blogged with Flock
height, background em elementos table. Ausência de atributo type em elemento script, valor de atributo que não faz parte do conjunto de valores admissíveis para esse atributo género absbottom em align. Não inclusam do atributo alt em imagens ((> 30) embora tenha que admitir que são espaçadores) na generalidade dos casos. Ignorância de como usar o atributo nowrap, etc, etc, etc. A página seria considerada noutras paragens como sendo feita de forma amadora.
alt e 1 uso de absmiddle como atributo de align. O tempo necessário para corrigir isto seria de quantos segundos? Embora a solução mais correcta tecnicamente esteja numa forma de construir a página diferente.
type obrigatório num elemento script e uso de atributos em body que foram substituídos por outros meios (deprecated) e uso do atributo hight em table. Tempo para corrigir isto algus minutos?
body. Restantes erros ver compta
body. Uso de atributos já substituídos.Fecho de marcadores não abertos, uso de elementos onde já não é possível usá-los (elementos que pertencem à head a surgirem dentro do body. Alguns erros introduzidos por tornar certas linhas comentários. Ignorância quanto à forma de codificar de forma válida um ficheiro flash.
scroll no marcador de body. Um não membro de um objecto VIEWASTEXT normalmente gerado pelo VS em desenvolvimento.
Em resumo nenhuma das páginas das empresas de tecnologias e internet registadas na bolsa valida. Algumas com pouco esforço poderiam validar. Mas algumas teriam que ser repensadas (não digo em termos de conteúdos ou aspecto) em termos de código.
Uma coisa de me deixa perplexo é a falta de separação efectiva entre o que é conteúdo, aspecto e comportamento nestas páginas mas a falta de profissionalismo (dos respectivos conceptores) é manifesta.
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.
O colapso das margens é um conceito simples mas que pode gerar
alguns problemas quando não estamos atentos. Os maiores problemas
surgem quando aparece espaço vertical em branco adicional que parece
não querer desaparecer ou o outro problema parace ser a incapacidade de
criar espaço em branco na vertical usando o atributo margens
(margin) de alguma caixa (de algum elemento com
comportamento de caixa).
O que sucede é que quando duas margens verticais estão uma em contacto com a outra, em vez de se adicionarem uma à outra, a margem maior toma a precedência e a outra "colapsa" no nada.
Se der uma margem de 20px a dois parágrafos consecutivos (como elementos de um documento html) a margem do topo do parágrafo de baixo, visto tocar na margem do parágrafo de cima, cai e assim o espaço entre os dois parágrafos mantém-se nos 20px em vez de somar 40px.
A maior parte das pessoas pensar que o colapso de margens sucede quando um elemento do nível de bloco (um elemento com comportamento de caixa) se sucede a outro. Contudo as margens entram em colapso quando uma margem entra em contacto com uma margem adjacente. Isto significa que as margens podem entrar em colapso quando um elemento está contido noutro.
Isto sucede por exemplo quando se coloca um parágrafo (p) dentro de uma divisão (div), ambos com margens verticais. Se a divisão tiver uma borda (border) as margens não se tocam e somam-se, caso contrário juntam-se uma à outra tomando a precedência a mais larga.
Para evitar colapsos é vulgar adicionar-se uma borda de 1px de forma a que as margens já não se toquem e portanto já não colapsem.
Outro método é mudar a propriedade da posição (position) do elemento. As especificações CSS2(en) [pt] explicam que margens de caixas posicionais absolutamente e relativamente não colapsam. Outra possibilidade ainda é fazer flutuar uma das caixas. Nem sempre é apropriado alterar as propriedades de posição de um elemento, mas em certas circunstâncias quando estiver a ter problemas de colapso de margens poderá ser uma opção.
Há ainda a possibilidade da margem de topo de um elemento estar em contacto com a margem de fundo do mesmo elemento por exemplo um parágrafo vazio e nesse caso poderá suceder que o espaço ocupado pelo parágrafo desapareça de todo.
Pode ainda haver a situação mais complicada de ter elementos flutuados, seguidos de elementos limpos com uma margem de topo pouco mais alta do que o elemento flutuado e ter que se perceber muito bem o que é que se deve à flutuação de um elemento e o que se deve à pequena diferença de alturas entre o primeiro elemento e a margem de topo do segundo elemento (esperando que nenhum esteja completamente vazio).
Nesta especificação, a expressão colapso de margens significa que margens adjacentes (sem esquadria ou borda a separá-las) de duas ou mais caixas (que podem estar uma a seguir à outra ou aninhadas) combinam-se para formarem uma só margem.
Em CSS2, as margens horizontais nunca colapsam.
As margens verticais podem colapsar entre certas caixas:
Por favor consultar os exemplos de margens, esquadrias e bordas para uma ilustração de margens colapsadas.
O RadRails é um IDE para desenvolvimento de aplicações usando Ruby on Rails (RoR). Há cerca de 2 semanas foi actualizado para a versão 0.7. Esta versão trás como características novas capacidades de integração contínua, integração com tarefas rake, modelos de código RHTML, além de correção de erros (e provavelmente alguns novos). Já se sabe que o quem o desenvolve deseja minimizar as diferenças entre um IDE e o ambiente de caracteres, para minimizar essas diferenças podemos iniciar ou parar o servidor web, executar os nossos geradores, aceder à base de dados, instalar a maior parte dos suplementos de rails e executar as tarefas de rake
Rails Plugin Directory é um repositório de suplementos (plugin) para aplicações web desenvolvidas em Ruby on Rails (RoR).
Não se esqueça que os suplementos rails podem ser usados fora do IDE.
Que coisa estranha um jornal generalista a falar de um aspecto tão obscuro como é a tipografia, Georgia ganha na Web
Se quizer ler o artigo completo no Herald Tribune iht.com/articles/2006/0...
Uma das coisas que me assusta é continuar-se a assistir à recriação de sítios de diversos organismos públicos que praticamente não servem para nada para além de repositórios de informação.
Veja-se por exemplo que a Câmara Municipal de Torres Vedras acaba de lançar o seu novo sítio na Web em www.cm-tvedras.pt .
O site foi concebido com técnicas standard (uma raridade na web portuguesa pelo que devo dar os parabéns à Slingshot), mas não me interessa só a roupagem (mesmo que só a interior ou seja o código) mas o conteúdo. E este parece-me parco. Será assim tão interessante saber a identificação dos vereadores ou poder efectuar interacção com os serviços do munícipio. Porque é que quando a câmara decidiu partir para um redesenhar da sua presença na net não observou o que de melhor se pratica cá e lá fora e tentou abrir o leque de serviços que se podem usar. Francamente parece-me um desperdício de recursos.
Para mim este sítio tem ainda o defeito de ter um número excessivo de ligações na sua página inícial: 74.
No entanto volto a dizer bom trabalho para quem criou o código, trabalho abaixo do que espero hoje para quem concebeu a arquitectura de informação do sítio por ser excessivamente pobre.
Por exemplo na secção «VISITAR» não há nada noutra língua que não o Português algo que não consigo comentar sem umas fortes palavras impublicáveis...
Subidas de Portugal no Ranking de Disponibilização Completa Online de Serviços Públicos, de Out. 2004 para Abr. 2006: • De 15º para 11º nos 28 países da UE25 + Noruega, Islândia e Suiça, • De 13º para 10º na UE25, • De 11º para 7º na UE15...Eu até dou de barato que há mais serviços disponíveis em linha por cá o que eu desconfio é da respectiva qualidade. Só encontrei um portal do cidadão declaradamente pior que o nosso o austriaco. Para poder aferir por si eis uma tabela de resumo da situação.
| País | endereço, não liga | erros html | obs. |
| Portugal | www.portaldocidadão.pt | HTML 4.01 c/ 74 erros | trata da acessibilidade como se estivesse em 1998 |
| Espanha | www.060.es | XHTML 1.0 Transitional (valida) | tenta a conformidade com WCAG WAI-AA |
| Itália | www.italia.gov.it | HTML 4.01, WAI-A, CSS | |
| Reino Unido | direct.gov.uk | HTML 4.01 (valida) | tenta a conformidade com WCAG WAI-AA |
| Áustria | www.buergerportal.at | s/ declaração doctype | está ao nível amador, muito pior que o nosso |
| Alemanha | www.buergerportal.de | XHTML c/ 2 erros xml:lang e lang com valores nulos (deviam ser de), WAI-AA, CSS, secção 508 | a conformidade com WAI-AA não é completamente conseguida |
| França | www.internet.gouv.fr | XHTML 1.0 Transitional | ao nível do alemão embora não ande para aí a pavoniar-se |
| Bélgica | www.belgium.be | HTML 4.01 | com o mesmo tipo de erros que o nosso |
Na sequência da minha entrada de ontem só hoje fui
à fonte e vi isto wiki.rubyonrails.com/ra...
Isto é absolutamente essencial. A Rails torna a escrita de testes unitários e testes funcionais muito simples e assim é praticamente obrigatório usar testes para validar aquilo que se irá programar. Devem ser empregues tanto testes positivos como testes negativos: primeiro verificar que a aplicação faz o que deve fazer quando são passadas as variáveis adequadas para a acção correcta e depois verificar se passando variáveis incorrectas se passa a ocorrer o comportamento preferido.
Como regra geral, os testes unitários devem testar todas as validações nos modelos assim como quaisquer métodos adiccionados a esses modelos.
Por exemplo, se tiver um modelo Utilizador que valide a presença do nome e do apelido (validates_presence_of...) nos respectivos campos e que tenha um método nomecompleto que combina os dois, é provável encontrarem-se os seguintes casos de teste: test_validates_nomes e test_nomecompleto, que irá testar o modelo para se poder verificar se funciona de acordo com o previsto.
Os testes funcionais são usados para testar controladores. Como regra, deve haver, pelo menos, um caso de teste por cada acção sendo necessário empregar também aqui os testes pela positiva e pela negativa. Isto significa que se tivermos uma acção create no nosso controlador de entradas PostsController deve haver pelo menos os métodos test_create e test_bad_create nos testes funcionais que efectuam os testes pela positiva e pela negativa. Isto não significa que devam haver só dois testes por cada acção. No caso de haver casos excepcionais para além de um simples bom ou mau, um teste adequado implica cobrir também esses casos.
As migrações significam nunca se arrepender de destruir completamente a sua base de dados. Permitem criar esquemas de bases de dados que são agnósticas quanto aos sistema de gestão de bases de dados específico, o que significa que pode desenvolver a sua aplicação localmente com SQLite e depois distribuir a sua aplicação com MySQL sem problema. São mais limpas (e mais fáceis) de escrever do que os seus esquemas à medida e devem ser sempre que possíveis usadas.
NUNCA, NUNCA, NUNCA por nunca alterar o ficheiro schema.rb pois é uma reflexão da sua base de dados. As migrações devem ser usadas para fazer a evolução. Se não usar as migrações e em seu lugar alterar o schema.rb as coisas passaram a ficar pouco estáveis e os seus utilizadores (e clientes) ficaram deveras pouco satizfeitos.
Nota: Deve sempre executar um svn update antes de gerar uma migração de modo a não ter que efectuar prefixos em colisões.
SQLite é um motor de SQL que corre num único ficheiro em vez de num servidor. É normalmente tão rápido quando o MySQL e torna-se assim uma ferramente excelente para teste e desenvolvimento. De facto com a possibilidade de executar uma base de dados directamente e completamente da memória (uma pequena base de dados excepto se tiver muita memória RAM disponível) os testes são acelerados de forma significativa. Com o aparecimento das migrações, faz todo o sentido usar o SQL para teste pois não há trabalho adicional para a instalação da sua aplicação num ambiente MySQL.
A principal ideia da DRY (seca) é a de que se o código se repete é extraído para um ajudante (helper) ou uma função, assim passa a ter só um lugar para ver (e alterar se for caso disso) se algo correr mal. Se encontrar código similar em vários lugares poderá querer ler atentamente esse código e extraí-lo para uma função ou um parcial.
Não use abreviaturas, em especial nos nomes das colunas de uma tabela. Deve ser óbvio qual o conteúdo de uma coluna (pelo menos qual o significado do nome) quando se lê o respectivo nome. além disso o sistema de erros da Rails sabe como humanizar os nomes das colunas, quando usar um nome que descreva bem o conteúdo de uma coluna será mais fácil a apresentação de erros.
Se os nomes forem demasiado compridos, pense noutra expressão (palavra ou frase) com o mesmo significado, mas que seja óbvia.
Deve ser usado algum modo de controlo de versões de forma contínua. Isto permite voltar atrás de forma fácil se algo correr mal, assim como a possibilidade de nos referir-mos a código antigo se necessário. A Rails tem alguns ficheiros que não devem ser incluidos no repositório central de fontes (gosto mais da palavra originais mas estou em minoria) e assim deve consultar esta página do wiki sobre preparação da importação inicial.
Já foram escritos vários módulos para autenticação para Rails, alguns são melhores que os outros.
script/plugin, é fácil de ampliar e pode tratar de todos os aspectos dos restantes módulos de autenticação. Além disso o código de teste é excelente o que o torna fácil de alterarlogin_generator é o gem gerador de login original desenvolvido por Tobias Luetke. A desvantagem é que se surgir um erro que danifica a palavra de passe se gravar um utilizador já existente. Não deve ser usado por esta razão. Foi substituído e ultrapassado por acts_as_authenticatedlogin_generator. É excessivo e difícil de alterar. Deve ser evitado.SaltedHashLoginGenerator e como tal tem as suas desvantagens. Além disso usa o sistema de Rails Engines que deve ser evitado pois está quase a ser descontinuado. Se necessitar mais do que de uma pequena alteração deve ser evitado.Os andaimes podem ser uma forma de poupar tempo ou um verdadeiro aborrecimento. Quando os usar assegure-se de que compreende exactamente o que é que o código está a fazer e porquê. Uma fez alcançado tal pode tornar-se mais fácil e rápido escrever o seu próprio código pois é frequente ter que se alterar cada uma das secções que o scaffolding nos oferece.
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
Web 1.0 – a web como parque fechado
Web 1.5 – Sistemas de Gestão de Conteúdos(Content Management Systems)
Troca de informação “por baixo da superfície”
Os utilizadores são jardineiros
Standards: Fim da LEI da selva
Standards, desenvolvimento não específico de um navegador
Separação de conteúdo, design e comportamento
AJAX e interfaces de utilizador ricos
Assinada por:
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.
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.
[[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”.]]
[[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.]]
[[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.]]
[[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 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.]]
[[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.]]
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.
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.
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:
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.
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!
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.
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.
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:
Não há bom material em sueco. Os livros seguintes em inglês são normativos:
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.
Mensagens
