Tag: browser

Webfonts: Agora vai!

23 de abril de 2010 às 15:10 | Lucas Petes | , , , , ,

Talvez o assunto mais polêmico da especificação do CSS3 (enquanto o mais polêmico do HTML5 provavelmente seja o codec de <video>), o Web Open Font Format foi aprovado pela W3C no último dia 8, tendo também como signatário… a Microsoft.

Ter a Microsoft no jogo significa muito. Primeiro, porque o IE detém o maior market share; de nada adianta o desenvolvimento de um padrão se ele não puder ser amplamente usado. Segundo, porque se esperava que a Microsoft fosse aparecer com algum formato próprio e ir mais uma vez contra a corrente. Terceiro que, além do suporte a HTML5 e outros padrões já estabelecidos que serão suportados no IE9, a Microsoft deve somar forças no desenvolvimento dos novos padrões e tirar o atraso.

O WOFF já vinha sendo apoiado pela Mozilla e por várias type foundries (design/comércio de fontes) e surge como a evolução de outras iniciativas: ZOT (Mozilla) e .webfont (designers de tipos). Outros formatos fazem parte das tentativas de incorporação de fontes em sites: EOT (da Microsoft. Talvez o primeiro formato, suportado inclusive no IE6), uso direto de OpenType (Safari, Mozilla) ou mesmo SVG.

Entre os requisitos para um bom formato de webfonts estão a geração de subsets, compressão, incorporação da licença de uso da fonte e a compatibilidade com os formatos existentes, tanto para uma boa conversão das curvas das fontes, quanto para o suporte a ligaduras e outras features dos formatos modernos de fontes.

O que muda com o WOFF

Como você deve saber bem, para se usar hoje uma fonte (declarando font-family e pronto) esta precisa estar instalada no computador do usuário, o que limita as escolhas a pouco mais de meia dúzia de fontes seguras.. A simples incorporação da fonte também não é uma solução aceitável para as foundries, uma vez que abriria (ainda mais) as portas para a pirataria.

Usar hoje uma fonte diferente em um projeto web exige alguns malabarismos. O primeiro deles é usar imagens para representar o texto (não esquecer do atributo alt, por favor). Dá algum trabalho, mas resolve se o texto for estático. Caso contrário, passamos para os text replacements, que são scripts (PHP, Flash, JS, etc) que substituem o texto dos elementos especificados na página por imagens geradas dinamicamente, Flash ou SVG (caso do Cufón, usado nos títulos aqui do TAS). O text replacement também tem suas desvantagens, por depender de plugins e outros suportes do browser, pesar um bocado ou não suportar a seleção do texto.

A incorporação de fontes é normalmente aceita de alguma forma pela licença das fontes. Comum em Flashs e PDFs, vai ser também para a Web. Uma versão limada da fonte (com apenas os caracteres necessários para a apresentação do conteúdo) é gerada e incorporada ao site, o que também já é considerada uma proteção suficiente.

Daqui pra frente

Aceito pela W3C, o padrão vai ser conduzido pelo WebFonts Working Group para refinar a especificação e desenvolver uma recomendação formal. Provavelmente o WOFF não seja suportado a curto prazo nos browsers, tampouco já deve fazer parte do IE9, mas, pra uma novela que já se arrasta por tanto tempo, não custa esperar um pouco mais.

(via Ars Technica e Estadão)

Comentários desativados

Apple: a bola é minha e você só joga se eu deixar

21 de abril de 2010 às 21:59 | Lucas Petes | , , , , , , ,

Após o lançamento do iPhone OS 4 há algumas semanas, foi amplamente noticiada a alteração da seção 3.3.1 dos termos de desenvolvimento para a plataforma: nada poderia ser desenvolvido sem que fosse escrito em Obj-C, C, C++ ou Javascript rodando na engine Webkit e usando as APIs da própria Apple. Sem frameworks de terceiros, intermediários e outras ferramentas.

O Flash CS5, então a dois dias do seu lançamento, teve inutilizada a sua funcionalidade mais falada: a compilação de apps pro iPhone (entre outros dispositivos). Usuários comentaram, executivos se enfureceram, o assunto foi acompanhado por muitos blogs. Um dos últimos episódios foi a resposta do próprio Steve Jobs a um dos e-mails, de certa forma validando a opinião de John Gruber, do Daring Fireball, sobre a alteração.

Resumindo, Gruber trata da visão e do controle da Apple sobre o seu negócio e sua plataforma. Trata-se de usar o grande market share de usuários para impulsionar o já grande market share de desenvolvedores, tornando o Cocoa Touch um padrão de fato de desenvolvimento mobile e, provavelmente, incentivando também o desenvolvimento de aplicativos para os Macs. Haver uma plataforma sobre o Cocoa Touch (ainda mais se for o Flash), cria uma base paralela de desenvolvedores, fortalece a nova plataforma e pode facilitar o desenvolvimento de novos apps. No entanto, a base de desenvolvedores da Apple será enfraquecida e, pior, a qualidade dos apps será comprometida. Suponhamos que a Apple libere hoje funcionalidades importantíssimas para o iPhone OS, tal como as APIs de multitarefa no último lançamento: quanto tempo a Adobe levaria para adotá-las (se adotasse)? O suporte seria completo? Haveria bugs? Esses bugs poderiam comprometer a segurança e a reputação da plataforma?

Por fim, Gruber cita o caso do Kindle para iPhone, que é um excelente app e pode ser um grande rival para os recém-lançados iBooks. Já a versão para Mac não se parece nem se comporta como um Mac app – é apenas um port (mal) feito em Qt.

Estamos em 2010 e na Web ainda estamos amarrados a tecnologias especificadas há uma década, por conta dos diferentes níveis de implementação da especificação entre os browsers e da sua frequência de atualização. Pouco adianta que um browser implemente toda as especificações da W3C se ainda temos o IE6 entre nós. A Web não tem um dono que possa arrumar a casa. A plataforma do iPhone tem e esta pode ser nivelada por cima, uma vez que é a Apple quem cria a especificação, desenvolve as tecnologias e os padrões de interação.

No próximo post vou tentar esticar um pouco mais esse paralelo entre o iPhone, o mercado de browsers e os padrões Web. Até lá :)

Update: A Adobe por fim limou do Flash CS5 a exportação para iPhone. A Apple respondeu. (via)

IE9: Chuva de Canivetes!

19 de março de 2010 às 16:25 | Lucas Petes | , , , , , ,

Site Internet Explorer 9

Em tempo: Anunciado esta semana, o Internet Explorer oferecerá suporte a CSS3, HTML5, SVG e tratá um novo motor Javascript, o Chakra. Pelos testes de desempenho, o novo motor é mais rápido que o Gecko (Firefox) mas ainda inferior a Webkit (Chrome, Safari) e Opera. O browser virá também com suporte a aceleração de hardware (usando a GPU) e faz uma bela pontuação no Acid3. Mais infos no blog oficial.

No rascunho do HTML5 ainda não consta o status atualizado da implementação no IE9.

(via Pinceladas da Web)

Comentários desativados

A Web e o HTML: Passado, presente e futuro (Parte 4)

21 de janeiro de 2008 às 11:03 | Lucas Petes | , , , , , ,

Juro que este será o último post da série :)

Minha intenção é começar a apresentar um pouquinho das mudanças de sintaxe no HTML 5. Tratarei aqui principalmente do que diz respeito ao cabeçalho, identificação do arquivo e coisas do tipo, principalmente porque isso já está definido pelo WHATWG e não deve ser mudado. As tags que ficarão dentro do <body> poderão sofrer mudanças de caráter semântico (terão outro sentido), outras serão mantidas como antes e algumas serão adicionadas, como a já famosa tag <canvas>, criada pela Apple no dashboard do OS X. Vários atributos e tags também serão removidos.

O DTD

O HTML nasceu com a sintaxe SGML, relativamente simples e prática pras necessidades de uso e semântica. A customização da sintaxe de uma linguagem de marcação em SGML é especificada por um DTD (Document Type Definition) como este:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

para o HTML 4 strict, ou este:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

para o XHTML 1.0 Strict.

O DTD carrega toda a especificação da linguagem – suas tags, atributos e valores aceitos.

No HTML 5, bastará a declaração <!DOCTYPE html>, que é suficiente para o navegador renderizar o html em ‘standards mode’ – não em ‘quirks mode‘.

MIME Type e Encoding

É o MIME Type que define o tipo do documento que você está usando. O padrão para HTML clássico é e vai continuar sendo servido como text/html. Se você utiliza text/html para enviar um XHTML, ele será considerado um HTML, talvez com erros de sintaxe.

Hoje, quando não é possível o envio do MIME e do encoding da página pelo cabeçalho HTTP, usa-se:

<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />

No HTML5, o tipo deverá ser identificado somente no cabeçalho HTTP, de modo que se for possível identificar o encoding, a tag abaixo deve ser colocada logo após do DOCTYPE/html/head, antes mesmo do título, nos primeiros 512 bytes do código:

<meta charset="UTF-8">

Um arquivo XHTML deve ser servido no cabeçalho HTTP com um MIME Type de XML, como application/xml ou application/xhtml+xml. A codificação é passada no atributo encoding, na declaração do XML (que DEVE estar na primeira linha):

<?xml version="1.0" encoding="UTF-8"?>

Por fim, um arquivo HTML 5 teria essa estrutura básica:

<!doctype html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>Example document</title>
    </head>
    <body>
        <p>Example paragraph</p>
    </body>
</html>

e um arquivo XHTML 5 seria basicamente apresentado assim:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <title>Example document</title>
    </head>
    <body>
        <p>Example paragraph</p>
    </body>
</html>

Provavelmente o elemento canvas ainda me renderá alguns post. Pra ir adiantando o assunto, deixo o ‘Doom’ feito pela Mozilla, os efeitos do CVI (canvas/JS), o clone do MS Paint e o tutorial feito pela Mozilla.

Para terminar, você pode conferir aqui a lista completa das diferenças entre o HTML 4 e o 5 e aqui um super artigo do A List Apart sobre o HTML 5, sua estrutura e a entrada de video/audio.

Comentários desativados

A Web e o HTML: Passado, presente e futuro (Parte 3)

15 de janeiro de 2008 às 11:57 | Lucas Petes | , , , , , , , , , ,

Bom, depois de ficar muito tempo sem postar (perdão!) e de assistir 2001: Uma Odisséia no Espaço, o que me deixará afetado por algumas semanas, retomo este post.

O HTML foi criado como um meio de troca de documentos (científicos) entre máquinas e sistemas diferentes, usando o protocolo HTTP. Quem um dia já teve a oportunidade de escrever um documento científico sabe que ele é constituído de diversos elementos (titulo, resumo, autores, bibliografia, referências, etc.) que geralmente se repetem ou são obrigatórios/necessários. Com essa estrutura ‘previsível’, levantar e implementar as tags HTML necessárias para formatar tais documentos provavelmente não foi uma tarefa das mais difíceis. Além disso, diversas tags o HTML já herdava do SGML.

… mas a Web cresceu. Foi aberta para o mundo, para todos. E aí? Nem só de documentos científicos vivia essa Web.

Pois bem. Os browsers cresceram e apareceram com a Web. Mosaic, Netscape, Internet Explorer.

- Como colocar ‘tal’ texto em ‘tal’ lugar? Como criar colunas, barras, etc?
- Tipo um jornal?
- É! Tipo um jornal!
- Ora! Com tabelas!

Com tabelas, por favor!

As tabelas foram incluídas na especificação do HTML 3, em 1995. Daí pra frente, além de carregarem consigo dados tabulares, as tabelas serviam de grid para as páginas. E assim foi até uns dias atrás.

A proposta do CSS1 veio no mesmo ano, em novembro. A Microsoft adotou a idéia e prometeu implementar no recém-lançado Internet Explorer

Vale lembrar que desde 1993 havia na lista www-talk a idéia de uma folha de estilos pra HTML. Nada ainda em ‘cascata’. Veja a proposta do pessoal da O’Reilly:

@H1 fo(fa=he,si=32,we=bo) ve(be=1,af=2)

que equivale a:

h1 {
  font-family: sans-serif;
  font-size: 32pt;
  font-weight: 900;
  padding-top: 1em;
  padding-bottom: 2em;
}

Daí em diante, muita água passou por debaixo da ponte. A web crescia mais e mais. Novas possibilidades surgiam: e-commerce, leilões, chats, comunidades, enormes portais, web apps. Os browsers – claro, principalmente o eixo IE-Netscape – implementavam novas tags e outras tecnologias deliberadamente, levados pelo mercado e na tentativa de ganhar novos adeptos, tanto o usuário final quanto o desenvolvedor. Site compatível com IE nem sempre era com o Netscape e vice-versa.

A especificações do HTML4 e do CSS2 foram liberadas em 1998. Também em 1998, foi fundado o WaSP, o projeto Mozilla e foram iniciados os rascunhos do que viria a ser o XHTML.

E o vento começou a virar

Pequenos e grandes movimentos deram início ao trabalho de evangelização dos webstandards. A tecnologia disponível e a maioria dos browsers em uso já suportava o “pleno” uso de HTML/CSS para a construção de quaisquer tipos de site sem o uso, por exemplo, de tabelas como grid ou da tag <font>.

Como antes “HTML não era importante”, era “coisa pra browser entender” e era “uma bagunça de tag com trilhões de <td>”, nem todo ‘profissional’ web entendia HTML – o negócio era editor WYSIWYG. Macromedia Dreamweaver, Microsoft FrontPage, Netscape Composer, Adobe GoLive! e tantos outros eram ferramentas essenciais. Até concordo. Criar inúmeras estruturas de tabelas aninhadas na unha nunca foi tarefa das mais fáceis. Pior ainda era entender aquilo depois. No entanto, o movimento dos webstandards pregava uma coisa que essas ferramentas ainda não faziam no modo visual – e não fazem direito até hoje. Talvez por isso a migração para os padrões tenha sido tão lenta: a longa curva de aprendizado dos profissionais que até então dominavam o mercado e a demora para a evolução das ferramentas.

Do início dos anos 2000 pra cá, a adoção dos webstandards cresceu exponencialmente. Quem até então relutava em fazer da web um mundo melhor foi convencido pelo bolso (redução de custos e tempo de implementação e manutenção), pela equipe (programador nenhum gosta de trabalhar em um mar de <td>), ou pelo Google (conteúdo relevante como ele deve ser). Ah, sem falar que agências e profissionais anunciavam webstandards como diferencial competitivo – o que de fato era. Como a concorrência não quer nunca ficar pra trás, fizeram a lição de casa.

O XHTML foi liberado em 2000, como uma substituição/evolução do HTML 4. Hoje provavelmente seja a especificação mais usada para a escrita de novos documentos, mais por conta das melhorias de sintaxe em relação do HTML 4 do que pela abordagem do seu uso como documento XML. O futuro proposto pela W3C para o XHTML foi visto por Apple, Mozilla e Opera como um distanciamento da realidade e das necessidades dos autores dos documentos da web. Por conta disso, formaram o WHATWG, com foco principal na construção da especificação do Web Applications 1.0 (aka HTML 5).

No próximo post (provavelmente o último), as mudanças nas sintaxes de HTML4 e XHTML para HTML 5.

Ref: http://virtuelvis.com/archives/2005/01/css-history – História do CSS, principalmente quanto às sintaxes propostas

Comentários desativados