Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)

Mostrar mensagens com a etiqueta Web Standards. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Web Standards. Mostrar todas as mensagens

15 maio, 2008

Google Doctype

A Google acaba de disponibilizar sob licença Creative Commons uma quantidade de informação sobre construção de websites usando tecnologias normalizadas: a google doctype. O código disponibilizado sê-lo-á sob uma licença BSD liberal. Os artigos podem ser editados por quem tenha uma conta google.

28 outubro, 2007

Flosse - Web Standards em Portugal

A Flosse é uma nova associação para a promoção do software livre (isto não é a sua denominação jurídica exacta) mas coitados a sua página inicial necessita de levar um redesenho aquilo não é feito é horrível. Mas eu não sou especialista nessa área pelo que não vou aqui dizer mais nada sobre o assunto. Passemos à carne (há umas imagens do arame farpado que caberiam aqui só não as ligo pois acho que seria uma má ligação), desculpem ao código.

Numa página simples não sei como foram cometidos tantos erros. Comecemos pelo primeiro a página indica que é um documento XHTML, depois nas linhas com expressões <link estas não são terminadas com um simples traço de fracção:

Está lá:

<link rel="SHORTCUT ICON" href="icon7.ico">

Em vez de:

<link rel="SHORTCUT ICON" href="icon7.ico" />

Há dois erros, iguais, de seguida.

Depois temos um expressão script sem estar no head nem no body:


</head>
<script src="lib_columns.js">
</script>

<body>

Mas o maior erro deste script é não dizer de que type é. Claro que isto leva depois ao surgimento de erros a dizer que não devem ali figurar uma série de tags. Outro erro é no uso de br sem o fechar devidamente (algo obrigatório no xhtml). Finalmente no destaque há ainda a falta de fecho do parágrafo. Com isso seriam eliminados vários erros.

Falta claro na expressão html qual o idioma em que a página está escrita. Um atributo xml:lang="pt".

Realmente agora fazia-me falta aquilo que tenho vindo a adiar mas está por uns dias o surgimento do cafonso num espaço com maior controlo por parte de mim.

19 julho, 2007

3 sítios conformes as WCAG 1.0 A

A nomensa foi contratada pelas Nações Unidas para efectuar uma auditoria de acessibilidade Web a nível mundial. Nessa auditoria foram, passe o pleonasmo, auditados 100 sítios em 20 países e todos apresentavam inconformidades em relação às WCAG 1.0 embora 3 (governos) passassem o nível básico de verificação.

Os sítios analizados incluiam as seguintes áreas:

  • Companhias aéreas,
  • bancos,
  • imprensa,
  • política e
  • lojas

14 março, 2007

Um Outro Olhar Sobre Validação

Tradução do artigo Another Way to Look at Validation de Aaron Gustafson para o WaSP em Março de 2007

O debate sobre validação já ocorre há muito tempo, com argumentos irados de ambos os lados. No artigo de Ethan Where Our Standards Went Wrong essa discussão é reduzida a duas opiniões contrastantes.

  1. Toma a linha dura, afirmando correctamente de que se falharmos ao seguirmos as convenções de uma linguagens, então produzimos algo totalmente diferente e bem, inválido.
  2. Tem uma visão pragmática, afirmando correctamente que a geração de código inválido devido a ferramentas com erros ou código de terceiros com erros não nega o comprometimento geral de cada um com os web standards.

Depois ele pergunta "Se as duas visões são correctas, onde é que isso nos deixa?" e diz-nos que estamos num impasse.

Mais tarde no artigo, Ethan [Marcotte na A List Apart] discute modos de «vender» os standards. Faz notar por exemplo que se podem usar balas mais «sexys».

  • ciclos de desenvolvimento mais curtos
  • custos de manutenção mais baratos, e
  • peso descrecente das páginas.

Mas também lamenta as nossas falhar na venda de outras vantagens tais como:

  • acessibilidade acrescida
  • independência de dispositivo, e
  • capacidade de tornar o seu sítio à prova de futuras evoluções

O que me leva de volta à validação e de como devemos de facto usá-la para vender standards.

Ao olhar para trás no ano passado, Ethan nota que cerca de 15% do seu tempo foi gasto a contornar código inválido. Com essa descoberta conclui que os sítios "[i]nválidos podem parecer-se com os construídos com uma fundação válida, código bem formado, mas que na minha experiência invariavelmente o custo para o manter é mais elevado." Isso pode parecer óbvio para si, mas ele argumenta que não é normalmente uma característica que se venda aos nossos clientes como parte do pacote dos standards.

Quando se está a orçamentar um projecto para um cliente ou quando se discute os standards com eles, quais são as vantagens que realça? Porquê?

Seguem-se alguns dos comentários:

  1. Rick Curran diz:

    Penso que os dois pontos indicados como falhas que ele menciona são pontos importantes para a venda [dos standards]:

    • acessibilidade acrescida
    • a possibilidade de tornar o sítio à prova de futuro

    Sei que muitos clientes não se preocupam com estas coisas por acharem não terem consequências, mas trata-se realmente de tomar algum tempo para tentar e ajudá-los a compreenderem as vantagens. Tornar à prova de futuro um sítio ao torná-lo mais fácil para se adaptar a novo design mais tarde deve equivaler a uma poupança a longo prazo.

    A acessibilidade é por vezes difícil de vendas para o "homem comum" mas está a tornar-se um ponto a realçar. É aqui que o aspecto da "independência de dispositivo" (que considero parte da acessibilidade) de codificar em conformidade com um standard vale a pena para evitar ter que criar 2 versões separadas de um sítio. Novamente persuadir o homem comum das vantagens pode ser difícil.

  2. Robert respondeu:

    Não é difícil escrever código válido. É difícil levar os clientes a escreverem código válido.

    Quando codifica os seus modelos para um CMS, torne-os válidos. Se o cliente acrescentar código inválido, não há nada que se possa esperar que possa fazer. Se vendo a alguém uma arma para caça e ele assalta uma loja, não se pode esperar que eu o prenda. Se for um programador de fundo com muitos recursos, tudo o que o cliente introduza poderá ser corrido através do HTML Tidy antes de o acrescentar à base de dados. Isto pelo menos reduz a potencialidade de o seu cliente bater no 711.

    Como eu disse várias vezes, o XHTML tem o seu lugar. O HTML desculpa mais. Num sítio sobre o qual não tenha controlo sobre aquilo que um utilizador introduz é mais provável que as páginas em HTML continuem a validar. Usar HTML em vez de XHTML não significa que não está a usar Web Standards. Aplique os mesmos standards estritos aos seu código HTML como faria com o XHTML e deixe o seu cliente fazer o que ele irá fazer com o CMS.

    Se a página acabar por não validar devido àquilo que o cliente inseriu não é nada que você tenha feito como designer. Não é um erro seu; o seu comprometimento com os standards foi alcançado quando o sítio limpinho que carregou foi válido. O web design comercial não tem problemas com a validação. O conteúdo gerado pelo cliente tem problemas com a validação. Usar ferramentas para clientes, gráficas, do género do XStandards em conjunto com o HTML Tidy irão ajudar a tornar a coisa mais fácil. Alguma formação simples sobre marcação (ou a utilização de uma marcação alternativa, tal como a Markdown) pode ajudar ainda mais.

    A única outra alternativa é fazer as actualizações você mesmo para se assegurar que o sítio continua a validar. Contudo julgo que isto não é necessário. A situação não é assim tão aborrecida. As ferramentas de que dispomos podem fazer o trabalho.

  3. Peter respondeu:

    Não há nada de inerentemente errado com ter elevados ideais, mas por vezes esses ideais são irrealizáveis ou difícieis de realizar em desenvolvimento web na prática.

    O desenvolvimento baseado em standards pode promover as qualidades de perfeição, desejabilidade e excelência para o benefício de todas as partes.

    Como pessoas envolvidas no desenvolvimento, não devemos ter receio a aspirar a oferecer xhtml completamente válido por meio de ferramentas que designamos para serem o nosso CMS.

    Mas a realidade prática é a de alguém com (relativamente) pouco conhecimento, corta e cola a partir de um processador de texto para o nosso modelo válido em XHTML e a não utiliza ferramentas apropriadas para estruturar o documento antes de o publicar.

    Os Web Standards estão a tornar-se mais visíveis fora da redoma dos blogues das pessoas que produzem sítios e de sítios excelentes como este.

    A publicação na web está a mudar e os web standards estão a começar a fazer uma diferença como comunidade, cabe-nos tornar algo anteriormente idealista numa realidade pragmática.

  4. Martin diz:

    A aproximação pragmática vende sempre pois é "fazível".

    Se estamos a mudar-nos para uma visão idealista para assegurar que as páginas web sejam 100% código válido, temos que ter algumas ajudas de todos os lados tais como das ferramentas de autoria de web, cms, etc...