Arquivo da tag: css3

projetando para o ipad

Fonte: http://www.8164.org/designing-for-the-ipad/

por Jin, 04-12-10
I decided a while back that I wasn’t going to get an iPad. Instead, I’d wait for the second generation iPad next year. This has been my approach when it comes to new Apple products. Yes, I’m scared of the early adopter regret. As the launch date neared, my mind changed a bit. My wife is an avid book reader, and I thought it’d be a perfect device for her. But more importantly, I think the iPad will have a significant impact on how us web designers approach interaction design for this medium and the coding behind it. I need one to tinker with.

I bought one on Saturday. I love it. I won’t get into the philosophical aspects that have been debated by many recently, instead I’ll focus the rest of this post on web design/development for iPad’s Mobile Safari. Creating web sites that look and behave consistently on different browsers and versions have been the bane of us web designers’ existence since Mosaic/Netscape days. While I’m happy with the experience surfing on the iPad, I can’t help but to think, “argh another browser.” Even though Mobile Safari on the iPad is identical to iPhone’s, but the term “optimized for mobile” means differently for each device. The iPhone optimized sites are often minified version of the desktop sites, for speed and better use of screen real estate. The iPad’s browser offers the desktop experience, so it should be treated as one. I divided the rest of this post to two sections: iPad ready and iPad optimized, depending on how far you want to customize your site for iPad.

ipad ready

In my opinion, for a site to be “iPad ready” simply means that all the content and functionality are accessible via the iPad. Sites that were written according to the web standard are in a good shape already. A few things to consider:

  • Flash – It’s unlikely that Apple will allow Flash on its mobile devices anytime soon, or ever. Sites that are done entirely in Flash will have to have a HTML alternative(as they should anyways). I embed Youtube and Vimeo videos on this site sometimes. Even though they both support HTML5 <video> on their sites, unfortunately as of now they do not generate embed codes in HTML5. I recently discovered Video for Everyone by Kroc Camen. It’s a great code snippet that plays hosted or embedded videos as HTML5, with Flash/Quicktime as fallback. html5media also has a Javascript file that enables <video> and <audio> for major browsers.P.S. I can’t figure out how this embedded Youtube video is being displayed properly without any HTML5 embedding code. Please let me know if you know the answer.
  • Mouse Events – Make sure your site’s functionality does not rely purely on mouse events (mousemove, mouseover, mouseout, and CSS :hover) . Mobile Safari can trigger onMouseover, but it involves quite a bit of timing and effort on the user. You need to press down on the element that has the onMouseOver event and release fairly fast. To make it easier for the user, either remove unnecessary mouse events or have a visible link that reveals the hidden elements. A good example of inaccessible functionality is twitter’s web interface. You cannot hover therefore you lose the ability to retweet or reply.
  • Scrolling Content – The default one-finger swipe on iPhone/iPad triggers window.scroll(). Two-finger swipe has the same effect as the mouse scroll wheel. Not a lot of users may know this, therefore I think it’s best not to have content in scrolling in fixed sized block elements such as <div>s. The Safari Reference Library has good documentation on handling events.
  • Fixed Positioning – In short, don’t use it:

    Safari on iPad and Safari on iPhone do not have resizable windows. In Safari on iPhone and iPad, the window size is set to the size of the screen (minus Safari user interface controls), and cannot be changed by the user. To move around a webpage, the user changes the zoom level and position of the viewport as they double tap or pinch to zoom in or out, or by touching and dragging to pan the page. As a user changes the zoom level and position of the viewport they are doing so within a viewable content area of fixed size (that is, the window). This means that webpage elements that have their position “fixed” to the viewport can end up outside the viewable content area, offscreen.

    But if you must, Richard Herrera has a work around.

  • contenteditable – Mobile Safari currently does not support contenteditable attribute. Use a styledtextarea instead.
  • Disabling Cut/Copy/Paste Dialog – Pressing down on a text block or image brings up the Cut/Copy/Paste dialog box by default. Sometimes this behavior is not desired. For example, when pressing the top link of a navigation menu. To disable this, use -webkit-user-select: none.

ipad optimized

Fortunately, Safari is one of the leading browsers to support HTML5 and CSS3. If you want to take advantage of all iPad’s mobile Safari has to offer, here is some useful info:

  • User-agent StringMozilla/5.0(iPad; U; CPU iPhone OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B314 Safari/531.21.10

    David Walsh’s recent post shows how to detect iPad using Javascript, PHP and .htaccess redirection.

  • Media Query – In a way, designing for iPad is a bit easier since the screen is fixed to two sizes(portrait and landscape). We can take advantage of this by using Media Query.<link rel="stylesheet" media="all and (orientation:portrait)" href="portrait.css">
    <link rel="stylesheet" media="all and (orientation:landscape)" href="landscape.css">

    Please keep in mind, just because you can, doesn’t mean you have to. I don’t recommend making the two sets of styles drastically different from each other because it’d make the users relearn the UI. One case where I can see it’d be useful is when in portrait mode, show only the main content of the site; when in landscape, display more meta info. For example, on a blog site, show just the post body in portrait, and unhide the meta navigation, Ads blocks when in landscape.

    Jason Grigsby has a simple demo page to display different CSS styling depending on the orientation.

  • Format Detection – On iPhone, Safari automatically renders telephone numbers as a link to call. On the iPad the default action is to add the number phone to Contacts. You can disable this by:<meta name="format-detection" content="telephone=no">
  • Viewport setting – Do not use hard-coded pixel for view port dimensions. Use device-width instead.<meta name="viewport" content="width=device-width" />
  • Disable Automatic Format – Automatic Correction and Automatic Capitalization are default behaviorsfor text input. But sometimes you may not want inputs to be auto formatted. For example, inputting user name and passwords. To disable them:<input type="password" autocorrect="off" autocapitalize="off">
    <textarea rows="4" cols="50" autocapitalize="off"> </textarea">
  • Keyboard Types – You can make make it easier for the users by presenting content appropriate keyboards by using the new HTML5 attributes:Text: <input type="text" />
    Telephone: <input type="tel" /> 
    URL: <input type="url" /> 
    Email: <input type="email" /> 
    Zip Code: <input type="text" pattern="[0-9]*" />
  • Multi-Touch Event Handling – You can bind a touch event to mimic any other event. For example, make one finger swipe to mimic a two finger swipe on a DOM object. There are cases where you may want to override the defaults. For example, wouldn’t it be nice if you can swipe navigate an Image/content slider box than having to press the next/prev links? If you’re interested, you may find these JQuery plugins helpful: jQuery SwipeMultiswipe and JQTouch.

 

 

Sites usando HTML5 e CSS3

Fonte: James Leme/cssextremo

O uso do HTML5, em combinação com CSS3, está realmente começando a decolar. Safari, Chrome e Mozilla estão dando mais suporte a cada nova versão de seus navegadores.

A melhor maneira de aprender novas técnicas é tentando. Atualmente você já pode começar a usar HTML5 apenas mudando o tipo de documento.

<! DOCTYPE HTML>

Ele vai validar com o seu código atual, mesmo se você estiver usando XHTML ou HTML.

Para você se inspirar e começar a usar HTML5 e CSS3, listei alguns dos melhores sites usando essas tecnologias.

Edgar Leijs

Vaullt

Ella Design

Background adaptável a qualquer resolução de tela com CSS 3

Fonte: Gustavo D. Castro/CriarNet

Definir o background de um site pode parecer tarefa simples, mas não é, o background é uma parte importante de um site e quando mal escolhido pode desvalorizar com qualquer arte que tenha sido desenvolvida para o layout, atualmente vem se utilizando muito backgrounds fixos que geralmente deixam os sites mais botinos e com um tom de modernidade, o grande problema de usar background que não se repetem é que dependendo da resolução de tela a imagem escolhida vai além da resolução de seu visitante cortando as vezes partes importantes da imagem ou as vezes a imagem escolhida é pequena para o tamanho de resolução de tela do visitante.

Para fazer com que uma imagem se adaptasse bem a qualquer resolução de tela existiam várias possibilidades, mas nenhuma que não passasse perto do que chamamos de gambiarra.

Com a chegada do CSS 3 podemos fazer com que uma imagem fique como background se adaptando a qualquer resolução de tela se expandindo por toda a tela e perdendo o mínimo possível de sua proporção. Esse tutorial é destinado a pessoas que desenvolvem sites na internet.

Como colocar uma imagem como background que se adapta a qualquer resolução de tela.

Para adicionar qualquer imagem como background e fazer com que ela se adapte a resolução de tela do visitante é fácil, veja o código abaixo:

body {
background-image: url(caminho/sua/img/bg.jpg);
background-repeat: no-repeat;
-moz-background-size: 100% 100%;
-webkit-background-size: 100% 100%;
background-size: 100% 100%;}

Modifique a url para o endereço correto de sua imagem que deve estar em uma boa resolução, costumo criar minhas imagens nos tamanhos 1300px x 700

Tudo pronto, agora o seu site já possui um background que se adapta a qualquer resolução de tela.

Curta nossa Fan-Page

Caixa de Feed Simples com CSS3

Fonte: Iago Melanias/BlogandocomFacilidade

No artigo de hoje, aprenderemos como inserir uma caixa de feed simples no Blogger. Precisamos sempre achar formas de conseguir mais leitores fidelizados, os feeds ligam muito os leitores aos blogs, e as caixas de assinar feed são táticas para conseguir mais assinantes. A caixa possui gradientes com CSS3 e tem um Design bem interessante. Temos abaixo a imagem que demonstra bem o que vamos inserir.


Vamos ao Tutorial:

1º – Acesse o painel do seu blog e clique na guia modelo.

2º – Clique no botão Editar HTML e segure as teclas CTRL+F e procure por:

]]></b:skin>

3º – E, acima dele, cole o seguinte código:

#input-rss {
width: 185px;
padding: 8px;
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
border-radius: 3px;
-webkit-box-shadow: rgb(204, 204, 204) 0px 0px 8px 0px inset;
box-shadow: rgb(204, 204, 204) 0px 0px 8px 0px inset;
-moz-box-shadow: rgb(204, 204, 204) 0px 0px 8px 0px inset;
border: 1px solid #CCC;
font-size: 12px;
height: 15px;
border-image: initial;
float: left;
margin-right: 6px;
}
#input-rss:focus {
border: 1px solid gray;
outline: none;
}
#btn-assinar {
cursor: pointer;
margin-top: -7px;
height: 31px;
color: white!important;
background: #1F9CD8;
background: -moz-linear-gradient(top, rgba(31, 156, 216, 1) 0%, rgba(14, 131, 201, 1) 100%);
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,rgba(31, 156, 216, 1)), color-stop(100%,rgba(14, 131, 201, 1)));
background: -webkit-linear-gradient(top, rgba(31, 156, 216, 1) 0%,rgba(14, 131, 201, 1) 100%);
background: -o-linear-gradient(top, rgba(31, 156, 216, 1) 0%,rgba(14, 131, 201, 1) 100%);
background: -ms-linear-gradient(top, rgba(31, 156, 216, 1) 0%,rgba(14, 131, 201, 1) 100%);
background: linear-gradient(top, rgba(31, 156, 216, 1) 0%,rgba(14, 131, 201, 1) 100%);
filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#1f9cd8', endColorstr='#0e83c9',GradientType=0 );
border: 1px solid #085988;
font-size: 17px;
color: white;
-webkit-border-radius: 3px;
-moz-border-radius: 3px;
border-radius: 3px;
padding: 8px;
cursor: pointer;
float: left;
line-height: 12px;
text-shadow: 1px 1px 1px #117AAB;
filter: dropshadow(color=#117aab, offx=1, offy=1);
border-image: initial;
}
#btn-assinar:hover {
background: #1F9CD8;
}

4º – Depois, clique em Salvar Modelo.

5º – Agora, vá até a guia Layout e clique em Adicionar Gadget.

6º – Selecione o Gadget HTML/Javascript e no conteúdo dele cole o seguinte código:

<form action="http://feedburner.google.com/fb/a/mailverify" method="post" target="popupwindow" onsubmit="window.open('http://feedburner.google.com/fb/a/mailverify?uri=NOME DO SEU FEED', 'popupwindow', 'scrollbars=yes,width=550,height=520');return true">
<input style="display: initial;" id="input-rss" class="input-rss" type="text" name="email" />
<input type="hidden" value="NOME DO SEU FEED" name="uri" /><input type="hidden" name="loc" value="pt_BR" />
<input id="btn-assinar" class="mais" style="width: 90px;margin-top: 1px;font-size: 15px;" type="submit" value=" ASSINAR " />
</form>

Lembre-se de substituir as duas partes que tem “Nome do seu Feed”.

7º – Depois, clique em Salvar.

Criando aplicativos móveis com PHP

Texto original: http://phpadvent.org/2010

Fonte: BlogdoExpert

Há um bom tempo, o PHP era a escolha óbvia para as necessidades de todo programador. Ele estava disponível em todos os servidores web virtuais, tinha excelente documentação, e conseguia lidar com todas as necessidades dos programadores. Essas coisas são ainda mais verdadeiras hoje, e o PHP ainda é o middleware de escolha da maioria dos profissionais da área. No entanto, o uso do PHP mudou nos último anos.

Durante uma solicitação típica de página, o PHP fazia coisas como começar uma sessão, consultar um banco de dados, processar alguns dados, e, finalmente, gerar uma tonelada de métricas de HTML que seriam retornadas para o browser do usuário. Em outras palavras, toda a interface do usuário era gerada no lado do servidor pelo PHP. Ocasionalmente, era possivel incluir o prototype.js ou jQuery para fazer um pouco de validação de formulário, ou uma lista dropdown com um campo para “auto-completar”.

Mas então veio o iPhone…

Em 2007, o iPhone deu início a uma onda de interesse em computação móvel. Como milhares de desenvolvedores maravilhado por aquele pequeno dispositivo mágico que colocou a web no bolso de muita gente. Sempre conectado, navegadores excelentes, interação de toque intuitiva – é de fato incrível, e todos queriam entrar nessa de cabeça.

Quando o iPhone foi anunciado pela primeira vez, Steve Jobs pediu ao desenvolvedores terceirizados que construíssem aplicativos web se eles quisessem programar para o iPhone.

Claro que Jobs acabou voltando atrás menos de um mês depois, com o anúncio do Cocoa Touch e a iTunes App Store. E a guerra santa entre “web apps” e “apps nativos” nasceu.

E o que isso tem a ver com PHP?

Felizmente, agora temos a convergência de novas tecnologias que tornam a construção de web apps – móveis e outros – muito mais fácil.jQTouch, Sencha Touch, e mais recentemente, jQuery Mobile tornaram a vida mais fácil para escrever JavaScript para browsers móveis. O CSS3 nós dá transformações, transições e animações que nos permitem facilmente adicionar efeitos visuais sofisticados. E, mais drasticamente, o HTML5 define uma enorme quantidade de novos recursos  —  geolocalização, canvas, sockets, workers, armazenamento de dados do lado do cliente, suporte a cache offline da aplicação, cross-origin resource sharing, e por aí em diante.

Como resultado,muitas pessoas podem criar suas próprias UI com HTML estático, CSS e documentos JavaScript que conversam com uma API do lado do servidor construída com PHP. Esta abordagem baseada em API pode minimizar, de fato, a quantidade de dados enviados através do fio, porque é possível esconder os arquivos estáticos localmente, e somente requisitar atualizações de dados relativamente pequenos do PHP (normalmente na forma de JSON). Isso também tem grandes vantagens secundárias. Aqui estão as três maiores:

1. Divisão de trabalho:

Uma vez que você tem configurado uma API do lado do servidor, você pode facilmente ter seu trabalho de design do aplicativo no front end sem saber o mínimo de PHP, linguagens de templates, ou qualquer outra tecnologia do lado do servidor. Você não tem nem que dar acesso ao servidor para o designer – ele pode codificar contra a API com os arquivos no seu desktop.

2. Clientes múltiplos

O cenário da informática está sob massivo crescimento e transformação. Estamos vendo telas tão pequenas quanto cartões de credito, e tão grandes quanto um outdoor. E está acontecendo também uma grande separação entre dispositivos que suportam entrada de toque, de mouse e, em menor número, de voz.

Diferenças no tamanho físico, modos de interação e capacidades do dispositivo exigem que forneçamos experiências otimizadas ao usuário para o terminal em questão. Expor uma API do lado do servidor, construída em PHP, possibilita o suporte a clientes front end, sejam eles clientes menores, construídos em HTML, CSS, e JavaScript, ou maiores, construídos com frameworks nativos.

Os benefícios dessa abordagem têm sido demonstrados pelo Google, Yahoo, e, talvez, mais dramaticamente pelo Twitter, que documentou e lançou uma API simples para a comunidade de desenvolvedores. Graças a isso, todos os clientes do Twitter encontraram seu caminho no mundo digital. Começando com uma API que permite esse tipo de flexibilidade, que parece infinita, certamente ela contribuiu imensamente para a aceitação do Twitter.

3. À prova do futuro

O cenário da informática está evoluindo e é muito difícil prever o que vem a seguir. Muitas pessoas inteligentes estão trabalhando em novas tecnologias que irão mudar a maneira com que interagimos com computadores, e mais importante, um com o outro. Tudo, desde projeções holográficas de eventos de esporte ao vivo, até entradas das ondas cerebrais dos usuários estão em jogo. A melhor maneira de se manter flexível à vista de novos desenvolvimento é fornecer uma API robusta para lidar com o máximo do levantamento do back end possível.

Comece com sua API

Para trabalho web front end, você vai querer se familiarizar com a nova maravilha que é o HTML5 e o CSS3, e mais importante, aprender JavaScript! É uma sintaxe muito parecida com PHP e ela deveria parecer bem familiar para você (existe até um artigo do PHP Advent sobre isso). No entanto, existem muitas diferenças importantes entre PHP e JavaScript que você realmente precisa entender antes de se auto intitular um especialista. O livro JavaScript: The Good Parts, de Douglas Crockford é recomendado. Se você programa para a web, deve lê-lo.

Para finalizar, nunca houve um momento melhor para ser um desenvolvedor web. A convergência de uma conectividade ubíqua, serviços de cloud e telas de toque interativa estão criando um ambiente onde qualquer um pode construir experiências do usuário convincentes que tenham um alcance massivo com uma barreira de entrada muito pequena. Então volte para seu editor de texto e comece a codificar.

OOCSS ou CSS do jeito certo

O CSS é algo muito simples de ser escrito mas com apenas um deslize todo o código pode transformar o projeto em um inferno. Saiba como podemos evitar isso.

O conceito

Escrever CSS é fácil. Isto não deveria ser um problema, mas é. Por ser fácil os desenvolvedores acabam se esquecendo de princípios básicos, técnicas e metodologias que nos ajudam a manter o controle durante a produção. Entenda que algumas dessas metodologias não precisam ser aplicadas em sites pequenos. Por exemplo, aqui no Tableless eu não modularizo o CSS em vários arquivos por um ou dois motivos: 1) Somente eu tenho acesso ao código. 2) O site não é grande. Ele tem meia dúzia de páginas e funcionalidades.

Mas quando falamos de sites grandes (em visitação e quantidade de páginas) existem algumas restrições: velocidade de carregamento, compatibilidade entre browsers, manutenção, flexibilidade para mudanças etc. Tudo isso deve ser pensado e planejado antes de colocarmos a mão na massa. É no planejamento que iremos estruturar como serão feitas as manutenções posteriores, como iremos mudar elementos principais sem interferir no layout como um todo.

O CSS Orientado a Objeto (em inglês OOCSS – Object Oriented CSS – Sendo sincero, esse nome é muito ruim) tem como conceito técnicas que já falamos durante muito tempo, mas que como o Responsive Web Design, está ganhando força somente agora.

Princípios

O OOCSS está baseado em dois pontos cruciais que são a separação da estrutura e do visual e a independência do container em relação ao conteúdo.

Separação da estrutura e do visual

A maioria dos elementos estilizados em uma página web tem diferentes características visuais que são repetidas em diferentes contextos e situações. Algumas características são fáceis de identificar como cores, títulos, gradientes, bordas etc. Essas são características visuais. Contudo, existem também as características de estrutura, que é onde nós “montamos” os elementos, definindo tamanhos, distâncias, medidas etc. Essas características também são repetidas em diversos elementos no decorrer do site.

A ideia é que nós separemos as características visuais das características estruturais, tornando-os modulares de forma que possamos reutilizá-los em diferentes elementos tendo resultados iguais.

Imagine 3 elementos diferentes, como um botão, uma caixa de chamada e um destaque que normalmente fica na lateral do site. Eles tem características estruturais diferentes, como width, height, paddings, margins etc. Mas as características visuais são iguais, como por exemplo o border-radius, background e o box-shadow. O CSS normal ficaria assim:

.botao {
width:100px;
height:50px;
text-align:center;
font:bold 13px verdana, arial, tahoma, sans-serif;
border-radius:10px;
background: url(gradients.png) repeat-X center;
box-shadow: 0 0 10px rgba(0,0,0,0.5);
}
 
.chamada {
width:250px;
float:left;
font:bold 23px verdana, arial, tahoma, sans-serif;
border-radius:10px;
background: url(gradients.png) repeat-X center;
box-shadow: 0 0 10px rgba(0,0,0,0.5);
}
 
.destaque {
width:300px;
height:250px;
border-radius:10px;
background: url(gradients.png) repeat-X center;
box-shadow: 0 0 10px rgba(0,0,0,0.5);
}

Para reutilizar de forma inteligente as características iguais destes elementos e prevendo que talvez seria criado outros elementos com as mesmas características – já que o designer mantém sempre (quase sempre, né?) um padrão visual estético – é interessante que criemos uma classe que componha estas características e apliquemos essa classe nos elementos necessários. Assim:

.botao {
width:100px;
height:50px;
text-align:center;
font:bold 13px verdana, arial, tahoma, sans-serif;
}
 
.chamada {
width:250px;
float:left;
font:bold 23px verdana, arial, tahoma, sans-serif;
}
 
.destaque {
width:300px;
height:250px;
}
 
.boxEffects {
border-radius:10px;
background: url(gradients.png) repeat-X center;
box-shadow: 0 0 10px rgba(0,0,0,0.5);
}
 

Em cada elemento que necessitasse destas características visuais, basta inserir a classe .boxEffects ao elemento.

Entenda que o abuso dessa técnica pode trazer complicações. Você não vai criar uma classe para cada característica visuais e sair aplicando essas classes em tudo quanto é elemento. Você estaria voltando a 1999 onde tínhamos aquele velho problema de misturar as camadas de formatação e informação.

Independência dos containers e do conteúdo

Imagine que você crie algum estilo para a formatação de algum elemento como por exemplo um parágrafo e atrela este estilo para os parágrafos localizados no article principal:

article p {
font:bold 13px verdana, arial, tahoma, sans-serif;
line-height:18px;
letter-spacing:1px;
}

Mas então surge a necessidade de ter um parágrafo com as mesmas características no rodapé, por exemplo, mas com o tamanho da fonte maior! Você pode fazer assim:


article p, footer p {
font: 13px verdana, arial, tahoma, sans-serif;
line-height:18px;
letter-spacing:1px;
}

footer p {font-size:20px;}
O que é ainda é ruim, mas é muito melhor do que fazer assim:

article p, footer p {
font: 13px verdana, arial, tahoma, sans-serif;
line-height:18px;
letter-spacing:1px;
}
 
footer p {
font: 20px verdana, arial, tahoma, sans-serif;
line-height:18px;
letter-spacing:1px;
}
 

Onde duplicamos desnecessariamente vários estilos.

Com o OOCSS nós devemos transformas estes estilos em módulos para serem reutilizados e não atrelando os estilos a um elemento específico.

Isso acontece também quando já fizemos uma classe onde carrega os estilos comuns. Se voltarmos ao exemplo anterior, alguém pode fazer assim:

footer .boxEffects {...}

Estamos aqui atrelando a classe que antes era para ser algo genérico ao elemento footer. Cuidado ao fazer isso. Tenha um bom motivo antes de ir adiante.

Outras boas práticas

Existem algumas boas práticas que fazem parte do OOCSS e que melhoram muito o planejamento e a prática do desenvolvimento web:

Modularização de código CSS

Não estou falando aqui sobre a modularização de arquivos CSS, mas sim do Código. Essa modularização é feita sob medida para cada um dos projetos. O objetivo é que o código CSS seja reutilizado em várias partes da produção evitando que você crie mais código. É aconselhável que se defina padrões de código para os principais elementos do layout. A equipe pode fazer isso ou delegar esse importante trabalho para um desenvolvedor, que será responsável em criar os métodos e os padrões estruturais dos elementos.

Minimizar usos de seletores muito específicos

Encontre o meio termo. Não faça seletores muito específicos ou seletores muito genéricos. O CSS trabalha com especificidade: quanto mais específico, mais certeiro você é ao capturar um elemento, mas seu CSS fica mais engessado e consequentemente você usa mais código. Quanto mais genérico, mais elementos do mesmo tipo você formata, mas o risco de conflito de estilos aumenta. O ideal é encontrar o meio termo, onde você é tão específico e nem tão genérico.

Dependendo da forma que você utiliza os seletores os browsers podem ser ou não mais rápidos ao renderizar seu site. Já falamos disso aqui.

Formate elementos com classes modulares

A ideia é que ao criar uma nova página, você não tenha que criar novo código CSS. Se a página tiver a estrutura diferente mas os elementos tem características visuais iguais, aí está uma boa oportunidade para modularizar o código visual dos objetos.

Um exemplo para demonstrar essa prática é ao fazer botões para diferentes ações. Normalmente utilizamos os mesmos botões com cores diferentes para definirmos visualmente ações diferentes que o usuário pode tomar. O botão de SALVAR tem o mesmo formato de CANCELAR, mas a cor dos dois é diferente, sendo que o primeiro é verde o segundo vermelho. O código seria assim:

.botao {
display:inline-block;
padding:10px 20px;
font:13px verdana, arial, tahoma;
color:white;
text-decoration: none;
}

Este código cria toda a estrutura do botão. Agora falta definir as cores de fundo. Eu farei isso criando duas classes: btVerde e btVermelho. Essas classes serão utilizadas em pareceria com a classe botao

.btVermelho {background: red;}
.btVerde {background: green;}

Agora, o HTML ficaria assim:

<a href="#" class="botao btVermelho">Cancelar</a>
<a href="#" class="botao btVerde">Salvar</a>

Porque criei os nomes das classes btVermelho e btVerde em vez de btCancelar e btSalvar? Porque pode ser que exista algum botão que também seja verde, mas não tenha a ação de salvar. Assim deixo meu leque aberto para novas atribuições.

Concluindo

Seguir esses pequenos detalhes evitam uma série de problemas comuns no desenvolvimento client-side. A reutilização de código CSS se torna real, a velocidade do carregamento melhora e os problemas de manutenção são solucionados. A flexibilidade que teremos ao modificar o CSS será muito grande e não aumentaremos nosso código a cada modificação feita. A ideia é que seu código CSS fique sob controle. A utilização de frameworks e bibliotecas podem ajudar em muitos momentos.

Fonte: Diogo Eis/Tabless

Javascript para fazer degrade/gradiente

Cada vez que eu vejo um layout com algum tipo de degrade chega a me dar coceira, me vejo recordando um png em milhares de pequenos pedacinhos para poder fazer os gradientes pq os navegadores ainda não implementaram o código de gradiente do css3, como a minha vida seria mais fácil.

Se funcionasse via css seria somente fazer algo assim:

.div_qualquer {
background: -webkit-gradient(linear, left top, left bottom, from(#dfdfdf), to(#f3f3f3));
background: -moz-linear-gradient(top,  #dfdfdf,  #f3f3f3);
}

Mas isto exclui o IE, e é bem difícil explicar aos clientes.

Outra forma é recortar uma imagem em 1px de largura ou altura, deixar ela bem comprida ou larga e usar ela como bg e replicar ela um montão de vezes, assim:

.div_qualquer {
background: url(images/background.png) top repeat-x;
}

Então pesquisando um pouco me surgiu uma opção usando jQuery muito simples que faz isto extremamente bem. Escrito pelo grande Brandon Aaron (contribuidor do jQuery) e fez o jquery-gradient, que de uma forma bem simples pode criar os gradientes para vc, mas ou menos desta forma:

<script type="text/javascript">
// <![CDATA[
    $(document).ready(function(){
         $('.div_qualquer').gradient({ from: 'dfdfdf', to: 'f3f3f3' });
    });
// ]]>
</script>

O que o script faz é criar um bando de divs de 1px diminuindo as cores aos pouquinhos para fazer o degrade linear. Realmente funciona bem para pequenos objetos, mas para objetos muito grandes pode ficar muito pesado e até travar o browser.

Fonte: Rafael Cirolini/NerdHead

Adobe admite: HTML5 é o futuro

Após a Adobe anunciar que o Flash Player 11.1 pode ser a última versão do Flash para navegadores móveis, Mike Chambers, chefe dos desenvolvedores da Adobe, publicou uma explicação sobre o motivo que levou a empresa a tomar essa decisão.

“A decisão é parte de uma grande mudança estratégica da Adobe”, escreveu Chambers. “Uma dessas mudanças é focar no HTML5, assimm como no Adobe Creative Cloud e nos serviços que ele pode prover”.

Ele ainda listou as cinco razões principais que levou a empresa a se decidir por esse caminho:

  1. O Flash nunca ganhará muita visibilidade em dispositivos móveis, já que a Apple não quis adotar a tecnologia no iPhone e no iPad. “Não importa o que fizéssemos, que o Flash não estaria disponível no iOS da Apple”, disse ele.
  2. Entretanto, o HTML5 é onipresente. “Em dispositivos móveis, o HTML5 oferece um nível similar de presença que o Flash Player oferece ao desktop”, afirmou.
  3. Os usuários não costumam consumir conteúdo em aparelhos móveis do mesmo jeito que o fazem em desktops. As diferenças do tamanho das telas, os problemas com redes sem fio e a disseminação das lojas de aplicativos fizeram do Flash irrelevante em mobiles.
  4. Desenvolver plugins para mobile é mais desafiador do que para desktop. Isso requer mais parcerias com desenvolvedores de OS, de hardware para mobiles e de componentes manufaturados. “Desenvolver o Flash Player para mobile mostrou que é preciso muito mais recursos do que imaginávamos”, admitiu.
  5. A Adobe quis mudar mais recursos para HTML5, e liberando o Flash gratuitamente para dispositivos móveis, e que eles façam o mesmo.

Depois, Chambers assegurou aos desenvolvedorees que o Flash é seguro, e explicou que a Adobe fez um termo de compromisso com o Flash Player para desktops, que tem o foco em permitir que desenvolvedores criem aplicativos móveis através da plataforma Adobe AIR.

Ao final, Chambers disse que cada vez mais o HTML5 vai ocupar as funcionalidades do Flash. “Se um recurso Flash é bem sucedido, ele será integrado ao navegador, e se os desenvolvedores e usuários vão acessá-lo cada vez mais pelo navegador, e não pelo Flash”.

“Muitas das coisas que você já fez usando o Flash, fará com o HTML5 e o CSS3 diretamente no navegador”, concluiu.

Com informações de Mashable

Fonte: IMasters

Adobe disponibiliza versão beta da ferramenta Muse

A Adobe disponibilizou hoje uma versão de testes de sua nova ferramenta chamada de Muse.

Ela é baseada na plataforma AIR e permite a criação e a publicação de sites de maneira fácil e rápida, o que o torna perfeito para usuários que não querem lidar com código e ferramentas mais complexas como o Dreamweaver.

De acordo com a empresa, a ferramenta utiliza os mais recentes padrões web, como HTML5 e CSS3.

Além disso, o Muse permite a criação de sites “trial”, que são hospedados pela própria Adobe. Dessa forma, os usuários podem testar os sites criados antes de publicá-los definitivamente.

O Adobe Muse Beta é compatível com Windows, Mac OS X e requer o Adobe AIR instalado.

Fonte: IMaster

Adobe lança ferramenta que cria animações no padrão HTML5

A Adobe liberou hoje uma versão de prévia do Adobe Edge, uma ferramenta voltada especificamente para criar animações no padrão HTML5 e que pode ajudar a diminuir a onipresença do Flash na web.

Além do HTML5, o Adobe Edge utiliza outros padrões web como CSS3 e JavaScript para criar as animações. Os interessados em testar o Adobe Edge podem baixá-lo no Adobe Labs ou esperar a versão final, que será lançada no ano que vem.

O programa parece ser um ótimo plano de contingência se o as habilidades do HTML 5 passarem a ser mais vantajosas e mais adotadas do que as do Flash.

Fonte: Imaster

Mais HTML5 no segundo Platform Preview do IE10

A equipe do Internet Explorer anunciou o segundo platform preview para o IE10. Esta versão preliminar apresenta muitas novas funcionalidades, especialmente no suporte a novos padrões do HTML5, como CSS3 Positioned Floats, HTML5 sandbox e HTML5 Forms. Oferece também as novas APIs setImmediate e Page Visibility, além do suporte a scripts assíncronos. O IE10 usa a mesma engine para HTML5 apresentada recentemente nas demonstrações do Windows 8.

Algumas das principais funcionalidades apresentadas são:

  • Suporte aos Positioned Floats do CSS3: permite que um determinado conteúdo da página seja agrupado a outros elementos, colocando esse conteúdo em destaque;
  • HTML5 SandBox: recurso de segurança que previne comportamentos maliciosos de sites de terceiros, como interceptação de cookies, submissão de formulários ou redirecionamentos de página indesejados;
  • HTML5 Forms: validação básica para formulários HTML;
  • Suporte a Drag and Drop em HTML5;
  • API setImmediate, uma alternativa à API setTimeout com desempenho melhor, para quebrar em partes a execução de operações longas em JavaScript;
  • Media Query Listeners: permite executar um script em resposta a mudanças numa media query (por exemplo, para trocar uma imagem, usando uma versão com resolução mais alta ou mais baixa conforme o tamanho da janela);
  • Async Scripts: habilita o download assíncrono de scripts JavaScript, sem bloquear o download do conteúdo restante da página;
  • API requestAnimationFrame: nova API que permite criar animações mais suaves e eficientes;
  • Web Workers: cria containers para execução de JavaScript, de forma independente do código da página web.

Todas essas funcionalidades são explicadas, com demonstrações e exemplos no Platform Preview. O guia do desenvolvedor mostra detalhes sobre como acessar e testar os novos recursos do HTML5 e de tecnologias relacionadas.

Fonte: InfoQ