Por isso, aqui vão algumas dicas de propriedades que você já deve conhecer, mas que não usa ainda por que acha que todos os IEs são iguais ao maldito IE6.

:after

Você deve usar alguma técnica de clearfix que você criou ou que você pegou de algum lugar. Eu usava muito jquery para criar um elemento vazio dinamicamente no final do elemento que necessita do clearfix para fazê-lo parar de sofrer influência dos floats dos elementos. Essa técnica aqui pode salvar sua vida:

O content pode ser usado para uma série de outras coisas, como por exemplo inserir um ícone, objeto ou até texto depois de um determinado elemento.

Nesse caso o IE7 fica de fora.

first-child

Sim. O First-child funciona no IE7 ou superior. Mas o last-child não. Sem chance.
Isso já acaba com aqueles problemas de alinhamento de elementos em linha, onde você precisa tirar a margin, padding ou border do último (ou o primeiro) elemento para que eles fiquem alinhados corretamente.

Seletores complexos

Olha só que maravilha, o IE7+ já suporta alguns seletores complexos como os descritos abaixo:

Todos eles funcionam no IE7 ou superior. Só com estes seletores já economizamos uma penca de código Javascript.

:first-letter e :first-line

Formatar a primeira letra do parágrafo ou a primeira linha. Coisa linda.

word-wrap

Essa propriedade é utilíssima. Você já deve ter escrito uma palavra muito grande ou uma URL, que geralmente não tem espaços, o que ocasionou da string ultrapassar a largura do objeto. A propriedade word-wrap faz com que essas strings muito grandes quebrem de linha assim que atingirem o limite do objeto.

Essa propriedade funciona desde o IE5. O.o

max-height/width e min-height/width

Essas aqui são essências para produzirmos layouts fluidos e responsivos. Funcionam a partir do IE7.

Tabela de referência

O MSDN guarda uma tabela de compatibilidade muito completa com propriedades do CSS que os IEs suportam ou não. Vale a pena dar uma olhada e entender melhor o que você já pode usar nativamente do CSS em vez de sair escrevendo loucamente soluções JQuery.

Posts Relacionados

• Ferramentas de diagnóstico
• Desenvolvendo para IE6
• Ah, o maravilhoso mundo real
• IE8 – O sonho não acabou
• Sobre Internet Explorer para Mobile – Breve impressão

Recentemente os principais buscadores se reuniram novamente, só que agora com a participação do Yandex um novo buscador russo que afirma ser melhor que o Google. Os buscadores se uniram para definir uma nova marcação de dados estruturados, trata-se do Schema.

Historicamente, o Google tem apoiado três padrões diferentes para dados estruturados, (microdados, microformat e RDFa) com a vinda do Schema as coisas irão mudar já que é proposto por três dos mais influentes players da web.

O projeto Schema vem basicamente para ser uma central de recursos para desenvolvedores, para auxiliar e apoiar o vocabulário de marcação de dados estruturados nas páginas web. Para conferir o novo projeto ele está disponível no endereço schema.org.

Navegando na web você já deve ter visto em um resultado de busca algumas snippets mais interessantes, que mostram reviews de usuários, preços de produtos.

Com uma snippet assim você acaba chamando mais atenção na SERP do Google conseguindo assim mais cliques e consequentemente mais visitantes, essa é uma das vantagens de utilizar a marcação de dados estruturados mais conhecida como Rich Snippets (Trechos ricos de informação).

Introdução de como implementar

Para implementar o Schema em seu site é muito simples, em uma marcação HTML adicione a tag itemscope essa tag é responsável por identificar a seção da página que é sobre um determinado “assunto”, após especificar o itemscope é necessário atribuir o tipo desse “assunto”, para tal utilize a tag itemtype.

No Schema para determinados assuntos temos várias propriedades, por exemplo em um filme temos atores, diretor, preço, trailer, avaliações. Para atribuir essas informações para os motores de buscas  utilize a tag itemprop, veja um exemplo:

No código acima o “assunto” é o novo filme do Anderson Silva (Como Água) dirigido pelo diretor Pablo Croce com um link para um trailer do filme, por isso foi utilizado o itemtype “Movie”.

Desde 2004 o Google vem dando fortes sinais em relação a semântica e trechos ricos de informação, em meados de 2009 lançou uma ferramenta chamada Rich Snippets Testing Tool que tem como finalidade trazer uma amostra de como os Rich Snippets aparecereia nos resultados das buscas do Google.

Recentemente um executivo do Google anunciou uma das maiores renovações em seu algoritmo de busca, a ideia dessa atualização é que o buscador entenda da mesma forma que nós humanos entendemos o mundo, mais uma vez ressalto a importância de se ter um site semântico e bem estruturado.

Posts Relacionados

• Responsive Web Design – focando a coisa certa
• Seu lugar ao sol
• WebIntents – Framework para WebApps
• Utilizando APPs em vez de browsers
• Mobilidade na cabeça

O vídeo conta a história de um cara que faz de tudo para que os usuários não utilizem a velha versão do Internet Explorer, fazendo com que isso se torne um vício. Ele diz que os IEs antigos servem para apenas uma coisa: “baixar outros browsers”. Hell yeah!

A Microsoft tem promovido o IE9 por que é o IE que mais se adequa ao padrões web até agora. O IE10 é muito melhor, mas ainda não está nas prateleiras e provavelmente vai ser lançado de verdade somente com o Windows 8. O IE10 fica no páreo com os browsers mais atuais como Chrome, Firefox e Safari, mas o IE9 está fazendo um ótimo trabalho também e não dá tanta dor de cabeça como as versões antigas do browser.

Veja o vídeo e divirta-se.

Posts Relacionados

• Dicas de sobrevivência em uma era pós o IE6
• Schema – Marcação de dados estruturados
• Seu lugar ao sol
• Prefixos dos browsers: A web precisa de você
• Google Chrome para Android

Você realmente acha que vai escrever CSS e HTML como escreve hoje em um cenário como este?
Você já parou para pensar onde CSS/HTML e Javascript se encaixam em um ambiente onde a web é praticamente camuflada por APPs específicos? Eu não estou me referindo a estes Apps como conhecemos hoje. Podem ser Apps instaladas ou WebApps, neste futuro, dá na mesma. Não há diferença.

Pior do que pensar o lugar que CSS e HTML estarão é pensar em como VOCÊ se colocará em um ambiente tão novo quanto este. O que realmente iremos fazer? Qual será o papel de cada um? Será que a metodologia de trabalho será a mesma?

Você também já deve ter visto o vídeo acima. Veja como os personagens utilizam seus gadgets e como tudo está sincronizado. A discussão aí não é se é melhor criar uma App ou uma aplicação Web, é se o seu produto é realmente relevante e se vai ajudar realmente a vida das pessoas. A forma como isso é oferecido não importa, porque em um cenário como esse tudo é igual. Não faz diferença nenhuma. A Web não é só o seu browser.

É por isso que eu acho que os desenvolvedores precisam acordar. Urgente.
Eu perco as contas de quantos desenvolvedores me castigam quando eu digo para ignorar totalmente os browsers antigos. Você acha que um futuro como mostrado nos vídeos ou qualquer outro tipo de futuro, vai ficar esperando um browser ser adequado aos padrões? Aliás, browsers existirão?

Você precisa repensar o que realmente é vida digital. Qual a real utilidade de se carregar um celular dispositivo móvel. Repense o que será design responsivo. Eu sei que a necessidade de hoje é adaptar websites e aplicações para as diversas telas, mas entende que isso é só uma necessidade que vai passar rápido? Vai passar rápido não porque é uma modinha sem importância, mas porque isso deverá ser padrão daqui pra frente. Assim como o Tableless. Lembra que falavam que isso era uma modinha e que já já passaria? Pois é.

Experimente fazer o exercício de entender o futuro da web. É algo que todo profissional web deveria fazer, principalmente os desenvolvedores. Não importa qual linguagem de programação você vai precisar aprender ou desaprender, o que importa é como ela será aplicada. Isso muda tudo.

Embora a ideia não seja apenas direcionada a Mobile mas para todos os meios de acesso, vale muito a pena ver a apresentação que o Michel Lent fez. Dá uma olhada:

Posts Relacionados

• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Boas práticas de Acessibilidade
• Experiência deve ter começo, meio e fim
• Manipulando a metatag Viewport

A combinação da grande variação de browsers no mercado com as mais as novas features do CSS resultam em problemas de compatibilidade. Você quer utilizar uma feature que ainda está sendo estudada, e que somente o Firefox, por exemplo, suporta. Se você simplesmente utilizar a propriedade no seu CSS, os browsers que não suportam essa propriedade, ou que suportam mas com uma sintaxe diferente, podem dar problemas. Aí é que entra os prefixos de browsers.

O prefixo é muito útil para podermos experimentar features que ainda estão sendo estudadas e que são rascunhos nos documentos do W3C. Prefixos são úteis por que nos direcionam para um caminho seguro sob as inconsistências entre propriedades e browsers.

Como utilizar um prefixo

Não se assuste, se você utilizará uma propriedade de CSS que ainda está sendo planejada mas ainda assim quer aplicar em seu projeto para que os usuários de novos browsers possam usufruir com uma melhor experiência ao acessar seu site, seu código pode ficar um pouco confuso. Por isso, organize-se melhor ao decidir quais propriedades você gostará de experimentar.
Para exemplo vamos utilizar a propriedade border-radius. Se quisessemos fazer uma borda arredondada com 10px, faríamos assim:

Note que colocamos por último a propriedade verdadeira, sem nenhum prefixo, essa propriedade cobrirá os browsers que não precisam da utilização de prefixos para renderizar a propriedade, por exemplo o Opera e o Internet Explorer 9.

O problema

Atualmente estamos beirando a mesma situação citada no início do artigo. O Firefox, Opera e Microsoft estão pensando em suportar o prefixo -webkit-. O problema é que os desenvolvedores estão utilizando em seus projetos apenas o prefixo -webkit- para algumas propriedades do CSS3. Isto é muito ruim.

Se todos os browsers suportarem um mesmo prefixo o mercado será “controlado” por apenas um fabricante de browser que poderá ditar as regras sobre quais propriedades do CSS poderão ser implementadas primeiro. Ok, ok, meu sonho era que um browser sob o engine webkit dominasse mesmo. Mas isso foi quando o IE era o browser mais utilizado e a Microsoft não havia aberto os olhos ainda. Mas concorrência é ótimo em qualquer lugar, até na web.

O pessoal está conversando sobre algumas possibilidades de soluções. Uma interessante e na minha opinião mais inteligente, é a criação de um prefixo neutro, utilizado por todos os browsers para indicar novas features. Algo como -alpha- ou -beta- e assim por diante.

Todos os grandes nomes da web estão se mobilizando para que a web não fique em volta de um único browser. Tenha em mente que o pessoal do -webkit- não está fazendo nada de errado, nós estamos.

Daniel Glazman, Co-chairman do W3C CSS Working Group escreveu um post, muito preocupado e chamando toda a comunidade de desenvolvedores a adequarem seus sites e a entenderem o grande problema que isso pode ser tornar. Veja uma parte do post:

Without your help, without a strong reaction, this can lead to one thing only and we’re dangerously not far from there: other browsers will start supporting/implementing themselves the -webkit-* prefix, turning one single implementation into a new world-wide standard. It will turn a market share into a de facto standard, a single implementation into a world-wide monopoly. Again. It will kill our standardization process. That’s not a question of if, that’s a question of when.

Veja o post completo aqui.

O Web Standards Project também se mobilizou.

E aí? Vai mudar sua atitude? O que você pensa sobre isso?
Como você pode ajudar?

Assine essa petição para os fabricantes de browsers não suportarem o prefixo webkit e espalhe para seus colegas a notícia. E claro, ao usar os prefixos para os browsers, utilize todos e não apenas um.

Foto do post

Posts Relacionados

• Dicas de sobrevivência em uma era pós o IE6
• Drops 9 – Préprocessadores, frameworks e bibliotecas
• Adobe e os Padrões Web
• Schema – Marcação de dados estruturados
• O browser que você amou odiar

O Google acaba de lançar o Google Chrome para Android. Antes que você fique todo alegre, o Chrome para Android só está disponível para os usuários do Ice Cream Sandwich ou tablets. Ele é baseado na simplicidade do Chrome para desktops, prometendo a experiência de navegação.

Eles reimaginaram o uso de tabs para os mobiles, e nas tablets a utilização as tavs ficaram similares com o Chrome para Desktops. Temos também incluído nessa versão mobile o famoso “Porn mode” ou o Incognito, que é o modo de navegação privativa.

O Google Chrome para Android ainda está em fase beta e você pode baixá-lo no MarketPlace mais próximo.

Uma boa notícia para toda a comunidade de desenvolvimento web mobile. A briga fica acirrada entre os sistemas. O que é bom para nós e para os usuários. Agora oremos para que o IE10 para Windows Phone saia logo, o que eu duvido. Acho que ele somente virá com o Windows Phone 8. Entretanto temos um ótimo cenário quando falamos sobre browsers para mobiles.

Posts Relacionados

• Dicas de sobrevivência em uma era pós o IE6
• Schema – Marcação de dados estruturados
• O browser que você amou odiar
• Seu lugar ao sol
• Prefixos dos browsers: A web precisa de você

Cada um destes personagens tem papéis importantes para que a evolução da web possa se tornar forte, traçando novos caminhos, cobrindo as necessidades atuais dos usuários e prevendo necessidades e soluções futuras. Há um ciclo para que estes personagens possam cumprir com seus objetivos.

O W3C cuida dos padrões. Ele tem ideias, ele prevê problemas e tenta solucioná-los. O W3C não aplica, ele apenas planeja. É um trabalho difícil, por que é necessário uma visão muito apurada do cenário da web para saber quais caminhos ela deverá tomar. Uma decisão errada, pode acarretar problemas que levarão anos para serem solucionados por completo. Vide o desenvolvimento com tabelas. Por isso esse trabalho de planejamento deve ser meticuloso. Devo confessar que em muitos casos o W3C não supera as expectativas e faz com que iniciativas paralelas surjam e direcionem a Web para um caminha mais correto. Foi o que aconteceu com o HTML5.

Os browsers, por sua vez, precisam entender e adotar as idéias do W3C, absorvendo as soluções e criando suporte nos seus softwares. Esse trabalho também tem seus perigos. Os browsers precisam pesquisar quais das necessidades dos desenvolvedores é mais importante e assim implementá-la para que a utilização de projetos seja executada. Obviamente que alguns decidem suportar aquelas soluções que darão mais pontos estratégicos contra o concorrente.

Finalizando o ciclo, os desenvolvedores aplicam tudo o W3C define, mas apenas aquilo que os browsers “querem” ou podem suportar. E isso, claro, faz com que o desenvolvedor se depare com problemas na ponta produção. Vide o IE6/7/8 e nossos problemas de cada dia.

Durante muito tempo, esse ciclo não era afinado. Havia uma certa confusão e um jogo de interesses próprios envolvendo principalmente os browsers. O W3C estava apenas pensando em como resolver problemas que talvez existiriam daqui longos anos. Os browsers estavam apenas interessados em criar uma massa de usuários suficiente para ser o primeiro no ranking. Os desenvolvedores, por sua vez, queriam ganhar seu dinheirinho, fazer o trabalho, entregar pro cliente e acabar com o problema.
Ninguém deu atenção quando começamos a desenvolver com tabelas, fazendo com que os sites ficassem mais pesados, aumentando o tempo de desenvolvimento e o custo do projeto.

Este ciclo defeituoso foi praticado durante muito tempo. Por incrível que pareça, foram os Desenvolvedores que começaram a fazer o ciclo funcionar novamente como deveria. Eles acordaram os fabricantes de browsers e também o W3C.

O W3C passou a pensar mais em problemas presentes. Solucionou problemas iminentes e que entregavam valor para os projetos.

Os browsers suportaram o mais rápido possível essas mudanças, atualizando seus engines, e fortalecendo as bases para novas soluções e flexibilizações posteriores.

Já os desenvolvedores estagnaram. Desculpe-me, serei um pouco revoltado daqui para frente. Os desenvolvedores dormiram. Quando o W3C e os browsers apresentaram soluções para problemas como transparência, bordas arredondadas, backgrounds inteligentes, utilização de fonts remotas e etc, os desenvolvedores resolveram que não era a hora dessas soluções por causa da retrocompatibilidade com browsers antigos, como o IE6. Na verdade estou sendo meio injusto aqui. Não foram todos os desenvolvedores que criaram caso com a retrocompatibilidade, foram somente os idiotas.

Nós reclamávamos que precisávamos de recursos mais inteligentes para trabalhar. Que precisávamos de idéias realmente inovadoras, que transformassem os projetos e facilitassem o desenvolvimento. Protestamos, escrevemos manifestos, postamos em nossos blogs revoltados com a falta de visão do W3C e com a pobreza do suporte dos browsers. E quando conseguimos o que queríamos, demos para trás. Amarelamos. Pedimos arrego.

Infelizmente, via-se muito disso aqui no Brasil do que no resto do mundo. Ouvi muitas desculpas como: – “Mas meu cliente usa IE6.” ou “Mas isso não funciona em IE6.” Você é desenvolvedor. Você trata com seu cliente todos os dias. Você tem o poder de educar e convencer. E se você acha que não tem poder nenhum, por que ainda trabalha com web?

Talvez isso seja trauma do passado. Talvez não. O fato é que não podemos mais nivelar por baixo. Isso é atrasar uma “evolução” inteira.

Tenho incansavelmente falado sobre Graceful Degradation, Enhanced Progressive, HTML 5, as maravilhas do CSS 3 e etc, pois esse é o assunto que rola lá fora. Há desenvolvedores e empresas, que acham que devemos ter uma autorização especial dos gringos para utilizarmos novas tecnologias e principalmente para deixar os browsers antigos no passado.

Esse assunto me faz pensar em outra pergunta: Estamos (você está?) preparados para o ritmo alucinante do W3C e dos browsers?
Até a Microsoft está cumprindo com a palavra de ter um browser atualizado. Eles já anunciaram o novíssimo Internet Explorer 10, com uma série de atualizações que promete trazer o IE para o patamar de browsers atuais.

O mercado de client-side se transformará rapidamente nos próximos anos. Muitas mudanças no HTML e no CSS serão publicadas com o intuito de tornar a web mais homogênea, flexível, portável. O HTML 5 não é só uma coleção de novas tags e APIs. O CSS 3 não ganhou só bordas arredondadas. E nem só de iPhone vive o homem. Existem milhares de Nokias, Blackberrys, Windows Phones e Androids por aí.

Os desenvolvedores precisam acordar.

Artigo originalmente publicado em Nov/2009 na revista TI Digital.

Posts Relacionados

• GoMo – Teste seu site mobile
• Introdução aos padrões de codificação
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Seu lugar ao sol
• ePub: Aprenda a criar um livro digital

O que você tem que fazer é simples:
- Você só pode enviar CSS.
- O seu código CSS deve ter 1K (1024 bytes), minificado.
- Não precisa utilizar prefixos de browsers, eles colocarão lá para você, logo, você pode usar as coisas bacanas de CSS que só funcionam em browsers (não o IE).
- O Design não precisa ficar igualzinho em todos os browsers, mas gracefull degradation é uma boa pedida.
- Seu código é submetido sob a licensa MIT.

Eles dão o código HTML que você não pode modificar em hipótese alguma, se não acaba a graça da brincadeira.

E aí, consegue?

Posts Relacionados

• Agora é a vez dos desenvolvedores
• Um pensamento sobre design para web
• Dicas de sobrevivência em uma era pós o IE6
• Qualidade de Imagens e densidade de pixels
• Seu lugar ao sol

A boa experiência no design de impresso depende muito da arte inspiradora do designer, qual o papel usado, que tipo de impressão, da gráfica… em web dependemos muito do tamanho da tela, do dispositivo utilizado, do browser, da configuração do texto, velocidade da internet e do computador. São muitas variações para tentarmos manter o controle de cada detalhe.

Quando um designer faz peças para uma campanha ou algum projeto offline, dependendo do caso é necessário criar peças para diversos formatos de veiculação em outdoors, revistas, posters etc. Em relação a web, nós temos todos os formatos de telas que envolvem tablets, notebooks, monitores, TVs e celulares… Com um diferencial: cada uma dessas telas tem um tipo de comportamento diferente dependendo da manipulação do dispositivo e também do usuário. Em alguns dispositivos como tablets e mobiles em uma tela temos dois formatos: retrato e paisagem. Já no impresso não há manipulação pelo usuário. A estimulo é totalmente visual e muitas vezes tátil. Mesmo assim, a experiência que a web entrega é totalmente outra.

No design impresso, quanto mais proporcional, harmoniosa e equilibrada for a peça, melhor será recebida. No design para web também, mas os layouts precisam ser harmoniosos em cada um dos dispositivos, precisa ser proporcional em cada navegador, além da acessibilidade para alcançar usuário distantes.

Mas em ambas a personalidade é a plataforma para a emoção do usuário. Seja online ou offline, o layout, a forma com que o usuário o consome deve leva-lo para uma experiência diferente do normal. E não estou falando de hotsites feitos em flashs ordinários puramente comerciais.

Eu queria ser designer para entender melhor os conceitos que envolvem esse assunto e talvez explicar tudo isso com mais propriedade.

Assim como não é possível escrever uma linha de código sem saber os porquês da importância do código semântico e acessível, não é possível desenhar um website sem ter a plena certeza de que qualquer usuário terá uma experiência envolvente e agradável.

O design para web está mudando de novo outra vez por causa da explosão de novos dispositivos. Se você ainda não parou para pensar, pense: faça as contas das telas: notebooks, monitores, tablets e smartphones. Sendo que cada uma destes tipos de telas tem diversas variações de tamanho e principalmente de resoluções. Já disse que a experiência do usuário precisa ser cross-device, caso contrário, algo se perde.

Eu queria mesmo era fazer um carro.

Posts Relacionados

• Experiência cross-device
• Adobe e os Padrões Web
• Qualidade de Imagens e densidade de pixels
• Agora é a vez dos desenvolvedores
• CSS1K

O problema a ser resolvido é que se quisermos criar um sistema que utilize algumas facilidades de outros sistemas, nós precisamos aprender a API deste determinado sistema. Acontece que as APIs não são iguais. Se você quer utilizar um sistema de localização como Foursquare ou Gowalla, você precisa aprender como a API de cada um funciona e então escolher entre um dos dois ou utilizar os dois no seu sistema. Nesse caso, você tem o dobro do trabalho para manter seu sistema. Os dois podem modificar partes da sua API e você tem que ficar atento para que seu sistema não quebre. O WebIntents faz com que você consiga usar um comando para os dois serviços.

Web Intents, based on an existing capability in Google’s Android mobile OS, will let Web apps express a simple call for an action, like ‘share’ or ‘edit,’ which receiving apps will be designed to use, without either app needing to have specific knowledge of the APIs of the other. This way, instead of having to code for each specific Web app one might want to access, developers can just use these simple requests, which will be built into the browser. The Chrome and Firefox teams are each building this functionality for their own browser, but they’re combining their proposals to use a single API for Web app developers to reach both platforms.

Paul Kinlan, o dono da ideia e desenvolvedor do Google, explica no em um post no seu blog o que é o WebIntents:

“If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user.”

Não é de hoje que iniciativas de desenvolvedores e grandes empresas tomam forma para que o desenovlvimento web fique cada vez mais fácil e menos trabalhoso. Isso aconteceu com muitos grupos de desenvolvedores, como o pessoal da WaSP, o pessoal da WHATWG e mais uma vez agora com o pessoal do WebIntents. Claro, existem outras iniciativas anônimas que nos fizeram chegar até aqui.

Eu gosto muito muito de uma frase do pessoal da WaSP utiliza há tempos: If not now, when? If not you, who?

Veja aqui o GitHub do Framework.

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis