No seguimento das cábulas para programadores eis as cábulas para programadores em Ruby.
Blogged with Flock
Web,ruby, Ajax ou qualquer outra coisa que me venha a cabeça (com prioridade para esta última)
No seguimento das cábulas para programadores eis as cábulas para programadores em Ruby.
Blogged with Flock
Em cinco passos: podcast.
p.s. inutilidade absoluta :)
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.