Este artigo é uma prévia do que passamos na Oficina de Wordpress da Visie. As aulas são bem mais detalhadas por conta de ter um professor explicando e trocando experiências. Mas este artigo mostra o quanto é fácil criar um template para Wordpress.
O Wordpress não foi feito para ser um CMS. Ainda falta algumas características interessantes para que ele possa ser realmente um CMS. Continuar lendo »
22 ComentáriosPara que possamos entender melhor o assunto do IE8 e como ele tratará as páginas, é bom que possamos entender o que houve no passado. Se você se lembrar bem como foi entre os anos de 1999, 2000 e 2001, provavelmente você vai lembrar que durante algum tempo, tínhamos que nos virar para garantir a total compatibilidade dos nossos sites em diversos browsers. Os principais eram o IE5, IE6, Firefox e Opera. Era uma época que - como no começo da bolha - estava tudo acontecendo ao mesmo tempo. Os Padrões Web estavam virando moda, os browsers, pelo menos os mais inteligentes, estavam se virando para suportar os Padrões Continuar lendo »
33 ComentáriosMetadados são dados sobre dados. Informações sobre a própria informação. Metadados são estruturas de informações que descrevem características de uma fonte de informação.
Metadados servem para ajudar seres humanos ou máquinas a localizar e descrever informações, melhorando o gerenciamento e uso destas informações.
Existem uma série de padrões para se criar Metadados, mas por você ser um possível profissional que trabalha com web, a que vai te interessar mais são as Metatags. Continuar lendo »
31 ComentáriosNo dia primeiro de Janeiro de 2008, o Tableless.com.br faz 5 anos de idade. Por isso, uma reformulação total do site era bem vinda. Essa reformulação não será rápida e não envolve apenas a constante mudança do layout, mas também a filtragem de todo o conteúdo contido no site.
Durante muito tempo, principalmente no começo do site, o tableless.com.br foi apenas um blog. Conforme o tempo foi passando, o site foi se transformando sendo influenciado pelo mercado e pelas tendências da comunidade. Continuar lendo »
82 ComentáriosVocê é um sujeito antenado e sabe disso. Mas talvez seu chefe não saiba. Talvez seu cliente não saiba. (Talvez você mesmo não saiba.) Ou por qualquer outro motivo, você pode se ver obrigado a enviar uma newsletter em HTML. E agora, o que você faz? Chuta o pau da barraca, abre o Dreamwaver e prepara “aquele” layout?
Você ainda pode, mesmo enviando emails em HTML, se preocupar em tornar melhor a experiência de seu usuário. Continuar lendo »
14 ComentáriosSe você já leu alguma coisa sobre Tableless, já deve ter percebido que nesse método nós separamos a informação da formatação.
Para fazer a formatação do site, ou seja, para literalmente aplicarmos o design do site, nós usamos o CSS (as famosas Folhas de Estilo), que eu julgo ser a principal ferramenta do desenvolvedor para criar sites tableless. Para a apresentação da informação, você pode usar HTML ou XHTML, o que você achar mais apropriado.
A separação entre informação e formatação traz muitas vantagens, mas vou citar apenas duas, divididos em dois artigos:
Então, vamos ao que interessa.
Separando a informação da formatação, você já organiza grande parte do código, pois você os separa em arquivos distintos, um arquivo .css para a formatação e outro arquivo .html (.asp, .php. seja lá o que for) para a informação. Esta simples organização, lhe permite fazer com rapidez e objetividade qualquer tipo de manutenção, sendo ela grande ou pequena.
Imagine a seguinte situação:
Você está no final daquele grande projeto, aquele site em que você fica horas desenhando tabelas, puxando daqui e dali, acertando medidas, etc… e quando você olha para o lado para descansar um pouco as vistas, você chega a pensar que seguiu o coelho branco…
Então, sem mais nem menos seu chefe lhe chama para conversar sobre o projeto e fala que o cliente pediu para que todos os títulos do site mudassem de cor, você o olha desacreditado, e já contando silenciosamente quantos títulos tem no site, se dirige para sua mesa e decide por onde começar.
Se você não passou por esta situação, acredite, muitos desenvolvedores já passaram por isso.
Vamos supor que o desenvolvedor do exemplo acima, usasse para apresentar os títulos a tag <h1></h1>, ele simplesmente atribuiria pelo CSS um valor para que todas as tags <h1> tivessem a cor desejada, em poucos segundos, ele mudaria a cor de todos os títulos do site, e isso tudo, sem mexer no arquivo HTML, economizando o tempo que ele levaria abrindo vários arquivos para procurar as intermináveis tags <font color=”#666666″></font> somente para mudar uma simples cor. Problemas como este, não vão mais tomar o precioso tempo do desenvolvedor.
Agora, e se a manutenção não fosse simples assim? E se fosse mais um pouco complicada, como do tipo mudar todo o layout do site? E se você pudesse mudar todo o layout do site, mudando apenas um arquivo .css?
Em um site tableless, o código HTML fica livre de tags desnecessárias do tipo: <font> <center>, deixando você à vontade para modificar o visual do site usando apenas CSS, te dando total controle sobre localização de objetos, tamanhos, cores e famílias de fontes, medidas, alinhamentos de texto, etc…
Fazendo isso, você pode escrever vários arquivos CSS distintos, que modifiquem o visual do site completamente, e o melhor, sem tocar numa letra do arquivo HTML, ele continua sendo o mesmo.
Vários sites usam está técnica, deixando o usuário escolher o layout que mais lhe agrada, veja alguns exemplos:
Realmente é uma mão na roda, não acha?
Tudo organizado, formatação de um lado, informação do outro, sem complicação… Seu código fica enxuto, limpo, muito menor do que se você tivesse feito do jeito tradicional, lhe dando menos dor de cabeça, e mais tempo. Ainda por cima, você contribui para uma web mais semântica.
No próximo artigo trataremos sobre o ganho de produtividade observado com a aplicação da metodologia tableless.
Leitura Recomendada:
http://www.pedromendes.com/words/molly-200211-truelanguage1.html
O papo que agora está começando a rolar entre os desenvolvedores é sobre Frameworks para CSS.
Sou totalmente contra a qualquer coisa que impeça o contato do desenvolvedor com o código. Sou avesso a qualquer tipo de interface que prometa facilitar o desenvolvimento, pelo menos de XHTML e CSS. Lembra daquele papo sobre o desenvolvedor “analbético” de código?
Ainda acho que utilizar editores que suportam Snippets - ou Macros, dependendo do editor - são as melhores formas de se trabalhar se você quer agilidade. Você mantém o contato com o código e agiliza seu trabalho ao mesmo tempo.
Lembre-se de que estamos falando sobre frameworks de CSS e XHTML. Nada de Django ou qualquer outro tipo de framework para linguagens server side.
Esses tipos de frameworks ajudam um bocado o programador. Boa parte do trabalho duro pode ser agilizado por causa destes frameworks. E até concordo que os desenvolvedores utilizem frameworks deste tipo para ajudar em seu trabalho.
O problema é um que eu já comentei com você e já falei bastante em palestras: o programador, muitas vezes é um bicho mais antenado que o designer ou o camarada que cuida de interface. Ele precisa estudar, precisa procurar soluções mais complexas para problemas mais específicos. Por isso, é bom que existam esse tipo de framework para que o trabalho dele seja mais ágil. Ele não vai desaprender a programar.
É importante que o desenvolvedor web saiba que o código é o mestre. Ler, compreender e escrever código é essencial para que tenhamos o controle sobre o projeto. É importante também para que a pessoa se torne um profissional decente e que tenha algum valor (desculpe aos mais fracos de estômago).
Não preciso dizer que os dois carros são totalmente diferentes. Mas, qual dos dois você teria? Me diga… Se você pudesse escolher, você ficaria com qual dos dois?
Acredito que 206 será a resposta mais dita para essa pergunta.
Queria então fazer outra pergunta: Porque você escolheria o 206? O Uno também não vai te levar para lá e para cá como o 206? O que te faz querer um 206 e não um Uno?
Para mim, a culpa é dos detalhes.
Em algumas versões do 206, ao abrir a porta, olhando para baixo, você verá uma soleira de alumínio trabalhado, escrito PEUGEOT, muito bem acabada. Como se dissesse: Prepare-se, você não está entrando em um carro qualquer.
No Uno…
Quando você já está dentro do 206, o painel tem uma série de pequenos compartimentos onde você consegue guardar miudezas como moedas, chaves e etc. Sem contar o material e o desenho do painel.
O detalhe em metal na ponta do câmbio dá um charme diferente para o 206. No Uno não há uma pontinha de metal… mas uma espécie de “sanfona” de borracha envolve o braço do câmbio. Muitas vezes essa “sanfona” rasga na base de plástico do câmbio.
A distância de um detalhe separa sua preferência pelo 206 e seu desprezo pelo Uno. Apenas um detalhe.
E em seus projetos? Já ouviu falar de um ditado que diz assim: O Diabo está nos destalhes?
O mesmo pensamento se aplica sobre PCs comuns e os fabricados pela Apple. A riqueza de detalhes da Apple faz a pessoa se sentir importante.
Outro exemplo: você entra em dois restaurantes: em um deles há 150 mesas. No outro há 15 mesas. Em qual dos dois restaurantes você se sentirá melhor atendido?
Entregar projetos ricos em detalhes faz valer a pena, acredite. Ter aquelae detalhe, mesmo sendo algo que se não existisse, não prejudicaria o funcionamento do todo, faz uma grande diferença. Não importa se o detalhe é visível (layout, texto, etc) ou invisível (código, banco, etc), ele sempre fará a diferença entre você e qualquer outra pessoa.
Pense bem: Os dois carros podem te levar para os mesmos lugares. Os dois restaurantes servem frango à milanesa. Mas em quais das opções você vai se sentir como se tudo fora feito especialmente para você?
38 ComentáriosA Web foi criada para ser um ambiente onde fosse possível trocar informações livremente, e que essas informações pudessem ser acessadas ao redor do planeta por qualquer pessoa. Em 1994, foi criado o W3C (World Wide Web Consortium): um consórcio internacional, onde são desenvolvidas os padrões para a web (Web Standards) tais como: HTML, CSS, XML, XSLT, entre outros.
Naquela época, no mercado de browsers, as opções ainda eram poucas: consistiam apenas em Lynx, Mozaic e Netscape Navigator, da Netscape Communications, então liderada por James Clark. A Microsoft, de Bill Gates, resolveu entrar nesse mercado lançando o Internet Explorer. A partir daí, o Netscape e o Internet Explorer começaram a travar uma guerra atrás de adpetos. A concorrência entre os dois browsers é chamada até hoje de Guerra dos Browsers. Durante essa “guerra”, os padrões do W3C ainda eram meros rascunhos. Por conta disso, as duas empresas que não podiam esperar que esses rascunhos ficassem prontos começaram a lançar seus browsers com padrões proprietários.
Agora o impasse: Os browsers tinham seus próprios padrões… Já os desenvolvedores não conseguiam criar um único código que funcionasse nos dois navegadores. Por este motivo, eles eram obrigados a desenvolver, na maioria das vezes, para apenas um browser.
Isso trouxe mais um problema, agora para os usuários. O usuário que usava Netscape, não conseguia acessar sites que eram feitos para Internet Explorer, e vice-versa.
Como a web não tinha sido projetada para desenvolver os criativos ambientes gráficos que temos atualmente, naturalmente, os recursos de desenvolvimento eram limitados e os criadores faziam das tripas coração para criar seus sites. Entre as muitas idéias que surgiram para ultrapassar ao ambiente de “apenas texto” da internet, estava aquela de utilizar tabelas de HTML para posicionar os elementos no layout, utilizando slices de imagem, gifs transparentes e a técnica de aninhamento de tabelas para contornar os problemas que os padrões proprietários traziam. A esse tipo de técnica, que foi usadapela maior parte dos websites, chamamos de layout com tabelas.
Os sites que seguem os Padrões Web utilizam uma metodologia de desenvolvimento baseado em 3 camadas, são elas:
Em poucas palavras: um site tableless é um site que não utiliza tables para a estruturação do Layout. É um site que segue os Padrões Web.
O termo “tableless” é usado mais largamente aqui no Brasil. Em outros países outros foram mais difundidos, por exemplo: CSS Layouts.
Um site tabeless segue obrigatoriamente regras de semântica. Cada tag tem sua função própria. Por exemplo, para criar um parágrafo de texto, usamos a tag <p></p>. A tag Table e suas filhas são utilizados para exibir dados tabulados, por exemplo, uma listagem de produtos, onde são mostrados algumas informações sobre o produto como tamanho, preço, cor, material, disponibilidade, etc…
| Tênis | Cor | Tamanho | Preço | Disponibilidade |
|---|---|---|---|---|
| Nike | Preto | 38-39 | R$ 100,00 | Em Estoque |
| Adidas | Branco | 40-41 | R$ 120,00 | Esgotado |
Formatar informações dos sites não é algo novo. Por volta de 1970, no começo da tragetória do SGML, vários browsers já personalizavam as aparências dos documentos, cada um com seu estilo próprio.
Håkon Wium Lie, estudava e percebia as dificuldades que se tinham ao desenvolver um site, e resolveu criar uma maneira fácil para formatar a informação do HTML. Foi aí que ele propôs a criação do CSS ou Cascading Style Sheets. Esse era o ano de 1994.
Em 1995 eles apresentaram sua proposta e finalmente, o W3C - World Wide Web Consortium - que estava acabando de nascer, se interessou pelo projeto e resolveu criar uma equipe, obviamente liderada por Håkon e Bert Bos. O resultado apareceu logo, em 1996, eles lançaram a recomendação oficial pelo W3C do CSS Level 1 (CSS 1).
Dois anos depois, no dia 12 de Maio de 1998, eles lançaram a recomendação do CSS de nível 2. A segunda versão das Folhas de Estilo para web.
Hoje em dia, o nível de compatibilidade entre os browsers é muito parecido, de forma que se você implementar algo específico em um browser, é muito provável que em outro browser esteja igual.
Portanto, o desenvolvedor pode ficar tranqüilo quanto a maioria dos problemas causados por diferenças entre browsers.
13 ComentáriosImagine se cada eletrodoméstico usasse um tipo de tomada. E ao comprar um novo eletrodoméstico, você tivesse que adaptar uma tomada nova em sua casa. Imaginou o caos que seria? Felizmente existe um PADRÃO de tomadas para todos os aparelhos domésticos. Se comprarmos um aparelho de som, e então levarmos para outra cidade, estado ou país, a tomada será a mesma e seu aparelho funcionará. Percebemos então o verdadeiro valor dos padrões. Na Web não é diferente, também é necessário haver padrões. Por isso que projetos como WaSP (Web Standards Project) surgiram no auge da desordem no desenvolvimento do sites. Eles foram um dos que impulsionaram a popularização dos Web Standards, fazendo a W3C (World Wide Web Consortium) ser conhecida por todos como uma autoridade e então ajudando-a a cumprir com seu papel.
O W3C criou linguagens básicas de publicação de conteúdo para Web. Essas linguagens são chamadas de Web Standards (Padrões Web). HTML, XHTML, CSS, SVG, XML, XSLT, entre vários outros.
Esses padrões hoje são estudados e felizmente os desenvolvedores estão aplicando em seus sites. Os desenvolvedores devem perceberem as incríveis vantagens que o desenvolvimento com os Padrões oferece, não só para a execução do trabalho, mas para a estruturação da web em si. Para a estruturação da Web do futuro, onde ninguém terá que garimpar em buscadores para conseguir a informação que se precisa, mas a informação estará aonde você estiver, andará com você aonde quer que for, e você terá acesso a ela sem barreiras, na hora que quiser, onde quiser, e usando o dispositivo que for.
Primeiramente é necessário que entendamos um pouco do conceito dos Web Standards.
A idéia original da Web, era que existisse um ambiente onde pessoas conseguissem trocar informações livremente, e que essas informações poderiam ser acessadas de diversos dispositivos. O W3C (World Wide Web Consortium) criou as linguagens básicas de publicação de conteúdo para Web, como por exemplo: HTML, CSS, SVG, XML, entre vários outros. Essas linguagens são chamadas de Web Standards (Padrões Web).
Por este tempo, deu- se início a Guerra dos Browsers. Onde o Internet Explorer e o Netscape travavam uma briga para conseguir mais adeptos. Durante essa guerra, as linguagens do W3C eram ainda rascunhos. Então, os browsers não tinham um guia completo para se basearem e lançarem seus browsers com suporte a esses Padrões. Resultou que os fabricantes de browsers criaram seus próprios padrões. E foi aí que problema começou a crescer para o lado dos desenvolvedores e usuários. De um lado estava o desenvolvedor estudando as diferenças de cada browser, para assim poder escolher qual ele iria priorizar e qual ele iria ignorar. Do outro usuário, com o mesmo dilema. Se ele escolhesse “tal” browser, os sites que ele visitara poderiam não funcionar.
Os usuários que tinham algum tipo de deficiência, como por exemplo auditiva ou visual, ficaram praticamente isolados do mundo digital, já que os desenvolvedores web tiveram que se adaptar a um certo tipo de browser, obedecendo suas peculiaridades.
Durante essa época, desenvolver um site era um trabalho árduo levando os desenvolvedores escolherem apenas um browser e desenvolver apenas para esse browser. Era quase que insuportável tenta desenvolver um site que se adequasse às duas plataformas de browsers. Os trabalho de atualizar ou fazer manutenções eram enormes e despendiam de muito tempo e paciência.
Foi por esse período que surgiram projetos como o WaSP (Web Standards Project), que é um movimento para difundir os Web Standards. Esse grupo teve um papel muito importante na divulgação dos Padrões. Eles conversaram com os fabricantes dos principais browsers, convencendo- os de fazerem browsers mais compatíveis com os Padrões. E isso deu certo… Tanto que temos o Opera, Mozilla, e vários outros por aí. Hoje, o desenvolvedor tem mais liberdade de desenvolvimento do que a 5 anos atrás. Hoje, a visão dos fabricantes de browser mudou completamente, e se continuar assim, teremos uma web melhor em muito pouco tempo.
Sabendo disso, podemos agora entender o que é Tableless.
Comecemos pelo nome. O nome Tableless é um nome mais “publicitário” para se referir a sites que seguem os Padrões. Os sites Tableless não são construídos usando as famigeradas tables. Elas usam XHTML para apresentar a informação e as Folhas de Estilo (CSS) para formatar essa informação. Pelo motivo de as tables não serem usadas para a estruturação, essa metodologia se chama Tableless.
Antes que você pense que as tables foram totalmente apagadas do mapa, eu explico: No movimento Web Standards, cada tag tem a sua função. Se você quer fazer um parágrafo, usa- se a tag <p>< /p>. Se quer fazer um título de primeiro nível, usa- se a tag <h1>< /h1>. Se você quer exibir dados tabulados, como por exemplo um calendário, ou ainda uma lista de produtos seguidos de nome, preço e tamanho, você usará as tables para exibir esses dados.
Essa pergunta é muito difícil de ser respondida porque as diferenças entre um método e outro são gritantes. Essas diferenças afetam todas as pessoas envolvidas no projeto: começando na equipe de desenvolvimento. Aquela briga tradicional entre designer e programador acaba. Eles começam a trabalhar juntos no mesmo projeto, sem um atrapalhar o trabalho do outro. O designer trabalhará sem tocar no código de programação, ficará apenas no código CSS, onde o programador não terá como estragar o layout do Designer. E dessa forma, com os dois trabalhando ao mesmo tempo, no mesmo projeto, o tempo de produção será diminuída.
Inclui os donos do negócio, já que há diversas economias no desenvolvimento do projeto e também em manutenções posteriores, bem como consumo de banda que é tão preciosa hoje em dia. E finalizando no usuário, que agora pode acessar o site usando a plataforma e o browser que preferir. Poderá acessar de seu Mac ou do seu Linux, usando Opera ou Konqueror. Ele terá controle.
Assunto interessantíssimo. Suponhamos a seguinte situação:
Final daquele grande projeto. Cliente grande, site gigantesco. Várias aprovações de layout durante o caminho. Tudo acertado e pronto para ir pro ar. Faltando apenas alguns detalhes, o chefe chama o designer em um canto e diz: - O cliente acabou de ligar; ele estava analisando o site e pediu que todos os títulos mudassem de cor. Ele não gostou do azul, gostaria de verde mesmo.
O designer, com um olhar de desgosto, volta para sua cadeira e fica pensando em apenas uma coisa: - Por onde vou começar?
Ele fez o site em um editor visual, os títulos do site estão sendo formatados nos próprios documentos, direto no código. A única saída seria abrir documento por documento e substituir título por título.
Creio que se isso não aconteceu com você, algo parecido deve ter acontecido. Se o site acima tivesse sido feito seguindo os padrões, usando CSS para sua formatação, e o código fosse um XHTML bem Semântico, o trabalho disso seria quase nulo. O designer (ou o responsável pelo código CSS) mudaria apenas uma linha.
E se, o caso não fosse para mudar apenas um título, mas mudar o layout do site, como faria? Se o site foi feito do jeito convencional, provavelmente seria da seguinte forma: O designer faria um novo layout em algum programa de imagem, implementaria este layout passando para HTML, e o programador teria que programar novamente em cima deste novo layout. Mas, se o site foi feito seguindo os Web Standards, bastava o designer escrever outro arquivo CSS, e depois de pronto, substituir os arquivos.
Despenderia de tempo apenas de uma pessoa. A programação não seria afetada, e o todo o site funcionaria perfeitamente, já que foi apenas o arquivo de formatação que foi substituído. Passe um pouco de tempo visitando o site: CSS Zen Garden.
Esse layout mostra como isso funciona. O criador deste site disponibilizou o arquivo HTML para download. Os interessados baixam esse arquivo, e fazem um CSS em cima dele e depois mandam enviam de volta. Os interessados tem apenas o direito de criar um CSS e se quiser usar imagens para compor o layout, eles não podem mudar o código HTML que o criador do site disponibilizou.
Há uma infinidade de layouts, bonitos, funcionais e compatíveis… Mudando apenas UM arquivo. Facilidade de manutenção ou renovação de layout, economia de tempo, trabalho e paciência.
Os usuários com necessidades especiais ganham mais facilidade de navegar no site.
Imagine um deficiente visual. Ele usa um browser que ao visitar um site, le todo o conteúdo mostrado na tela.
Os sites convencionais são feitos, em sua maioria com editores visuais. E em todos são usados os famosos spacer.gif. Para quem não sabe o que é isso, eu explico: São gifs transparentes de 1px que servem para dar espaçamento entre celular ou outro objeto da página. Esses spacer.gif normalmente são colocados apenas a tag relacionada a imagem, sem nenhum texto alternativo. Isso faz com que alguns sintetizadores leiam o nome da imagem. Então, suponha que você tem uma célula separada 20px e que essa distância foi feita com os spacer.gif.
O visitante terá que ouvir ou apertar uma tecla 20 vezes para passar essas imagens que são extremamente inúteis para ele. Isso transforma a navegação deles muito, muito cansativa. São coisas bem pequenas que fazem a navegação dessas pessoas valerem a pena.
Existem hoje muitos sistemas que analisam sites para checar se estão de acordo com as guias de acessibilidade. Esses são alguns:
Lembrando que o site não precisa ser Tableless para se aplicar as Guias de Acessibilidade. Mas se o site seguir os padrões, com certeza a experiência de se navegar vai ser muito melhor.
Existia muito, hoje a resistência é menor.
Os desenvolvedores ainda tem medo do novo. Muitos pensam:
- Preciso aprender tudo outra vez?! Tenho que largar o editor visual? Tenho que fazer o código na unha em vez de usar o editor visual que é tão mais fácil, rápido e prático?
Ou, muitas vezes o desenvolvedor já se convenceu, quer mudar, mas esta decisão não depende dele somente, e sim do Chefe. Parece brincadeira, mas já vi muitos casos do chefe falar:
- Você quer dizer que os sites que você vai fazer com essa nova metodologia não vai funcionar no Netscape 4?
Outros dizem que não vale a pena dedicar mais tempo aprendendo tudo de novo só para fazer sites funcionarem em outros browsers que não sejam Internet Explorer:
- Internet Explorer domina 90% do mercado, vou querer fazer para os outros 10%, porque?!
Hoje, felizmente esses comentários estão desaparecendo, e finalmente estão percebendo todas as vantagens que um site que segue os padrões pode trazer. No começo, uma desculpa bastante usada era que: Fazer sites usando os Padrões não servem para criar Portais, como Terra, UOL, AOL, e etc… Isso já é passado, mesmo porque naquele tempo nenhum era Tableless. A equipe do Terra foi treinada pela empresa em que trabalho (visie.com.br), e o site deles é Tableless. O ganho que tiveram com economia de banda foi espetacular e a facilidade de manutenção também foi enorme.
Outro caso interessante é o site da ESPN.
Aquele site é enorme. Depois que migraram o site para os padrões estima- se que a economia de banda seria de 730 terabytes no ano. A Wired conseguiu uma redução de tamanho das páginas de 54%. Diante de números tão expressivos, é difícil contestar de que não vale a pena. E se não valesse, porque sites como: Lee Jeans, Fast Company, Macromedia, Blogger, Chevrolet, Terra, Quark, e outros migraram para os Web Standards?
Como a folha de estilo (CSS) favorece o webdesigner no processo criativo de um site desde a criação até a montagem? Controle.
CSS favorece um grande controle para o designer. Tanto para a criação quanto para a modificação do layout. Usando CSS, o designer não precisa criar inúmeros gifs transparentes para controlar medidas e distâncias. Com CSS ele tem total controle na manipulação de margens, bordas, distâncias, posição, tamanho, e etc. Formatação de texto também uma das vantagens que é muito flexível. O designer pode aumentar o tamanho das linhas dos parágrafos, capitalizar, fazer caixa alta/baixa, e etc… CSS é como se fosse uma ferramenta para o designer. Assim como Photoshop, Illustrator, ou outro programa visual.
Atualmente poucos browsers causam problemas ao desenvolvedor. A maioria dos browsers atuais tem um bom suporte aos padrões, o que permite que os desenvolvedores façam sites sem muitos problemas.
Acho que o que dará mais problemas futuramente, serão os browsers de dispositivos móveis. Mas temos o consolo de que essa fatia do mercado, está começando a caminhar mais rapidamente… isso promete.
São visualizados com a melhor qualidade possível para esse dispositivo.
Claro, se você espera ver um site em um dispositivo móvel do mesmo jeito que vê num PC, é melhor rever seus conceitos. E se você pensa que só porque fez um site seguindo os Web Standards, ele vai ser visto com a melhor qualidade em “mobiles” (dispositivos móveis), também tire o cavalinho da chuva. Lembre- se que existem sites Tableless mal feitos, isso é claro.
Temos que ter em mente que usuários desses dispositivos tem algumas dificuldades, como por exemplo barra de rolagem. Dá um desanimo quando você abre um site num handheld, e então aquela imponente barra de rolagem horizontal aparece. Quando você é obrigado a rolar a barra toda vez que precisa navegar no menu.
No CSS existe uma facilidade enorme, chama-se Media Types. As Medias Types te permitem fazer um CSS exclusivamente para um tipo e Media. Como por exemplo Impressão ou até HandHelds (Essas são as mais comuns, existem outras medias, como por exemplo para leitores de telas para deficientes visuais ou outra que é exclusivamente para impressoras que imprimem em braile. Essas medias ainda não estão totalmente implementadas, por isso não são muito comuns.) As Medias Types funcionam da seguinte forma: se você quer que seu site tenha letras grandes na hora da impressão… Vocês simplesmente fará um arquivo CSS para impressão, que será usado automaticamente quando o visitante tentar imprimir uma página no seu site.
Com a Media Type para HandHelds não é diferente. Você cria um CSS exclusivamente para os dispositivos móveis. Seu site usará a mesma estrutura XHTML para qualquer media, o que muda é apenas o arquivo CSS. Essa é a facilidade que o CSS dá em relação a isso. Mas o desenvolvedor deve ter bom senso, e estudar um bocado esse mundo que é tão interessante e está se aproximando da popularidade tão rápido.
Vantagens enormes, para desenvolvedores e para usuário.
As vantagens ligadas à parte dos desenvolvedores estão na facilidade de manutenção e na briga entre designers e programadores. Na facilidade de manutenção, o desenvolvedor terá uma flexibilidade tremenda na hora de corrigir algum erro ou se simplesmente quiser mudar todo o layout do site. Se o designer quiser mudar o layout do site, ele simplesmente terá o trabalho de escrever outro código CSS formatando o site com o novo visual, e depois apenas substituir os arquivos. Sem trabalho de ter que refazer o código XHTML e sem precisar mexer no código do programador.
A briga entre o designer e o programador termina por que eles não atrapalham mais o trabalho um do outro. Nem o designer estraga o código do programador e nem o programador estraga o layout do designer.
Há muitas maneiras de os designers e programadores trabalharem harmoniosamente. Como por exemplo: no início do desenvolvimento, o designer e o programador podem sentar juntos e então criar a estrutura do documento, ou seja, o código XHTML do site. Aqui eles farão um código semântico, legível. Feita essa parte, os dois trabalharão em cima deste XHTML separadamente, cada um com sua responsabilidade. O programador com seus códigos client - side, banco de dados e etc… Já o designer ou o responsável por isso, formatará o visual do site, usando CSS. Com o XHTML estruturado semanticamente, o designer não terá grandes problemas ao aplicar estilos às tags.
Outra vantagem que interessa a sites grandes (como portais) é a diminuição do consumo de banda. Há uma queda enorme no número de linhas de código, já que tags desnecessárias foram totalmente excluídas e a separação de informação (XHTML) e formatação (CSS) é praticada. O fator “tamanho” é bastante importante, pois se o tamanho do site diminui, o consumo de banda diminui; logo, os gastos excessivos por causa do estouro de banda são imediatamente reduzidos.
Já o lado do usuário ganha uma grande vantagem: flexibilidade e controle. O usuário ganha a liberdade de escolher qual dispositivo, qual plataforma e por fim, qual browser ele irá utilizar para visualizar seus sites. Um usuário por exemplo pode utilizar Mac e navegar com Safari, Firefox ou até mesmo Internet Explorer. Ou utilizar Linux e navegar com Konqueror, Galeon ou Opera. Se preferir, o visitante pode estar usando algum dispositivo móvel como um PocketPC com Windows Mobile e visitar o site utilizando o Internet Explorer.
Como você já percebeu, há uma variação interminável de plataformas e dispositivos. Isso só tende a aumentar. Esse é o caminho que a web deve percorrer. Liberdade para troca de informações, independente do dispositivo utilizado para isso. É isso que o usuário espera.
16 Comentários