Tableless http://tableless.com.br Tableless - Desenvolvimento inteligente com padrões web Thu, 17 May 2012 02:39:20 +0000 pt-br hourly 1 http://wordpress.org/?v=3.3.2 Documentos poliglotas com XHTML5 http://tableless.com.br/documentos-poliglotas-com-xhtml5/ http://tableless.com.br/documentos-poliglotas-com-xhtml5/#comments Wed, 16 May 2012 13:35:51 +0000 Talita Pagani http://tableless.com.br/?p=6057 Quando se começou a falar massivamente a respeito do HTML5, em 2009, muitos desenvolvedores (inclusive eu) torceram o nariz para o fato de poder voltar a utilizar a sintaxe tolerante do HTML, ou seja, tags em uppercase ou sem fechamento, valores de atributos sem aspas, fechar tags em ordem incorreta, entre outros. Inclusive, comentei especificamente sobre isso em um outro artigo.

Grande parte dos desenvolvedores aprenderam  e se habituaram a utilizar a sintaxe do XHTML, que segue as diretrizes do XML para documentos bem formados e que apresentariam erros de renderização caso essas diretrizes são fossem seguidas. Isto nos permitia códigos mais limpos e bem estruturados. Porém, no HTML5, a escolha é sua e você não será punido por não fechar tags.

Com toda essa preocupação, no mesmo ano começou a ideia do XHTML5, uma tentativa de contornar o problema, adicionando as restrições de marcação do XML a documentos escritos em HTML5. Podemos dizer que seria uma tentativa de unir o melhor de cada especificação. O artigo escrito por Bruce Lawson para o HTML5 Doctor (com versão traduzida no Pinceladas da Web) foi um dos primeiros a comentar sobre o tema.

Durante cerca de 1 ano isto era uma forma, digamos, marginalizada de tratar essa questão, por não ser algo reconhecido pelo  WHATWG / HTML WG. Mas em 2010 surgiu o primeiro draft com a proposta de nortear o uso do HTML5 com a sintaxe do XML/XHTML. O W3C denominou essa metodologia de marcação poliglota.

O que é um documento com marcação poliglota?

Um documento com marcação poliglota é um documento escrito em HTML5 que pode ser processado tanto como HTML quanto como XML dentro de um conjunto de restrições definidas, porém, ainda seguindo a especificação do HTML5. Eles são compatíveis com o HTML e XHTML.

Significa que você pode utilizar todo o poder do HTML5 dentro do padrão de marcação bem formada do XML. É importante ressaltar que isto não afeta as tags que você pode utilizar. Por exemplo, elementos que são considerados deprecated em XHTML mas válidos no HTML5 continuam a ser válidos. Uma exceção é com relação a algumas tags que são excluídas de documentos poliglotas por não serem possível de serem replicadas em um parser XML (como é o caso da tag <noscript>).

Mas em linhas gerais, esta “fusão” não altera a especificação, mas sim as regras de sintaxe para processamento e há influência no DOM também (ex.: document.write não é permitido, mas sim innerHTML).

Segundo o W3C, um documento poliglota resulta em:

  • Um documento HTML5 válido;
  • Um documento XML bem formado (mas não significa um documento XML válido);
  • DOM idêntico quando processado tanto como HTML quanto como XML, isto porque os parsers geram diferentes DOMs para determinados atributos relativos ao XML.

Como escrever um documento poliglota

Um dos principais requisitos para escrever um documento em XHTML5 é o MIME-type utilizado. Isto vai definir se o navegador irá interpretar o documento como HTML ou XHTML. Segundo o WHATWG, um documento HTML5 se torna um documento poliglota se for provido o MIME-type application/xhtml+xml.

1
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8" />

Até algum tempo atrás, o IE não suportava este MIME-type. Para isso, você pode indicar que o MIME-type é o usual text/html. Ele pode ser utilizado junto com o primeiro (separando por vírgula), ou pode ser feita uma validação do navegador para decidir qual o MIME-type a ser utilizado.

O doctype passa a ser opcional, mas ainda é recomendável utilizar para prevenir o quirks mode dos navegadores. Se utilizado, a palavra doctype deve ser escrito adequadamente em uppercase, ex.: <!DOCTYPE html>. A meta-tag que especifica o charset e a declaração <?xml version=”1.0” encoding=”UTF-8”?> (herdada do XHTML 1.1) também passam a ser opcionais se o charset desejado para o documento é UTF-8 (padrão do XML).

Além disso é preciso definir também o namespace do XHTML na tag <html>:

1
<html xmlns="http://www.w3.org/1999/xhtml">

Ao utilizar recursos como SVG e MathML, é preciso especificar também o atributo xml para a tag raiz correspondente de cada um.

Outras recomendações são:

  • Usar tanto o atributo lang quanto xml:lang na tag <html>;
  • Usar tbody / thead / tfoot em <table>s;
  • Quando o elemento <col> é utilizado em tabelas, utilizar também o elemento <colgroup>;
  • Não utilizar o elemento <noscript>;
  • Não iniciar as tags <pre> e <textarea> com linha em branco;
  • Utilizar innerHTML ao invés de documento.write;
  • Para scripts embutidos na página, escreva o código entre uma seção CDATA com os delimitadores comentados. É uma forma de fazer com que o parser do XML (que analisa apenas a marcação) não acuse erros ao utilizar < ou & no script;
  • Os atributos xml:space e xml:base são permitidos apenas nos elementos relativos a SVG e MathML;
  • Elementos que podem ter conteúdo mas estão vazios não devem ser minimizados para o formato de tag órfã. Ex.: <p /> não deve ser utilizado, mas sim <p></p>.

Ao escrever documentos poliglotas, é possível utilizar todas as funcionalidades do HTML5 com uma garantia de código bem formado de acordo com as restrições do XHTML. Com isso, é possível ter um código mais organizado e consistente que seja mais fácil de produzir, manter e reutilizar a longo prazo, principalmente quando este trabalho é realizado em equipe.

Referências

Polyglot Markup: HTML-Compatible XHTML Documents
XHTML5 in a nutshell
Benefits of polyglot XHTML5
HTML 5 + XML = XHTML 5

Posts Relacionados

]]> http://tableless.com.br/documentos-poliglotas-com-xhtml5/feed/ 8 Estruturação de Client-side – Parte 2: Designers e Programadores http://tableless.com.br/estruturacao-de-client-side-designers-e-programadores-parte-2/ http://tableless.com.br/estruturacao-de-client-side-designers-e-programadores-parte-2/#comments Mon, 14 May 2012 22:42:44 +0000 Diego Eis http://tableless.com.br/?p=6121 Se dividirmos as áreas de desenvolvimento, chegaremos a 3 grandes grupos, totalmente distintos que são: designers, programadores e nós, front-end.

Nós estamos no meio dos dois grupos. Nós nos relacionamos diretamente com os dois profissionais, fazendo uma ponte e tentando adequar as necessidades de cada um durante o projeto. E é aí que entra o problema.

Os dois mundos são totalmente diferentes. O designer se preocupa em deixar o sistema lindo, maravilhoso, fácil de usar, vendável e etc. O programador faz com que tudo funcione. O cliente tem que conseguir comprar quando clicar no botão. Nosso trabalho é fazer com que a beleza não estrague a funcionalidade. É fazer com que as necessidades do programador não entrem em conflito com as necessidades do designer. Nesse meio entra o seu trabalho. Sua obrigação é deixar o site acessível, com código de fácil indexação e escalonável ao mesmo tempo que você deixa o layout do designer fiel ao original do Photoshop.

Necessidades dos Designers

Os designers precisam de liberdade para criar. Isso sempre foi muito difícil na web e por isso o Flash ganhou tanta atenção. Se antes só podíamos fazer coisas básicas utilizando CSS, o Flash dava ao designer acesso a um mundo de possibilidades. Atualmente isso mudou muito graças ao Santo protetor dos desenvolvedores front-end.

Com a vinda das features do CSS3, boa parte das funcionalidades que antes tínhamos que fazer gambiarras com imagens, hoje podemos fazer com apenas uma propriedade. Quem nunca passou horas recortando imagens de bordas arredondadas, sombrinhas e degrades? Hoje resolvemos tudo diretamente pelo CSS, que roda mais rápido e é muito mais flexível.

A ideia é transportar fielmente a arte que o designer criou no editor gráfico, para código HTML/CSS. Nesse momento você precisa se preocupar com duas coisas: fidelidade de layout e semântica de código.

O código HTML irá refletir os elementos do layout, traduzindo a informação visual, para informação em código semântico de forma que os dispositivos, robôs de busca, scripts e afins acessem esse código e executem suas tarefas. O Google precisa saber o que é um link e um botão. Mesmo que eles tenham o mesmo design. O leitor de tela precisa entender o que é um título e um parágrafo. Isso tudo aliado com os detalhes visuais que o designer desenhou, como sombras, degrades, transparências, bordar arredondadas e etc.

Esse processo inicia a fase de código do projeto. Estamos criando uma estrutura que vai perdurar o projeto inteiro. Os programadores, posteriormente, irão produzir o sistema em cima deste código. Por isso é muito importante que sua base seja bem estruturada mas ao mesmo tempo super flexível para mantermos o layout da maneira correta.

Necessidades dos Programadores

Os programadores precisam automatizar coisas. O projeto precisa que as tarefas sejam automatizadas para que o projeto funcione de forma escalonável e sem a necessidade de replicação de código desnecessariamente. Essas tarefas vão desde a criação de formulários até comunicação com o servidor.

O problema é que a maioria das vezes essas tarefas automatizadas não são criadas pelos programadores da equipe. São plugins, scripts e etc que foram criados pela comunidade. Não estou dizendo aqui que isso é ruim, por favor. Na verdade, é o certo. Não tem sentido recriarmos algo que já existe e que funciona muito bem. Esses plugins, scripts e etc foram criados por outros programadores que um dia tiveram a mesma necessidade que os programadores do seu projeto e por isso, nada mais sensato do que criar um plugin para ajudar outros devs com a mesma necessidade. Acontece que programadores, são programadores. Eles não tratam o HTML com o mesmo carinho que nós.

Vamos pegar um exemplo de formulários. Os programadores aqui onde trabalho programam em RUBY, utilizando Rails. Há uma GEM que cria e gerencia formulários no projeto. O código que esta GEM gera por default não é legal e o pior, é totalmente diferente do código que você usaria ou usou no projeto – Por isso é interessante entender quais ferramentas os programadores utilizarão antes de iniciarmos nosso código HTML. Assim podemos adaptar o que for preciso para códigos que fujam do seu padrão pessoal.

Você não pode obrigar os programadores a fazerem tudo na mão. Se você conseguir, ótimo. Essa é sempre a minha primeira opção… Mas caso isso seja impossível, sugiro que sente e tente entender o maldito plugin. Converse com o programador e tente mostrar as desvantagens para o projeto caso continuem a utilizar o código default. Veja se não há a possibilidade de modificar esse código. Na maioria das vezes há. Caso não dê, estude a possibilidade de trocarem para um plugin que dê.

Existem frameworks – como o Web2Py – que ainda utilizam tabelas para exibir formulários. Chorei sangue quando eu vi pela primeira vez e chorei mais ainda ao descobrir que não é algo muito fácil customizar eses código para que ele entregasse o HTML que eu queria. Paciência.

Sincronizando as necessidades

O encontro de dois mundos gera o problema. Sincronizar as necessidades visuais dos designers com as necessidades de código dos programadores é algo que geralmente deixa traumas em qualquer dev front-end.

O programador precisa usar ferramentas que os ajudam a executar tarefas complexas, mas que adulteram demais o código. O designer precisa que seu layout seja fielmente seguido, ou seja, todas as firulas visuais como sombras, degrades, bordas, backgrounds e etc permaneçam intactas. Como você pode manter o padrão de qualidade se o código manipulado não é o seu, mas o do plugin? É aqui que os front-ends maricas pedem arrego.

Cada efeito visual, cada estrutura, cada necessidade de layout determinam com que o HTML será escrito. Se o HTML é criado automaticamente por um plugin ou algo parecido, como você faz? Entende a questão?
Você até faz o layout ficar igual ao planejado, mas e a semântica? O design, a funcionalidade e a semântica precisam coexistir. Essa é a essência da responsabilidade do profissional client-side.

Não há mágica que faça isso tudo acontecer. Você precisa sentar e conversar. Eu costumo chamar o designer e o programador e explicar minhas limitações. Eles entendem e cada um abre mão de algo que pode me ajudar. O designer tira aquele efeito visual desnecessário e o programador tenta colocar aquela classe importante e retirar um ou outro código automático. A opção de conversar com os dois é melhor do que você criar uma solução com Javascript. Para retirar ou inserir as tags ou classes que você precisa. O código fica mais feio e seu site perde performance. Sem contar que para resolver suas pendências manipulando o DOM com Javascript, é pior para o Google, para os leitores de telas e para os robôs em geral.

Padronizando tudo

Uma outra solução que eu cheguei é mais complicada, mas sem dúvida a mais duradoura. Começamos a criar dentro da empresa uma biblioteca que une código HTML/CSS semântico com o visual predefinido dos designers e que contemple as necessidades de funcionalidades dos programadores.

Assim, começamos a criar uma cultura de padronização de código que vai perdurar por várias gerações de serviços e acima de tudo, não quebra a linearidade dos produtos em si. Manteremos a uniformidade de código com a a uniformidade de identidade visual dos sistemas. Não estamos engessando a criação, pelo contrário, estamos criando uma base sólida que poderá ser reutilizada em toda a empresa, em larga escala e independente.

Posts Relacionados

]]> http://tableless.com.br/estruturacao-de-client-side-designers-e-programadores-parte-2/feed/ 5 Adobe: The Expressive Web http://tableless.com.br/adobe-the-expressive-web/ http://tableless.com.br/adobe-the-expressive-web/#comments Fri, 11 May 2012 17:13:45 +0000 Diego Eis http://tableless.com.br/?p=6117 Essa é antiga, mas muita gente ainda não viu!

Mais uma iniciativa da Adobe para divulgar as maravilhas do CSS3 e HTML5. O The Expressive Web é um sitezinho maneiro onde a Adobe mostra alguns exemplos das novas features do HTML5 e do CSS3 com exemplos sensacionais.

The Expressive Web, by Adobe.

Cada uma das features tem uma pequena descrição, e o mais importante, eles mostram uma porcentagem de quantos usuários veriam aquela feature. CANVAS, por exemplo, seria visto por 75% dos usuários, obviamente, dos usuários que usarem browsers novos, como IE9, Safari, Chrome e etc…

Não vá ver isso em um Internet Explorer ruim ou um browser antigo. Estamos falando de web de verdade, aqui. ;-)

Posts Relacionados

]]> http://tableless.com.br/adobe-the-expressive-web/feed/ 5 Drops 9 – Préprocessadores, frameworks e bibliotecas http://tableless.com.br/drops-9-preprocessadores-frameworks-e-bibliotecas/ http://tableless.com.br/drops-9-preprocessadores-frameworks-e-bibliotecas/#comments Fri, 11 May 2012 03:13:13 +0000 Diego Eis http://tableless.com.br/?p=6114 Uma continuação do post que escrevi sobre o assunto e a primeira parte de uma série de artigos com dicas sobre como estruturar uma área client-side.

Arquivo Mp3.

Posts Relacionados

]]> http://tableless.com.br/drops-9-preprocessadores-frameworks-e-bibliotecas/feed/ 3 Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas http://tableless.com.br/estruturacao-de-client-side-preprocessadores-framewoks-e-bibliotecas-parte-1/ http://tableless.com.br/estruturacao-de-client-side-preprocessadores-framewoks-e-bibliotecas-parte-1/#comments Wed, 09 May 2012 16:53:47 +0000 Diego Eis http://tableless.com.br/?p=6094 Existem três categorias de “ferramentas” que nos ajudam a desenvolver um projeto client-side: Préprocessadores, Frameworks e Bibliotecas.

Préprocessadores

Préprocessadores são ferramentas onde você escreve CSS de uma determinada forma, modificando sua sintaxe, fazendo com que na hora de sua utilização o código CSS precise ser préprocessado para que o código escrito seja transformado em código CSS puro e assim então os browsers consigam entender.

Existem muitos préprocessadores no mercado como Less, Sass, Turbine, Switch CSS e outros.

Particularmente eu não gosto de usar préprocessadores. Para começar é necessário que você aprenda a linguagem de cada um e a ideia de que seu CSS precisa ser compilado para poder funcionar não me agrada muito. O CSS é simples demais para complicarmos desse jeito. Entretanto, há uma série de coisas interessantes que podemos fazer com os préprocessadores como variáveis, funções, operações e etc que demorarão um pouco (ou não) para fazerem parte do core definitivo da linguagem. Mesmo assim, pessoalmente, para a maioria dos projetos, não vale a pena.

Frameworks

Frameworks são diferentes de préprocessadores mas são muito parecidos com Bibliotecas. Um Framework disponibiliza para o dev um conjunto de estilos e estruturas prontas para a utilização em projetos de forma escalável e uniforme. Normalmente os frameworks te dão uma coleção de componentes para que sejam usadas por todo o projeto. Esses componentes na maioria das vezes já vem com estilos visuais aplicados, bem como a estrutura. Veja por exemplo o Bootstrap ou o Blueprint.

Com o Bootstrap você consegue, rapidamente, fazer um protótipo simples ou uma estrutura básica de sistema. É o preferido dos programadores. Os elementos visuais já foram criados e desenhados. Talvez não seja uma boa ideia você utilizar um framework em um projeto cujo design já esteja aprovado. Você teria muito retrabalho para “zerar” o estilo visual de cada elemento para depois reconstruí-lo utilizando o seu design.

É muito importante que o uso de um framework CSS/Javascript seja aprovado no início de um grande projeto. Mesmo que você planeje criar um framework do zero, específico para seu projeto. O que na maioria das vezes não vale a pena.

Bibliotecas

Bibliotecas CSS geralmente não modificam o visual como os Frameworks fazem, mas eles disponibilizam uma coleção de classes, reutilizáveis e o melhor, combinatórias, para que se adeque a diversos cenários do seu projeto. Como essas classes não estão ligadas a nenhuma formatação visual, você consegue combinar sem grandes problemas com suas classes e IDs, modificando a hora que quiser a formatação visual dos elementos.

As bibliotecas são indicadas para projetos mais simples, sem grandes apetrechos técnicos, como um site ou algo parecido. Para fazer um sistema, as bibliotecas irão reforçar os Frameworks, facilitando a organização e formatação da estrutura do site. A biblioteca também ajuda na manipulação dos elementos via Javascript se baseando por estas classes prontas.

A verdade é que hoje é muito difícil diferenciar uma biblioteca de um framework.

Como todos eles trabalham juntos?

Você pode usar todos os três ao mesmo tempo em um projeto. Mas não é muito inteligente, já que se você estiver utilizando um framework, muito provavelmente ele terá uma “biblioteca” em sua base. Imagine que a biblioteca pode ser específica de estrutura ou formatação visual. O Framework, basicamente, junta os dois. Obviamente há mais coisas envolvidas. Mas para simplificarmos a explicação, imagine que um Framework é a mistura dessas duas bibliotecas.

O Preprocessador é independente do Framework e da Biblioteca. O seu ganho está ao escrever um código mais escalável, muitas vezes melhorando ou piorando a sintaxe do código. É pura sintaxe, não são classes prédefinidas. Mesmo assim você pode basear seu Framework/Biblioteca em um Préprocessador. O Bootstrap faz isso para facilitar features dinâmicas como grids, cores e etc.

Como eu disse, eu não gosto de misturar as coisas. Prefiro utilizar o Bootstrap puro, sem a interferência de nenhum préprocessador. Mas, há gosto para tudo. ;-)

Qual deles é melhor para o meu projeto

Eu não sugiro que você utilize um framework para criar websites institucionais. Websites geralmente não usam os mesmos elementos, nem as mesmas estruturas, nem o mesmo design. Logo, se você utilizasse um framework como o Bootstrap, ou o JQuery UI, você acabaria gastando mais tempo reestilizando e brigando com o CSS já criado dos frameworks do que fazendo o que realmente importa: o seu trabalho.
Logo, para projetos de pequeno porte eu sugiro que você utilize uma biblioteca simples. Sugiro ainda que essa biblioteca seja criada por você.

Não precisa de muito. Em uma biblioteca você só precisa ter algumas propriedades que fazem tarefas básicas, como fazer o elemento flutuar para a esquerda, para direita, clear, retirar margens e etc. Normalmente eu utilizo um reset chamado Normalize. Ele já reseta meu CSS inteiro e então eu me foco apenas nas propriedades que eu reutilizarei no resto do projeto.

Se seu projeto for médio ou grande, você já pode pensar em utilizar um Framework. Principalmente se seu projeto for um sistema. Você já vai ter à disposição estilos para formulários (que são um saco pra fazer), botões, grids, reset CSS e outras coisas. O trabalho fica mais fácil por que você tem menos arestas para acertar. Ainda mais se o designer aceitar utilizar alguns dos estilos já prontos do Framework, assim você não precisa reconfigurar formatações visuais e etc.

A utilização do Préprocessadores é totalmente opcional. Mas se você decidir utilizá-lo juntamente com algum Framework, procure saber se o Framework escolhido suporta algum tipo de préprocessador. O Bootstrap, por exemplo, tem uma versão para LESS.

No próximo artigo vou contar como estamos fazendo aqui na Locaweb. Estamos criando uma grande biblioteca visual e de front-end que será utilizado por todos os serviços. Os programadores conseguem subir um sistema sem precisar esperar um código HTML definitivo, utilizando os módulos dessa biblioteca. A galera de design faz todos os layouts padronizados visualmente, garantindo a uniformidade de todos os sistemas. E o pessoal de front? Bom o pessoal de front cuida para que tudo isso funcione. ;-)

Posts Relacionados

]]> http://tableless.com.br/estruturacao-de-client-side-preprocessadores-framewoks-e-bibliotecas-parte-1/feed/ 10 O dev front-end – Podcast #1 http://tableless.com.br/o-dev-front-end-podcast-1/ http://tableless.com.br/o-dev-front-end-podcast-1/#comments Sun, 06 May 2012 13:36:37 +0000 Diego Eis http://tableless.com.br/?p=6084 Estamos relançando o podcast do Tableless. Este será o primeiro e falamos sobre um assunto que está sendo bastante comentado nos últimos dias.

Será que o desenvolvedor client-side deveria fazer alguma faculdade? Será que ele precisa aprender a programar? Será que seria interessante ele ser um designer? Será que aprender apenas um framework javascript já é o suficiente?

Assine o FEED direto do podcast.
Arquivo mp3.

Link direto do MP3.

Posts Relacionados

]]> http://tableless.com.br/o-dev-front-end-podcast-1/feed/ 31 Adobe e os Padrões Web http://tableless.com.br/adobe-e-os-padroes-web/ http://tableless.com.br/adobe-e-os-padroes-web/#comments Thu, 03 May 2012 22:11:44 +0000 Diego Eis http://tableless.com.br/?p=6068 Depois que o Steve Jobs fez o favor de nos livrar do Flash em seus dispositivos, parece que a Adobe acordou e resolveu entender o que realmente ele estava querendo dizer. Em vez de tentar devorar o mercado com uma tecnologia proprietária, por que não ajudar uma comunidade e os padrões que já existem no mercado?

O pessoal da Apple fez isso com o Webkit. Eles tomaram emprestado o motor de renderização criado pelo pessoal do KDE – com o motor chamado KHTML – e fuçaram, mexeram, arrumaram, criaram e devolveram o resultado para a comunidade como um dos melhores motores de renderização que já existiu, o Webkit.

Em vez de criarem um motor novo, eles resolveram começar de uma base que já estava bem feita, pronta e organizada por uma comunidade forte. O KHTML e o KJS (motor de Javascript do KDE) permitiam o desenvolvimento mais fácil que as outras tecnologias do mercado e detalhe, tinha apenas 140.000 linhas de código! Era limpo e principalmente tinha um bom suporte com os padrões web.

A Adobe Macromedia, sem dúvida, revolucionou a web com a criação do Flash. Eu fui um dos doidos eufóricos quando eles mostraram uma linha se transformando em um circulo. Chorei sangue quando aprendi a manipular a timeline e fiz minha primeira animação. Não estou dizendo que o Flash é um lixo. Estou dizendo que o Flash fez o seu papel. Todo mundo achou que a Apple desistiria da decisão, mas não foi o que aconteceu. Eles se mantiveram firmes e isso, felizmente, agitou o mercado. Ajudou na divulgação da importância dos Padrões Web e impulsionou muito o HTML5 e o CSS3, que até então apenas o W3C e a comunidade estavam incentivando a sua utilização.

Depois da atitude da Apple de barrar o Flash de seus aparelhos, o que a Adobe faria? Quando a Adobe percebeu que seu software não teria vez, ela foi obrigada a seguir outro caminho. Graças ao grande senhor das montanhas indígenas extraterrestres, eles tomaram o caminho correto. A Adobe tem tido algumas iniciativas para ajudar os desenvolvedores a criarem websites melhores. Se não pode com eles, junte-se a eles.

Para você entender o que eu quero dizer, a Adobe criou um http://html.adobe.com para divulgar suas iniciativas para com a comunidade de desenvolvedores. As ideias expostas no site são sensacionais e eu, particularmente, quero muito que tudo se torne verdade. Separe um tempo e visite esse site. Você não vai perder nada.

Eles tem um software interessante que te ajuda a testar a responsividade do seu layout em diversos aparelhos e tem algumas sugestões de novos padrões que poderão nos ajudar demais em desenvolvimentos específicos. Leia sobre o CSS Regions e o CSS Shaders. Tem também o PhoneGap.

Parabéns para Adobe.

Posts Relacionados

]]> http://tableless.com.br/adobe-e-os-padroes-web/feed/ 10 Tudo que você gostaria de saber sobre plugins jQuery e ninguém teve paciência de explicar http://tableless.com.br/tudo-que-voce-gostaria-de-saber-sobre-plugins-jquery-e-ninguem-teve-paciencia-de-explicar/ http://tableless.com.br/tudo-que-voce-gostaria-de-saber-sobre-plugins-jquery-e-ninguem-teve-paciencia-de-explicar/#comments Wed, 02 May 2012 12:10:14 +0000 Zeno Rocha http://tableless.com.br/?p=5999 Então quer dizer que você anda brincando com jQuery. Volta e meia utiliza uns plugins que mais parecem mágica e se duvidar até se aventurou em criar o seu próprio, acertei?

Acontece que, caso você já saiba desenvolver os seus, talvez possam existir melhores formas de escrevê-lo. Será que você está seguindo as melhores práticas? Será que realmente entende o que está acontecendo por trás de cada linha?

Hoje vou tentar responder as dúvidas mais frequentes, explorando as melhores práticas para se construir um plugin. E no fim lhe mostrar um padrão interessante que você pode seguir agora que já entendeu os conceitos.

A ideia aqui não é simplesmente mostrar como criar um plugin, mas sim como criar direito, explorando tudo o que o jQuery tem de melhor para nos oferecer.

Por que eu deveria construir um plugin?

Encapsulamento e reaproveitamento de código, essas são as palavras-chave. Se você está codificando algo que talvez sirva para futuros projetos, pode ser uma boa encapsular tudo isso em um plugin.

Entendi, quero criar um! Como faz?

Existem diversas formas, mas vamos começar com essa:

1
2
3
$.fn.meuPlugin = function() {
    // aqui vem a lógica
};

Esse é o mínimo que você precisa para iniciar o desenvolvimento de um plugin, basta adicionar uma propriedade ao $.fn.

Por mais trivial que isso possa parecer, muita gente não entende o que está acontecendo por trás disso exatamente. Portanto, antes de evoluirmos esse padrão, vamos recorrer ao código fonte da biblioteca, na sua versão mais recente, para entender de verdade esse pequeno trecho de código.

O que significa o cifrão ($) ?

O famoso $ nada mais é do que um “apelido” para o objeto jQuery. Próximo ao fim do código fonte da biblioteca encontramos a seguinte definição:

1
window.jQuery = window.$ = jQuery;

Isso significa que o mesmo objeto em memória pode ser referenciado de diversas formas: window.jQuery, window.$, jQuery ou simplesmente $.

Qual a diferença entre $.meuPlugin e $.fn.meuPlugin?

Possivelmente você já se deparou com plugins que não utilizavam a propriedade .fn. Mas afinal, por que eu deveria utilizar o .fn? Por que não apenas $.meuPlugin ao invés de $.fn.meuPlugin?

Novamente, ao nos aventurarmos no código fonte percebemos, logo nas primeiras linhas, como o objeto jQuery é definido.

1
2
3
var jQuery = function( selector, context ) {
    return new jQuery.fn.init( selector, context, rootjQuery );
}

Note que jQuery é uma função e no Javascript uma função é também um objeto do tipo Function. Por isso jQuery.meuPlugin (ou $.meuPlugin) irá atribuir meuPlugin para o objeto jQuery do tipo Function.

Dito isso, voltamos ao código fonte e veremos que jQuery.fn é a mesma coisa que dizer jQuery.prototype.

1
jQuery.fn = jQuery.prototype;

Portanto, a cada vez que você atribuir uma função (ou propriedade) para jQuery.fn, como em $.fn.meuPlugin, a função estará disponível para todas as instâncias desse objeto.

Isso é importante, pois quando você invoca a função $(), como em $(“#algumID”), uma nova instância é criada nessa linha:

1
return new jQuery.fn.init( selector, context );

E essa instância terá todos os métodos que atribuirmos ao prototype, mas não todos os métodos que foram atribuídos direto ao objeto Function.

Logo, vá de .fn.

Evite conflitos

Sabia que existem outras bibliotecas Javascript que também utilizam o símbolo cifrão para referenciar seus objetos? Pois é, isso pode lhe causar uma baita dor de cabeça se utilizar apenas aquele primeiro padrão proposto.

Logo, uma boa prática seria encapsular a lógica do plugin em uma função anônima. Assim, garantimos que não irá haver conflito entre o $ do jQuery com o $ de outras bibliotecas.

1
2
3
4
5
(function( $ ){
    $.fn.meuPlugin = function() {
        // aqui vem a lógica
    };
})( jQuery );

Dessa forma mapeamos o $ para que não seja afetado por nada fora desse escopo.

Não quebre a corrente

Então, você já entendeu como funcionam algumas coisas, vamos criar nosso primeiro plugin! Começaremos com o clássico exemplo de um Tooltip (aquelas caixinhas que aparecem no mouseover).

Criamos então a chamada para o plugin a partir de determinado seletor:

1
2
3
$(function() {
    $(".BlaBlaBla").tooltip();
});

E código do nosso plugin ficará definido assim:

1
2
3
4
5
(function( $ ){
    $.fn.tooltip = function() {
        this.css({ background: 'yellow' });
    };
})( jQuery );

Aparentemente tudo certo, já que o plugin funciona direitinho, certo?

Na verdade não, pois dessa forma estamos ferindo um dos princípios importantes que diferem os plugins bons dos ruins, e esse princípio se chama encadeamento.

No jQuery é muito comum vermos declarações do tipo:

1
$('div').show().addClass('BlaBlaBla').fadeIn();

Isso, porque é possível encadear diversas chamadas, a um mesmo seletor. E uma excelente prática por sinal, já que não criamos diversas instâncias como em:

1
2
3
$('div').show();
$('div').addClass('BlaBlaBla');
$('div').fadeIn();

Para permitirmos comportamento similar com nosso plugin basta retornar o this.

1
2
3
4
5
6
7
(function( $ ){
    $.fn.tooltip = function() {
        return this.each (function() {
            $(this).css({ background: 'yellow' });
        });
    };
})( jQuery );

Assim, além de garantirmos o encadeamento, também manipulamos a coleção passada para o plugin através do método each, muito similar a um loop com for por exemplo.

Como passar parâmetros e lidar com eles depois?

E que tal se evoluíssemos nosso plugin e resolvessemos passar como parâmetro a cor de fundo do nosso elemento.

1
2
3
4
5
$(function() {
    $(".BlaBlaBla").tooltip({
      'corDeFundo' : 'blue'
    });
});

Agora preparamos nosso plugin para receber os parâmetros através da variável options e aplicamos a propriedade corDeFundo no background.

1
2
3
4
5
6
7
(function( $ ){
    $.fn.tooltip = function(options) {
        return this.each (function() {
            $(this).css({ background: options.corDeFundo });
        });
    };
})( jQuery );

Maravilha, funcionou! Mas o que acontece se você resolve mais tarde não passar como parâmetro a cor de fundo? Nosso plugin quebra.

Portanto, não podemos nos esquecer de que precisamos nos preparar para receber esse conjunto de opções e assegurar que, caso não seja passado nenhum valor como parâmetro, nós possamos lidar com valores padrão.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(function( $ ){
    $.fn.tooltip = function(options) {

        var defaults = {
          'corDeFundo' : 'yellow'
        };

        var settings = $.extend( {}, defaults, options );

        return this.each(function() {
            $(this).css({ background: settings.corDeFundo });
        });

    };
})( jQuery );

Para isso recorremos a função $.extend que irá buscar os valores passados pela variável options e mesclar com os valores definidos na variável defaults, armazenando em outra variável chamada settings.

A procura da batida perfeita

Esse é só o começo para você que deseja se aprofundar um pouquinho mais nessa arte de criar plugins, para entender mais visite o guia oficial.

Mesmo que a ideia de se formar um padrão único para criar plugins seja utópico, sugiro fortemente que dê uma olhadinha no jQuery Boilerplate, lá você vai encontrar um padrão bem sólido para iniciar seus projetos, sem contar que a versão traduzida para português foi lançada hoje!

Mas se o buraco for mais em baixo e você for lidar com plugins stateful que controlam o estado dos objetos, confira o jQuery UI Widget Factory.

Lembre-se que o jQuery não é apenas uma caixa preta que faz mágicas pra você. Aventure-se no código fonte e verá que não é nada muito diferente do que você já faz com JavaScript puro.

E é isso, espero que depois desse artigo, você tenha evoluido de um simples “manipulador de plugins” para um criador de fato. Até a próxima!

Mais comentados

]]> http://tableless.com.br/tudo-que-voce-gostaria-de-saber-sobre-plugins-jquery-e-ninguem-teve-paciencia-de-explicar/feed/ 27 Entendendo quais APIs (realmente) fazem parte do HTML5 http://tableless.com.br/entendendo-quais-apis-realmente-fazem-parte-do-html5/ http://tableless.com.br/entendendo-quais-apis-realmente-fazem-parte-do-html5/#comments Wed, 02 May 2012 12:00:36 +0000 Talita Pagani http://tableless.com.br/?p=5981 Com o HTML5 ganhando força no mercado de desenvolvimento web, maior tem sido o interesse dos desenvolvedores em compreender seus recursos, novas APIs e tecnologias adjacentes. E é aí que acontece uma grande confusão.

Sabemos que o HTML5 não se trata apenas de marcação, mas também de um conjunto de novas funcionalidades encapsuladas em APIs que podem ser acessadas via JavaScript.

Porém, há APIs em processo de padronização pelo W3C que não fazem parte da especificação do HTML5. Elas são especificações relacionadas não intrínsecas ao HTML5, ou seja, a utilização delas não está estritamente atrelada ao uso da linguagem. Algumas, inclusive, faziam parte do core do HTML5, mas hoje estão dissociadas e contam com uma especificação separada, como é o caso do Web Storage.

As APIs próprias do HTML5 são mais específicas às funcionalidades que atuam no escopo da página e da manipulação de elementos. Elas se relacionam em grande parte com o DOM. Já as outras APIs geralmente trabalham com funcionalidades um pouco mais complexas, como armazenamento de dados e manipulação de arquivos, por exemplo.

Algumas das novas APIs que estão contidas na especificação do HTML5 são:

  • Canvas
  • Validação de formulários
  • Controles de áudio e vídeo
  • Application cache / offline applications
  • Funcionalidade de markup editável (contenteditable)
  • Drag and drop
  • Novas funcionalidades para manipulação do histórico do navegador

Algumas das novas APIs que são desenvolvidas em conjunto pelo WHATWG e W3C e trabalham muito bem com HTML5 mas que não são (mais) exclusivas dele:

  • Web Storage (localStorage e sessionStorage)
  • Web messaging
  • Microdata
  • Web Workers
  • Web Sockets

E algumas especificações relacionadas, que não são desenvolvidas pelo WHATWG e possuem especificações publicadas separamente pelo W3C:

  • Geolocation
  • File API
  • Indexed DB
  • File Writer
  • Notifications

O gráfico abaixo, desenvolvido por Sergey Mavrody fornece uma boa visão deste contexto e do relacionamento entre as novas APIs e o HTML, além de mostrar o status de desenvolvimento de cada uma destas especificações. Note que o Web Storage ainda está incluído junto à especificação do HTML5, mas isto já mudou.

HTML5 e as APIs relacionadas

HTML5 e as APIs relacionadas por Sergey Mavrody

Portanto, muitas vezes quando falamos das novas possibilidades do HTML5, na verdade estamos nos referindo à toda uma nova geração de tecnologias para a web.

O que podemos concluir disso tudo é que o HTML5, sozinho, não faz uma web melhor. Porém, ele ajudou a movimentar o mercado rumo ao desenvolvimento de novas tecnologias. Saímos da zona de conforto que já estávamos há alguns anos. O cenário que temos agora é de uma série de tecnologias web que, trabalhando em conjunto, fazem uma web melhor, para as pessoas e para os desenvolvedores ;)

Referências:

Especificação do HTML pelo WHATWG
W3C – HTML5 differences from HTML4
HTML5 – Wikipedia

Posts Relacionados

]]> http://tableless.com.br/entendendo-quais-apis-realmente-fazem-parte-do-html5/feed/ 3 Opera experimentando o -webkit- http://tableless.com.br/webkit-dominando-tudo/ http://tableless.com.br/webkit-dominando-tudo/#comments Mon, 30 Apr 2012 16:07:48 +0000 Diego Eis http://tableless.com.br/?p=6043 Eis que começou a bagunça.

Não importa o que o pessoal dos outros browsers falem, isso vai virar uma bagunça tremenda. Cada browser tem seu próprio prefixo. Os prefixos foram criados para facilitar a vida de todos os early adopters que queiram testar as novas features do CSS. O problema é que muitos desenvolvedores acabam utilizando apenas o prefixo -webkit- em seus projetos e por causa disso, os browsers como Firefox, IE e Opera estão pensando em suportar o prefixo do -webkit- além dos seus próprios. Isso daria margem para que a web fosse “controlada” por apenas um navegador. Foi aí que grande parte dos desenvolvedores começaram a se mobilizar para que os prefixos de outros browsers também fossem utilizados nos projetos… Leia mais sobre esse assunto aqui.

Parece que toda a apelação dos devs não está adiantando muito. A Opera se encheu e está experimentando o suporte do prefixo -webkit- no seu emulador mobile.

Vamos torcer para que os outros browsers não caiam na mesma besteira ou entrem em comum acordo de criar um prefixo único. Isso facilitaria as coisas, ou não.

Mais comentados

]]> http://tableless.com.br/webkit-dominando-tudo/feed/ 7