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

29 dezembro, 2005

ALA 209

Dia 19 saiu o A List Apart209.
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?».

24 dezembro, 2005

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 />

22 dezembro, 2005

Í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).

21 dezembro, 2005

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.

19 dezembro, 2005

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 é, "&amp;"). 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&amp;;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 &apos; (o apóstrofe, U+0027) foi introduzido no XML 1.0 mas não aparece no HTML. Os autores devem assim usar o &#39; em vez de &apos; 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...

16 dezembro, 2005

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).

15 dezembro, 2005

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)

14 dezembro, 2005

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 ))
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

12 dezembro, 2005

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.

10 dezembro, 2005

RoR 3

Correspondência Automatizada

Active Record efectua automaticamente a correspondência entre tabelas e classes, linhas a objectos (exemplos das classes modelos), e colunas para atributos de objectos. Por exemplo:


class Produto < ActiveRecord::Base
end

é feita corresponder de forma automática à tabela designada produtos, tal como:


CREATE TABLE produtos (
  id int(11) NOT NULL auto_increment,
  name varchar(255),
  PRIMARY KEY (id)
);

que cria também automaticamente um atributo name que pode usar como em:


meu_produto = Produto.find(:first)
STDOUT.print meu_produto.name
meu_produto.name = "Novo Nome do Produto"

Active Record usa regras de formação de plurais em inglês para efectuar a correspondência entre classes e tabelas. O nome da classe modelo fica no singular e com letra maíscula inicial, enquanto o nome da tabela é plural e com letras minúsculas. Exemplos disto incluem:

  • Uma classe modelo de Factura corresponde a uma tabela de facturas.
  • Uma classe modelo Person corresponde à tabela people que é o respectivo plural.
  • Uma classe modelo Country faz-se corresponder a uma tabela countries.
  • Uma class modelo NivelSeguranca corresponde a uma tabela nivel_segurancas.

A convenção singular/plural resulta em código (que em inglês) se lê de forma relativamente normal. Note que a correspondência é inteligente no uso das regras de formação de plurar em inglês. Note-se ainda que os nomes das classes usam maísculas (CamelCase) para separar palavras (o que é uma convenção Ruby), enquanto os nomes das tabelas são na sua totalidade em minúculas e têm traços de sublinhado entre as palavras.

Nos casos em que isto não funciona (tais como quando se faz um interface com bases de dados antigas onde não se tem controlo dos nomes), pode explicitamente dizer ao Active Record que nomes deve usar.

A documentação de ActiveRecord::Base explica com mais detalhe a correspondência automátoca de Active Record.

Associações

Nenhuma tabela fica sozinha. Bem, não é habitual que tal suceda. A maior parte das aplicações de base de dados usam várias tabelas com relações específicas entre essas tabelas. Pode dizer ao Active Record que relações existem e o Active Record irá geral um conjunto de métodos de navegação que tornam fácil ao seu código aceder a dados relacionados. Os modelos seguintes:


class Firma < ActiveRecord::Base
  has_many   :clientes
  has_one    :conta
  belongs_to :grupo
end

permite-lhe escrever código como este:


minha_firma = Firma.find(:last)
STDOUT.print minha_firma.conta.name
STDOUT.print minha_firma.grupo.empregado_contador
for c in minha_firma.clientes
  STDOUT.print "Cliente: " + c.name + "\n"
end

Este código irá trabalhar correctamente quando a base de dados tiver tabelas de clientes e contas, onde cada uma tiver uma coluna name e um tabela grupos que tem uma coluna empregado_contador.

A documentação ActiveRecord::Associations explica com mais detalhe as associações.

Validação

Visto não desejar só guardar uma coisa velha na sua base de dados, irá querer validar os seus dados antes de os guardar. O Active Record contem um conjunto de validadores semelhantes a macros que pode adicionar ao seu modelo.


class Conta < ActiveRecord::Base
  validates_presence_of     :subdominio, :name, :endereco_email, :palavra_de_passe
  validates_uniqueness_of   :subdominio
  validates_acceptance_of   :condicoes_de_servico, :on => :create
  validates_confirmation_of :palavra_de_passe, :endereco_email, :on => :create
end

Se as macros integradas de validação não poderem fazer o que necessita pode sempre escrever os seus métodos de validação próprios.


class Pessoa < ActiveRecord::Base
  protected
    def validate
      errors.add_on_empty %w( nome_proprio, nome_familia )
      errors.add("numero_telefone", "tem formato invalido") unless numero_telefone =~ /[0-9]*/
    end

    def validate_on_create # só é executado da primeira vez que um objecto é guardado
      unless valid_discount?(desconto_socio)
        errors.add("desconto_socio", "expirou")
      end
    end

    def validate_on_update
      errors.add_to_base("Não ocorreram alterações") if unchanged_attributes?
    end
end


pessoa = Pessoa.new("nome_proprio" => "David", "numero_telefone" => "o quê?")
pessoa.save                         # => falso (e não grava)
pessoa.errors.empty?                # => false
pessoa.contador                        # => 2
pessoa.errors.on "nome_familia"        # => "não pode ser vazio"
pessoa.errors.on "numero_telefone"     # => "tem formato inválido"
pessoa.each_full { |msg| puts msg } # => "O apelido não pode ser vazio\n" +
                                            "Número de telefone em formato inválido"
pessoa.attributes = { "nome_familia" => "Afonso", "numero_telefone" => "555-555" }
pessoa.save # => true (e pessoa é agora guardado na base de dados)

Se existir um método validate a RoR irá chamá-lo imediatamente antes de escrever um objecto na base de dados. Se a validação falhar ele não escreve o objecto na base de dados. validate_on_create e validate_on_update são similares, excepto que o primeiro é chamado antes de RoR criar um novo registo na base de dados enquanto o seguinte é chamada quando RoR está praticamente a actualizar um registo existente.

Pode validar um atributo específico só quando uma determinada condição seja verdadeira.


# São possíveis validações condicionais tais como:
  validates_numericality_of :rendimento,   :if => :empregado?
  validates_confirmation_of :palavra_de_passe, :if => :nova_palavra_de_passe?

# Usar blocos
  validates_presence_of :nome_do_utilizador, :if => Proc.new { |utilizador| utilizador.assinalar_entrada > 1 }

A documentação ActiveRecord::Validations explica a validação com mais detalhe.

Continua...

Aprender Ruby na rede (básico)

Querem experimentar a linguagem de programação Ruby na Web então passem por este hobby.

A Ruby é a linguagem de programação na base da Ruby On Rails.

Divirta-se.

24 maneiras de impressionar as suas amigas e amigos

  1. Em Imagens de Fundo CSS. Porreiras ou Malandrecas?Derek Featherstone avalia a diferença entre gráficos decorativos ou informativos e como melhor efectuar uma aproximação aos mesmos em relação à sua acessibilidade. Tenha a certeza saber o que está a fazer da próxima vez que decidir sobre este assunto.

  2. Em Tabelas com estilo distintivoJonathan Snook investiga a combinação de todos os elementos de tabelas com o CSS para criar uma tabela de dados mais atractiva.

  3. Em Introduzindo UDASSSDustin Diaz introduz uma técnica para comutação de folhas de estilo do lado do servidor sem recarregar a página. Usando Ajax, o Comutador de Folhas de Estilo Ajax não Obstrutivo e Degradável de Forma Aceitável combina a conveniência de um comutador do lado do cliente com a robustez do processamento de um servidor.

  4. Em Evitar truques CSS para Internet ExplorerKimberly Blessing examina alguns dos truques comuns para passar regras CSS específicas para o desafiante estilisticamente falando Internet Explorer. Com a próxima chegada do IE7, os truques que não sejam revistos podem provocar problemas. Assim sendo acompanhe-nos.

  5. Em Z não está morto e enterrado Andy Clarke passa o espanador na propriedade CSS z-index para tomar o controlo da profundidade dos seus elementos posicionados. Porque não experimentar você mesmo e ver como é que se empilha tudo.

  6. Em Splintered StriperPatrick H. Lauke cria uma pequena função em JavaScript útil para ajudar a despir (olha umas listas tão bonitas) as suas tabelas, listas, casa de banho, indique você mesmo o quê. E estava você à espera de que a única coisa para despir que ia obter no Natal era uma nova camisola.

  7. Em Cantos Maiores Patrick Griffiths experimenta com um método directo a adição de cantos redondos a uma caixa baseado em CSS. Toda a gente adora cantos redondos e assim sendo se isto não o entusiasmar nada o fará.

  8. Em Transitional vs. Strict Markup Roger Johansson re-edita um dos seus artigos sobre html ou xhtml transitivo ou estrito, indicando as diferenças básicas entre estes. Os comentários parecem tirados a papel químico daquilo que já se sabe.

  9. Em Introdução aos efeitos scriptaculous - Michael Heilemann brinca com a biblioteca em JavaScript de efeitos chamada Script.aculo.us para demonstrar como é fácil juntar efeitos poderosos que podem melhorar a interactividade das páginas web.

  10. O selector de atributo para Graça e (sem lucro de anúncio)

    Andy Budd estuda um selector de atributo CSS relativamente maligno e vê como pode ser usado produtivamente mesmo que com um suporte incompleto por parte de navegadores (leia-se IE principalmente). Aproveita ainda para falar de microformatos (Votelinks) e folhas de estilo de utilizador. Muito interessante.

  11. Drew McLellan complementa o artigo de Ethan sobre separadores (como elementos de navegação) indicando como não depender de componentes activos do lado do servidor para determinar qual o separador activo.
  12. Molly E. Holzschlag apresenta um artigo que nos trás pistas sobre internacionalização e localização de sítios da Web;
  13. Ethan Marcotte apresenta um artigo sobre separadores (badanas) centradas baseadas em listas para navegação;
  14. Simon Willison apresenta um artigo sobre os cuidados na utilização da função eval() em JavaScript, o seu estilo de código responsável;
  15. Drew McLellan apresenta um artigo sobre o microformato hCard em a sua riqueza semântica.;
  16. Jeremy Keith apresenta um artigo sobre melhores citações;
  17. Rachel Andrew apresenta uma forma de desenvolvimento fiável e rápido de CSS nas suas técnicas rápidas de desenvolvimento de CSS;
  18. Ian Lloyd fala-nos da melhoria da acessibilidade de um formulário usando adequadamente Scripting do DOM;
  19. Richard Rutter fala-nos de uma unidade de medida pouco compreendida o "em" no seu artigo Um pouco de fineza tipográfica;
  20. Drew McLellan Diz-nos que não há nada tão pequeno que possa impressionar na web hoje que não seja um toque de Ajax apropriado no seu artigo Ajax fácil com "Prototype".

08 dezembro, 2005

RoR 2

Esta é a segunda parte do artigo: RoR

Componentes RoR

A RoR consiste ela própria em vários componentes, que pode instalar e usar em separado. Contudo foram concebidos para trabalhar em conjunto de forma integrada e normalmente os programadores usam-nos em conjunto.

  • O Active Record é a camada de correspondência entre objectos e base de dados relacional (ORM) que liga os objectos de negócio (modelos) a tabelas de base de dados. É uma implementação do padrão Active Record descrito por Martin Fowler.

  • O Action Pack é o componente que implementa as partes de vista e controlador numa arquitectura MVC. A parte "controlador" trata os pedidos chegados do navegador do utilizador e dirige os pedidos para o método correcto numa classe de controlo. A parte "vista" constrói uma resposta e envia-a de volta, ao navegador, usando um sistema de modelos similar ao do ASP ou do JSP.
  • O Prototype é o componente que implementa o Ajax, arrastar e largar, e outros efeitos visuais nas suas páginas web.
  • O Action Mailer é o componente que trata de enviar e receber correio electrónico.
  • O Action Web Service é o componente que torna fácil a adição de API de serviços web à sua aplicação web. O Action Web Service suporta SOAP, XML-RPC, e WSDL.

Características Gerais

A RoR tem algumas características gerais e algumas específicas.

Servidores de web

A RoR pode funcionar praticamente com qualquer servidor web que implemente CGI. Contudo, a performance do CGI é má e assim sendo o modo de distribuição de uma aplicação RoR é usando FastCGI. Houve um ensaio extenso de distribuição de aplicações RoR tanto com Apache como com LightTPD. Há ainda a entrada em cena recente do SCGI, com uma performance semelhante à do FastCGI sem a complicação da instalação.

Durante o desenvolvimento é normalmente mais fácil usar o Servidor Web WEBrick que está incluído na Ruby.

Bases de dados

A RoR actualmente contem suporte para as seguintes bases de dados:

Para implementar um adaptador de base de dados em Ruby leva-se cerca de 100 linhas, assim adicionar adaptadores a esta lista não é particularmente oneroso.

Depuração

Quando algo corre mal dentro de uma aplicação web baseada em RoR, obtem-se uma mensagem de erro muito detalhada no seu navegador (quando a mesma é executada em modo desenvolvimento). Normalmente estas mensagens de erro são suficientes para diagnosticar o problema. Quando tal não se passa tem outras opções. Por exemplo:

  • Inserir informação no controlador como em:

    render_text "Cheguei aqui"

    ou

    render_text "objecto de utilizador =" + obj_utilizador
  • Verificar os ficheiros de registo da RoR. Ver os ficheiros developemnt.log, production.log e fastcgi.crash.log.

    Lembrar-se de também observar os ficheiros de registo do servidor web.

  • Usar pontos de paragem.

  • Usar um IDE comercial (como o ArachnoRuby com um depurador integrado).

URL simpáticos

A correspondência entre URL e acções de controlo são muito simples e fáceis de compreender. A RoR tenta apresentar ao utilizador URL simpáticos. Os URL da RoR são simples e directos, não sendo nem longos nem parecendo cifrados.

Mesmo assim pode alterá-los usando as capacidades de encaminhamento da RoR. O encaminhamento de URL da RoR é suficientemente flexível para permitir criar virtualmente qualquer esquema de correspondência de URL.

A capacidade de encaminhamento da RoR é obtida com código Ruby puro permitindo o uso de expressões regulares. Visto a RoR não usar a capacidade de encaminhamento do servidor Web (como o mod_rewrite em Apache), as correspondências de URL por nós definidas funcionam em qualquer servidor de web, da mesma forma.

Teste Unitário

A RoR facilita activamente os testes unitários:

  • A geração de novos controladores, modelos e a construção de andaimes cria os esqueletos dos testes unitários;
  • correspondentes.

  • A arquitectura estritamente MVC tende a naturalmente resultar em acções e componentes que se possam testar;
  • A RoR inclui um script Rake (Ruby Make) que automaticamente executará todos os testes unitários.

Para mais detalhes pode ler Um guia de testes com RoR.

Active Record

Active Record é a parte da RoR que trata da correspondência automática entre tabelas de bases de dados e os objectos dos modelos no momento de execução. É o M em MVC e é a implementação da camada ORM em RoR.

Para todos os casos de uso mais corrente (e alguns não tão correntes como isso), não irá necessitar de usar SQL quando aceder ou actualizar a sua base de dados. O objectivo do Activo Record é especificamente trabalhar com bases de dados relacionais. Não tenta abstrair o uso do SQL. O Active Record torna fácil usar o seu SQL à medida para aqueles casos em que seja necessário. Mesmo que tal seja raramente necessário.

Continua...

display: table

A forma mais fácil de imitar a apresentação tabular é ...adivinhou... usar uma tabela. Já os estou a ouvir gritar. Mas se lhes disser que pode alcançar a mesma apresentação usando a propriedade display com valores tais como table, table-cell e table-row?

Infelizmente os navegadores da Microsoft (tanto no Windows como no Mac) não sabem aplicar estes valores. Trataremos deles mais tarde.

Vejamos então a marcação:


<div id="menu">
    <ul>
        <li>
            <a href="...">item 1</a>
        </li>
        <!-- outros itens da lista -->
    </ul>
</div>

Navegadores modernos

Pense nisto como uma tabela: a div actua como o elemento table, ul como o elemento tr e os elementos li como células (td):

Então o CSS seria algo como:


#menu {
    display: table;
}

ul {
    display: table-row;
}

li {
    display: table-cell;
}
   

Agora poderá adicionar algumas width e outros estilos e eis que está pronto.


#menu {
    width: 100%;
    display: table;
}

#menu ul {
    margin: 0; padding: 0;
    width: 100%;
    display: table-row; /* MS diz WTH */
    background: #ccc;
    vertical-align: middle;
}

#menu li {
    margin: 0; padding: 0;
    display: table-cell; /* Novamente, IE não
                      compreende este valor */
    text-align: center;
    vertical-align: middle;
    background: #ddd;
    border: 1px solid #ccc;
}

* html #menu li { /* MacIE */
    display: inline-block;
    width: 14%; /* um erro de espaço em branco? 
                 100 por cento a dividir por 7 
                 itens arredondado */
}

/* O truque do IE (escondido do MacIE) \*/
* html #menu li {
    display: inline;
    width: 14.2%;
}
/* */

#menu li a {
    display: block;
    width: 100%;
    vertical-align: middle;
    text-decoration: none;
    color: #008;
}

#menu li a:hover {
    background: #eee;
    color: #900;
}


07 dezembro, 2005

HTML ou xhtml?

Embora pessoas como eu tenham aprendido HTML (há 10 aninhos) e esteja a aprender (na minha opinião) a usar convenientemente o xhtml, julgo, que para quem se esteja a iniciar agora no desenvolvimento de web pode aprender uma ou outra desde que a aprenda bem.

O xhtml é mais exigente para quem o cria e para quem o gere no dia-a-dia. Exige mais cuidado e quase que diria que só deve ser usado se podermos controlar (de algum modo mesmo que indirecto) a forma como o mesmo é servido a visitantes das nossas páginas.

Caso contrário podemos abrir uma caixa da pandora de problemas.

A curva de aprendizagem do HTML poderá não ser tão grande (mas algo que devemos incutir em quem aprende que aprender bem exige esforço e dedicação), mas devemos quase implorar para que quem esteja a aprender não nos peça que indiquemos exemplos de páginas bem escritas quer em HTML quer em XHTML, salvo honrosas excepções já aqui anteriormente indicadas.

Estou a fazer um estudo sobre o tipo de erros encontrados em sítios portugueses. São muito poucos, aqueles que encontrei escritos de forma não só a validarem com os programas automáticos de validação mais habituais, mas que além disso, na marcação tirem partido da mesma para transmitirem a verdadeira estrutura do respectivo conteúdo.

Voltando à questão inicial usar/aprender/ensinar HTML ou XHTML mas com o cuidado de o fazer bem é o que é importante, tanto quanto julgo.

RoR 1

Ruby on Rails (RoR) é uma infraestrutura de aplicações para a web escrita em Ruby, uma linguagem de programação com tipos dinâmicos similar à Python, Smalltalk e Perl.

Acaba de passar há pouco tempo um ano desde o aparecimento da RoR em 25 de Julho de 2004. Num intervalo de tempo muito curto progrediu de uma versão 0.5 impressionante até a uma versão 1.0 lançada à pouco tempo que manteve a facilidade de uso e a alta produtividade enquanto adicionava algumas capacidades novas. Este artigo introduz os componentes desta nova versão e explica o bru-a-a que anda à volta desta infraestrutura.

Não pretendo explicar como usar a RoR para escrever aplicações para a Web. Para isso deve começar com: Rolling with Ruby on Rails. Este artigo é uma introdução e roteiro às características da RoR.

Alta produtividade e tempo reduzido de desenvolvimento

Ao nível das capacidades RoR não nos trás nada de novo. Já várias infraestruturas para aplicações para a web o fizeram. Então o que é realmente novo na Ror? O que é que esta infraestrutura trás de diferente. Quando pode acabar aplicações simples em dias em vez de semanas e aplicações mais complicadas em semanas em vez de meses as pessoas começam a notar.

O novo amor teria vida curta se as aplicações web resultantes fossem uma salgalhada e difíceis de manter e ampliar. Felizmente a RoR facilita as boas práticas de programação, o que leva a código fácil de manter e bem factorizado.

A atenção seria também de vida curta se a RoR não tivesse profundidade - isto é, se uma vez experimentada para além das aplicações web mais simples, tivessemos encontrado uma barreira, e nos fosse impossível avançar devido a limitações inerentes. Programadores experimentados que sabem o que fazer na Web repetidamente relataram que não é esse o caso da RoR. Por exemplo James Duncan Davidson recentemente disse:

A RoR é a infraestrutura de desenvolvimento para web mais bem concebida. Digo isto após 10 anos de construção de infraestruturas, ajudei a desenvolver a Servlet API e criei alguns servidores web de raíz. Ninguém o tinha feito desta forma anteriormente. Não estou a dizer que tudo está bem. Não é "perfeita". Tenho alguns detalhes com que não concordo sobre como as coisas devem ser juntas. Mas a "perfeição" não é o ponto. O ponto é que nos põe rapidamente a ser produtivos e tem profundidade suficiente para continuar. A RoR faz isso muito bem.

É difícil acreditar que isto é possível sem desvantagens significativas. Felizmente não tem que julgar a minha palavra (ou a de outra pessoa). Pode provar a sí mesmo num dia ou menos percorrendo um tutorial de RoR e desenvolver uma aplicação simples à sua escolha. Ver para crer! No caso de não se desejar ver espantosamente produtivo, pode ver alguém a fazê-lo vendo o vídeo sobre Ror.

Como é que a RoR o faz?

Como uma boa receita, RoR ajuda a alcançar um novo nível de produtividade combinando os ingredientes correctos nas quantidades correctas. Eis alguns dos ingredientes mais importantes que tornam a RoR naquilo que é:

  1. Ruby

    Muito do poder da RoR advém da linguagem de programação Ruby. A concepção única da Ruby torna fácil criar linguagens específicas de um domínio e fazer metaprogramação. A RoR tira total partido disso.

  2. Infraestrutura MVC completa

    A RoR é uma infraestrutura MVC (modelo, vista, controlador) onde a RoR fornece todas as camadas e funcionam de forma integrada. Outras infraestruturas normalmente só implementam parte da solução, exigindo que o programador integre várias infraestruturas na aplicação e então obrigar as mesmas a funcionarem em conjunto (por exemplo um programador Java poderá usar Hibernate, Struts e Tiles para obter suporte MVC completo.)

  3. Convenção sobrepõe-se a configuração

    Convenção sobrepor-se a configuração significa o fim de ficheiros de configuração XML muito extensos, uma aplicação RoR usa algumas convenções de programação relativamente simples que permitem determinar tudo através de reflexão e descoberta. Por exemplo, RoR usa reflexão inteligente para automaticamente mapear tabelas de bases de dados a objectos Ruby. O seu código de aplicação e a sua base de dados já têm tudo o que a RoR necessita de saber.

  4. Menos código

    Seguindo as convenções simples da RoR faz mais do que eliminar os ficheiros de configuração. Significa também que a RoR pode automaticamente tratar de uma grande quantidade de detalhes de baixo nível sem ter de lhe dizer nada sobre isso. Isto significa escrever menos linhas de código para implementar a sua aplicação. Manter o seu código pequeno significa desenvolvimento mais rápido, menos erros e tornar o código mais fácil de compreender, manter e melhorar.

  5. Geradores

    O uso pela RoR da reflexão de tempo de execução e da metaprogramação elimina muito do código de corta e cola que de outro modo teria que criar. Pode frequentemente evitar o código do tipo corta e cola usando o gerador de scripts integrado para o fazer por si. Isto deixa-lhe mais tempo para se concentrar no código que realmente interessa - a lógica do seu negócio.

  6. Ciclo de desenvolvimento curto

    O ciclo típico de desenvolvimento para teste de uma alteração numa aplicação web tem passos como configurar, compilar, instalar, reiniciar e testar. Isto leva a consumir muito tempo. O ambiente de desenvolvimento RoR não tem nada disto. Nós fazemos uma alteração e vê-mos o seu funcionamento. Não faço o erro de julgar que isto é um ponto menor. É difícil de dizer quanto é que isto melhorar a produtividade e o ajuda a manter um fluxo criativo ininterrupto.

  7. Andaimes

    A RoR pode criar automaticamente um conjunto completo de operações CRUD (Criar, recuperar, actualizar e apagar) e vistas de qualquer tabela de base de dados. Estes andaimes permitem-lhe começar rapidamente com a manipulação das suas tabelas de bases de dados. Ao longo do tempo pode substituir as operações CRUD geradas e as vistas com o seu próprio código - presumivelmente muito mais bonito e funcional.

Continua...

06 dezembro, 2005

Descrição: Define como é que o espaço em branco é tratado.

Sintaxe: white-space: valor;

Define como é que o espaço em branco será tratado


  white-space : normal;

O espaço em branco será tratado como normal


white-space : pre;

O espaço em branco será tratado como no elemento


  white-space : nowrap;

O elemento não volta atrás nas quebras de linha normais.

Exemplos:


<p style="white-space : pre;">

Isto só se usa para espaços nada mais.


<p style="white-space : nowrap;">

Esta linha não volta atrás e irá forçar o navegador a colocar uma barra de rolamento em baixo se não tiver espaço para a apresentar na totalidade.

Notas:

  • normal age como um navegador típico: qualquer sequência de caracteres de espaço em branco é reduzido a um caracter.
  • pre age como um elemento pre
  • nowrap evita a quebra de linha.

05 dezembro, 2005

hasLayout

Sumários

Muitas das inconsistências na reprodução pelo Internet Explorer podem ser corrigidas dando a um elemento "layout". John Gallant e Holly Bergevin classificaram estas inconsistências como "erros dimensionais" querendo dizer que podem ser frequentemente resolvidos aplicando uma largura ou uma altura ao elemento. Isto leva a pergunta de porque é que o "layout" pode alterar a reprodução e as relações entre elementos. A questão, embora uma boa questão, é de difícil resposta.

Definição de hasLayout

"Layout" é um conceito proprietário do IEWin que determina como é que os elementos, em analogia com uma janela, desenham e limitam o seu conteúdo, interagindo com e relativamente a outros elementos e reagem ou transmitem eventos da aplicação/utilizador.

Os programadores da Microsoft decidiram que os elementos do tipo caixa devem ser capazes de adquirir uma propriedade (no sentido de programação orientada a objectos) a que se referem como layout, ou em alternativa, hasLayout.

hasLayout provavelmente não é nem uma propriedade nem mesmo um comportamento mas talvez um conceito de engenharia inerente à reprodução que dá uma qualidade a um elemento.

Esta qualidade de reprodução pode, de facto, ser irreversivelmente despoletada para tomar o valor true por algumas propriedades CSS e alguns elementos têm «layout» por omissão.

Nomenclatura

Dizemos que um elemento "tem layout" ou "ganha layout" quando presumimos que a propriedade da Microsoft hasLayout toma o valor true. Um elemento com layout pode ser qualquer elemento que tenha layout por omissão ou que tenha ganho layout pelo estabelecimento de propriedade CSS apropriada.

Elementos sem layout, onde hasLayout não tenha sido despoletada, por exemplo div sem dimensões podem ser ancestrais sem layout.

Dar um aplicar layout a um elemento que por omissão não o tem envolve estabelecer uma propriedade CSS que despolete hasLayout = true ao elemento em questão. Não há maneira de despoletar hasLayout = false a não ser apagar a propriedade CSS que tenha causado o inverso.

Introdução

O problema hasLayout afecta os web designer e os codificadores com todos os níveis de experiência. O Layout tem efeitos inabituais e difíceis de prever sobre o comportamento da reprodução de caixas que têm layout, assim como as implicações para os elementos seus descendentes dentro dessas caixas.

As consequência que podem resultar de um elemento ter ou não layout podem incluir:

  • Muitos erros habituais em elementos flutuantes no IE;
  • As caixas tratarem cercas propriedades básicas de forma diferente;
  • Colapso das margens entre um contentor e os seus descendentes;
  • Diferenças no posicionamento de imagens de fundo;
  • Diferenças entre navegadores quando se usa scripting.

Esta lista está incompleta.

De onde é que vem o layout

Ao contrário de propriedades padronizadas, ou mesmo de propriedades CSS proprietárias disponíveis nos diversos navegadores o layout não é directamente atribuível via declaração CSS. Por outras palavras, não há propriedade layout. Alguns elementos automaticamente têm layout e é adicionado de forma invisível quando certas declarações CSS são feitas.

Elementos com layout por omissão

Os elementos seguintes parecem ter layout

  • <table>
  • <td>
  • <body>
  • <img>
  • <hr>
  • <input>, <select>, <textarea>, <button>
  • <iframe>,
  • <embed>, <object>, <applet>
  • <marquee>

Propriedades

Os seguintes pares propriedade CSS/valor se aplicados permitem que um elemento ganhe layout

position: absolute
Refer-se ao seu bloco contentor e é aqui que começam alguns problemas.
float: left ou float:right
O elemento flutuante tem diversos detalhes devido a algunas aspectos de um elemento com layout
display: inline-block
Por vezes a cura quando um elemento é de nível em linha e necessita de layout. Aplicar layout é provavelmente o único efeito real desta propriedade. O comportamento de bloco em linha pode ser alcançado de forma independente: IEWin: bloco em linha e tem layout.
width: qq valor
Isto normalmente é uma correcção implícita, frequetemente o gatilho quando hasLayout gera erros.
height: qq valor
Por exemplo usado no Holly Hack.
zoom: qq valor
Proprietária da MS, não valida. zoom: 1 pode ser usado em depuração.
writing-mode: tb-rl
Proprietária da MS, não valida.

Notas sobre elemento ao nível em linha

Para elementos em linha (sejam elementos em linha por omissão como span seja elementos com a regra CSS display: inline:

  • width e height despoletam hasLayout no IE5+ só em modo quirks. No IE6 em modo standard os elementos em linha ignoram as propriedades width e heigth e indicar uma largura ou altura para estes elementos não despoletará a propriedade hasLayout.
  • zoom irá sempre despoletar hasLayout mas não está disponível em IE5.

Elementos que tenham layout (por omissão) e display:inline comportam-se como indicado nos standards: fluem horizontalmente como palavras num parágrafo, são sensíveis ao alinhamento vertical e aplicam uma forma de envelope ao seu conteúdo. Assim que os elementos em linha tenham layout, agem como bloco em linha, e isto explica porque é que no IEWin os elementos em linha podem conter elementos de nível bloco com mesmo problemas que noutros navegadores, onde display:inline se mantem em linha.

01 dezembro, 2005

xml:lang e lang

Contexto

Por vezes os documentos contêm ou incluem conteúdo com línguas diferentes. Por vezes é necessário armazenar um valor de língua natural como dado ou metadado sobre algo externo ao documento. Devido a estas diferentes aplicações usarem formatos similares, os conceptores de esquemas por vezes confundem a utilização admissível de xml:lang e quando devem definir os seus próprios elementos/atributos relativos a línguas.

Por exemplo em XHTML 1.0 há um atributo hreflang no elemento e também um xml:lang (ou atributo lang, no caso do HTML 4.0) para o conteúdo de um elemento a:

<a xml:lang="pt" href="xyz" hreflang="de">
   Carregar aqui para versão alemã</a>

O atributo xml:lang descreve uma língua contida pelo elemento a ("Carregar aqui para versão alemã"), enquanto o atributo hreflang é metadado, neste caso descrevendo a língua de um conteúdo externo a esta página web.

Resposta

Quando usar xml:lang

Conteúdo directamente associado ao documento xml (seja contido dentro do documento directamente seja considerado parte de um documento quando processado ou reproduzido) deve usar o atributo xml:lang para indicar a língua desse conteúdo. xml:lang deve ser reservado a autores de conteúdo para etiquetarem directamente qualquer conteúdo em língua natural que tenham.

xml:lang é definido pelo xml 1.0 como um atributo comum que pode ser usado para indicar a língua de qualquer conteúdo de um elemento. Isto inclui texto legível por humanos assim como outro conteúdo (tais como os objectos embebidos, imagens ou ficheiros de som), contidos por um elemento no qual apareça. O valor xml:lang é aplicado a cada um dos sub-elementos contidos pelo elemento. Também se aplica a valores de atributos associados com o elemento e sub-elementos (embora usar língua natural num atributo não seja uma boa prática). O valor de um atributo xml:lang é um dos possíveis indicados no RFC 3066 ou um dos seus sucessores.

Eis um exemplo de xml:lang num elemento t:


   <t xml:lang="pt"> 
   Isto é texto contido num elemento 't'. O uso do atributo
   xml:lang indica que a língua, que por exemplo um corrector 
   ortográfico deve aplicar quando estiver a efectuar uma
   revisão do documento é Português. Se não o indicarmos
   podemos ter problemas se tivermos conteúdo embebido 
   noutra língua como na frase <span xml:lang="fr">
   C'est la vie</span>, que está em francês.
   </t>

Este exemplo mostra a aplicação de xml:lang a um atributo:


 <para>Il faut utiliser 
 <abbr title="Simple Object Access Protocol" xml:lang="en">
 SOAP</abbr></para>

Quando usar o seu próprio elemento ou atributo

Quando o valor da língua é realmente um atributo de ou metadado sobre algum conteúdo externo, então xml:lang não e uma escolha apropriada. Nestes casos deseja guardar informação sobre língua, mas a língua não se refer ao conteúdo do documento xml (ou conteúdo incluído, tal como imagens, que são processadas como parte do documento) directamente. Neste caso deve definir um elemento ou atributo com um nome diferente e não usar o atributo xml:lang. O valor do elemento ou atributo deve usar o RFC 3066, tal como xml:lang.

Alguns exemplos disto podem incluir:

  • Um elemento num documento xml descrevendo a sua colecção de DVD's para indicar em que línguas se encontras as canções;
  • Um elemento de uma base de dados de clientes com um campo para a língua preferida do cliente;
  • Um atributo de um elemento de ligação (tal como o a no xhtml) apontando para uma versão do documento noutra língua.

A razão pela qual optar por criar o seu próprio elemento (ou atributo) é comunicar a língua como um valor (ou parte de uma estrutura de dados ou como metadados sobre um documento externo) em vez de indicar a língua de uma peça específica de conteúdo. Evitar usar xml:lang para descrever valores externos de língua evita criar problemas a autores de conteúdos que necessitem de etiquetar conteúdo com finalidades relativas a processamento de texto.

Por exemplo um documento xml poderá ter o seguinte aspecto:


 <item type="DVD"> 
  <title xml:lang="fr">Cyrano de Bergerac</title>    
  <!-- indic a língua em que o filme se encontra -->
  <duracao value="137" />                        
  <!-- não afectado pela língua -->
  <dialogue>en</dialogue>                            
  <!-- indic a língua do diálogo -->
  <legendas pista="1" lingua="zh-Hant" />         
  <!-- Esta pista contém legendas em chinês tradicional -->
  <legendas pista="2" lingua="zh-Hans" /> 
 </item>

Neste exemoplo o atributo xml:lang comunica informação sobre a língua natural do texto que aparece neste documento. O elemento diálogo e o atributo língua dos elementos legendas são definidos no esquema do documento xml e comunicam um valor de língua natural associado a estes itens. Por exemplo comunica a informação de que as legendas na pista número 1 são escritas ou mostradas em chinês tradicional.

A propósito

É importante lembrar que xml:lang tem âmbito de validade: os elementos de nível inferior herdam o atributo. Isto pode servir para identificar a língua de muito conteúdo (sem ter marcadores de língua redundantes em cada elemento). Por exemplo, é boa prática colocar xml:lang no elemento html no início do documento xhtml e só o voltar a usar quando a língua mudar. Para mais informação ver o artigo: Marcadores de Língua em HTML e XML.

Recursos adicionais

Técnicas de autoria para internacionalização de xhtml e html: Especificação de língua de conteúdo 1.0

Artigos Interessantes

  1. Conceber Aplicações com Interface Complexo com Visio de Bill Scott explica como conceber um interface de utilizador para uma aplicação da internet usando uma ferramenta (extensão) produzida para o Visio pelo Bill. No seu blogue, Bill expõe os pontos fracos e fortes da sua extensão. No artigo das caixas e das setas expõe a concepção de um interface de utilizador completo.
  2. Como colaborar bem com os restantes responsáveis pelo desenvolvimento de Mike Stenhouse apresenta a sua experiência e pensamento sobre o desenvolvimento de CSS modular e de manutenção simplificada.
  3. Rascunho das WCAG 2.0 de Jeffrey Zeldman diz-nos que as directrizes WAI se estão a afinar retirando algumas das ambiguidades que nela figuram actualmente. Acho que qualquer pessoa que deseje começar deve ler os documentos fundamentais mesmo na sua forma de rascunhos para puder avaliar as tendências para o futuro (este comentário é meu).
  4. (Modelo de) Caixa de Pandora de Truques CSS e Outra Boas Intenções de Tantek, apresenta-nos a visão que Tantek tem hoje dos truques que se foram aplicando ao código CSS para acomodar não conformidade com as especificações do W3C por parte de alguns navegadores. Tem algum fundo histórico para se perceber qual foi a evolução e a razão do aparecimento destes itens indesejáveis em muitos casos.
  5. Padrões e Semântica Web de John Allsopp fála-nos da expressividade baixa do HTML mesmo com as identificações e classes.
  6. 24 maneiras de impressionar as suas amigas (desculpem os seus amigos) Mostra-nos uma aplicação de uma infraestrutura JavaScript de Sam Stephenson chamada Prototype
  7. Ir à placa giratória (o meu título seria: Alimentos para um junkie da web de Danny Ayer toca mais tecnologias de alimentação de informação do que eu gostaria.

Fora de tópico

Assinalar vulnerabilidades em sistemas de escuta artigo produzido na Universidade da Pensilvânia curioso. Os "maus" parecem poder ter as costa livres.

30 novembro, 2005

ALA - 208

Saiu o número 208 do A List Apart.

Neste número temos artigos para audiências diferentes:

Para o tipógrafo que há em si tem:

  1. Imprimir um livro com CSS: Boom! Trata-se da apresentação de um método de produção de livros impressos baseado em HTML e CSS mediado pelo Prince para produzir um PDF final para impressão. Boom trata-se de um microformato proposto pelos autores: Bert Bos e Hakon Wium Lie.
  2. Poder ao povo de D. Keyth Robinson, que julgo resumir razoavelmente como criar soluções para necessidades de utilizadores fazendo-o de forma mais simples possível. Além disso é bom ouvir os seus utilizadores e/ou visitantes/clientes.
  3. O terceiro artigo (o repescado do número 96) A maldição da Concepção da Informação de Scott Jason Cohen, fala das dificuldades colocadas pelos especialistas em acessibilidade e usabilidade e os problemas que algum conservadorismo dos arquitectos de informação pode trazer à evolução da web.

28 novembro, 2005

Sítio de Eleição

Por vezes é necessário criar uma visualização de dados complexos e não sabemos como. Aqui http://www.visualcomplexity.com/ poderá encontrar algo para as suas necessidades/desejos.

Erros comuns em XHTML

  • Não fechar elementos vazios (elementos sem marcador de final)
    • Incorrecto: <br>
    • Correcto: <br />
  • Não fechar elementos não vazios
    • Incorrecto: <p>Isto é um parágrafo.<p>Isto é um outro parágrafo.
    • Correcto: <p>Isto é um parágrafo.</p><p>Isto é outro parágrafo.</p>
  • Aninhar elementos de forma imprópria (os elementos têm que ser fechado pela ordem inversa)
    • Incorrecto: <em><strong>Isto é algum texto.</em></strong>
    • Correcto: <em><strong>Isto é algum texto.</strong></em>
  • Não especificar texto alternativo para imagens (usar o atributo alt, que ajuda a tornar as páginas acessíveis a utilizadores com dispositivos que não carregam imagens ou têm dificiência visual)
    • Incorrecto: <img src="/peles/comuns/imagens/alimentadoporblabla.png" />
    • Correcto: <img src="/peles/comuns/imagens/alimentadoporblabla.png" alt="Blabla" />
  • Colocar texto directamente no corpo do documento (isto não é um erro em XHTML 1.0 Transitional)
    • Incorrecto: <body>Bem vindo à minha página.</body>
    • Correcto: <body><p>Bem vindo à minha página.</p></body>
  • Aninhar elementos bloco dentro de elementos em linha
    • Incorrecto: <em><h2>Introdução</h2></em>
    • Correcto: <h2><em>Introduction</em></h2>
  • Não colocar pelicas à volta de valores de atributos
    • Incorrecto: <td rowspan=3>
    • Correcto: <td rowspan="3">
  • Usar e comercial fora de entidades (usar &amp; para mostrar o caracter «e comercial»)
    • Incorrecto: <title>Carros & Camiões</title>
    • Correcto: <title>Carros &amp; Camiões</title>
  • Uso de e comercial fora de entidades em URLs (usar & em vez de & também em ligações)
    • Incorrecto: <a href="index.php?page=noticias&estilo=5">Notícias</a>
    • Correcto: <a href="index.php?page=noticias&amp;estilo=5"gt;News</a>
  • Uso de nomes de elementos ou atributos em maísculas
    • Incorrecto: <BODY><P>A Melhor Página de Sempre</P></BODY>
    • Correcto: <body><p>A Melhor Página de Sempre</p></body>
  • Minimização de atributo
    • Incorrecto: <textarea readonly>SÓ DE LEITURA</textarea>
    • Correcto: <textarea readonly="readonly">SÓ DE LEITURA</textarea>

Esta é uma lista muito abreviada dos erros encontrados

25 novembro, 2005

XHTML para leigos

Se dissermos «qual é a coisa qual é ela que antes de o ser já o era?» Então um ouvinte terá que adivinhar qual será a resposta.

Se dissermos tudo o que sobe tem que cair. Nada de tentar adivinhar, uma frase simples e com início e fim adequados. Faz sentido que algo que seja lançado para o alto tenha que voltar à terra. O não voltar desafia a gravidade não estando de acordo com aquilo que vemos no dia a dia.

Isto é muito semelhante às diferenças entre o XHTML e o HTML 4.01. Em XHTML, tudo o que tem um princípio tem que ter um fim. Em HTML, tal não se passa. Pode começar um parágrafo mas, nunca o acabar. Pode ter uma lista de coisas e nunca terminar cada item. Se tivermos que comunicar com alguém que nunca termina as frases, tal será confuso no mínimo.

Pense nisto da seguinte forma: o HTML foi pensado como um pacote, com uma dobra em cada lado. Contudo mesmo a especificação estrita é tem ainda alguma maleabilidade, ou seja o pacote não necessita estar fechado. Não sei o que é que pensa mas é mais provável comer uma bolacha dum pacote fechado de um aberto sabe quem há quanto tempo.

Exemplos:

Abaixo encontrará um exemplo de código HTML válido mesmo sob o tipo de documento HTML 4.01 estrito:



     <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN" 
                                              "http://www.w3.org/TR/html4/strict.dtd">
     <html>
     <HEAD>
     <meta http-EQUIV="Content-TyPe" content="text/html; 
                                                                CHARSET=utf-8">
     <titlE>Testing HTML 4.01</TITLe>
     </head>
     <body>
     <P>This is some sloppy HTML 4.01!
     <oL>
     <LI>List item one
     <LI>List item two
     <li>List item three</LI>
     </Ol>
     </BODy>
     </HTmL>

Para comparação eis o mesmo reescrito em XHTML 1.1:


     <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
     <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
     <head>
     <meta http-equiv="content-type" content="application/xhtml+xml; 
         charset=utf-8" />
     <title>Testing XHTML 1.1</title>
     </head>
     <body>
     <p>This is some clean XHTML 1.1!</p>
     <ol>
     <li>List item one</li>
     <li>List item two</li>
     <li>List item three</li>
     </ol>
     </body>
     </html>

Como pode comprovar o segundo exemplo é mais legível (desde que saiba sintaxe HTML). Tudo excepto o DOCTYPE está em minúsculas e tudo que tem um início tem um fim explicíto. Não é só mais fácil, evita que o navegador faça algum trabalho de adivinhação sobre o local onde seria suposto encontrar-se os marcadores de fecho. Por exemplo um <li> pode ser fechado no final da linha, mas também é possível envolver coisas dentro de itens de lista.

Um navegador não sabe até atingir o marcador de abertura seguinte se deve fechar o marcador anterior ou se o deve deixar aberto. Assim não há só confusão para uma pessoa que leia o código, mas para a reprodução da página. Implicitamente esta lógica extra necessária provoca um aumento do tempo de carregamento, independentemente do caso de uns tantos bytes extra necessários ao fecho dos marcadores de cada vez que são abertos. O código limpor é reproduzido mais rapidamente, ponto parágrafo. Para prova de tal verifique estes artigo (não o código do sítio).

Terminador por si:

No final do Terminator 2, Arnold diz "não posso acabar comigo". No caso do XHTML isto é bom. Se tudo o que começa tem que ser terminado há alguns pontos nos quais o HTML mesmo que bem formado tem uns quantos problemas. No exemplo acima, há um desses pontos no marcador meta descrevendo o tipo de conteúdo.

Em HTML um meta termina com um ">" significando que tecnicamente ele se mantem aberto. O XHTML corrige isto terminando-se a sí próprio o meta com um traço de fracção final "/>". Outros marcadores com o mesmo comportamento são img, br e hr – todos são tipicamente deixados "em aberto" no HTML, terminando-se a sí próprios no XHTML. Isto torna muito mais fácil uma leitura sabendo que sempre que encontrar um "/>" se está na presença do fim do marcador.

Resumo:

Deixando de lado toda a argumentação para servir XHTML como text/html ou como application/xhtml+xml, prefiro XHTML devido à rigidez inerente à sua validação. Isto claro que não quer dizer que o HTML não possa ser escrito com um padrão muito próximo em mente o problema é que não não é exigído. Veja se me entende não estou a dizer que o XHTML é a forma mais apropriada de fazer as coisas.

Isto não é uma atitude pedante. Sei perfeitamente que o HTML pode ser tão estruturado e semântico quando o XHTML. Roger Johansson e Robert Nyman são perítos em desenvolvimento de web e ambos usam HTML 4.01 estrito de maneira adequada. Ambos fecham tudo e usam código em minúsculas. Robert escreveu um artigo sobre html versus xhtml. Roger é claramente um apaixonado pelo fecho adequado dos marcadores como pode ser comprovado no seu artigo.

Doug Bowman, outra lenda no campo usa XHTML 1.0 estrito, mas serve-o como text/html, sem grande problema. Vejo a lógica por detrás dos argumentos de ambos os lados sobre quererem continuar a trabalhar adequadamente com navegadores obsoletos, etc.

Voltemos ao assunto principal: Resolvemos os mistérios da humanidade? Não. Este artigo está aqui para provar as vantagens de um doctype sobre outro? Não. Só quiz dar uma revisão geral sobre o que me levou inicialmente para o XHTML e porque prefiro continuar a usar. O aspecto fundamentar é que independentemente do que escolha se lhe mantenha fiel. Não tente misturar - mantenha os marcadores em minúsculas e feche-os.

Ou seja no fim disto tudo. Faça uma selecção de um standards e depois aja em conformidade com o mesmo. Uma disputa sobre que standard seguir é fútil.

24 novembro, 2005

Esquadria azul à volta de uma imagem

Tornar uma imagem a ligação para outra página é muito simples, o HTML que segue trata disso:


 <a href="http://aindaapensar.blogspot.com/">
 <img src="/aindaapensar.png" 
alt="logotipo de aindaapensar"> </a>

No entanto irá verificar que aparece uma esquadria azul à volta da imagem. Esta esquadria serve para informar os utilizadores que a imagem é uma ligação. Claro que há algo a dizer para indicar o que é que ou não uma ligação.

Hoje a generalidade dos designers da web tornam óbvio através das concepções do anúncios ou botões de navegação aqueles elementos que são ligações e nos quais se pode carregar. Então como é que apagamos essa esquadria?

Aqueles que gostam de aplicar as recomendações devem usar folhas de estilo e assim o código será algo como:


 <a href="http://aindaapensar.blogspot.com/">
 <img src="/aindaapensar.png" 
alt="logotipo de aindaapensar"
style="border-style: none"> </a>
Ou ainda melhor remetendo a regra para a folha de estilo separada:

img
{
 border-style: none;
}

E no elemento header da sua página fazer uma menção à folha de estilo:


 <link href="/folha_de_estilo.css" 
rel="stylesheet" type="text/css">

Este método irá automaticamente remover a esquadria azul de todas as imagens que usem este ficheiro css e no caso desta regra não ser ultrapassada por outra mais específica.

23 novembro, 2005

div versus span

Para quem não sabe um elemento div é um elemento bloco e um elemento span é um elemento em linha.

Para os curiosos podem dirigir-se à fonte do html

O que é que é isso de elemento bloco e elemento em linha?

Campos escaláveis

As listas de discussão podem não ser a leitura mais agradável que se possa ter mas permite que um principiante aprenda umas coisas.

Por exemplo quando o utilizador altera o tamanho do tipo de letra é razoável esperar que o campo de pesquisa também veja o seu tamanho aumentar para que isso suceda basta na nossa folha de estilo incluir algo como:


form input {
      width: 15em;
      height: 1.3em;
      font-size: .9em;
}

Nem todos os navegadores respondem a isto de forma imediata alguns necessitam de ser refrescados para ajustarem a altura por exemplo de um select

Com o código acima aumenta a largura e altura do campo assim como o tamanho do tipo da letra.

RSS

No blogue da equipa de RSS da Microsoft diz-se que:

...a nossa experiência de vários anos com o HTML no IE ensinou-nos os problemas a longo prazo que resultam de sermos demasiado liberais naquilo que aceitamos de terceiros. Assim, adoptamos o seguinte princípio para o IE7 e a plataforma RSS no Windows Vista: só iremos suportar alimento XML bem formado.

O que me der na mona

Estou a experimentar uma alternativa ao blogger, o wordpress em "O que me der na mona". Até agora a primeira coisa que me salta à vista é que o processo de produção de colocação na net de um texto permite uma classificação coisa que este directamente não faz. Assim provavelmente a minha secção de Web Standards em Portugal vai passar para lá ficando neste blogue pequenos excertos de html, javascript, css, ruby e outras coias mais associadas a puro código.

As minhas observações sobre web design, arquitectura de informação, web 2.0 e outras devem passar para lá (claro que mantendo-se aqui o que já cá está.)

22 novembro, 2005

background-color e color

background-color e color

Algumas pessoas quando vêm o relatório do validador de CSS acham sem importância os avisos em especial quando estes se referem a cores de texto e cores de fundo (color e background-color).

Quando não se especifica uma ou outra o que pode suceder é que um visitante do sítio ter uma configuração específica em que ambas em determinados elementos sejam coincidentes e nesse caso o visitante deixará de poder ler o conteúdo pois a página lhe vai parecer vazia.

21 novembro, 2005

Web Standards em Portugal

Parem a Impressão, parem a impressão! O novo sítio da Universidade de Lisboa passou a validar!

Não sei em que dia é que isto terá sucedido mas o novo sítio da Universidade de Lisboa passou a validar.

A utilização de tabelas para criar a disposição dos vários elementos mantêm-se (mas já esteve mais longe).

Resumindo a componente mecânica já está! Falta a componente mais humana (semântica).

É pena que haja pelo menos uma página na UL(no interior) com erros ligeiros (falta de fecho de parágrafo) quando deviam validar página a página (teste unitário) para saberem o que mudar.

O CSS também valida com alguns avisos em especial com falta de cores de fundo em elementos com cor (de texto) ou vice-versa.

Continuam a usar atributos que já não se esperaria usarem td com width .

Já agora depois de transformarem as tabelas que não são tabelas em div e torna-se em algo importante um sítio de um estabelecimento de ensino superior a seguir as regras.