Como acabei precisando de um scroller assim, aproveitei e criei uma classe que poderei reutilizar em algum outro projeto em que ela se faça necessária. Já que gostei do resultado, vou aproveitar e deixar o script pra vocês. O resultado será algo parecido com esse exemplo. Prontos? Então vamos lá!

O Código

O script não poderia ser mais simples, em torno de umas 50 linhas de código (você precisaria de centenas se não fosse a Mootools, ou alguma outra biblioteca que faça o serviço sujo). Você pode fazer o download dele aqui. Para “instalá-lo”, basta incluí-lo em seu documento, assim como a Mootools. Além disso, você também vai precisar do plugin Fx.Scroll, que pode ser conseguido no More Builder da Mootools, e incluí-lo no seu documento também.

Update: logo que precisei usar a classe novamente, vi que cometi um erro grotesco. Código atualizado, com erro corrigido e uma nova funcionalidade, explicada logo abaixo. Valendo uma mariola pra quem descobrir minha estupidez, os dois códigos estão disponíveis para download.

O HTML

O HTML necessário é a parte que eu considero a mais complicada, chata e sem graça. Sem o HTML criado direitinho, o scroller não vai funcionar. A lógica é a seguinte: precisamos de um container (geralmente uma div) de uma largura (ou altura) fixa. Esse container é quem vai esconder os itens que não serão mostrados no scroller. Dentro desse container, vamos precisar de mais um container (geralmente mais uma div, ou então uma lista), também de altura/largura fixa, mas que seja igual a toda a extensão dos itens. Ou seja, o container de dentro será maior do que o container de fora.

<div id="container">
    <div></div>
</div>

Acredite, é mais complicado do que parece. Agora sim, podemos colocar nossos itens dentro do container que está dentro de outro container (hein?). Fora isso, precisamos apenas de mais dois elementos (podem ser links) para serem os handlers de anterior e próximo e pronto, aí está o HTML. Só precisamos do CSS que vai ajudar na mágica do script.

O CSS

Como o nosso container externo precisa esconder o que há no container interno (que é maior), ele precisará de um overflow: hidden. Sem isso, tudo o que há no container interno ficará exposto, e aí o scroller perde a graça. Também não podemos nos esquecer de definir as alturas/larguras dos containers e itens. Vamos fazer primeiro um scroller vertical, ligeiramente mais fácil:

* {
  margin: 0;
  padding: 0;
}
#container {
  height: 20px;
  overflow: hidden;
  width: 100px;
}
#container div {
  /* Não é necessário definir a altura, o elemento irá "crescer" sozinho */
  width: 100px;
}
#container p {
  /* A mesma altura de #container, mas isso pode variar com o gosto do freguês */
  height: 20px;
}

O Script

Agora sim, vamos colocar a mão na massa. Minha classe, quando instanciada, leva apenas dois parâmetros: o container exterior (o container interior é deduzível…) e as opções. Dentre elas, temos à disposição todas as opções da classe Fx, e também previousButton e nextButton, que são os handlers para o elemento anterior e posterior do scroller.

var myScroller = new Fx.Scroller("container", { previousButton: "previous", nextButton: "next" })

Aproveitando a atualização da classe, também criei vergonha na cara e adicionei os eventos onNext e onPrevious, executados quando o scroller vai para frente ou para trás, respectivamente.

Pronto! Você escreveu apenas uma linha de script e seu scroller já está funcional, passando de um elemento para outro com apenas um clique!

Scrollers Horizontais

A termos de script, um scroller horizontal é idêntico. A mágica se esconde toda no CSS para este caso. Primeiro precisamos colocar os elementos um ao lado do outro dentro do container interior, certo? Certo. Para isso, usamos a propriedade float, sinta-se à vontade para escolher a qual lado flutuar.

Passando ao segundo passo, devemos definir a largura. A fórmula é a seguinte: número de elementos vezes a largura de qualquer um deles. Se você usar margins ou paddings, não esqueça de levá-los em consideração também.

Usando a técnica de scrollers horizontais, também podemos criar scrollers “mistos”. Nesse caso, há várias linhas e várias colunas de itens ao mesmo tempo. O efeito, se bem usado, pode ficar muito interessante. Quem teve a oportunidade de observar os demos da versão 1.1 da Mootools deve saber do que estou falando.

Dicas para Ir Além

Bem, só fazer itens se mexerem pode não ter tanta graça assim pra você. Como eu disse, minha classe usa todas as opções da classe Fx, ou seja, eventos, transições, offsets, enfim. Agora é sua vez de brincar! Use o offset para mudar a posição dos itens, eventos para mudar sua opacidade, criatividade! Também sinta-se livre para usar os métodos da classe também: next, previous, scrollTo, enable e disable (para ativar ou desativar os botões).

Espero que isso sirva pra alguma coisa! E também espero postar em um intervalo um pouco menor… O pessoal deve ter pensado que eu fugi do país depois de uma certa polêmica. Mas não, só estive ocupado mesmo… Até mais!

Posts Relacionados

• Mootools – Chain
• Mootools – Eventos
• Mootools – Options
• Sliders com Mootools
• Mootools – Menu Sanfona

O site é focado em “ler sobre código, ler código e colaborar”, segundo o próprio Élcio. Não há muitos posts até o momento, mas o que já foi postado, tanto pelo Élcio quanto por outros colaboradores, é um conteúdo selecionado, e de boa qualidade.

Gostei muito da política do site, bastante rígida quanto à seleção de conteúdo. Teremos uma boa referência se ela for cumprida. O cadastro e postagem são abertos a qualquer um, basta enviar bom conteúdo.

Já assinei o feed e me inscrevi. Falta acertar todos os dados do cadastro, e logo estarei postando algum conteúdo, talvez até exclusivo (se me vier alguma idéia). Se quiser, também sinta-se livre para cadastrar-se e começar a postar.

Posts Relacionados

• Cliente x Seu Ego
• O que você faz em 4Kb?
• Back Button Improved!
• Ajax vs. Acessibilidade
• Ativando o Botão Voltar

A maioria das pessoas que passar por aqui vai responder essa pergunta sem nem pensar: “SIM”. Será mesmo?

Não duvido que muita gente saiba DE VERDADE Webstandards (falo aqui só de XHTML e CSS), mas muita gente se equivoca. Isso porque falta experiência. Antes de começar esse meu trabalho secreto (suspense…), pensava que sabia razoavelmente WebStandards. Me enganei. Eu já tinha certa experiência, mas ela foi bem mais elevada agora. Principalmente no que se diz respeito a posicionamento. Agora dá pra ver que não estou tão perto assim.

E você, ainda acha que sabe? Tem certeza? Experimente colocar uma coluna do lado da outra sem usar float… Ou resistir a colocar uma tabela em algum lugar (é, isso que eu nunca trabalhei com tabelas). Se você ainda se sente inseguro, treine bastante. Se você já é experiente, continue treinando, tenho certeza de que não sabe tudo, e experiência nunca é demais.

E isso serve para qualquer coisa, não só Webstandards. Usei esse tema para se relacionar com as dificuldades que passei (resolvi sozinho, mas levei uns dois dias quebrando a cabeça, na tentativa-e-erro). Treine, leia, estude, faça desafios a si mesmo, experimente converter um site (em caso de WS), colocar JavaScript em algum lugar, enfim…

Posts Relacionados

• Qual editor você usa?
• Pra quem você escreve?
• O que você faz em 4Kb?
• Cliente x Seu Ego
• Semântica

Continuo defendendo aquele meu velho ponto de vista, mas desta vez vou ampliar um pouco minha “visão da coisa”.

Impor o Firefox como browser a ser escolhido pelo seu cliente é suicídio. Nem tente. No máximo uma sugestão. Mas aí surge um problema: se 80% dos internautas usam Internet Explorer, vale a pena usar os padrões? Já voltamos aí.

Por mais que seu ego diga “Valida logo!”, seu cliente diz “Termina Logo!”. No caso, IE, gambiarra, hack, defeito, dor de cabeça… Se você desenvolve primeiro no Firefox, há uma grande possibilidade de tudo estar validadinho. Se você desenvolve primeiro no IE, nem vou falar.

E aí, já decidiu? Crie tudo primeiro para o Firefox. Quando tudo estiver direitinho, faça as alterações, gambiarras, hacks, comentários condicionais… Vai tudo estar pronto antes (por mais que não pareça), e você satisfez seu ego (isso é bom, né?) e seu cliente (que vai estar feliz por funcionar 100% no IE e por você ter entregue na hora). Além disso, sua impressora fica livre de ter que imprimir alguns currículos…

E a pergunta de sempre: Validar ou não? Sim, sempre que possível (nem sempre há tempo). Não perca seu emprego por um bug do seu código ou do W3C, siga feliz!

Posts Relacionados

• ClientSide: Mostre seu Código!
• Não validou. E agora?
• Vale a pena arriscar em novas tecnologias?
• DIVless
• Caindo na Real

Quando os padrões “apareceram” aqui no Brasil, e ganharam uma certa forcinha, acredito que a maioria dos desenvolvedores conscientes correu para o validador da W3C, para ver os trabalhos validados e colocar aqueles selinhos de validação. Se não validasse, tudo de novo, até estar 100% validado. Isso leva, várias vezes, em um bom tempo ajustando em todos os navegadores, para que fique igualzinho ou pelo menos apresentável.

Creio que hoje essa “mania” passou. Claro que temos vários sites validados, mas é realmente necessário todo esse trabalho? Essa é mais uma questão filosófica, e discutiremos aqui.

Como todo mundo sabe, o validador do W3C (seja ele (X)HTML ou CSS) verifica apenas se o código está bem escrito, avisando sobre tags não fechadas, erros de código e etc. Ele não diz se o site está apresentável em todos os navegadores, não verifica semântica, não mede desempenho, nada. Então, “ser ou não ser” validado?

Analisemos a nossa situação. Temos um documento não validado, e pra ajudar um browser horrível (não quero citar o nome IE para não constranger), mas nosso documento funciona perfeitamente nele e em outros browsers decentes. Existe apenas um único erro de código, que serve exatamente para nosso querido amigo azul. Ahh! Temos um prazo também, e só existe uma solução para corrigir o tal bug, mas a solução é enorme, e demoraria séculos para terminar. Temos as seguintes opções:

• Suicidar-se
• Começar a chorar
• Apelar pra tudo quanto é santo
• Perder o emprego
• Entregar o trabalho não validado

Tempo… E aí, já decidiu? Considere que as três primeiras opções não são de grande ajuda. Sobram-nos duas. Perder o emprego também não é bom…

Os nossos browsers de hoje em dia não conferem nossa marcação. Se está errado, e funcionando, tudo certo. É lógico que um trabalho validado é uma conquista, mas quando se tem um prazo pequeno não vale a pena perder boa parte do tempo para consertar um bug.

Em um futuro muito distante, os browsers lerão tudo como XML. Aí sim precisaremos de marcações impecáveis. Mas se você serve seus documentos como “text/html”, não há problema (muito).

Cortando toda minha enrolação, resuminho pra vocês: não perca tempo para consertar um bug, se está tudo certo deixe assim. Mas é lógico que se você tiver um tempinho de sobra, faça o possível para validar tudinho. Tempo = dinheiro. Validação = menos tempo. Validação + tempo extra = tudo validado. Captou? Até!

Posts Relacionados

• PC formatado, e agora?
• Desenvolver com Rails não tem graça…
• Diz que até não é … um mau blog
• Semântica
• Cliente x Seu Ego

Pra quem conhece, Tableless significa criar um site seguindo os padrões, com código semântico, preferencialmente estrito, e não banir totalmente o uso da tag <table>, como quem está entrando no tema pensa. Alguns se gabam de conseguir mostrar dados tabulares usando apenas DIVs. Isso é o equivalente a criar um site usando tabelas.

Em minha opinião, um site Tableless é feito seguindo os padrões (ou deveria). O termo tableless é polêmico (vide Tableless tem que morrer), e é apenas um nome. Lá fora o termo usado para definir um site que segue os padrões é “CSS Layout”. E poderia ser qualquer outro. O nome não interessa, o que interessa é como o site é feito. WebStandards são necessários para a criação da Web 2.0, e nesse bolo também entra a semântica.

Tableless, no sentido que costumamos usar, é seguir os padrões, e não banir o uso de tabelas. Pense nisso, lembre-se disso.

Alguns ainda não consideram que um site Tableless segue os padrões (mas pode seguir sim, sem nenhum problema). No Tableless e no Revolução Etc tem dois posts interessantes sobre o assunto: Tableless vs. WebStandards.

Baseando-se nisso, praticamente excluí Tableless do meu vocabulário. Costumo usar “Site Semântico”, ou coisas assim. O termo em questão está aberto a muitas interpretações diferentes. Novamente digo: o nome não interesa. O que interessa é o que o conceito quer dizer.

Posts Relacionados

• DIVless
• Semântica
• E a tal da Web 2.0?
• Você sabe Webstandards?
• Cliente x Seu Ego

O que é?

Basicamente (e literalmente), DIVless é a ausência de DIVs. Todas as DIVs são trocadas por listas não ordenadas e listas de definição.

Por quê?

Segundo o autor do DIVless, as listas tem um sentido inerente mais hierárquico e sintático. Em outras palavras, a hierarquia do site se apresentaria melhor, com ou sem o uso de CSS ou no código.

O autor também afirma, com ajuda do W3Schools, que as listas como elementos de layout seguem os padrões semânticos.

Também é apontada a falta de significado da tag DIV em browsers antigos, e ela também não apresenta estrutura hierárquica e visual em browsers que não usam CSS. Isso realmente é verdade. E tudo testado em IE 6 e 5.5, Firefox e Safari.

E a Semântica?

Em minha humilde opinião, a semântica vai por água abaixo. O que vale é a palavra do W3C, e não qualquer outra. Layouts são controlados por DIVs, e não listas.

Lembra-se quando ainda usávamos tabelas para posicionar elementos? DIVless é tão semântico quanto isso. Realmente a tag DIV não tem nenhum valor semântico, mas podemos adiciona-lo através dos atributos class e id.

A técnica do DIVless realmente foi bem bolada, todos os argumentos do autor são verdadeiros (exceto a questão semântica). Visitei a página sem suporte a CSS e apareceu bem melhor do que com DIVs. Isso é indiscutível. Mas e a semântica? Realmente é uma questão delicada.

Em minha opinião, DIVless não terá muito futuro, pelo menos até que o futuro chegue.

Posts Relacionados

• Tableless
• Semântica
• CodeCast #3 – Semântica e Microformatos
• Não validou. E agora?
• CodeCast #2 – XHTML 2 e HTML 5

Nas recomendações do W3C, cada elemento (tag) tem sua função própria no (X)HTML. Cada tag tem seu papel a cumprir, foi criada com um propósito. Criar documentos semanticamente corretos significa utilizar a tag certa no lugar certo. Por exemplo: <h1> para título superior, <p> para parágrafos… Não pretendo explicar aqui a função de todas as tags. Se estiver interessado, visite o W3Schools.

É completamente possível fazer um site inteiro usando apenas parágrafos. Talvez listas. É possível fazer um layout completo e apresentável usando qualquer tag. Isso é possível graças ao CSS, que permite modificar propriedades das tags. Mas essas propriedades são apenas visuais. Não é possível modificar a função semântica de algum elemento por CSS. Isso é impossível. E um site feito assim passaria na validação? Lógico! Se ele for bem formado, usar tags de acordo com o DTD, ele será validado. Não existe e nunca existirá um validador de semântica. Você mesmo terá que avaliar se seu documento é semanticamente correto. E se passa na validação, por que semântica?

A resposta é simples. Pense em um usuário que não enxerga, não ouve e ainda por cima não “raciocina”. Um exemplo desse usuário é o famoso Google. Ele não se importa com seu CSS. Então, quando ele for indexar sua página, ele procurará significado em suas tags, de acordo com as recomendações do W3C. Como ele entende apenas o significado das tags, como ele entenderá suas classes? Classes não tem valor semântico (ainda). Se seu código é bem tratado e tem significado, ele é Semântico. Aplicações como o Google, quando encontram uma certa tag, elas dão uma importância X para aquele elemento, dependendo do valor semântico que ele possui.

Analise: criando documentos semanticamente corretos, além de contriuir para uma web melhor, você estará beneficiando a si próprio. Seu site poderá aparecer primeiro no Google e outros motores de busca, será bastante amigável aos leitores de tela, será compatível com aplicações futuras, enfim, muitos outros benefícios que você descobrirá quando for desenvolver. Senti diferença ao ver que minhas folhas de estilo referenciavam mais tags do que classes. Você terá uma maior variedade de tags.

Bem, espero que tenha sido útil. Pretendo colocar mais alguns exemplos de semântica e seus benefícios a medida que meus estudos avançarem. Até a próxima!

Posts Relacionados

• DIVless
• CodeCast #3 – Semântica e Microformatos
• Tableless
• innerOptions
• Não validou. E agora?