Image Image Image Image Image
Scroll to Top

Topo

html

28

abr
2012

Sem Comentários

Em Blog
HTML

Por Allison

HTML5 – O que vai mudar em seu Blog ou Site?

Em 28, abr 2012 | Sem Comentários | Em Blog, HTML | Por Allison

Fonte: CriarSites

Este é um guest post que foi escrito por Vinicius Horta do blog Dinheiro Web.

O padrão atual do HTML já não era atualizado desde 1999, isso mesmo, o HTML passou mais de 10 ANOS sem ter uma reestruturação. Organizações como a W3C e diversos desenvolvedores estavam mais focados em desenvolver o XML e também em fazer melhorias no RSS Feed, mas enfim chegou a novidade, que certamente ainda trará muitas outras.

Entre diversos ganhos que se tem com o HTML5 vale ressaltar o ganho real com a semântica, visto que muitos sites são publicados sem nem ao menos as devidas classes (class) e ids para as divs, o que resulta em maior dificuldade para que seu conteúdo seja devidamente indexado.

Com o HTML5 há Maior Clareza sobre o Código

Antigamente era mais complexo de “mostrar” para o buscador e também para o navegador o que era o que dentro de um site, mas isto agora vai mudar devido a novas tags do HTML5, como por exemplo <header> <footer> <article>, que são facilmente compreendidas pelos buscadores, assim dando a devida importância para cada área.

Também há outras novidades com APIs gráficas através da novidade <canvas>, que é algo interessante para imagens 2D, pois embora ainda não plenamente desenvolvido talvez futuramente seja a solução para a correta indexação de imagens.

Ainda falando em indexação, sabemos que o Google segue os links do menu, para isso o HTML5 também já possui seu elemento específico que é <nav>, vale lembrar que quanto melhor seu blog “falar a língua do buscador” melhor ele tende a ser indexado.

Outro grande dilema no desenvolvimento também era o momento de distribuir as tags H1 até H6, pois a repetição de determinada tag poderia enfraquecer o “poder” da próxima entre outros problemas, mas isso também estará resolvido com <section>, que são marcadores para “partes” distintas do site ou blog. Desta forma poderá estruturar seu código de forma a uma área não interferira em outra!

O que Significam estes novos Elementos do HTML5?

Mesmo a nomenclatura já sendo bastante sugestiva de para que serve cada um dos elementos, segue aqui uma breve lista com os principais elementos com os quais vai começar a se deparar pela web e também a usar em seus blogs e sites.

  • Header <header>: Este elemento define o cabeçalho de seu site em HTML5.
  • Nav <nav>: este elemento define a área de navegação, com menus e links importantes do site.
  • Article <article>: é o conteúdo propriamente dito que deverá ir nesta área, como os posts do blog por exemplo.
  • Section <section>: irá definir uma seção do layout, que trabalha de certa forma de maneira independente, podendo até mesmo conter um header e um footer.
  • Aside <aside>: este é outro interessante elemento que serve para envolver conteúdos que sejam diretamente ligados ao conteúdo do blog, como por exemplo a sidebar ou mesmo um menu lateral.

Entendendo o Poder da <section>

Para ficar mais claro como se pode utilizar a <section> de forma a distribuir melhor a autoridade de cada elemento em separado dentro do blog fiz esta imagem:

Repare que são estrutura independentes para o código, ou seja, o H1 do título do blog não irá interferir no H1 do título do post, assim cada qual terá seu grau de relevância correto para os buscadores.

Ainda falando em section poderia por exemplo ter um footer no section do post, desta forma poderia até inserir elementos de certa relevância como artigos relacionados. (o que também pode ser feito com aside).

HTML5 Grátis no WIX!

A Wix é uma empresa que vem crescendo a passos largos, antigamente fazia apenas sites gratuitos em flash, mas a grande novidade é que agora é perfeitamente possível fazer um site de ótima qualidade em HTML5 na Wix sem saber nada de HTML. Tudo é feito com recursos extremamente simples de arrastar e soltar.

Também vale citar que poderá fazer a otimização SEO para cada página do site de forma independente, isso também ajuda bastante! Para saber mais detalhes sobre os sites em HTML5 da Wix poderá ver em Criar um Site Grátis em HTML5 é com a Wix!

Tags | , ,

27

abr
2012

Sem Comentários

Em Blog
CSS
HTML

Por Allison

Sites usando HTML5 e CSS3

Em 27, abr 2012 | Sem Comentários | Em Blog, CSS, HTML | Por Allison

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

Tags | , , ,

25

abr
2012

Sem Comentários

Em Blog
HTML

Por Allison

W3C revela progresso com HTML5 e vai desenvolver seu sucessor

Em 25, abr 2012 | Sem Comentários | Em Blog, HTML | Por Allison

Fonte: IMasters

Com informações de The H

O W3C liberou um comunicado sobre seu progresso com a especificação HTML5 e como planeja proceder a partir de agora. Como parte de seu plano de padronização, o HTML Working Group Chairs anunciou um segundo review para a última chamada para a especificação HTML5.

Um novo grupo de editores será necessário para realizar o processo de ratificação das especificações do HTML5 e do HTML Canvas 2D Context; ao mesmo tempo, o W3C irá refazer o contrato do HTML Working Group para começar a trabalhar na padronização da próxima versão do HTML. Como resultado desse processo, o trabalho no que deve vir a ser o HTML6 será executado em paralelo com o trabalho que ainda precisa ser feito para tornar o HTML5 um padrão completamente ratificado.

De acordo com o W3C, a adoção do HTML5 continua forte, assim como seu trabalho de implementação. Entretanto, a organização ainda não disse quando pretende finalizar a especificação, mas disse que a pesquisa por novos editores deve levar aproximadamente um mês.

Tags | ,

26

mar
2012

Sem Comentários

Em Blog

Por Allison

Aprenda como criar caixas para exibir códigos nos posts de seu blog

Em 26, mar 2012 | Sem Comentários | Em Blog | Por Allison

Este é um guest post escrito por Dieggo Bezerra que administra o Conexão CL.

Fonte: CriarSites

Se você tem um site ou blog do nicho de Criação de Sites, blogs, WordPress ou até mesmo ensinando a configurar widgets e/ou blogs, é de extrema importância você ler este artigo!

A caixa de códigos é muito usada para sites/blogs que disponibilizam algum formato de código para seus visitantes poderem copiar e colar, como exemplo aqui, o CriarSites.com.

Não são todos os sites que precisam dessa caixinha, um exemplo é meu Fã Site, como se trata de um artista musical, quase nunca iriai usar este recurso…

Esta caixa de códigos é muito útil, pelo fato de facilitar a vida do leitor, identificando claramente qual parte do artigo é texto e qual parte é um código.

Alguns usuários colocam seus códigos dentro de um ‘blockquote’, mas eu acho bem melhor esta caixa de código, já que seu uso é para isso (para postar códigos claramente).

Para criarmos a caixa de códigos, é necessário incluir um código CSS no HTML do modelo de seu Blogger.

LEMBRANDO: Esta caixinha que estou postando aqui será para uso apenas no blogger / blogspot.

Neste passo a passo você aprenderá a criar a caixa de códigos simples, mas também poderá personalizar com uma imagem de fundo da caixa.

Vamos ao passo a passo?

Como forma de precaução, lhe aconselho a fazer um backup de seu template. Para isso, clique em ‘Design’ e depois em ‘Baixar modelo completo’. Caso algo saia errado nesse tutorial, você poderá restaurar tudo como estava antes, fazendo o upload desse modelo que você baixou.

1. Vá ao seu painel de seu blogger, clique em ‘Design’ e em ‘Editar HTML’. Não precisa selecionar ‘Expandir modelos de widgets’.

2. Procure por: ]]></b:skin> e ACIMA dele cole o código abaixo:

code{
overflow:auto;  /* barra de rolagem*/
background: #E8E8E8;
border:1px solid #000000;
color:#XXXXXX;  /* cor da fonte*/
font-size:90%;
height:200px;
display:block;
white-space:pre;
text-align:left;
word-wrap:break-word;
padding:0 10px 5px 20px;
}

3. Depois clique em ‘Salvar Modelo’.

No código que disponibilizei acima, a caixa irá ter uma barra de rolagem automaticamente se a altura da caixa passar de 200px.

Se você quiser, edite a altura da caixa editando os números da parte height: 200px;

Se você deseja colocar uma imagem de plano de fundo, depois do trecho do código: backgroundo: #E8E8E8 – Adicione: url(ENDEREÇO-DA-IMAGEM) ; e modifique a parte ‘ENDEREÇO-DA-IMAGEM’ pela URL da imagem de fundo que você deseja colocar.

Agora você me pergunta:

Como eu coloco a caixa de códigos nas postagens de meu site ou blog?

É simples!

Toda vez que você for postar algum código, você deverá incluir uma TAG para que o Blogger reconheça a caixa e o texto que vai ficar dentro dela.

Para isso, basta usar as TAGs <code> marcando o inicio da caixa e </code> marcando o fim da caixa.

E o código que você quer publicar basta você colocar no meio dessas TAGs.

LEMBRANDO: Essas tags devem ser adicionadas no modo ‘Editar HTML’ da caixa de postagem.

Veja como você deve publicar:

<code>

Insira o código aqui

</code>

Faça um teste!

Depois que você editou o HTML do tema de seu Blogger, faça uma postagem usando as TAGs, se der certo tudo bem.

Espero ter ajudado muito vocês!

Tags | , ,

29

fev
2012

Sem Comentários

Em Blog
HTML
SEO

Por Allison

Como o HTML5 pode influenciar na otimização para mecanismos de busca (SEO)

Em 29, fev 2012 | Sem Comentários | Em Blog, HTML, SEO | Por Allison

Por Sergio Nascimento

Nova semântica do HTML5 e SEO devem andar juntas. Como critério de desempate, o site que tiver um conteúdo de qualidade bem organizado (HTML5/semântica) terá prioridade para mecanismos de busca, em especial o Google. E relevância de conteúdo envolve tanto um bom conteúdo – leia-se, o mais enxuto e aderente possível ao que você deseja transmitir em um post ou página do seu site ou portal – como um código bem estruturado e relevante em web semântica, sendo o HTML5 a opção mais confiável atualmente para organizar essas informações, “traduzindo-as” da melhor forma possível para os robôs de busca.

Pois bem. Pensando nisso, Sergio Nascimento aka Elvis Detona, especialista em web standards, HTML5 e CSS3, elaborou algumas dicas básicas para aqueles que desejam usar a nova semântica do HTM5 com o intuito de obter um posicionamento adequado nos buscadores:

Para mim, cada página tem que ter APENAS um <h1>, mas o W3C, na especificação do HTML5, coloca que cada section pode ter um <h1>, mas eu não uso assim.

“Se eu usar vários <h1>, o Google vai me punir?” O Google não vai punir… isso usando HTML5 ou não. A não ser que você use de forma inadequada.

Além disso, utilize as tags adequadas de acordo com o seu conteúdo, heading tags seguindo uma hierarquia, tag de navegação <nav>, cabeçalho <header>, conteúdo <section>, <article>, <p>, <video>, <audio>, <figure>… os novos types de formulário (email, search, url, tel…), link relations, microdata…

Volto a lembrar, o Google quer conteúdo com qualidade e semântica.

INFELIZMENTE, existem técnicas que “bagunçam” toda a organização do código/semântica a fim de se obter melhores resultados nos buscadores. (Essa de colocar vários h1 na página é lenda, ok?) Não é isso que o Google quer… mas em algumas situações, o resultado é bem melhor sim! Só tem que ficar esperto para não ser punido.

Quando você desenvolve um projeto é claro que quer resultado (conversão/venda de produto ou serviço), mas acho que não é só isso! EU, Sergio (@elvisdetona), penso num todo. Desenvolvo sempre meus projetos pensando num bom resultado nos buscadores e que seja o mais acessível/compatível possível com a maioria dos dispositivos que têm acesso à web.

Se você pensa “Eu preciso ficar em primeiro no Google a qualquer custo”, não se preocupe tanto com semântica e siga a orientação de caras especialistas em SEO.

Tags | , ,

27

jan
2012

Sem Comentários

Em Blog

Por Allison

.htaccess Files for the Rest of Us

Em 27, jan 2012 | Sem Comentários | Em Blog | Por Allison

Original Post for Dan Wellman/NetTuts+

.htaccess files are used to configure Apache, as well a range of other web servers. Despite the .htaccess file type extension, they are simply text files that can be edited using any text-editor. In this article, we’ll review what they are, and how you can use them in your projects.

Please note that .htaccess files don’t work on Windows-based systems, although they can be edited and uploaded to a compatible web server, and on Linux-based systems they are hidden by default.

In order to work with htaccess files locally, to see how they work and generally play around with them, we can use XAMPP (or MAMP) on the Mac – a package that installs and configures Apache, PHP and MySQL. To edit these .htaccess files on Mac, we should use a text editor that allows for the opening of hidden files, such as TextWrangler.

A .htaccess file follows the same format as Apache’s main configuration file: httpd.conf. Many of the settings that can be configured using the main configuration file can also be configured with them, and vice versa.

A setting configured in an .htaccess file will override the same setting in the main configuration file for the directory which contains the file, as well as all of its subdirectories.

They are sometimes referred to as dynamic configuration files because they are read by the server on every request to the directory they are contained within. This means that any changes to an .htaccess file will take effect immediately, without requiring a reboot of the server, unlike changes made to the global configuration file. It also means that you pay a slight performance hit for using them, but they can be useful when you don’t have access to the server’s main configuration file.

So now we all know what .htaccess files are, how they are edited and worked with, and some of their pros and cons, let’s look at how they can be used and some of the cool stuff they can do.

Redirects and URL Rewriting

A popular use of .htaccess files is to perform redirects or rewrite URLs. This can help with SEO following a domain name change, or file-structure reorganisation, or can make long unsightly URL more friendly and memorable.

Redirections

A redirection can be as simple as the following:

Redirect 301 ^old\.html$ http://localhost/new.html

This sets the HTTP status code to 301 (moved permanently) and redirects all requests to old.html transparently to new.html. We use a regular expression to match the URL to redirect, which gives us a fine degree of control to ensure only the correct URL is matched for redirection, but adds complexity to the configuration and administration of it. The full URL of the resource being redirected to is required.

Rewrites

A rewrite rule can be as simple as this:

RewriteEngine on
RewriteRule ^old\.html$ new.html

In this example, we just provide a simple file redirect from one file to another, which will also be performed transparently, without changing what is displayed in the address bar. The first directive, RewriteEngine on, simply ensures that the rewrite engine is enabled.

In order to update what is displayed in the address bar of the visitor’s browser, we can use the R flag at the end of the RewriteRule e.g.

RewriteRule ^old\.html$ http://hostname/new.html [r=301]

The r flag causes an external redirection which is why the full URL (an example URL here) to the new page is given. We can also specify the status code when using the flag. This causes the address bar to be updated in the visitor’s browser.

One of the possible uses for URL rewriting I gave at the start of this section was to make unsightly URLs (containing query-string data) friendlier to visitors and search engines. Let’s see this in action now:

RewriteRule ^products/([^/]+)/([^/]+)/([^/]+) product.php?cat=$1&brand=$2&prod=

This rule will allow visitors to use a URL like products/turntables/technics/sl1210, and have it transformed into product.php?cat=turntables&<WBR>brand=technics&prod=sl1210. The parentheses in between the forward slashes in the above regular expression are capturing groups – we can use each of these as $1, $2 and $3 respectively. The [^/]+ character class within the parentheses means match any character except a forward-slash 1 or more times.

In practice, URL rewriting can be (and usually is) much more complex and achieve far greater things than this. URL rewriting is better explained using entire tutorials so we won’t look at them in any further detail here.

Serving Custom Error Pages

It’s just not cool to show the default 404 page anymore. Many sites take the opportunity offered by a file not found error to inject a little humour into their site, but at the very least, people expect the 404 page of a site to at least match the style and theme of any other page of the site.

Very closely related to URL rewriting, serving a custom error page instead of the standard 404 page is easy with an .htaccess file:

ErrorDocument 404 "/404.html"

That’s all we need; whenever a 404 error occurs, the specified page is displayed. We can configure pages to be displayed for many other server errors too.

Restricting Access to Specific Resources

Using .htaccess files, we can enable password protection of any file or directory, to all users, or based on things like domain or IP address. This is after all one of their core uses. To prevent access to an entire directory, we would simple create a new .htaccess file, containing the following code:

AuthName "Username and password required"
AuthUserFile /path/to/.htpasswd
Require valid-user
AuthType Basic

This file should then be saved into the directory we wish to protect. The AuthName directive specifies the message to display in the username/password dialog box, the AuthUserFile should be the path to the .htpasswd file. The Require directive specifies that only authenticated users may access the protected file while the AuthType is set to Basic.

To protect a specific file, we can wrap the above code in a <files> directive, which specifies the protected file:

<Files "protectedfile.html">
   AuthName "Username and password required"
   AuthUserFile /path/to/.htpasswd
   Require valid-user
    AuthType Basic
</Files>

We also require an .htpasswd file for these types of authentication, which contains a colon-separated list of usernames and encrypted passwords required to access the protected resource(s). This file should be saved in a directory that is not accessible to the web. There are a range of services that can be used to generate these files automatically as the password should be stored in encrypted form.

Block Access to Certain Entities

Another use of .htaccess files is to quickly and easily block all requests from an IP address or user-agent. To block a specific IP address, simply add the following directives to your .htaccess file:

order allow,deny
deny from 192.168.0.1
allow from all

The order directive tells Apache in which order to evaluate the allow/deny directives. In this case, allow is evaluated first, then deny. The allow from all directive is evaluated first (even though it appears after the deny directive) and all IPs are allowed, then if the client’s IP matches the one specified in the deny directive, access is forbidden. This lets everyone in except the specified IP. Note that we can also deny access to entire IP blocks by supplying a shorter IP, e.g. 192.168.

To deny requests based on user-agent, we could do this:

RewriteCond %{HTTP_USER_AGENT} ^OrangeSpider
RewriteRule ^(.*)$ http://%{REMOTE_ADDR}/$ [r=301,l]

In this example, any client with a HTTP_USER_AGENT string starting with OrangeSpider (a bad bot) is redirected back to the address that it originated from. The regular expression matches any single character (.) zero or more times (*) and redirects to the %{REMOTE_ADDR} environment variable. The l flag we used here instructs Apache to treat this match as the last rule so will not process any others before performing the rewrite.

Force an IE Rendering Mode

Alongside controlling how the server responds to certain requests, we can also do things to the visitor’s browser, such as forcing IE to render pages using a specific rendering engine. For example, we can use the mod_headers module, if it is present, to set the X-UA-Compatible header:

Header set X-UA-Compatible "IE=Edge"

Adding this line to an .htaccess file will instruct IE to use the highest rendering mode available. As demonstrated by HTML5 Boilerplate, we can also avoid setting this header on files that don’t require it by using a <FilesMatch directive like so:

FilesMatch "\.(js|css|gif|png|jpe?g|pdf|xml|oga|ogg|m4a|ogv|mp4|m4v|webm|svg|svgz|eot|ttf|otf|woff|ico|webp|appcache|manifest|htc|crx|xpi|safariextz|vcf)$" >
      Header unset X-UA-Compatible
</FilesMatch>

Implement Caching

Caching is easy to set up and can make your site load faster. ‘Nuff said! By setting a far-future expires date on elements of sites that don’t change very often, we can prevent the browser from requesting unchanged resources on every request.

If you’re running your site through Google PageSpeed or Yahoo’s YSlow and you get the message about setting far-future expiry headers, this is how you fix it:

Caching is easy to set up and can make your site load faster.

ExpiresActive on
ExpiresActive on
ExpiresByType image/gif                 "access plus 1 month"
ExpiresByType image/png                 "access plus 1 month"
ExpiresByType image/jpg                 "access plus 1 month"
ExpiresByType image/jpeg                "access plus 1 month"
ExpiresByType video/ogg                 "access plus 1 month"
ExpiresByType audio/ogg                 "access plus 1 month"
ExpiresByType video/mp4                 "access plus 1 month"
ExpiresByType video/webm                "access plus 1 month"

You can add different ExpiresByType directives for any content that is listed in the performance tool you’re using, or anything else that you want to control caching on. The first directive, ExpiresActive on, simply ensures the generation of Expires headers is switched on. These directives depend on Apache having the mod_expires module loaded.

Enabling Compression

Another warning we may get in a performance checker refers to enabling compression, and this is also something we can fix simply by updating our .htaccess file:

FilterDeclare COMPRESS
FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/html
FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/css
FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/javascript
FilterChain     COMPRESS
FilterProtocol  COMPRESS  DEFLATE change=yes;byteranges=no

This compression scheme works on newer versions of Apache (2.1+) using the mod_filter module. It uses the DEFLATE compression algorithm to compress content based on its response content-type, in this case we specify text/html, text/css and text/javascript (which will likely be the types of files flagged in PageSpeed/Yslow anyhow).

In the above example we start out by declaring the filter we wish to use, in this case COMPRESS, using the FilterDeclare directive. We then list the content types we wish to use this filter. The FilterChain directive then instructs the server to build a filter chain based on the FilterProvider directives we have listed. The FilterProtocol directive allows us to specify options that are applied to the filter chain whenever it is run, the options we need to use are change=yes (the content may be changed by the filter (in this case, compressed)) and byteranges=no (the filter must only be applied to complete files).

On older versions of Apache, the mod_deflate module is used to configure DEFLATE compression. We have less control of how the content is filtered in this case, but the directives are simpler:

SetOutputFilter DEFLATE
AddOutputFilterByType DEFLATE text/html text/css text/javascript

In this case we just set the compression algorithm using the SetOutputFilter directive, and then specify the content-types we’d like to compress using the AddOutputFilterByType directive.

Usually your web server will use one of these modules depending on which version of Apache is in use. Generally, you will know this beforehand, but if you are creating a generic .htaccess file that you can use on a variety of sites, or which you may share with other people and therefore you don’t know which modules may be in use, you may wish to use both of the above blocks of code wrapped in <IfModule module_name> directives so that the correct module is used and the server doesn’t throw a 500 error if we try to configure a module that isn’t included. You should be aware that it’s also relatively common for hosts that run a large number of sites from a single box to disable compression as there is a small CPU performance hit for compressing on the server.

Summary

We looked at some of the most common uses for .htaccess files, and reviewed how we can achieve certain tasks that, as website builders/maintainers, are of particular interest to us. As is the case with any introductory tutorial of this nature, the subjects we’ve covered are presented as introductions to a particular topic. There are many other options and configurations than we have been able to look at, so I’d strongly recommend further reading on any subject that is of particular interest.

Tags | , , , , , , , ,

26

jan
2012

Sem Comentários

Em Blog

Por Allison

Google propõe atributo de HTML para facilitar o autocompletar

Em 26, jan 2012 | Sem Comentários | Em Blog | Por Allison

Por Thássius Veloso

Fonte: IMasters

O Google publicou um artigo, no blog que mantém voltado para webmasters, aconselhando a adoção de um novo parâmetro em formulários encontrados em todo momento na internet. A proposta do gigante da web é muito simples: que no código-fonte do formulário apareçam atributos de HTML específicos para que o navegador complete automaticamente a informação que o usuário precisaria adicionar manualmente ali.

De acordo com a empresa, o Chrome e outros browsers já oferecem o autocompletar com alguma taxa de acerto. Entretanto, a situação ficaria ainda melhor se o navegador não precisasse adivinhar se o campo pede o nome ou o endereço de e-mail, por exemplo.

Se depender do Google, a seguinte estrutura será adotada nos formulários:

<input type=”text” name=”field1” x-autocompletetype=”email” />

Através da presença do atributo “x-autocompletetype”, o desenvolvedor especifica qual é a informação que o campo apresentado e, assim que lê isso, o navegador pode adicionar a informação automaticamente.

Para tanto, o autocompletar tem que estar ativo no browser. Além disso, o usuário precisa ter preenchido a informação antes pelo menos uma vez para que fique salva.

Até agora, apenas o Google se comprometeu com o atributo e disse que ele está instalado no Chrome. Outras empresas que oferecem o autocompletar devem implementa-lo, mas o Google não disse quais são essas companhias. Ainda é importante observar que o atributo foi lançado em caráter experimental e não passou por endosso do W3C, o consórcio que regula os padrões para a web.

Aqui está o texto completo relatando a proposta do atributo.

Tags | , , , ,

20

jan
2012

Sem Comentários

Em Blog
HTML

Por Allison

Paginação em listas HTML com jQuery Quick Pagination

Em 20, jan 2012 | Sem Comentários | Em Blog, HTML | Por Allison

Fonte: KaduNew


Com o plugin Quick Pagination você é capaz de criar paginações rapidamente em suas listas. Ótimo para converter listas extensas em listas menores. O plugin ainda permite ajustar alguns dos seus parâmetros adicionais. Você pode especificar a navegação na parte superior, inferior ou ambos, pode também especificar o número de itens a serem exibidos.

Lembrando que para usar esse plugin você deve fazer o download da biblioteca jquery, ou carregar o arquivo a partir do site do Google.

Como usar jQuery Quick Pagination

Exemplo de marcação HTML

    <ul class="pagination1">
        <li>1 - Item 1 de 25</li>
        <li>2 - Item 2 de 25</li>
        <li>3 - Item 3 de 25</li>
        <li>4 - Item 4 de 25</li>
        <li>5 - Item 5 de 25</li>
        <li>6 - Item 6 de 25</li>
    ....

Criando três exemplo de paginação

    <script type="text/javascript">
    $(document).ready(function() {
        $("ul.pagination1").quickPagination();
        $("ul.pagination2").quickPagination({pagerLocation:"both"});
        $("ul.pagination3").quickPagination({pagerLocation:"both",pageSize:"3"});
    });
    </script>

Primeiro exemplo

Opção padrão mostrando 10 itens da lista e navegação na parte inferior.

$(”ul.pagination1″).quickPagination();

Segundo exemplo

Mostrando 10 itens da lista e navegação na parte superior e inferior.

$(”ul.pagination2″).quickPagination({pagerLocation:”both”});

Terceiro Exemplo

Especificados 3 itens na lista e navegação na parte superior e inferior.

$(”ul.pagination3″).quickPagination({pagerLocation:”both”,pageSize:”3″});

Referências:


Tags | , , , ,

09

jan
2012

2 Comentários

Em Blog

Por Allison

Declarando idiomas no HTML

Em 09, jan 2012 | 2 Comentários | Em Blog | Por Allison

O conteúdo online pode ser acessado no mundo inteiro, não importa seu idioma. Para tanto o idioma deve ser declarado corretamente para que os meios de acesso entreguem o conteúdo da melhor forma possível.

Publicar conteúdo na web definitivamente não é a mesma coisa da publicação de conteúdo nos meios impressos. Quando imprimimos o conteúdo, temos como foco um determinado público de uma determinada região. Eu, estando no Brasil, não vou fazer uma revista em no idioma Japonês. Quando falamos publicação de conteúdo online a coisa muda de cenário. O conteúdo online pode ser acessado no mundo inteiro, não importa seu idioma. Obviamente se você conhece outros idiomas, você amplia suas possibilidades para encontrar conteúdo e novos sites.

Os desenvolvedores do mundo inteiro juntamente com os fabricantes de browsers e outros interessados, querem ter certeza que os navegadores, robôs de busca, leitores de tela e outros sistemas detectem da forma ideal o idioma correto.

A declaração do idioma no código HTML não determina a informação no encoding de caractére do texto nem a direção de leitura do texto em outros idiomas. Essas definições precisam ser declaradas separadamente.

Nós precisamos definir o idioma por alguns motivos:

  • Melhor pronunciação do texto em leitores de tela.
  • Para que os buscadores possam indexar o website no buscador do respectivo idioma. Por exemplo: não tem sentido o Google ranqueear muito bem um site em português no Google americano.
  • Selecionar as fonts corretas para mostrar na tela. Nesse caso para idiomas como Chinês.
  • Para que os browsers escolham o dicionário correto para a correção gramatical nativa em textos e formulários.
  • Renderizar a página rapidamente – o browser carrega o documento mais rápido quando o browser sabe qual o idioma nativo.

Definindo o idioma padrão do documento

Existem algumas maneiras que você pode definir o idioma padrão no documento exibido ou em partes do texto para aqueles termos em idiomas diferentes.

Podemos definir diretamente via metatag nativa:

<meta http-equiv="Content-Language" content="pt-br">

Pela Metatag podemos definir vários valores no atributo content:

<meta http-equiv="Content-Language" content="pt-br, en, fr, it">

Via HTTP Header:

HTTP/1.1 200 OK
Date: Fri, 30 Dez 2011 10:46:04 GMT
Server: Apache/1.3.28 (Unix) PHP/4.2.3
Content-Location: CSS2-REC.en.html
Vary: negotiate,accept-language,accept-charset
TCN: choice
P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml
Cache-Control: max-age=21600
Expires: Wed, 05 Nov 2003 16:46:04 GMT
Last-Modified: Tue, 12 May 1998 22:18:49 GMT
ETag: "3558cac9;36f99e2b"
Accept-Ranges: bytes
Content-Length: 10734
Connection: close
Content-Type: text/html; charset=utf-8
Content-Language: pt-br

Via atributo lang nos elementos do HTML.

<p>Nós utilizamos o <span lang="en">mouse</span> para navegar na <span lang="en">web</span> por meios dos <span lang="en">browsers</span>.

Assim indicamos, principalmente para os leitores de tela, quais termos ele deve ler com o idioma nativo do termo.

Temos o costume de indicar o atributo lang no elemento html logo no início do documento para indicar que todo o conteúdo contido dentro do html está escrito em um determinado idioma.

<!DOCTYPE html>
<html lang="pt-br">
<head>
  <title>Título</title>
</head>
<body>
</body>
</html>

Ordem de herança

Os meios de acesso, normalmente browsers, seguem esses passos de verificação para identificar o idioma:

  1. Verifica se elemento HTML que tem o atributo lang, se não,
  2. Verifica se pai mais próximo ao termo que tenha o atributo lang, se não,
  3. Verifica se o documento tem a metatag definida <meta http-equiv=”content-language” content=”pt-br”>, se não,
  4. Verifica se o HTTP Header Content-Language tem uma tag de idioma definido. Se não,
  5. O idioma é tratado como não reconhecido.

O W3C recomenda que você sempre utilize o lang no elemento html para definir o idioma padrão de todo o conteúdo e também em todo o termo encontrado no texto com idioma diferente do definido como padrão.

Declarações de idioma baseados nestes atributos são importantes para a maioria das aplicações web hoje, que vão desde os corretores ortográficos embutidos diretamente nos browsers até leitores de telas que interpretam as páginas web, etc etc.

Estas possibilidades são interessantes para que possamos globalizar ainda mais nossos projetos. Imagine por exemplo um website que ensina Russo para Chineses. É interessante que possamos marcar os termos dos dois idiomas de forma que os mecanismos trabalhem adequadamente em diversos meios de acesso. Os browsers precisam identificar quando o texto está em Russo ou quando está em Chinês. Os buscadores também precisam entender essa diferença, bem como os leitores de tela.

Aos poucos vamos padronizando características que antes eram ignoradas no desenvolvimento web. Não são ações muito difíceis de aplicar. Para começar, basta colocar o atributo lang no elemento html dos seus documentos e pronto.

Referências

Fonte: Diego Eis/Tableless

Tags | , , , ,

05

jan
2012

Sem Comentários

Em Blog
Python
Rails
Ruby

Por Allison

Como Ruby vem ganhando a prefrência do Python para administração de sistemas

Em 05, jan 2012 | Sem Comentários | Em Blog, Python, Rails, Ruby | Por Allison

Há cerca de três anos, eu comprei o livro “Python for Unix and Linux System Administration“, e ele me convenceu de que o Python seria a linguagem padrão de scripts para administradores do sistema Linux no futuro próximo. Eu estava trabalhando no projeto One Laptop Per Child (Um Laptop Por Criança) na época, onde o Python era a linguagem comum. Parecia que o Red Hat estava usando o Python para quase todo novo projeto. Além disso, o Unladen Swallow estava fazendo um progresso rápido. Eu não poderia estar mais errado.

Através de uma combinação de acidente histórico e algumas diferenças de recursos aparentemente pequenas, o Ruby está, inexoravelmente, se tornando a linguagem padrão dominante para a administração do sistema Linux.

Antes de eu ir mais adiante, seus administradores de sistema estão provavelmente gritando “Nós já temos uma linguagem de scripts, Bash!”. Mesmo amando Bash e commandlinefu, o Bash se torna uma obrigação, não uma qualidade quando seu script excede 100 linhas, e um completo pesadelo se você precisa analisar ou dar saída em HTML, CSV, XML, JSON etc.

Acidentes históricos

Em 2004, Luke Kanies falou sobre a construção do Puppet, um sistema de gerenciamento de configuração para melhorar as deficiências que ele via na CFEngine. Do excelente blog On Ruby:

Eu tentei implementar minha ideia em Perl, mas eu simplesmente não conseguia fazer os relacionamentos de classe funcionar (todos atributos e tipos de recursos precisavam ser classes, de acordo com o design na minha cabeça). Isso era quando o Python era o melhor, então eu naturalmente o experimentei, mas o Python simplesmente faz meus olhos sangrarem (e não, não era o espaço em branco, eram coisas como o fato de que `print` era uma instrução em vez de uma função, e `len` era uma função ao invés de um método).

Eu tinha um amigo que tinha ouvido falar que o Ruby era legal, mas não tinha de fato testado. Como eu estava simplesmente à toa na época, pensei em dar uma olhada. Quatro horas depois, nunca tendo visto uma linha de Ruby antes, eu tinha um protótipo funcional.

Dois anos depois, muitos desenvolvedores Puppet sentiram que o Puppet não satisfazia suas necessidades. Eles começaram suas própria ferramenta de configuração de gerenciamento, Chef, largamente inspirada pelo Puppet. A grande diferença entre Puppet e Chef é que Chef utiliza Ruby puro como “receita”, enquanto o Puppet usa sua própria linguagem de configuração baseada no Ruby.

Ambos Puppet e Chef estão sendo adotados rapidamente por grandes empresas, de acordo com a BusinessWeek. Se você ainda não estiver usando Puppet ou Chef, você deve começar a planejar a usá-los no futuro. Seja escolhendo Chef ou Puppet, você terá efetivamente o script da sua infraestrutura em Ruby. Depois de gastar 25% do seu tempo trabalhando com Puppet, você estará muito mais inclinado a escolher o Ruby para sua própria tarefa de scripting.

Projetos populares


Aqui está uma lista não definitiva de projetos sysadmin/devops em ruby

  • puppet
  • chef
  • vagrant
  • mcollective
  • cucumber (behavior-driven testing)
  • capistrano
  • rake (ruby Make)
  • aeolus project/openshift
  • cloud foundry
  • graylog2
  • logstash
  • travis-ci

e em Python:

  • openstack
  • cobbler
  • fabric
  • func
  • buildbot

O que é importante aqui não é o comprimento das respectivas listas, mas a importância dos projetos individuais. Chef, Puppet e Vagrant são os novos martelos e chaves-de-fenda da administração de sistemas. Se você for um administrador de sistema e ainda não está usando essas ferramentas, não se preocupe, você irá, cedo ou tarde.

O Openstack merece uma atenção especial, e é um projeto muito animador, mas ainda está no seu estágio inicial. Ele pode representar um papel importante no seu futuro como administrador do sistema.

Por favor, me notifique de projetos devops significantes que estão faltando nessa lista.

O que um administrador de sistema quer

Aqui estão os recursos em uma linguagem script que um administrador de sistema quer:

  • Um DSL para o problema do domínio
  • Alta produtividade, por exemplo, sintaxe expressiva e concisa
  • Fácil interação com comandos shell
  • Expressões regulares
  • Comandos de linha poderosos

Note que desempenho não está na lista de necessidades. O Ruby é acentuadamente mais lento que o Pyhton, e isso era particularmente verdade para a série 1.8.* do Matz Ruby Interpreter (MRI). No entanto, desempenho simplesmente não é algo crítico para 90% do nosso trabalho como administradores de sistema. Nós nos importamos mais com produtividade do que com desempenho. Legibilidade é legal, mas está um segundo distante de produtividade.

O Python não tem expressões regulares nativamente, provavelmente para melhorar a legibilidade. Ele também limita o número de variáveis globais de alto nível embutidas. De uma perspectiva de design de linguagem, isso é muito mais limpo. Da perspectiva do seu administrador de sistema padrão, treinado na rua, estressado, viciado em VI, é irritante.

Essas variáveis de alto nível também deixam as ONE_LINERS mais concisas. Aqui estão algumas.

$_ last line read from STDIN
$? last exit code from a child process
$stdin reference to stdin
$stderr reference to stdout
$stdout reference to stdout

Aqui está uma sessão IRB para mostrar esses valores em ação.

hitman@hiroko:~/pr$ irb
irb(main):001:0> %x[ ls -a ]
=> ".\n..\nfoo1\nfoo2\nfoo3\n"
irb(main):002:0> puts $?
0
=> nil
irb(main):003:0> %x[ ls xys ]
ls: cannot access xys: No such file or directory
=> ""
irb(main):004:0> puts $?
512
=> nil

“IRB?” você me zomba, “Você terá que arrancar o IPython das minhas mãos mortas geladas.”

Eu adoro o IPython. Eu usei o IPython por mais de quatro anos, e o IRB não tem comparação a ele. Dito isso, os atalhos do Ruby são bastante úteis, o suficiente pra compensar as deficiências do IRB. Existe algo chamado wirble que eu ainda não tentei, mas ele pode deixar o IRB bem mais produtivo.

Aqui está algum código Python para detectar se uma máquina é VMware VM.

# edit: fixed python code tks to kstrauser

import os
  if 'vmware' in os.popen('dmidecode').upper():
    print 'this is a vmware vm'
  else:
    print 'this is not a vmware vm'

Aqui está o mesmo código em Ruby:

`dmidecode`
if $_ ~= /vmware/i
   puts 'this is a vmware vm'
else
   puts 'this is not a vmware vm'

Francamente, esse tipo de código faz meus olhos sangrarem. O exemplo do Python é muito mais legível e mais fácil de manter. Dito isso, muitos dos administradores de sistema iriam gostar de quão conciso é o exemplo do Ruby.

Vamos ver como escrever comandos de linha em ambas as linguagens.

O código imprime as primeiras 10 linhas em um arquivo usando Python.

python -c "import sys; sys.stdout.write(''.join(sys.stdin.readlines()[:10]))" < /path/to/your/file

Aqui está o mesmo código em ruby:

ruby -ne 'puts $_ if $. <= 10 ' < /path/to/your/file

Compare você mesmo essas coleções de oneliners no Python e no Ruby. Se o Ruby te lembra o Perl, seus olhos não te enganam. Em muitas maneiras, ele é o filho querido do Perl e do Smalltalk.

DSLs FTW

Há algum tempo, eu tentei assistir a todas as palestras da Structure and Interpretation of Computing. Todo esse esforço falhou miseravelmente, mas eu me lembro de Harold Abelson dizendo que todo grande programa deveria ter seu próprio DSL interno adequado para o problema de espaço. Isso é debatível devido ao grande mundo da programação, mas eu acredito estar apto para a administração de sistemas. Passamos toda nossa carreira com vários DSLs diferentes. Cada formato de arquivo com configuração diferente é seu próprio DSL.

Se você comparar o rake (Ruby Make) ao código rails, eles parecem muito diferentes, quase linguagens diferentes. Se você comparar o código fabric a uma classe django, eles se parecem muito. Isso é uma força e uma responsabilidade. Não sou nenhum advogado de linguagem, mas parece muito mais fácil criar DSLs (Domain Specific Languages). O Ruby certamente gera DSLs com uma frequência muito maior do que o Python. Nenhuma ferramenta de construção do Python domina o problema de espaço como o rake faz na comunidade Ruby. A maioria dos projetos Python parece usar setup.py para tarefas administrativas, mesmo este não sendo seu objetivo explícito.

Ambos, Puppet e Chef são DSL para administração de sistemas. O Capistrano é uma DSL para deploy de aplicações. Sobrecarga de operadores e os blocos do Ruby facilitam a criação de DSLs.

Em resumo

A maior força do Ruby é sua grande flexibilidade. Existe muita “mágica” no Ruby, e às vezes essa magia é negra. O Python intencionalmente tem o mínimo de mágica. Sua maior força é a capacidade de reforçar as boas práticas através da sua comunidade. Essas práticas tornam o Python bastante legível em vários projetos. Eles garantem alta qualidade de documentação, fazendo sua biblioteca padrão arrasar. Mas o fato é que nós sysadmin precisamos de flexilidade mais do que precisamos de poder ou consistência. Mesmo assim, esses não são os motivos reais pelos quais o Ruby está tomando o lugar do Python.

O Ruby está rapidamente se tornando a linguagem de script para os administradores de sistema porque, em 2004, Luke Kanies olhou para o Python e se sentiu doente (eu tive a reação oposta). Como um administrador de sistema, você ou está ou logo estará usando o Puppet ou o Chef diariamente, gastando muito tempo essencialmente codificando em Ruby. Pessoalmente, eu prefiro em Python, mas estou mudando a escrita dos meus scripts para Ruby porque passo muito tempo no Chef.

Texto original em inglês de Bryan Berry, disponível em http://devopsanywhere.blogspot.com/2011/09/how-ruby-is-beating-python-in-battle.html

Fonte: Bryan Willson Berry/IMasters

Tags | , , , , , ,

05

jan
2012

Sem Comentários

Em Blog

Por Allison

Como começar nesse mundo louco da Web?

Em 05, jan 2012 | Sem Comentários | Em Blog | Por Allison

Eu sempre recebo perguntas no forum do mxmasters ou mesmo por e-mail, de pessoas que devem estudar para começar a desenvolver seus sites ou mesmo algumas dicas e/ou também qual referência de blog/site que seria interessante. Acho o que a pessoa tem que aprender, de forma sólida é html e css. É impressionante os “analfabetos” de html e css, devido a utilização de programas como Dreamweaver. Mas tudo pode ser revertido. Muitos defendem que desenvolver os códigos é um retrocesso, conhecido “reinventar a roda”, mas não se trata de reinventar, e sim saber o que é mais produtivo, e sem sombra de duvidas, desenvolver o seus próprio código é a melhor solução. Mas por quê? Não podemos pensar na concepção imediata do site, temos que pensar nas mudanças que irão ocorrer, e você pode ter certeza que irão ocorrer.

Então vamos colocar alguns pontos que seriam interessantes ser estudado e algumas dicas:

  • Aprender html e css, isso é de vital importância. Não depender de programas, se em algum momento você tiver apenas o bloco de notas, você resolve.
  • Aprender a utilizar um editor de imagem, como photoshop, ou fireworks, ou outros programas. Não tenha medo de testá-los até encontrar um que te agrade mais.
  • Aprenda Javascript, ou aprenda a utilizar um framework, uma boa pedida é o jquery, é de fácil aprendizado e muito produtivo.
  • Aprenda alguma linguagem server-side, indico o php, por ser uma linguagem de fácil aprendizado, e por ter muito material na web.
  • Adquira livros. Na maioria dos casos vão te ensinar coisas que tutoriais não ensinam de uma maneira mais sólida.
  • Aprenda a utilizar o Google. Sabendo pesquisar, e não tendo preguiça você consegue arrumar soluções rápidas;
  • Não desista na primeira dificuldade. Esse é mau de muitas pessoas, quando esbarram no primeiro desafio, não tentam resolver. Lembre-se da sugestão anterior.
  • Participe dos fóruns. Você vai encontrar muitas soluções de duvidas que você tem.
  • Aprenda a ajudar. Quando você tentar ensinar algo, você aprender muito mais.
  • Não seja arrogante. Acredite, dizer que sabe tudo de determinado assunto, é comprovadamente mentira, existe sempre algo a aprender.
  • Aprenda a filtrar as informações. Nem tudo que escrito nos blog é uma verdade absoluta(inclusive no meu);
  • E não utilize o IE. Parece brincadeira, e até um pouco. Mas outros navegadores, como firefox não são simples navegadores, e sim ferramentas de desenvolvimento. Na sua caminhada, com certeza você vai odiar o IE6.
  • Não tenha medo de outros idiomas, nada que o Google tradutor não possa te ajudar.

Espero que essas dicas sejam válidas, isso não é uma regra, ou mantra que deve ser dito, mas são alguns passos que te ajudarão nessa nova jornada.

Fonte: DavidCHC

Tags | , , , , , , , ,

20

dez
2011

Sem Comentários

Em Blog
CSS
HTML

Por Allison

3 Métodos para criar colunas de largura igual com CSS

Em 20, dez 2011 | Sem Comentários | Em Blog, CSS, HTML | Por Allison

No mundo da programação, uma das coisas que não é fácil fazer, nomeadamente em CSS é criar colunas de igual largura. No entanto, e como o caro leitor sabe, não há impossíveis! Através de um destes quatro métodos que lhe vamos apresentar, poderá facilmente criar colunas de igual largura em CSS. Durante a apresentação destes quatro métodos poderá observar que existem prós e contras, que em nada alteram o resultado final – colunas com largura igual. Este artigo foi baseado num artigo dos colegas do Vanseodesign. Aconselhamos a leitura dos nossos artigos de CSS para principiantes, nomeadamente CSS para Tótós!, Tutorial: Aprender o básico sobre CSS e ainda Começando com CSS – Dê os primeiros passos em segurança que o irão ajudar a fazer a introdução a esta linguagem, para completar com sucesso os 3 Métodos para criar colunas de igual largura com CSS!

1. BORDERS & NEGATIVE MARGINS

Este método é bastante conhecido e também bastante simples de aplicar. Consiste em definir limites e margens negativas para dar a ilusão de colunas com largura igual. Como temos vindo a dar enfase, o melhor para aprender é praticar, e é isso que vamos fazer:

1. Crie um ficheiro HTML com o seguinte código:

<body>
<div id="container">
    <div id="sidebar">
        <p>Sidebar</p>
    </div>
    <div id="content">
        <p>Main content</p>
    </div>
</div>
</body>

2. De seguida crie um ficheiro CSS, insira o código abaixo e linke-o ao documento HTML. Se não souber como o fazer, visite o artigo Programação CSS para iniciantes (Parte I).

#container {
    width:960px;
    margin: 0 auto;
}
#content {
    float:left;
    width:700px;
    border-left: 260px solid #555;
}
#sidebar {
    float: left;
    width:260px;
    margin-right: -260px;
    position: relative;
}

3. Guarde o ficheiro HTML e o ficheiro CSS e observe o resultado prematuro:

4. Neste método as cores de fundo são definidas em #content no ficheiro CSS. Definimos o limite a 260px para criar espaço para a sidebar e definimos o fundo desse limite, que é o fundo da sidebar. Depois define-se a margem direita negativa de 260px para mover a sidebar para onde queremos, no espaço que criámos dentro do #content, para mover a sidebar para onde queremos. Como o #container está hierarquicamente por cima da #sidebar, é necessário dar a posição relativa para que saia de trás do #content. E basicamente temos as colunas criadas!

2. PSEUDO COLUMNS

As pseudo colunas são uma boa alternativa às “faux columns” pois não necessitam de utilizar uma imagem no fundo como uma cor de fundo. No entanto este método continua a ser similar às faux columns pois também envolve o método de definir um fundo no container. Este não é um método comum, e por isso mesmo é um pouco restrito relativamente a onde pode ser aplicado, mas quando encontrar essa situação onde pode ser aplicado, funciona perfeitamente. Passamos a praticar:

1. Crie um ficheiro HTML e insira o seguinte código:

<body>
<div id="container">
    <div id="sidebar">
        <p>Sidebar</p>
    </div>
    <div id="content">
        <p>Main content</p>
    </div>
</div>
</body>

2. De seguida crie um ficheiro CSS, insira o código abaixo e linke-o ao documento HTML. Se não souber como o fazer, visite o artigo Programação CSS para iniciantes (Parte I).

#container {
    background: #555;
    overflow: hidden
}
#content {
    float:left;
    width:75%;
    background:#eee;
}
#sidebar {
    float:left;
    width:25%;
    background:#555;
}

3. Guarde os ficheiros e observe o resultado:

4. Além da utilização de percentagem ao invés de px, irá notar algumas diferenças relativamente aos outros métodos, como a definição da cor de fundo no #sidebar e no #content. Como referimos neste caso utilizamos uma cor de fundo, e não uma imagem de fundo. A limitação deste método prende-se com o facto de ter de haver uma coluna mais pequena que outra, uma diferença que não se deverá notar por parte de quem visita a página.

3. FAUX COLUMNS

Este método já data de 2004, quando foi introduzido pela primeira vez numa página web. Não só por causa da sua antiguidade mas também pela sua facilidade e fiabilidade, as faux columns são provavelmente o melhor método para criar colunas de igual largura. Em termos básicos, consiste em utilizar uma imagem que é repetida verticalmente, mantendo desta forma a mesma largura ao longo do eixo vertical. Vamos praticar:

1. Crie um ficheiro HTML e insira o seguinte código:

<body>
<div id="container">
    <div id="sidebar">
        <p>Sidebar</p>
    </div>
    <div id="content">
        <p>Main content</p>
    </div>
</div>
</body>

2. De seguida baixe este ficheiro e insira-o na pasta onde estiverem os ficheiros HTML e CSS. Crie um ficheiro CSS, insira o código abaixo e linke-o ao documento HTML. Se não souber como o fazer, visite o artigo Programação CSS para iniciantes (Parte I).

#container {
    width:960px;
    margin:0 auto;
    background: url("faux-columns.png") repeat-y;
    overflow: hidden
}
#sidebar {
    float:left;
    width:340px;
}
#content {
    float:left;
    width:620px;
}

3. Guarde os ficheiros HTML e CSS e observe o resultado:

4. Por outro lado também poderia ter sido usado o <body> como container, mas é preferível criar uma div para esse efeito. O container tem a largura de 960px, e essa largura terá de ser dividida entre a sidebar e o content. Para fazer uma divisão esteticamente bonita, optamos por criar a sidebar com 340px e o container com 620px. Aquilo que irá diferenciar a sidebar e o content é a sua cor de fundo. Como referenciamos anteriormente, utilizámos uma imagem como cor de fundo não só para dar cor como também para delimitar as áreas de conteúdos. Como nota adicional, é necessário definir o overflow: hidden para que a div container se mantenha como pretendemos. Este método é especialmente indicar para larguras fixas, mas poderá obter bons resultados com larguras não fixas.Obviamente não está limitado à cor e estética dada pela imagem de fundo, podendo adicionar efeitos ao seu gosto e alterando a imagem de fundo.

Fonte: Diogo Espinha/escolacriatividade

Tags | ,