<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<br><div><div>On Oct 8, 2007, at 22:31 , Fernando Silva wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">On 10/8/07, Bruno Rodrigues <<a href="mailto:bruno.rodrigues@litux.org">bruno.rodrigues@litux.org</a>> wrote:</div> <blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">mas sabes a diferença entre os dois? (não a diferença técnica, mas de</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">onde surgiram e/ou porque foram criados?)</div> </blockquote><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">De uma forma resumida:</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">1. XHTML2 foi uma tentativa de quebrar com o que existia e dar o salto</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">não contemplando compatibilidade quer com HTML4 e XHTML1</div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">2. HTML5 surgiu como forma de evoluir com base no HTML4</div></blockquote><br></div><div>Bzzzzz. quase! :P</div><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>Foi aí que o pessoal do WHATWG percebeu o cerne da questão e quebrou as ligações com a W3C e o XHTML2.</div><div><br class="webkit-block-placeholder"></div><div>- é 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.</div><div><br class="webkit-block-placeholder"></div><div>- qualquer standard têm de ser baseado no principio "<span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: 'Century Gothic'; font-size: 13px; font-style: italic; text-align: justify; ">Be strict in what you send, but generous in what you receive.<span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 11px; font-style: normal; ">", 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.</span></span></div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div><div style="text-align: justify;">- 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".</div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div><div style="text-align: justify;">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.</div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div><div style="text-align: justify;">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.</div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div><div style="text-align: justify;"><br class="webkit-block-placeholder"></div></body></html>