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 »
21 ComentáriosQualquer um que codifique HTML, ou mesmo use um editor WYSIWYG, já esbarrou no problema. Se você trabalha com internet, já deve ter tido também esse problema. O código se tornou complexo, com várias tabelas, uma dentro da outra. Vários frames, com uma porção de scripts para manter o
conteúdo atualizado entre eles. Uma parte da aplicação rodando em um pop-up, com um script
que atualiza o conteúdo principal.
Então, cumprindo a lei de Murphy, um dos seguintes fatos indesejáveis acontece:
Que fazer? É claro que com muito cuidado e talentoesse tipo de problema pode ser evitado, mas isso envolve umaquantidade de trabalho insana. Já vi muitos projetosonde se gastou mais tempo preso nas entranhas de umcódigo complexo do que em qualquer outra fase doprojeto.
Tem um pessoal na web que propõe umasolução bastante interessante para isso.É a turma do WaSP (www.webstandards.org.) Assoluções não são apenas uma listade novas tecnologias, mas também uma filosofia dedesenvolvimento baseada na simplicidade.
Baseado nessa filosofia da simplicidade, que tem me rendidoresultados surpreendentes, gostaria de fazer algumassugestões interessantes:
Quem já trabalha com XML certamente percebeu o poderda flexibilidade e da simplicidade. Éimpossível escrever um XML com erros de sintaxe,porque os interpretadores reclamam imediatamente. Émuito simples escrever documentos XML, sendo fácilextrair dados de qualquer banco de dados etransformá-los em XML (a maioria dos SGBDs incorporaou tem planos de incorporar o suporte nativo a XML.)Através da poderosa linguagem XSL e da farta oferta deparsers gratuitos, XML pode ser transformado em praticamentequalquer formato de arquivo.
XHTML nada mais é do que uma forma de escrever umdocumento HTML de modo que ele também seja umdocumento XML válido. Ou seja, seu documento HTMLganha a coerência e flexibilidade de um documento XML,podendo ser facilmente lido por ferramentasautomáticas e convertido em outros formatos dearquivos. Com XHTML torna-se muito fácil oferecer osdados do seu site através de WAP ou de um RSS(http://rssficado.pilger.inf.br)por exemplo. Torna-se fácil também transformaro resultado de uma consulta a banco de dados ou um documentoXML numa página web.
A boa notícia é que é muito fácilescrever XHTML. Qualquer um que escreva HTML pode aprender afazê-lo sem muita dificuldade. Existem inclusive umasérie de ferramentas interessantes para tornar esseprocesso mais produtivo, como o excelente HTML Tidy(http://tidy.sourceforge.net)que tem uma eficiência impressionante para umaferramenta automática.
Como você cria um título num documento HTML?
O meio comum hoje em dia para fazê-lo é:<font face=”Arial” size=”4″ color=”blue”>Texto doTítulo</font>.
Quando eu estudei HTML, em 1996, aprendi que existia uma tagespecífica para criação detítulos. É a tag h1. Assim, a maneira de secriar um título em HTML seria: <h1>Texto doTítulo</h1>.
Extremamente mais simples, não é verdade? Etorna o código também mais significativo. Assimum interpretador pode saber, por exemplo, onde estãoos títulos no meio do texto. Ou seja, esta abordagemdá significado semântico ao código.Aquele tag passa a significar alguma coisa, mesmo quenão seja vista num browser que renderize a fonte maiore azul que você tinha planejado.
Aliás, por falar no texto azul, se você usar asegunda abordagem seu título será exibido comos estilos padrão do navegador, e seu azul vai para obeleléu. Como você não quer perder abonita formatação que havia planejado, aquientra uma segunda linguagem, o CSS. Com CSS você podecolocar toda essa informação sobreformatação num arquivo externo. Assimvocê fica com um arquivo HTML apenas cominformação (que fica muito mais simples,organizado e rápido de se escrever) e mantémtoda a formatação num arquivo externo. Se umdia seu chefe resolver que todos os títulos do sitetem que ser vermelhos ao invés de azuis (acredite,isso é muito comum) você sóprecisará alterar uma palavra em um únicoarquivo e todos os títulos do site estarãoautomaticamente ajustados.
Tabelas são um recurso muito útil do HTML. Semtabelas como exibiríamos informaçõescomo uma lista de produtos, um extrato bancário ou umcalendário? O problema é que tabelas tem sidousadas para muito mais do que isso. É preciso colocaro menu ao lado do texto? Cria-se uma tabela. É precisoque o texto tenha uma largura delimitada? Cria-se uma tabela.Imagem junto ao texto? Menu no cabeçalho? Duas colunasde texto? Tabela neles!
E como fica, nessa situação, a semânticado documento? Como você deve imaginar, nãohá aqui aquela prática separaçãoentre informação e formatação.Além disso, temos um outro sério problema: embrowsers antigos, ou mesmo em browsers modernos maldesenvolvidos, como o Internet Explorer, as tabelas sósão exibidas depois que a última tag</table> chega ao navegador.
É por isso que, quando você estáconectado via dial-up, em alguns sites a tela fica em brancodurante longos segundos (às vezes minutos) atéque é exibido de uma vez só.
Abrir mão de tabelas para montar layouts vai tornarseu código muito menor, mais simples e organizado. Vaitambém centralizar a formatação,colocando tudo que se refere a layout em um únicoarquivo. Imagine a facilidade de manutenção.Melhora também a experiência do usuário,pois a informação é exibida instantaneamente, assim que chega ao browser.
Dá-se a esta abordagem o nome de tableless. Apesar donome, não é a ausência total de tabelas,mas o seu uso apenas onde é semanticamentejustificável. De lambuja, um documento tableless bempensado vai funcionar em qualquer navegador, em qualquer sistema operacional, mesmo em PDAs.
Pense muito antes de aplicar uma solução
baseada em frames, DHTML, scripts absurdos, pop-ups, plugins,
ActiveX, Applets ou qualquer outra tecnologia que quebre
essas duas premissas da internet:
- A web é um ambiente multiplataforma.
- Cada documento na web tem um endereço associado a
ele.
Não vou me alongar nesse tópico, mas gostaria que você tomasse um tempo para ler:
O interessante dessa abordagem baseada na simplicidadeé que você não precisa fazer tudo de umavez. Se está inseguro para começar, pode apenaseliminar as tags <font> e criar um arquivo CSSúnico. Ou pode começar usando os recursos deXML do seu banco de dados para gerar XHTML, ou criando umRSS. O importante é começar a simplificar antes que você fique maluco!
7 ComentáriosA maior parte dos desenvolvedores web, designers ou programadores, começaram antes do surgimento dos movimentos em prol dos padrões web, usando tabelas para montar layouts em editores WYSIWYG, e ainda hoje este método é usado na maioria dos projetos de internet. Logo, é natural que muita gente, ao começar a entender o valor dos padrões, se pergunte como migrar do desenvolvimento “tradicional” para o desenvolvimento de código semanticamente coerente.
É um caminho muito duro o que separa o desenvolvedor acostumado a editores visuais do desenvolvimento de código coerente. E é muito comum que o designer desista após uma primeira tentativa frustrada de desenvolver um website tableless, com layout CSS e XHTML validado.
Por isso gostaria de propor um caminho gradual, mais suave, para aqueles que querem se aventurar pela primeira vez pelos padrões web. O princípio desse método é da recompensa. Você pode obter um grande benefício aproximando seu código dos padrões web, mesmo que não faça tudo de uma vez. Quero mostrar como você pode começar, e obter benefícios imediatos.
A minha primeira recomendação é que você estude CSS. Comece pela formatação básica de fonte, cor e tamanho. Isso vai te garantir código menor e produtividade maior com pouquíssimo esforço.
Assim, ao criar um item de menu, você vai evitar códigos como este:
<a href="parceiros.asp"><font face="Arial, Helvetica, Sans-serif" size="2" color="#FF3300"><b>Parceiros</b></font></a>
Colocando no lugar:
<a href="parceiros.asp" class="menu">Parceiros</a>
Tendo no CSS:
.menu{
font-family: Arial, Helvetica, Sans-serif;
font-size: 80%;
font-weight: bold;
color:#FF3300;
}
Como você pode ver, o CSS é extremamente simples. Aprender esses quatro atributos, mais o “font-style” (para fazer itálico), é a primeira coisa que eu recomendo. É claro, isso apenas faz cócegas nas possibilidades do CSS, ainda há muito o que aprender, mas recomendo começar por aí porque é algo que você pode aprender em alguns minutos e vai te salvar muito, muito tempo. E você vai começar a ter o controle da formatação, tendo todas as definições de fonte em um único arquivo, podendo alterar, por exemplo, a qualquer momento, a fonte de todo o conteúdo ou de todos os menus do site.
O passo seguinte para limpar seu HTML é se livrar do spacer.gif, aquele gif transparente de 1 pixel que se usa para dar espaços em tabelas, e das dezenas de tabelas aninhadas. Para isso vamos começar a estudar o “box-model”.
O pulo-do-gato aqui é um atributo CSS chamado padding. O padding é a distância entre as bordas de um elemento e o texto dentro dele. Assim, se é preciso que o conteúdo de uma célula esteja a 10 pixels da borda esquerda, ao invés de inserir uma célula extra como espaçador, ou inserir mais uma tabela, basta definir uma classe para essa célula. Uma vez que você já está colocando a formatação no CSS, provavelmente esta célula já tem uma classe. Então basta:
.conteudo{
padding-left:10px;
}
Isso vai fazer com que o texto esteja a 10 pixels da borda esquerda do documento. Ah, claro, o CSS também pode livrar você de definir no HTML as bordas e o background das células de sua tabela. Lembre-se, quanto mais layout e formatação você colocar no CSS, mais controle terá sobre seu site, principalmente em mudanças de layout durante o processo de produção e em futuras manutenções. O site também será mais leve para carregar.
Concluímos então que, após aprender os atributos de formatação de fonte, o passo seguinte é aprender os atributos background, border e padding. Indo até aqui você com certeza será um desenvolvedor muito mais feliz! Depois de limpar seu HTML, ganhar controle sobre a formatação de seu site e se tornar muito mais produtivo, você está pronto para passar à segunda etapa, correndo atrás da semântica.
Muito bem, agora você já pode limpar seu código. Vamos estudar um exemplo prático. No começo de cada uma de suas páginas você tem um título, cujo código hoje é assim:
<font face="Arial, Helvetica, Sans-serif" size="4" color="#FFFF00"><b>Novidades</b></font>
Ao limpar esse código, você vai substituir esse monte de tags por uma só. Que tag você vai usar? Como o CSS te permite formatar qualquer elemento, muita gente que começa a estudar o assunto acha que é indiferente que tag usar, e coloca algo como:
<p class="titulo">Novidades</p>
Agora, veja bem, outro desenvolvedor poderia resolver o mesmo problema com:
<div class="titulo">Novidades</div>
E o resultado visual poderia ser o mesmo. Acontece que há algo na natureza do HTML que nos diz que tag usar. Chamamos esse algo de “semântica”: as tags do HTML tem significado. A tag P é para parágrafos, a tag DIV para divisões no conteúdo, e há uma série de tags para título, h1, h2, h3, h4, h5 e h6. Assim, se você pode usar qualquer tag, pode fazer assim:
<h1>Novidades</h1>
O que você ganha com essa preocupação? Os buscadores inteligentes podem ler semanticamente o conteúdo de um documento, entendendo que trecho de código é um título, por exemplo. Assim, escrever HTML semanticamente correto pode melhorar muito sua visibilidade em buscadores. O segundo bom motivo é que você vai saber para que serve cada tag se tiver que mexer nesse mesmo documento daqui a alguns meses. E vai ser mais fácil também se outra pessoa tiver que dar manutenção no seu código.
Logo, use as tags do HTML para aquilo para o que foram criadas:
Você pode obter uma lista mais abrangente em:
http://www.w3schools.com/xhtml/xhtml_reference.asp
E formate tudo ao seu gosto com CSS.
Não há bons motivos para você eliminar a qualquer custo todas as tabelas de seu primeiro trabalho. Conheço alguns excelentes profissionais, muito talentosos, que fizeram um ótimo trabalho em sua primeira tentativa de tableless. Mas a maioria dos que eu vi tentarem demoraram muito para conseguir da primeira vez, e alguns não obtiveram os resultados que esperavam. Isso tudo serve para que você possa produzir mais rápido e melhor, não o contrário. Então vá com calma. Faça alguns estudos em tableless, comece eliminando parte das tabelas em seus primeiros trabalhos. Por exemplo, remover as células de tabela que formam o menu, trocando por uma lista (com as tags ul e li), é um ótimo desafio para o primeiro projeto.
Ah, e não se esqueça que para dados como uma tabela periódica ou um calendário a solução semanticamente correta é a tabela mesmo. Ou seja, tableless não é ausência de tabelas, é o seu uso apenas onde é semanticamente justificável.
Não vou entrar em detalhes aqui, porque já escrevi bastante sobre como construir um layout no Tutorial Tableless Básico, mas o conselho é ir com calma, sem estresse. Você logo vai estar produzindo tableless mais fácil do que produz sites com tabelas.
Há uma coisa que muita gente que está começando me pergunta: o que é e para que serve esse tal de XHTML? É muito mais simples do que parece. Um arquivo XHTML é um arquivo HTML, que pode ser lido por qualquer browser. Não estamos falando de um novo HTML, com novas tags ou coisa assim. Pelo contrário, o XHTML 1 foi feito para funcionar mesmo em navegadores antigos. Mas, ao mesmo tempo, Um arquivo XHTML é também um arquivo XML válido, que pode ser lido por qualquer interpretador de XML.
Meu primeiro conselho, nesse caso, é que você, se não trabalha com XML, deixe preocupação com o XHTML para depois de dominar bem o código semântico e o layout tableless. Não porque seja complicado, pelo contrário, transformar bom HTML em XHTML é bem simples, mas simplesmente porque você pode obter benefícios muito significativos, e muito mais rapidamente, aprendendo CSS do que XHTML.
O segundo conselho é que você comece a estudar o assunto. Depois de dominar bem layouts CSS, mergulhe no XML. A maioria dos bancos de dados hoje permite extrair dados diretamente em XML e todas as plataformas de aplicações web trabalham bem com XML. E com a poderosa linguagem XSLT você pode muito facilmente oferecer seus os dados em XHTML para o navegador.
Estamos falando de muito mais do que criar sites estilosos. Há duas semanas esteve aqui um amigo com um Palm novo, um Zire 71, e um celular com acesso à internet. Isso está se tornando cada vez mais barato e comum. Conheço também uma porção de empresas e instituições, entre elas uma série significativa de TeleCentros e órgãos públicos, que estão adotando Linux como sistema operacional para desktops. O Google hoje é responsável por 90% do tráfego que meu site consegue de buscadores. É o primeiro colocado absoluto entre os buscadores. E conseguiu isso indexando semanticamente o conteúdo real dos sites. Praticamente todas as plataformas web estão oferendo suporte a XML e apostando na idéia de webservices.
Quem segue os padrões web não precisa ter medo do futuro. Não importa que browser vai ser o mais usado daqui a dois anos, que tecnologia vai estar na moda ou de onde as pessoas vão estar usando a internet. Seu site estará lá, leve, acessível, atual e útil.
5 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.
15 Comentários