[ANSOL-geral] E-mail e OpenOffice WAS: E-mail e Unicode

[Bruno Rodrigues]

On Oct 8, 2007, at 22:31 , Fernando Silva wrote:

> On 10/8/07, Bruno Rodrigues <bruno.rodrigues  litux.org> wrote:
>> mas sabes a diferença entre os dois? (não a diferença técnica, mas de
>> onde surgiram e/ou porque foram criados?)
>
> De uma forma resumida:
> 1. XHTML2 foi uma tentativa de quebrar com o que existia e dar o salto
> não contemplando compatibilidade quer com HTML4 e XHTML1
>
> 2. HTML5 surgiu como forma de evoluir com base no HTML4

Bzzzzz. quase! :P

O XHTML foi uma forma de definir um novo standard onde ou se respeita  
cegamente o standard a 100%, ou se se cometer um erro, por mais  
pequeno que seja, leva-se uma valente sapatada. Como toma por base o  
XML puro, qualquer erro que um designer faça iria causar um erro  
indecifravel que o utilizador nunca iria perceber. Digo "iria" porque  
XHTML nunca chegou a existir no mundo real, apenas XHTML disfarçado  
de HTML e entregue com content-type text/html. Mesmo no caso do XHTML  
Mobile Profile, largamente usado nos telemoveis, nunca foi XHTML puro.

Foi aí que o pessoal do WHATWG percebeu o cerne da questão e quebrou  
as ligações com a W3C e o XHTML2.

- é muito mais eficaz definir standards que documentam a realidade  
existente do que criar standards completamente novos e esperar que  
todo o mundo o siga e respeite, por muito correcto academicamente que  
o novo standard seja.

- qualquer standard têm de ser baseado no principio "Be strict in  
what you send, but generous in what you receive.", o tal que gerou  
esta discussão. Quem vai gerar conteudo é humano e irão sempre haver  
erros, portanto é da responsabilidade do browser/"consumer" entender  
o que recebe e corrigir o que fizer sentido.

- assumindo que irás receber sempre lixo, o HTML5 predispos-se a  
documentar o "lixo" mais comum num standard, de forma que toda a  
gente seja coerente na "generosidade".


Tal como disse noutro email, HTML ganhou ao XHTML, RSS ganhou ao RDF  
(puro), e o REST tem ganho aos XMLRPC's e SOAP's. Tudo standards  
"real-life", cheios de indefinições que o "mercado" encarregou-se de  
corrigir, vs. standards academicamente correctos que ninguem tem  
vontade de olhar para.


Voltando à questão inicial, se um "consumer" receber algo que não  
está 100% correcto e for "fazível" detectar o erro e corrigir, para  
mim é um BUG quando a app não o corrige. No caso especifico do kmail,  
quando nem sequer há uma definição do charset, e quando é fácil  
entender que o conteúdo é utf-8 e não iso-8859-1, para mim é um BUG  
que devia ser corrigido. Se procurar bem no bugtracker do kde deve  
ainda haver por lá um bug meu.


-------------- próxima parte ----------
Um anexo em HTML foi limpo...
URL: http://listas.ansol.org/pipermail/ansol-geral/attachments/20071008/b4a532ed/attachment-0001.htm