» Publishers, Monetize your RSS feeds with FeedShow: More infos (Show/Hide Ads)
Olá, pessoal! Tudo tranquilo?
Estou contente pela boa receptividade que as colunas sobre HTML5 têm tido! A primeira, sobre a introdução do HTML5 no mercado, e a segunda, sobre tags para organização. No artigo de hoje vou focar em formulários, que particularmente é a coisa que mais detesto fazer em HTML. A divergência entre os browsers é muita, variando bastante alinhamentos e estilos aplicados.
Lembrando que o manual completo sobre HTML5 é encontrado no site da W3C, sendo lá um material oficial. Quem quiser dar uma conferida em tudo, só acessar por este link .Qualquer dúvida podem entrar em contato comigo pelo meu site ou meu Twitter.
Vamos recapitular as principais funções que temos disponíveis no HTML hoje:
- Accept - Aceito em inputs do tipo FILE, porém muito pouco usado diretamente. Decreta os tipos de arquivos aceitos.
- Alt - Define um texto alternativo caso não tenha imagem, para inputs do tipo IMAGE.
- Checked - Usado para botões de seleção (checkbox e radio), permite deixar o botão selecionado.
- Class - Setamos um estilo para usarmos através do CSS, Javascript e outros fins.
- Disabled - Para desabilitar a edição de um elemento.
- ID - Setamos o nome do nosso elemento, para referenciarmos em nosso sistema.
- Maxlength - Definimos o número máximo de caracteres a serem digitados
- Name - Setamos um nome para o campo, podendo ser usado para validação ou outros meios de controle, além de ajudar em questões de SEO.
- Size - Número de caracteres, que na teoria deveria ser a quantidade de itens visíveis, mas que funciona mais como uma forma alternativa de setar largura.
- Src - Inputs do tipo Imagem, usado para setar o caminho da imagem.
- Tabindex - Definimos a ordem de importância do campo, quando o mudamos através da tecla TAB.
- Type - Usado em Inputs, para setarmos se é um botão, botão em forma de imagem, checkbox, radio e etc.
- Value - Determina o valor do campo (não é usado para Textarea, cujo valor fica interno na tag).
Peço desculpas se esqueci algum parâmetro, mas acho que todos entenderam as principais opções que temos hoje em formulários.
Agora, vamos partir para as novidades!
Antes de tudo, vou contar as boas notícias:
- Será possível fazer uma validação diretamente por HTML
- Será possível fazer máscaras diretamente por HTML
- Será possível mencionar quais tipos de dígitos são aceitos no campo por HTML
- Não serão mais necessários componentes para Datapicker (aqueles que aparecem o calendário quando você clica em um campo de data), o HTML5 faz isso automaticamente!
Além de várias outras funções que tendem a facilitar a nossa vida (ou talvez complicar ainda mais).
Agora veremos todos parâmetros "Types" novos que um INPUT pode ter no HTML5, e se ele é ou não compatível hoje (não considerei versões anteriores ao IE8).
Esses novos "types" que vão anular componentes externos que muitas vezes dão dor de cabeça nos projetos.
Testei nos seguintes navegadores/plataformas: Firefox 3.6.8, Opera 10.60, Chrome/Safari 5.0 e Internet Explorer 8.
Exemplo de como é usado: <input type="color" />
COLOR
- Compatibilidade atual: Nenhum dos browsers mencionados.
- Função: Exibir uma palheta de cores para escolha, como faz falta em muitos projetos! Às vezes é um bom trabalho para conseguir aplicar uma, quanto mais fazer.
DATE
- Compatibilidade atual: Opera.
- Função: Abre um calendário para escolhermos uma data.
DATETIME
- Compatibilidade atual: Opera.
- Função: Abre um calendário para escolhermos uma data e ainda podemos setar um horário.
DATETIME-LOCAL
- Compatibilidade atual: Opera.
- Função: Abre um calendário para escolhermos uma data, também podendo setar horário. Mas agora nosso horário local, com fuso horário.
- Compatibilidade atual: Opera (ainda sem diferenciação visual).
- Função: Teoricamente servirá para fazermos validação direto com o HTML5. Existem outros campos com esta finalidade.
MONTH
- Compatibilidade atual: Opera.
- Função: Abre um datapicker para escolhermos mês e ano.
NUMBER
- Compatibilidade atual: Opera.
- Função: Será usado para validação também. No Opera tem diferenciação visual e não possibilita o usuário escrever outro caracter.
RANGE
- Compatibilidade atual: Chrome/Safari e Opera.
- Função: Abre uma espécie de 'régua' para podermos setar um valor, estilo pior/melhor.
TEL
- Compatibilidade atual: Opera (ainda sem diferenciação visual).
- Função: Será usado para validação, não achei muitas informações sobre. Vejo problemas nesse aspecto, devido a cada país diferenciar a quantidade de dígitos do número.
TIME
- Compatibilidade atual: Opera.
- Função: Um campo somente para setar hora-minuto.
URL
- Compatibilidade atual: Opera (ainda sem diferenciação visual).
- Função: Outro campo usado para validação, visualmente não tem diferenciação.
WEEK
- Compatibilidade atual: Opera.
- Função: Bem interessante, abre um campo para escolhermos ano e dia. Escolhendo o dia, ele armazena o ano e a semana.
Pela análise, ponto para o Opera! Ponto negativo (para variar) para o IE8 e, quem diria, Firefox. Queria ver funcionando o tipo COLOR, ver a palheta de cores sendo mostrada, mas infelizmente ainda não é suportado. Meu medo principal dessas tags é a personalização; fui tentar editar no Opera as tags equivalentes a data/hora etc. Algumas coisas não foram aceitas, consegui editar tamanho da fonte, cor da fonte (de algumas coisas apenas). Outros comandos não foram bem aceitos.
Veja:
Outros parâmetros novos (não ligados ao type).
Exemplo: <input parâmetro="valor" /> - <input autocomplete="on" />
Não vou passar todos parâmetros novos, pois são muitos e o texto ficará cansativo. Seguem alguns bem interessantes:
Autocomplete
- Valores: On, Off.
- Função: Não fique tão feliz com antecedência! Achei que era um autocomplete, de dar sugestões por usuário através de dados vindos de um banco ou semelhantes. Mas a real função dele é te dar a opção de escolha de o campo ser ou não lembrado. Por exemplo, eu digitar "email" em um campo de e-mail, e ele me mostrar o que já preenchi em campos do mesmo nome. Comando simples e que pode ser bem útil.
Form
- Valores: 'nome do formulário'.
- Função: Você pode concatenar o campo a um formulário específico, criando campos interligados.
Formenctype
- Valores: application/x-www-form-urlencoded, multipart/form-data, text/plain.
- Função: Pode setar um formenctype específico para um campo, anulando o "formtype" principal.
Formtarget
- Valores: _blank, _self, _parent, _top.
- Função: Após darmos a ação, onde que será aberto a nova tela.
Height
- Valores: % ou pixels.
- Função: Podemos definir uma altura por nossos campos, antes só era possível por CSS.
Max
- Valores: número máximo de caracteres.
- Função: Podemos setar um tamanho máximo de caracteres, uma espécie de Maxlength, só que é usado em combinação com o parâmetro MIN, para setarmos um tamanho máximo e um mínimo para o campo.
Min
- Valores: número mínimo de caracteres.
- Função: Número mínimo de caracteres que o campo deve ter.
Required
- Valores: required.
- Função: Podemos mencionar se este campo é ou não obrigatório.
Nota importante - é possível setar no CSS algo como: input:required e colocar um estilo nos campos obrigatórios.
Width
- Valores: pixels ou %.
- Função: Podemos setar uma largura em pixel ou porcentagem, não mais por número de caracteres.
Como percebemos, as novas funcionalidades para formulários são grandes! Existem diversos novos parâmetros para diversas outras TAGs, nos quais pouca gente se habitou 100% ainda. Mas, infelizmente, como percebemos também, poucos browsers hoje suportam, mas isso é uma questão de tempo (longo tempo).
Para finalizar, gostaria de agradecer à HostDime, que sempre me dá uma força enorme para produzir os artigos!
Espero que tenham gostado, até a próxima!
Olá, pessoal! Tudo tranquilo?
Estou contente pela boa receptividade que as colunas sobre HTML5 têm tido! A primeira, sobre a introdução do HTML5 no mercado, e a segunda, sobre tags para organização. No artigo de hoje vou focar em formulários, que particularmente é a coisa que mais detesto fazer em HTML. A divergência entre os browsers é muita, variando bastante alinhamentos e estilos aplicados.
Lembrando que o manual completo sobre HTML5 é encontrado no site da W3C, sendo lá um material oficial. Quem quiser dar uma conferida em tudo, só acessar por este link .Qualquer dúvida podem entrar em contato comigo pelo meu site ou meu Twitter.
Vamos recapitular as principais funções que temos disponíveis no HTML hoje:
- Accept - Aceito em inputs do tipo FILE, porém muito pouco usado diretamente. Decreta os tipos de arquivos aceitos.
- Alt - Define um texto alternativo caso não tenha imagem, para inputs do tipo IMAGE.
- Checked - Usado para botões de seleção (checkbox e radio), permite deixar o botão selecionado.
- Class - Setamos um estilo para usarmos através do CSS, Javascript e outros fins.
- Disabled - Para desabilitar a edição de um elemento.
- ID - Setamos o nome do nosso elemento, para referenciarmos em nosso sistema.
- Maxlength - Definimos o número máximo de caracteres a serem digitados
- Name - Setamos um nome para o campo, podendo ser usado para validação ou outros meios de controle, além de ajudar em questões de SEO.
- Size - Número de caracteres, que na teoria deveria ser a quantidade de itens visíveis, mas que funciona mais como uma forma alternativa de setar largura.
- Src - Inputs do tipo Imagem, usado para setar o caminho da imagem.
- Tabindex - Definimos a ordem de importância do campo, quando o mudamos através da tecla TAB.
- Type - Usado em Inputs, para setarmos se é um botão, botão em forma de imagem, checkbox, radio e etc.
- Value - Determina o valor do campo (não é usado para Textarea, cujo valor fica interno na tag).
Peço desculpas se esqueci algum parâmetro, mas acho que todos entenderam as principais opções que temos hoje em formulários.
Agora, vamos partir para as novidades!
Antes de tudo, vou contar as boas notícias:
- Será possível fazer uma validação diretamente por HTML
- Será possível fazer máscaras diretamente por HTML
- Será possível mencionar quais tipos de dígitos são aceitos no campo por HTML
- Não serão mais necessários componentes para Datapicker (aqueles que aparecem o calendário quando você clica em um campo de data), o HTML5 faz isso automaticamente!
Além de várias outras funções que tendem a facilitar a nossa vida (ou talvez complicar ainda mais).
Agora veremos todos parâmetros "Types" novos que um INPUT pode ter no HTML5, e se ele é ou não compatível hoje (não considerei versões anteriores ao IE8).
Esses novos "types" que vão anular componentes externos que muitas vezes dão dor de cabeça nos projetos.
Testei nos seguintes navegadores/plataformas: Firefox 3.6.8, Opera 10.60, Chrome/Safari 5.0 e Internet Explorer 8.
Exemplo de como é usado: <input type="color" />
COLOR
- Compatibilidade atual: Nenhum dos browsers mencionados.
- Função: Exibir uma palheta de cores para escolha, como faz falta em muitos projetos! Às vezes é um bom trabalho para conseguir aplicar uma, quanto mais fazer.
DATE
- Compatibilidade atual: Opera.
- Função: Abre um calendário para escolhermos uma data.
DATETIME
- Compatibilidade atual: Opera.
- Função: Abre um calendário para escolhermos uma data e ainda podemos setar um horário.
DATETIME-LOCAL
- Compatibilidade atual: Opera.
- Função: Abre um calendário para escolhermos uma data, também podendo setar horário. Mas agora nosso horário local, com fuso horário.
- Compatibilidade atual: Opera (ainda sem diferenciação visual).
- Função: Teoricamente servirá para fazermos validação direto com o HTML5. Existem outros campos com esta finalidade.
MONTH
- Compatibilidade atual: Opera.
- Função: Abre um datapicker para escolhermos mês e ano.
NUMBER
- Compatibilidade atual: Opera.
- Função: Será usado para validação também. No Opera tem diferenciação visual e não possibilita o usuário escrever outro caracter.
RANGE
- Compatibilidade atual: Chrome/Safari e Opera.
- Função: Abre uma espécie de 'régua' para podermos setar um valor, estilo pior/melhor.
TEL
- Compatibilidade atual: Opera (ainda sem diferenciação visual).
- Função: Será usado para validação, não achei muitas informações sobre. Vejo problemas nesse aspecto, devido a cada país diferenciar a quantidade de dígitos do número.
TIME
- Compatibilidade atual: Opera.
- Função: Um campo somente para setar hora-minuto.
URL
- Compatibilidade atual: Opera (ainda sem diferenciação visual).
- Função: Outro campo usado para validação, visualmente não tem diferenciação.
WEEK
- Compatibilidade atual: Opera.
- Função: Bem interessante, abre um campo para escolhermos ano e dia. Escolhendo o dia, ele armazena o ano e a semana.
Pela análise, ponto para o Opera! Ponto negativo (para variar) para o IE8 e, quem diria, Firefox. Queria ver funcionando o tipo COLOR, ver a palheta de cores sendo mostrada, mas infelizmente ainda não é suportado. Meu medo principal dessas tags é a personalização; fui tentar editar no Opera as tags equivalentes a data/hora etc. Algumas coisas não foram aceitas, consegui editar tamanho da fonte, cor da fonte (de algumas coisas apenas). Outros comandos não foram bem aceitos.
Veja:
Outros parâmetros novos (não ligados ao type).
Exemplo: <input parâmetro="valor" /> - <input autocomplete="on" />
Não vou passar todos parâmetros novos, pois são muitos e o texto ficará cansativo. Seguem alguns bem interessantes:
Autocomplete
- Valores: On, Off.
- Função: Não fique tão feliz com antecedência! Achei que era um autocomplete, de dar sugestões por usuário através de dados vindos de um banco ou semelhantes. Mas a real função dele é te dar a opção de escolha de o campo ser ou não lembrado. Por exemplo, eu digitar "email" em um campo de e-mail, e ele me mostrar o que já preenchi em campos do mesmo nome. Comando simples e que pode ser bem útil.
Form
- Valores: 'nome do formulário'.
- Função: Você pode concatenar o campo a um formulário específico, criando campos interligados.
Formenctype
- Valores: application/x-www-form-urlencoded, multipart/form-data, text/plain.
- Função: Pode setar um formenctype específico para um campo, anulando o "formtype" principal.
Formtarget
- Valores: _blank, _self, _parent, _top.
- Função: Após darmos a ação, onde que será aberto a nova tela.
Height
- Valores: % ou pixels.
- Função: Podemos definir uma altura por nossos campos, antes só era possível por CSS.
Max
- Valores: número máximo de caracteres.
- Função: Podemos setar um tamanho máximo de caracteres, uma espécie de Maxlength, só que é usado em combinação com o parâmetro MIN, para setarmos um tamanho máximo e um mínimo para o campo.
Min
- Valores: número mínimo de caracteres.
- Função: Número mínimo de caracteres que o campo deve ter.
Required
- Valores: required.
- Função: Podemos mencionar se este campo é ou não obrigatório.
Nota importante - é possível setar no CSS algo como: input:required e colocar um estilo nos campos obrigatórios.
Width
- Valores: pixels ou %.
- Função: Podemos setar uma largura em pixel ou porcentagem, não mais por número de caracteres.
Como percebemos, as novas funcionalidades para formulários são grandes! Existem diversos novos parâmetros para diversas outras TAGs, nos quais pouca gente se habitou 100% ainda. Mas, infelizmente, como percebemos também, poucos browsers hoje suportam, mas isso é uma questão de tempo (longo tempo).
Para finalizar, gostaria de agradecer à HostDime, que sempre me dá uma força enorme para produzir os artigos!
Espero que tenham gostado, até a próxima!
Olá, pessoal!
Fiquei feliz pela aceitação do artigo anterior e os bons debates que acabaram por surgir. Hoje darei início a uma coisa mais prática e menos teórica sobre o HTML5.
A primeira coisa que irei abordar são tags para organização e otimização em mecanismos de buscas (SEO), o que muda na estrutura de um site com os novos padrões de HTML.
Caso tenham alguma dúvida ou queiram conversar sobre o assunto, podem me encontrar no Twitter ou entrar em contato pelo meu site. Bem, vamos lá...
Estrutura Básica
Quando damos início à construção de um site em tableless, na estrutura básica, normalmente são utilizadas DIVs principais, como: topo/head, menu, conteudo/content/home/post, rodape/footer, coluna/sidebar/lateral e etc...
Exemplo que costumo usar:
<div class="topo">
</div>
<div class="menu">
</div>
<div class="conteudo">
</div>
<div class="rodape">
</div>Costumo sempre usar a nomenclatura em português, para facilitar manutenções futuras por outros profissionais.
Com o HTML5, estas DIVs não serão mais necessárias. Teremos tags específicas para separarmos o nosso layout por partes. Que são elas: Header, Article, Nav, Section, Footer e Aside.
As DIVs ficarão encarregadas apenas para posicionamento de conteúdo dentro de cada sessão e não mais para toda estrutura.
Exemplo de como ficará uma estrutura básica:
<header>
<h1>Logotipo da Empresa</h1>
</header>
<nav>
<ul>
<li>Página Inicial</li>
<li>Portfolio</li>
<li>Contato</li>
</ul>
</nav>
<article>
<section>
<h1>Nome da Notícia<h1> - Postado por <h2> Nome do Autor </h2>
<p><span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean odio quam,dictum in sagittis a,cursus
sit amet enim. Nunc ante dolor, condimentum ut mattis eget, fringilla non urna. Nam ultricies
dolor ac felis scelerisque rhoncus. Nunc varius velit ac nulla aliquet at ullamcorper tellus vehicula.
Nulla tincidunt velit non tellus scelerisque vehicula. Praesent pellentesque aliquet arcu quis mattis.</span></p>
<div class="fotos">
<img class="fotoprincipal" src="http://imasters.uol.com.br/imagem.jpg" />
<ul>
<li><img src="http://imasters.uol.com.br/thumb01" /></li>
<li><img src="http://imasters.uol.com.br/thumb02" /></li>
<li><img src="http://imasters.uol.com.br/thumb03" /></li>
</ul>
</div>
</section>
</article>
<aside>
<h1>Conheça a Empresa</h1>
<p><span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean odio quam, dictum in.span></p>
<h1>Assine Nossa Newsletter</h1>
<p><span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean odio quam, dictum in.span></p>
</aside>
<footer>
<h2>Copyright - Todos os Direitos Reservados</h2>
<h1> Nome do Site </h1>
</footer>Agora, vamos entender melhor o que fizemos:
- Header: topo/cabeçalho do nosso site. Como padrão, hoje ele costuma ter o logotipo da empresa e informações normalmente fixas.
- Nav: vem de navegação, seria para onde você pode ir/vir. Seria bacana se tivesse algum modo de vincular o link no elemento NAV com algum ARTICLE específico, fazendo no próprio HTML o comando de "menu ativo", não acham? Pelo que pesquisei e testei, não é possível. Mas vamos ver em futuras atualizações.
- Article: seria o nosso conteúdo dinâmico, content/post. Dentro dele teríamos o conteúdo daquela página, dividido em sessões.
- Section: as sessões dentro do Article, por exemplo, dentro da home temos sessões de: Notícias, Eventos, Galeria de fotos. É importante ressaltar que cada section pode ter um footer e um header próprio.
- Aside: uma terceira coluna, com informações complementares ao conteúdo dentro do Article.
- Footer: o rodapé do nosso site, onde normalmente vão os Copyrights, quem fez e menu secundário.
Veja nesta ilustração como seria dividido hoje um site com estas tags:
Observações importantes:
- Tags seqüenciais, como por exemplo de Títulos (h1, h2, h3, h4, h5 e h6) se adequarão automaticamente dentro de cada section, header, footer, nav e semelhantes. Sempre houve a preocupação com estas tags, agora você pode tratá-las a partir de cada sessão, e tanto o navegador como o mecanismo de busca irão se virar para fazer uma leitura correta do site, dando uma ordem de importância certa para os títulos.
- As DIVs não irão 'sumir', serão usadas mais para alinhamentos internos, como demonstrei no exemplo anterior, com a div "FOTOS". Servindo para posicionar os conteúdos dentro dos elementos principais.
Dúvidas, medos e preocupações
Na teoria são tudo mil maravilhas, mas e na prática? Serão novas TAGs para nos preocuparmos na hora de fazer um site crossbrowser.
Como será o comportamento destas tags? Elas aceitarão comandos de alinhamento, margens, bordas e etc? Alguns IEs mais antigos lêem de forma diferente alguns elementos, não aceitam HOVER, nem espaçamentos em alguns outros. Espero que isso não ocorra com estas tags e que sejam flexíveis em questão de estilização e posicionamento, em todos os browsers.
Já até imagino sites assim:
<div class="alinhamentoMenu">
<nav>
</nav>
</div>Ou:
<nav>
<div class="bordaMenu" style="width:100%; height:100%">
</div>
</nav> Fazendo isso para corrigir problemas em alguns browsers. Espero realmente que isso não ocorra e que estas TAGs funcionem como devem funcionar.
Chega de milhares de DIVs para organização, dependendo de quem estruturou fica uma bagunça, ainda mais quando tem ajustes nos projetos, que o nome de cada DIV não condiz mais com sua função. Agora teremos o site devidamente separado!
Espero que tenham gostado do artigo, dentro de alguns dias falaremos sobre formulários em HTML5!
Vale a pena um agradecimento especial para a HostDime, que tem me dado um apoio gigantesco para produção destes artigos e apoiado o uso de novas tecnologias no mercado.
Olá, pessoal!
Fiquei feliz pela aceitação do artigo anterior e os bons debates que acabaram por surgir. Hoje darei início a uma coisa mais prática e menos teórica sobre o HTML5.
A primeira coisa que irei abordar são tags para organização e otimização em mecanismos de buscas (SEO), o que muda na estrutura de um site com os novos padrões de HTML.
Caso tenham alguma dúvida ou queiram conversar sobre o assunto, podem me encontrar no Twitter ou entrar em contato pelo meu site. Bem, vamos lá...
Estrutura Básica
Quando damos início à construção de um site em tableless, na estrutura básica, normalmente são utilizadas DIVs principais, como: topo/head, menu, conteudo/content/home/post, rodape/footer, coluna/sidebar/lateral e etc...
Exemplo que costumo usar:
<div class="topo">
</div>
<div class="menu">
</div>
<div class="conteudo">
</div>
<div class="rodape">
</div>Costumo sempre usar a nomenclatura em português, para facilitar manutenções futuras por outros profissionais.
Com o HTML5, estas DIVs não serão mais necessárias. Teremos tags específicas para separarmos o nosso layout por partes. Que são elas: Header, Article, Nav, Section, Footer e Aside.
As DIVs ficarão encarregadas apenas para posicionamento de conteúdo dentro de cada sessão e não mais para toda estrutura.
Exemplo de como ficará uma estrutura básica:
<header>
<h1>Logotipo da Empresa</h1>
</header>
<nav>
<ul>
<li>Página Inicial</li>
<li>Portfolio</li>
<li>Contato</li>
</ul>
</nav>
<article>
<section>
<h1>Nome da Notícia<h1> - Postado por <h2> Nome do Autor </h2>
<p><span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean odio quam,dictum in sagittis a,cursus
sit amet enim. Nunc ante dolor, condimentum ut mattis eget, fringilla non urna. Nam ultricies
dolor ac felis scelerisque rhoncus. Nunc varius velit ac nulla aliquet at ullamcorper tellus vehicula.
Nulla tincidunt velit non tellus scelerisque vehicula. Praesent pellentesque aliquet arcu quis mattis.</span></p>
<div class="fotos">
<img class="fotoprincipal" src="http://imasters.uol.com.br/imagem.jpg" />
<ul>
<li><img src="http://imasters.uol.com.br/thumb01" /></li>
<li><img src="http://imasters.uol.com.br/thumb02" /></li>
<li><img src="http://imasters.uol.com.br/thumb03" /></li>
</ul>
</div>
</section>
</article>
<aside>
<h1>Conheça a Empresa</h1>
<p><span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean odio quam, dictum in.span></p>
<h1>Assine Nossa Newsletter</h1>
<p><span> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean odio quam, dictum in.span></p>
</aside>
<footer>
<h2>Copyright - Todos os Direitos Reservados</h2>
<h1> Nome do Site </h1>
</footer>Agora, vamos entender melhor o que fizemos:
- Header: topo/cabeçalho do nosso site. Como padrão, hoje ele costuma ter o logotipo da empresa e informações normalmente fixas.
- Nav: vem de navegação, seria para onde você pode ir/vir. Seria bacana se tivesse algum modo de vincular o link no elemento NAV com algum ARTICLE específico, fazendo no próprio HTML o comando de "menu ativo", não acham? Pelo que pesquisei e testei, não é possível. Mas vamos ver em futuras atualizações.
- Article: seria o nosso conteúdo dinâmico, content/post. Dentro dele teríamos o conteúdo daquela página, dividido em sessões.
- Section: as sessões dentro do Article, por exemplo, dentro da home temos sessões de: Notícias, Eventos, Galeria de fotos. É importante ressaltar que cada section pode ter um footer e um header próprio.
- Aside: uma terceira coluna, com informações complementares ao conteúdo dentro do Article.
- Footer: o rodapé do nosso site, onde normalmente vão os Copyrights, quem fez e menu secundário.
Veja nesta ilustração como seria dividido hoje um site com estas tags:
Observações importantes:
- Tags seqüenciais, como por exemplo de Títulos (h1, h2, h3, h4, h5 e h6) se adequarão automaticamente dentro de cada section, header, footer, nav e semelhantes. Sempre houve a preocupação com estas tags, agora você pode tratá-las a partir de cada sessão, e tanto o navegador como o mecanismo de busca irão se virar para fazer uma leitura correta do site, dando uma ordem de importância certa para os títulos.
- As DIVs não irão 'sumir', serão usadas mais para alinhamentos internos, como demonstrei no exemplo anterior, com a div "FOTOS". Servindo para posicionar os conteúdos dentro dos elementos principais.
Dúvidas, medos e preocupações
Na teoria são tudo mil maravilhas, mas e na prática? Serão novas TAGs para nos preocuparmos na hora de fazer um site crossbrowser.
Como será o comportamento destas tags? Elas aceitarão comandos de alinhamento, margens, bordas e etc? Alguns IEs mais antigos lêem de forma diferente alguns elementos, não aceitam HOVER, nem espaçamentos em alguns outros. Espero que isso não ocorra com estas tags e que sejam flexíveis em questão de estilização e posicionamento, em todos os browsers.
Já até imagino sites assim:
<div class="alinhamentoMenu">
<nav>
</nav>
</div>Ou:
<nav>
<div class="bordaMenu" style="width:100%; height:100%">
</div>
</nav> Fazendo isso para corrigir problemas em alguns browsers. Espero realmente que isso não ocorra e que estas TAGs funcionem como devem funcionar.
Chega de milhares de DIVs para organização, dependendo de quem estruturou fica uma bagunça, ainda mais quando tem ajustes nos projetos, que o nome de cada DIV não condiz mais com sua função. Agora teremos o site devidamente separado!
Espero que tenham gostado do artigo, dentro de alguns dias falaremos sobre formulários em HTML5!
Vale a pena um agradecimento especial para a HostDime, que tem me dado um apoio gigantesco para produção destes artigos e apoiado o uso de novas tecnologias no mercado.
Pretendo fazer algumas colunas em seqüência abordando itens interessantes do HTML5, não no sentido de 'efeitos mirabolantes', mas como facilitaria hoje o trabalho e produção de determinados itens. Todos que já tiveram a oportunidade de trabalhar com sites de médio ou grande porte acabaram se deparando com certas dificuldades ou trabalho exaustivo para fazer determinadas tarefas, que com o HTML5 e CSS3 seria resolvido facilmente.
Para começar, algumas perguntas básicas sobre HTML5 que rolam por aí:
- O HTML5 é viável hoje? A resposta é, infelizmente, não. Para um público extremamente seleto talvez seja um pouco viável, mas, mesmo assim, nenhum browser (até mesmo os mais conceituados) suporta o HTML5 com tranqüilidade, apenas algumas tags são aceitas.
- O HTML5 vai extinguir o Flash e/ou o Javascript? Não. O HTML5 busca reduzir o uso de Javascript, deixando seu uso para o que é realmente necessário. Assim também para o Flash, que vai ficar encarregado de aplicativos para interatividade - e, na minha opinião, é para isso que ele deve ser usado.
- O HTML5 vai entrar rápido no mercado? A resposta também é, infelizmente, não. Tomara que eu esteja muito errado, mas estava conversando com alguns colegas de trabalho e fazendo uma média de tempo que o usuário leva para se atualizar, e nossas conclusões foram tristes. O Internet Explorer 6, um grande causador de problemas hoje, existe desde 2001. Apenas em 2010 as gigantes da internet tomaram providências a respeito e, mesmo assim, a versão 6 do IE ainda possui muitos usuários. Tudo bem que isso tem o mérito de o Windows Vista não ter tido o sucesso esperado e muitos usuários continuarem no Windows XP, que tem o IE6 como padrão, mas foram nove anos para ele finalmente começar a ser ignorado.
Os atuais navegadores não suportam com perfeição o HTML5; provavelmente browsers como Firefox, Opera, Chrome, Safari e outros, serão atualizados rapidamente suprindo estes problemas. Mas o nosso bom e velho IE (o navegador mais usado no mundo) é complicado, sendo que ele ainda nem suporta comandos como borda-arredondada (border-radius), obrigando a usar 'soluções alternativas'. O Internet Explorer 9 está tendo boas resenhas, deve sair em um ou dois anos, acredito eu. Mas vai demorar quanto tempo para grande maioria dos usuários migrarem de vez para browsers com este suporte? Provavelmente uns bons anos...
O trabalho para sites vai acabar sendo redobrado, pois os clientes vão querer um site com novas tecnologias, mas também será necessário oferecer suporte para navegadores antigos, como foi muito tempo com o IE6, e talvez seja até mais trabalhoso, pois não usaremos somente hacks para navegadores, e sim versões diferenciadas de HTML e CSS para dar este suporte.
Ainda, com a popularização de Tablets e 'mega-celulares', versões diferenciadas para esta finalidade também devem ser exigidas. Os usuários estão vindo de locais cada vez mais dispersos e atender à demanda vai resultar em ainda mais trabalho (navegadores antigos, navegadores novos e navegadores 'portáteis').
Nas próximas colunas, buscarei dar uma explicação sobre as principais novas tags do HTML, dividindo elas em quatro categorias, que são:
- Otimização, organização e SEO
- Formulário
- Multimídia
- Tags e parâmetros de "enfeites"
Caso queiram tirar umas dúvidas, jogar uma conversa fora ou dar sugestões sobre este assunto, podem me encontrar no Twitter (@ravielcarvalho) ou podem me mandar um e-mail pelo meu site.Valendo um agradecimento especial para a HostDime que vem incentivando o uso destas novas tecnologias. É bom ver empresas de grande porte fazendo sua parte para alertar o mercado destes novos padrões.
Pretendo fazer algumas colunas em seqüência abordando itens interessantes do HTML5, não no sentido de 'efeitos mirabolantes', mas como facilitaria hoje o trabalho e produção de determinados itens. Todos que já tiveram a oportunidade de trabalhar com sites de médio ou grande porte acabaram se deparando com certas dificuldades ou trabalho exaustivo para fazer determinadas tarefas, que com o HTML5 e CSS3 seria resolvido facilmente.
Para começar, algumas perguntas básicas sobre HTML5 que rolam por aí:
- O HTML5 é viável hoje? A resposta é, infelizmente, não. Para um público extremamente seleto talvez seja um pouco viável, mas, mesmo assim, nenhum browser (até mesmo os mais conceituados) suporta o HTML5 com tranqüilidade, apenas algumas tags são aceitas.
- O HTML5 vai extinguir o Flash e/ou o Javascript? Não. O HTML5 busca reduzir o uso de Javascript, deixando seu uso para o que é realmente necessário. Assim também para o Flash, que vai ficar encarregado de aplicativos para interatividade - e, na minha opinião, é para isso que ele deve ser usado.
- O HTML5 vai entrar rápido no mercado? A resposta também é, infelizmente, não. Tomara que eu esteja muito errado, mas estava conversando com alguns colegas de trabalho e fazendo uma média de tempo que o usuário leva para se atualizar, e nossas conclusões foram tristes. O Internet Explorer 6, um grande causador de problemas hoje, existe desde 2001. Apenas em 2010 as gigantes da internet tomaram providências a respeito e, mesmo assim, a versão 6 do IE ainda possui muitos usuários. Tudo bem que isso tem o mérito de o Windows Vista não ter tido o sucesso esperado e muitos usuários continuarem no Windows XP, que tem o IE6 como padrão, mas foram nove anos para ele finalmente começar a ser ignorado.
Os atuais navegadores não suportam com perfeição o HTML5; provavelmente browsers como Firefox, Opera, Chrome, Safari e outros, serão atualizados rapidamente suprindo estes problemas. Mas o nosso bom e velho IE (o navegador mais usado no mundo) é complicado, sendo que ele ainda nem suporta comandos como borda-arredondada (border-radius), obrigando a usar 'soluções alternativas'. O Internet Explorer 9 está tendo boas resenhas, deve sair em um ou dois anos, acredito eu. Mas vai demorar quanto tempo para grande maioria dos usuários migrarem de vez para browsers com este suporte? Provavelmente uns bons anos...
O trabalho para sites vai acabar sendo redobrado, pois os clientes vão querer um site com novas tecnologias, mas também será necessário oferecer suporte para navegadores antigos, como foi muito tempo com o IE6, e talvez seja até mais trabalhoso, pois não usaremos somente hacks para navegadores, e sim versões diferenciadas de HTML e CSS para dar este suporte.
Ainda, com a popularização de Tablets e 'mega-celulares', versões diferenciadas para esta finalidade também devem ser exigidas. Os usuários estão vindo de locais cada vez mais dispersos e atender à demanda vai resultar em ainda mais trabalho (navegadores antigos, navegadores novos e navegadores 'portáteis').
Nas próximas colunas, buscarei dar uma explicação sobre as principais novas tags do HTML, dividindo elas em quatro categorias, que são:
- Otimização, organização e SEO
- Formulário
- Multimídia
- Tags e parâmetros de "enfeites"
Caso queiram tirar umas dúvidas, jogar uma conversa fora ou dar sugestões sobre este assunto, podem me encontrar no Twitter (@ravielcarvalho) ou podem me mandar um e-mail pelo meu site.Valendo um agradecimento especial para a HostDime que vem incentivando o uso destas novas tecnologias. É bom ver empresas de grande porte fazendo sua parte para alertar o mercado destes novos padrões.
Frameworks são estruturas de códigos definidas onde um projeto de software, seja ele web ou não, pode ser criado e desenvolvido. Frameworks podem incluir programas de suporte, bibliotecas de código, linguagens de script ou qualquer outro tipo de software para auxiliar no desenvolvimento.
Eles foram projetados para auxiliar no desenvolvimento de softwares, auxiliando designers e programadores a gastar menos tempo com desenvolvimento.
Em CSS, frameworks geralmente são um conglomerado de arquivos css com coisas base para tipografia, estrutura de layout, menu. Sua utilização deve ser muito cuidadosa, pois utilizar frameworks em desenvolvimento XHTML e CSS pode não trazer a mesma produtividade do que se você estivesse usando um framework para PHP, JavaScript. É importante que o desenvolvedor saiba ler e compreender o código que ele está escrevendo.
Não, não quero colocar aqui a idéia de que a utilização de frameworks em CSS é o fim do mundo, que você não deve utilizar, aliás, quem aqui nunca fez um pouco de copiar e colar em CSS? Quem não tem algumas coisas já prontas e sempre as reutiliza a cada projeto? A idéia que quero passar é que é importante você conhecê-los, entender seu funcionamento para saber se o que você faz hoje é mesmo o correto, conhecer a forma como trabalham os outros desenvolvedores, aprender a utilizar herança, uma coisa que é essencial e todo desenvolvedor Front-end deveria dominar.
Se você ficou interessado em conhecer os Frameworks CSS, dê uma olhada na lista abaixo:
Elements CSS Framework
Foi desenvolvido para ajudar aos desenvolvedores a escrever CSS de forma mais rápida e mais eficiente. Elements fica longe de ser um simples Framework, ele possui tudo o que você precisa para concluir os seus projetos. Leia o Overview para maiores informações.
YUI Grids CSS
Framework desenvolvido pelo Yahoo que possui um preset com 6 modelos pré-definidos de página. Um simples arquivo de 4KB fornece mais de 1000 combinações diferentes de paginação.
YAML CSS Framework
Dirk Jesse's extensive (X)HTML/CSS Framework oferece um montante de modelos padrão para uma série de simples ou complexos layouts. YAML é baseado em padrões web e suporta os mais variados browsers. Todas as correções de bugs do Internet Explorer você pode encontrar nesse Framework.
Blueprint CSS
Blueprint CSS é um Frameork criado para diminuir o tempo gasto com desenvolvimento em CSS. Possui uma estrutura sólida para que você possa construir seus projetos, além de possuir folhas de estilo para tipografia e impressão.
Schema Web Design Framework
Schema foi desenvolvido para conceber e proporcionar uma essencial marcação XHTML e CSS que é utilizada repetidamente no desenvolvimento XHTML e CSS. Ao invés de reconstruir seu XHTML e CSS a cada projeto, Schema fornece a base necessária para tê-lo instalado e funcionando em qualquer projeto.
CleverCSS
CleverCSS é uma pequena linguagem de marcação CSS inspirada em Python que pode ser usada para o desenvolvimento de uma folha de estilos limpa e clara. Em muitos aspectos é mais limpa e clara do que CSS2. A mais óbvia diferença é a sintaxe: trata-se de identação e não com base plena.
Tripoli CSS Framework
Tripoli é um padrão genérico de CSS e HTML para renderização, tornando crossbrowser e mais estáveis seus projetos.
ESWAT Web Project Framework
ESWAT não nos passa muitas informações em seu site, portanto, faça o download do framework e descubra por si só todo seu potencial.
Boilerplate CSS Framework
Esse Framework se esforça ao máximo para não definir nomes não semânticos para suas Classes ou ID's, pois aqui o desenvolvedor é você.
WYMstyle CSS Framework
O objetivo desse Framework é fornecer um conjunto de arquivos para tornar seu CSS modular, que pode ser usado para o desenvolvimento de web sites rápidos. Ele também visa suprimir a incompatibilidade entre browsers através de módulos CSS.
ESWAT Web Project Framework
Permite o rápido desenvolvimento de projetos com componentes pré-escritos. Tudo isso é necessário para construir um ambiente flexível.
Logicss Framework
Logicss é uma coleção de arquivos CSS e PHP para reduzir o tempo de desenvolvimento de aplicações Standard Compliance. Possui também folhas de estilo para Tipografia.
That Standards Guy CSS Framework
O único válido para WCAG 1.0. Crossbrowser possui folhas de estilo com hacks para IE separados.
960 Grid System
Framework desenvolvido com base em uma largura de 960 pixels. Possui 2 variantes de 12 e 16 colunas, que podem ser utilizadas separadamente ou em conjunto.
Emastic CSS Framework
Ele é leve e possui larguras de página personalizadas. Utiliza unidades de medida "em" para o desenvolvimento dos layouts.
Origo CSS
Framework baseado no desenvolvimento em Grids. A chave está no desenvolvimento utilizando blocos e colunas. As colunas permitem ordenar os elementos de forma horizontal. Enquanto os blocos de informação são ordenados na vertical.
Typogridphy
Framework para designers e desenvolvedores front-end de forma a mostrar em seu site uma tipografia mais gratificante. É baseado no Framework 960 Grid System lhe permite desenvolver layouts baseados em grids de forma semântica.
Haml
Framework Server-side para Rails onde o principal objetivo é tornar sua marcação a mais limpa possível. Foi criado para ser utilizado em ambientes altamente produtivos.
SenCSS
Pode ser pronunciado como "bom senso", onde aqui a tarefa de ser repetitivo é deixada de lado e o desenvolvimento com CSS fica mais prazeroso. É otimizado para deixar o CSS o mais funcional possível. Possui estilos básicos para Tipografia e Formulários.
Taffy
Taffy foi desenvolvido para lhe poupar tempo. Como desenvolvedor web, existem várias coisas que você deve fazer por padrão a cada projeto: Sobrepor os estilos padrão de cada navegador, tipografia, entre outras coisas. Taffy cuida disso e de outras tarefas para que você possa ser semântico e produtivo.
Hartija CSS Print Framework
Hartija é Framework CSS desenvolvido para impressão, onde pretende em uma arquivo css otimizar da melhor forma possível seu site para impressão.
Formy CSS Form Framework
Formy foi criado para lhe auxiliar na criação de formulários acessíveis e simples. Funciona perfeitamente nos principais browsers: IE 6 / 7, o Firefox 2 / 3, Opera 9.23/9.5, Safari 3.1 (Win).
Construct
Construct é uma espécie de editor visual baseado no Blueprint em conjunto com o Framework jQuery.
*
Esse post foi inspirado no original de Hidden Pixels
Frameworks são estruturas de códigos definidas onde um projeto de software, seja ele web ou não, pode ser criado e desenvolvido. Frameworks podem incluir programas de suporte, bibliotecas de código, linguagens de script ou qualquer outro tipo de software para auxiliar no desenvolvimento.
Eles foram projetados para auxiliar no desenvolvimento de softwares, auxiliando designers e programadores a gastar menos tempo com desenvolvimento.
Em CSS, frameworks geralmente são um conglomerado de arquivos css com coisas base para tipografia, estrutura de layout, menu. Sua utilização deve ser muito cuidadosa, pois utilizar frameworks em desenvolvimento XHTML e CSS pode não trazer a mesma produtividade do que se você estivesse usando um framework para PHP, JavaScript. É importante que o desenvolvedor saiba ler e compreender o código que ele está escrevendo.
Não, não quero colocar aqui a idéia de que a utilização de frameworks em CSS é o fim do mundo, que você não deve utilizar, aliás, quem aqui nunca fez um pouco de copiar e colar em CSS? Quem não tem algumas coisas já prontas e sempre as reutiliza a cada projeto? A idéia que quero passar é que é importante você conhecê-los, entender seu funcionamento para saber se o que você faz hoje é mesmo o correto, conhecer a forma como trabalham os outros desenvolvedores, aprender a utilizar herança, uma coisa que é essencial e todo desenvolvedor Front-end deveria dominar.
Se você ficou interessado em conhecer os Frameworks CSS, dê uma olhada na lista abaixo:
Elements CSS Framework
Foi desenvolvido para ajudar aos desenvolvedores a escrever CSS de forma mais rápida e mais eficiente. Elements fica longe de ser um simples Framework, ele possui tudo o que você precisa para concluir os seus projetos. Leia o Overview para maiores informações.
YUI Grids CSS
Framework desenvolvido pelo Yahoo que possui um preset com 6 modelos pré-definidos de página. Um simples arquivo de 4KB fornece mais de 1000 combinações diferentes de paginação.
YAML CSS Framework
Dirk Jesse's extensive (X)HTML/CSS Framework oferece um montante de modelos padrão para uma série de simples ou complexos layouts. YAML é baseado em padrões web e suporta os mais variados browsers. Todas as correções de bugs do Internet Explorer você pode encontrar nesse Framework.
Blueprint CSS
Blueprint CSS é um Frameork criado para diminuir o tempo gasto com desenvolvimento em CSS. Possui uma estrutura sólida para que você possa construir seus projetos, além de possuir folhas de estilo para tipografia e impressão.
Schema Web Design Framework
Schema foi desenvolvido para conceber e proporcionar uma essencial marcação XHTML e CSS que é utilizada repetidamente no desenvolvimento XHTML e CSS. Ao invés de reconstruir seu XHTML e CSS a cada projeto, Schema fornece a base necessária para tê-lo instalado e funcionando em qualquer projeto.
CleverCSS
CleverCSS é uma pequena linguagem de marcação CSS inspirada em Python que pode ser usada para o desenvolvimento de uma folha de estilos limpa e clara. Em muitos aspectos é mais limpa e clara do que CSS2. A mais óbvia diferença é a sintaxe: trata-se de identação e não com base plena.
Tripoli CSS Framework
Tripoli é um padrão genérico de CSS e HTML para renderização, tornando crossbrowser e mais estáveis seus projetos.
ESWAT Web Project Framework
ESWAT não nos passa muitas informações em seu site, portanto, faça o download do framework e descubra por si só todo seu potencial.
Boilerplate CSS Framework
Esse Framework se esforça ao máximo para não definir nomes não semânticos para suas Classes ou ID's, pois aqui o desenvolvedor é você.
WYMstyle CSS Framework
O objetivo desse Framework é fornecer um conjunto de arquivos para tornar seu CSS modular, que pode ser usado para o desenvolvimento de web sites rápidos. Ele também visa suprimir a incompatibilidade entre browsers através de módulos CSS.
ESWAT Web Project Framework
Permite o rápido desenvolvimento de projetos com componentes pré-escritos. Tudo isso é necessário para construir um ambiente flexível.
Logicss Framework
Logicss é uma coleção de arquivos CSS e PHP para reduzir o tempo de desenvolvimento de aplicações Standard Compliance. Possui também folhas de estilo para Tipografia.
That Standards Guy CSS Framework
O único válido para WCAG 1.0. Crossbrowser possui folhas de estilo com hacks para IE separados.
960 Grid System
Framework desenvolvido com base em uma largura de 960 pixels. Possui 2 variantes de 12 e 16 colunas, que podem ser utilizadas separadamente ou em conjunto.
Emastic CSS Framework
Ele é leve e possui larguras de página personalizadas. Utiliza unidades de medida "em" para o desenvolvimento dos layouts.
Origo CSS
Framework baseado no desenvolvimento em Grids. A chave está no desenvolvimento utilizando blocos e colunas. As colunas permitem ordenar os elementos de forma horizontal. Enquanto os blocos de informação são ordenados na vertical.
Typogridphy
Framework para designers e desenvolvedores front-end de forma a mostrar em seu site uma tipografia mais gratificante. É baseado no Framework 960 Grid System lhe permite desenvolver layouts baseados em grids de forma semântica.
Haml
Framework Server-side para Rails onde o principal objetivo é tornar sua marcação a mais limpa possível. Foi criado para ser utilizado em ambientes altamente produtivos.
SenCSS
Pode ser pronunciado como "bom senso", onde aqui a tarefa de ser repetitivo é deixada de lado e o desenvolvimento com CSS fica mais prazeroso. É otimizado para deixar o CSS o mais funcional possível. Possui estilos básicos para Tipografia e Formulários.
Taffy
Taffy foi desenvolvido para lhe poupar tempo. Como desenvolvedor web, existem várias coisas que você deve fazer por padrão a cada projeto: Sobrepor os estilos padrão de cada navegador, tipografia, entre outras coisas. Taffy cuida disso e de outras tarefas para que você possa ser semântico e produtivo.
Hartija CSS Print Framework
Hartija é Framework CSS desenvolvido para impressão, onde pretende em uma arquivo css otimizar da melhor forma possível seu site para impressão.
Formy CSS Form Framework
Formy foi criado para lhe auxiliar na criação de formulários acessíveis e simples. Funciona perfeitamente nos principais browsers: IE 6 / 7, o Firefox 2 / 3, Opera 9.23/9.5, Safari 3.1 (Win).
Construct
Construct é uma espécie de editor visual baseado no Blueprint em conjunto com o Framework jQuery.
*
Esse post foi inspirado no original de Hidden Pixels
Há muito pouco tempo começaram a surgir boatos por aí de que estamos entrando na Web 3.0, ou a "Web Semântica". E hoje eu vim falar um pouquinho, pra vocês, sobre essa nova tendência.
Como meu amigo Bernard De Luna (especialista em (X)HTML, CSS e semântica) disse: "Não existem versões. Existe a tendência a uma evolução natural das coisas. Nós simplesmente percebemos essa mudança de vento e queremos dar um nome pra ela." Não exatamente com essas palavras, mas sei que foi isso que ele quis dizer.
Estamos entrando numa época onde cada vez mais sites e mais domínios são comprados, publicados e jogados na Internet e, diga-se de passagem, sem nenhum cuidado, planejamento ou organização. E é esse o pilar da tal Web 3.0: organização. Cada vez mais informações (verdadeiras ou falsas) estão sendo publicadas na Internet. Isso se deve ao boom da Web 2.0 onde a contribuição do visitante é o bem mais valioso de um site. São comentários, fóruns, notícias, muitos blogs, fotos, vídeos, Twitters e por aí vai. É um mundo de possibilidades onde você pode criar o seu conteúdo, da forma e cor que desejar.
A tecnologia não pára de crescer, cada vez as máquinas e os robôs estão mais inteligentes. E juntando essa inteligência artificial com inúmeros algoritmos de processamento, essas máquinas são capazes de armazenar e organizar informações.
Então veja que mundo perfeito: se nós, humanos, estamos produzindo e publicando qualquer tipo de informação (em todos os idiomas e dialetos possíveis) e as máquinas, em contrapartida, são capazes de captar, entender e organizar essas informações, o mundo está a um passo do que poderia ser chamado de cultura global, ou conhecimento global, onde cada pessoa tem acesso a qualquer tipo de informação, e as máquinas são capazes de, baseadas nessas informações, tomar decisões e automatizar (mais ainda) a vida dos seres humanos.
Tá... e o que essa lengalenga toda tem a ver com o meu HTML?
Sem dúvida nenhuma, o maior formato de publicação de conteúdo na Internet hoje (o maior acervo de conhecimento da humanidade) é o formato em HTML ou XHTML Seja o Twitter ou um blog, são todos HTML. E a Web 3.0 sugiu da necessidade de organizar toda essa avalanche de informação que vem sendo criada diariamente de uma forma irresponsável, para que as máquinas possam ter acesso a esse tipo de informação.
Veja o exemplo do Crawler Google. O que é ele, senão um super-robô que fica, o dia inteiro, vasculhando todos os sites do mundo e armazenando informações para serem entregues quando você faz uma busca? Agora imagine que você é esse robô e tem que armazenar, na sua memória, informações relativas a uma biblioteca inteira 25 mil livros. Só que infelizmente cada livro foi escrito por um autor, seguindo uma escola literária diferente, idioma diferente e catalogado de forma diferente Fica bem pior pra você, não fica?
A tendência da "nova Web" é exatamente essa: Organizar o HTML usando os elementos corretos, seguindo um padrão internacional (definido pelo W3C) e, permitindo assim, uma melhor compreensão do seu site.
O "Melhor dos Mundos"
Imagine o que pode acontecer em um futuro próximo: você marca um evento na sua agenda do Google ou Yahoo, por exemplo, "reunião no escritório da empresa X às 14h". Aí o seu computador, baseado em toda essa gama de informações possíveis, descobre o endereço desse escritório e, usando uma API geográfica, descobre que esse escritório fica em outro estado. Então, automaticamente, ele já busca a melhor opção de vôo pra você e até informa o vôo, horário, data, e preço, usando um sistema das empresas de linhas aéreas. É só você concordar com ele e a sua vida está resolvida.
Isso tudo será possível se nós, criadores de conteúdo (leia-se HTML), a partir de hoje mesmo, começarmos a organizar o que criamos.
A maioria dos desenvolvedores está acostumada a criar o HTML e o CSS ao mesmo tempo. Com isso você acaba tendo que escolher os elementos que vai usar para facilitar a sua vida na hora de criar o CSS. Faça como o Bernard De Luna me ensinou: sempre crie TODO o HTML da página antes, sem nem pensar no CSS. Use os elementos corretos para exibir o conteúdo do seu site de forma hierárquica e concisa.
Se você for criar uma série de elementos que irão se repetir, como menus, listas de produtos e listas de notícias, use listas (<ul>), pois esse elemento informa pra máquina que aquilo é uma lista!
MicroFormats
Existe uma coisa bem legal chamada MicroFormats que é uma das bases dessa tal Web 3.0 (que vem acompanhado do HTML 5 e do XHTML 2). Ele se baseia na passagem de parâmetros, via seu código HTML (usando elementos específicos acompanhados de classes pré-definidas) para informar que tipo de informação está sendo transmitida. Um exemplo básico seria numa página onde tem os dados de contato e, ao redor do telefone, você diz que aquilo ali é o seu telefone usando um class="phone". Isso vai fazer com que o robô identifique mais fácil que o telefone do autor daquele site, ou da empresa em questão, é aquilo que está dentro do elemento.
Desenvolvimento Ético, por uma WEB melhor
Não é só na medicina e na advocacia que existe ética. Você deve ser ético também na hora de criar um conteúdo HTML pois, se você o fizer da forma correta, usando os conceitos e padrões internacionais, inserindo todas as informações necessárias, além de ter um site muito mais bem posicionado e indexado nos sistemas de busca, você vai contribuir para uma digitalização correta de todo o conhecimento do mundo e, quem sabe, não precise ter que procurar a sua passagem de avião pro próximo evento que for.
E pra quem ficou curioso sobre o assunto, as palavras-chave de busca são: semântica, XHTML, W3C e outras espalhadas pelo texto.
Um grande abraço!
Há muito pouco tempo começaram a surgir boatos por aí de que estamos entrando na Web 3.0, ou a "Web Semântica". E hoje eu vim falar um pouquinho, pra vocês, sobre essa nova tendência.
Como meu amigo Bernard De Luna (especialista em (X)HTML, CSS e semântica) disse: "Não existem versões. Existe a tendência a uma evolução natural das coisas. Nós simplesmente percebemos essa mudança de vento e queremos dar um nome pra ela." Não exatamente com essas palavras, mas sei que foi isso que ele quis dizer.
Estamos entrando numa época onde cada vez mais sites e mais domínios são comprados, publicados e jogados na Internet e, diga-se de passagem, sem nenhum cuidado, planejamento ou organização. E é esse o pilar da tal Web 3.0: organização. Cada vez mais informações (verdadeiras ou falsas) estão sendo publicadas na Internet. Isso se deve ao boom da Web 2.0 onde a contribuição do visitante é o bem mais valioso de um site. São comentários, fóruns, notícias, muitos blogs, fotos, vídeos, Twitters e por aí vai. É um mundo de possibilidades onde você pode criar o seu conteúdo, da forma e cor que desejar.
A tecnologia não pára de crescer, cada vez as máquinas e os robôs estão mais inteligentes. E juntando essa inteligência artificial com inúmeros algoritmos de processamento, essas máquinas são capazes de armazenar e organizar informações.
Então veja que mundo perfeito: se nós, humanos, estamos produzindo e publicando qualquer tipo de informação (em todos os idiomas e dialetos possíveis) e as máquinas, em contrapartida, são capazes de captar, entender e organizar essas informações, o mundo está a um passo do que poderia ser chamado de cultura global, ou conhecimento global, onde cada pessoa tem acesso a qualquer tipo de informação, e as máquinas são capazes de, baseadas nessas informações, tomar decisões e automatizar (mais ainda) a vida dos seres humanos.
Tá... e o que essa lengalenga toda tem a ver com o meu HTML?
Sem dúvida nenhuma, o maior formato de publicação de conteúdo na Internet hoje (o maior acervo de conhecimento da humanidade) é o formato em HTML ou XHTML Seja o Twitter ou um blog, são todos HTML. E a Web 3.0 sugiu da necessidade de organizar toda essa avalanche de informação que vem sendo criada diariamente de uma forma irresponsável, para que as máquinas possam ter acesso a esse tipo de informação.
Veja o exemplo do Crawler Google. O que é ele, senão um super-robô que fica, o dia inteiro, vasculhando todos os sites do mundo e armazenando informações para serem entregues quando você faz uma busca? Agora imagine que você é esse robô e tem que armazenar, na sua memória, informações relativas a uma biblioteca inteira 25 mil livros. Só que infelizmente cada livro foi escrito por um autor, seguindo uma escola literária diferente, idioma diferente e catalogado de forma diferente Fica bem pior pra você, não fica?
A tendência da "nova Web" é exatamente essa: Organizar o HTML usando os elementos corretos, seguindo um padrão internacional (definido pelo W3C) e, permitindo assim, uma melhor compreensão do seu site.
O "Melhor dos Mundos"
Imagine o que pode acontecer em um futuro próximo: você marca um evento na sua agenda do Google ou Yahoo, por exemplo, "reunião no escritório da empresa X às 14h". Aí o seu computador, baseado em toda essa gama de informações possíveis, descobre o endereço desse escritório e, usando uma API geográfica, descobre que esse escritório fica em outro estado. Então, automaticamente, ele já busca a melhor opção de vôo pra você e até informa o vôo, horário, data, e preço, usando um sistema das empresas de linhas aéreas. É só você concordar com ele e a sua vida está resolvida.
Isso tudo será possível se nós, criadores de conteúdo (leia-se HTML), a partir de hoje mesmo, começarmos a organizar o que criamos.
A maioria dos desenvolvedores está acostumada a criar o HTML e o CSS ao mesmo tempo. Com isso você acaba tendo que escolher os elementos que vai usar para facilitar a sua vida na hora de criar o CSS. Faça como o Bernard De Luna me ensinou: sempre crie TODO o HTML da página antes, sem nem pensar no CSS. Use os elementos corretos para exibir o conteúdo do seu site de forma hierárquica e concisa.
Se você for criar uma série de elementos que irão se repetir, como menus, listas de produtos e listas de notícias, use listas (<ul>), pois esse elemento informa pra máquina que aquilo é uma lista!
MicroFormats
Existe uma coisa bem legal chamada MicroFormats que é uma das bases dessa tal Web 3.0 (que vem acompanhado do HTML 5 e do XHTML 2). Ele se baseia na passagem de parâmetros, via seu código HTML (usando elementos específicos acompanhados de classes pré-definidas) para informar que tipo de informação está sendo transmitida. Um exemplo básico seria numa página onde tem os dados de contato e, ao redor do telefone, você diz que aquilo ali é o seu telefone usando um class="phone". Isso vai fazer com que o robô identifique mais fácil que o telefone do autor daquele site, ou da empresa em questão, é aquilo que está dentro do elemento.
Desenvolvimento Ético, por uma WEB melhor
Não é só na medicina e na advocacia que existe ética. Você deve ser ético também na hora de criar um conteúdo HTML pois, se você o fizer da forma correta, usando os conceitos e padrões internacionais, inserindo todas as informações necessárias, além de ter um site muito mais bem posicionado e indexado nos sistemas de busca, você vai contribuir para uma digitalização correta de todo o conhecimento do mundo e, quem sabe, não precise ter que procurar a sua passagem de avião pro próximo evento que for.
E pra quem ficou curioso sobre o assunto, as palavras-chave de busca são: semântica, XHTML, W3C e outras espalhadas pelo texto.
Um grande abraço!
Web Beacons ou Web Bugs são umas séries de técnicas utilizadas para monitorar quem está lendo uma página na web, email e/ou dados do computador. Também pode ser usado para verificar se um determinado e-mail foi lido ou se uma determinada matéria foi copiada indevidamente para outro site. Os primeiros Web Beacon eram imagens de 1x1.
Adicionalmente, um Web Beacon é utilizado para medir padrões de tráfego dos usuários de uma página a outra com objetivo de maximizar o fluxo de tráfego através da Web. Por exemplo, o usuário e o visitante do site Mercado Livre manifestam conhecer e aceitar que Mercado Livre poderá utilizar um sistema de monitoramento mediante a utilização dos mesmos.
Embora Web Beacons seja utilizada da mesma forma nas páginas da Web ou e-mails, as finalidades são diferentes:
- Se está embutido em um e-mail, a imagem é carregada pelo browser quando o usuário lê o e-mail pela primeira vez, assim podemos saber se um determinado e-mail foi lido ou não;
- Sempre que é feito o download de uma página da Web (com ou sem erros), o servidor que retém a página sabe e pode armazenar o endereço IP do computador que solicita a página, linguagem do browser etc.
Abaixo segue um exemplo simples, onde eu vou pegar o IP do usuário que acessa uma determinada página.
Criaremos um arquivo chamado http://imasters.uol.com.br/webbug.php
<?php
// crio um arquivo aonde vou armazenar o ip do usuário
f = fopen('teste.txt','a');
fwrite(f,_SERVER['REMOTE_ADDR']."\\n");
fclose(f);
// aqui eu retorno o cabeçalho informando que esse arquivo é uma imagem, isso evita erros do browser
header('Content-type: image/gif');
?>Agora vamos incluir o Web Beacon, para isso vamos criar uma tag IMG com as dimensões 1x1
<img src="http://imasters.uol.com.br/webbug.php" alt="" width="1" height="1" />Dessa forma quando o browser carregar a imagem, ele também está executando o arquivo http://imasters.uol.com.br/webbug.php, desta forma criamos um Web Beacon.
Hoje os Web Bugs também utilizam IFrame, link , script e outras tags para monitorar uso.
Web Beacons podem ser utilizados em combinação com cookies HTTP como qualquer outro objeto transferido usando o protocolo HTTP.
Espero que tenham gostado.
Web Beacons ou Web Bugs são umas séries de técnicas utilizadas para monitorar quem está lendo uma página na web, email e/ou dados do computador. Também pode ser usado para verificar se um determinado e-mail foi lido ou se uma determinada matéria foi copiada indevidamente para outro site. Os primeiros Web Beacon eram imagens de 1x1.
Adicionalmente, um Web Beacon é utilizado para medir padrões de tráfego dos usuários de uma página a outra com objetivo de maximizar o fluxo de tráfego através da Web. Por exemplo, o usuário e o visitante do site Mercado Livre manifestam conhecer e aceitar que Mercado Livre poderá utilizar um sistema de monitoramento mediante a utilização dos mesmos.
Embora Web Beacons seja utilizada da mesma forma nas páginas da Web ou e-mails, as finalidades são diferentes:
- Se está embutido em um e-mail, a imagem é carregada pelo browser quando o usuário lê o e-mail pela primeira vez, assim podemos saber se um determinado e-mail foi lido ou não;
- Sempre que é feito o download de uma página da Web (com ou sem erros), o servidor que retém a página sabe e pode armazenar o endereço IP do computador que solicita a página, linguagem do browser etc.
Abaixo segue um exemplo simples, onde eu vou pegar o IP do usuário que acessa uma determinada página.
Criaremos um arquivo chamado http://imasters.uol.com.br/webbug.php
<?php
// crio um arquivo aonde vou armazenar o ip do usuário
f = fopen('teste.txt','a');
fwrite(f,_SERVER['REMOTE_ADDR']."\\n");
fclose(f);
// aqui eu retorno o cabeçalho informando que esse arquivo é uma imagem, isso evita erros do browser
header('Content-type: image/gif');
?>Agora vamos incluir o Web Beacon, para isso vamos criar uma tag IMG com as dimensões 1x1
<img src="http://imasters.uol.com.br/webbug.php" alt="" width="1" height="1" />Dessa forma quando o browser carregar a imagem, ele também está executando o arquivo http://imasters.uol.com.br/webbug.php, desta forma criamos um Web Beacon.
Hoje os Web Bugs também utilizam IFrame, link , script e outras tags para monitorar uso.
Web Beacons podem ser utilizados em combinação com cookies HTTP como qualquer outro objeto transferido usando o protocolo HTTP.
Espero que tenham gostado.
Neste artigo iremos aprender a criar um formulário simples para o Joomla, utilizando o componente Chrono Forms. Esse formulário será similar ao fale conosco, mas com algumas particularidades bem interessantes. Além disso, este tutorial vai lhe abrir um leque de possibilidades para a criação de formulários para o Joomla.
Antes de tudo você precisa baixar o componente para sua máquina, abaixo segue o link da versão V3. 1 RC2 desse componente.
Componente ChronoForms V3.1 RC2
Nota: Se uma nova versão já está disponível, recomendo utilizá-la.
Após a instalação do Chrono Forms na área administrativa do Joomla, vá até - Componentes - Chrono Forms - Forms Manager.
Aqui nesta página nós vamos criar nosso primeiro formulário. Para isso vamos clicar em NOVO.
Imagem do Chrono Forms 1
Como mostra circulada de vermelho na figura acima, podemos notar um menu bem extenso no qual teremos de mexer para criar nosso formulário!
Calma, não se preocupem! Não é necessário mexer em tudo! Vamos começar!
No primeiro menu General (Geral), temos alguns campos a preencher.
O primeiro campo é: Form Name (do nome), eu vou chamar de contato. O nome pode ser qualquer um, lembrando apenas que não pode entrar espaços, acentos, letra maiúscula etc.
Segundo campo é: Email the results? (Resultado de email). Esse campo pergunta a você se deseja receber um e-mail com os dados do formulário que foi preenchido. Esse campo sempre vem marcado como "não", vamos mudar para "sim", já que queremos receber esses e-mails.
Nota: Não é necessário alterar os campos posteriores.
Vamos para o segundo menu: Setup Emails (Configuração de emails). Aqui vamos configurar o email para receber os formulários.
Pra realizar tal tarefa, temos que clicar no envelope com uma seta verde para baixo:
Obs: Ao clicar no envelope o campo fica com uma cor rosada.
Para jogar os campos dentro do quadrado rosado basta clicar em cima dos campos ao lado e arrastar para dentro do quadrado. Os campos que vamos utilizar são os seguintes:
- To (Para), pra onde o formulário vai;
- Subject (Assunto), quando o formulário chegar até seu e-mail no assunto virá o nome que colocou aqui;
- Fromname (do nome), quando o formulário chegar até seu e-mail você o identificará com o nome que colocou aqui;
- Dynamic FromEmail (do email dinâmico), aqui você colocaria o e-mail de quem irá preencher o formulário, como você não sabe e não será somente um e-mail, você irá inserir o "name" do campo (input) correspondente ao e-mail que você irá criar para o formulário (eu vou colocar "email", desta forma quando o formulário chegar no lugar de email virá o e-mail da pessoa que preencheu o formulário.
Veja na figura abaixo os campos que acabamos de arrastar já preenchidos.
Após todos os campos devidamente preenchidos vamos ao quadro ao lado na parte inferior onde diz: "Email Properties" (Propriedade de email). Dentre as opções que temos nesse espaço vamos alterar somente uma: "Enabled". Somente escolhendo a opção (Yes) vamos tornar valido tudo que fizemos nesse menu (General).
Agora basta clicar em Apply (aplicar). Esse processo deve demorar um pouco, mas não impede de prosseguirmos.
Vamos pular o próximo menu (Emails Templates) por enquanto, sendo assim, vamos ao seguinte: Form Code (do código).
Essa parte é muito importante, pois é aqui onde colocaremos o nosso código do nosso formulário.
Para esse tutorial vamos trabalhar com um formulário de 5 campos!
Obs: Neste tutorial não iremos ensinar como desenvolver o código do formulário. O que estamos utilizando segue abaixo, como exemplo.
Obs2.: Não insira a tag <form>, normalmente utilizada em formulários, pois o próprio componente irá inserir para você corretamente.
Você deve estar se perguntando o porquê de: nome, telefone, email, assunto, mensagem, estarem em negrito... Calma! Mais a diante vamos explicar!
Nesta etapa existem 4 campos, nosso código do formulário entrará no primeiro campo: Form HTML (do HTML).
Nota: Como se trata de um formulário simples, o segundo e terceiro campo não precisar mexer. E o quarto campo: On Submit code - after sending email (Enviar código - depois de enviar e-mail) é opcional.
Se você deseja que seu cliente veja uma mensagem de agradecimento, ou qualquer outra mensagem após enviar o formulário, então você irá querer preencher esse campo! Basta criar o código com a mensagem que deseja transmitir.
Abaixo segue o Código que usamos para esse campo.
Nota: Aqui não usamos um texto e sim uma imagem de agradecimento.
Após ter feito, vamos prosseguir para o próximo menu.
Nós vamos para o menu Validation (Validação).
Nota: Pulamos 6 menus, pois eles não precisam ser alterados para este tipo de formulário.
No menu Validação vamos alterar o primeiro campo: Enable Validation (Ativar Validação). Esse campo vem como (No), vamos alterar para (Yes), para nosso formulário ser Validado.
Na lista de 1 à 12, como mostra a figura abaixo, vamos acrescentar em ordem os nomes em negrito que mencionamos em nosso código HTML acima.
Você deve está se perguntando: Por que eu tenho que preencher com esses nomes, não poderia ser outros?
Eu te responderia: Sim, poderia ser outros se esses outros estivessem em seu código. Vamos voltar no código. Se você reparar bem, todos o que está em negrito são os "names"
name="nome"
name="telefone"
name="e-mail
etc.
Você escreverá no campo: required (not blank) os campos que você deseja que não fiquem em branco. O que isso quer dizer? Quer dizer que se alguém não preencher algum campo e tentar enviar o formulário não vai conseguir, pois os campos são todos obrigatórios.
Nota1: Você pode alterar o texto da validação, inserindo uma tag "title" no campo input correspondente, exemplo: <input type="text" name="nome" id="nome" title="Preencha seu nome!" />
Nota2: Você só preenche o required (not blank) se quiser que algum campo seja obrigatório em seu formulário.
Após preencher o campo clique em salvar.
Após esse processo, nosso formulário estará pronto para ser utilizado!
Importante: Se você abrir novamente o formulário que criou, poderá verificar na aba "Emails Templates", como será o e-mail que receberá após o mesmo ser enviado. Sabendo que os textos entre {} são os values dos campos. O texto pode ser alterado livremente.
Importante2: Não se esqueça de publicar o formulário na listagem da página inicial do componente.
Espero que esse tutorial seja de grande valia para muitos!
Qualquer dúvida estou pronta para tirá-las!
Um Grande abraço e até a próxima!
Fonte Original: Portal Joomla RJ
Escrito por: Rachel Soares Pereira
Neste artigo iremos aprender a criar um formulário simples para o Joomla, utilizando o componente Chrono Forms. Esse formulário será similar ao fale conosco, mas com algumas particularidades bem interessantes. Além disso, este tutorial vai lhe abrir um leque de possibilidades para a criação de formulários para o Joomla.
Antes de tudo você precisa baixar o componente para sua máquina, abaixo segue o link da versão V3. 1 RC2 desse componente.
Componente ChronoForms V3.1 RC2
Nota: Se uma nova versão já está disponível, recomendo utilizá-la.
Após a instalação do Chrono Forms na área administrativa do Joomla, vá até - Componentes - Chrono Forms - Forms Manager.
Aqui nesta página nós vamos criar nosso primeiro formulário. Para isso vamos clicar em NOVO.
Imagem do Chrono Forms 1
Como mostra circulada de vermelho na figura acima, podemos notar um menu bem extenso no qual teremos de mexer para criar nosso formulário!
Calma, não se preocupem! Não é necessário mexer em tudo! Vamos começar!
No primeiro menu General (Geral), temos alguns campos a preencher.
O primeiro campo é: Form Name (do nome), eu vou chamar de contato. O nome pode ser qualquer um, lembrando apenas que não pode entrar espaços, acentos, letra maiúscula etc.
Segundo campo é: Email the results? (Resultado de email). Esse campo pergunta a você se deseja receber um e-mail com os dados do formulário que foi preenchido. Esse campo sempre vem marcado como "não", vamos mudar para "sim", já que queremos receber esses e-mails.
Nota: Não é necessário alterar os campos posteriores.
Vamos para o segundo menu: Setup Emails (Configuração de emails). Aqui vamos configurar o email para receber os formulários.
Pra realizar tal tarefa, temos que clicar no envelope com uma seta verde para baixo:
Obs: Ao clicar no envelope o campo fica com uma cor rosada.
Para jogar os campos dentro do quadrado rosado basta clicar em cima dos campos ao lado e arrastar para dentro do quadrado. Os campos que vamos utilizar são os seguintes:
- To (Para), pra onde o formulário vai;
- Subject (Assunto), quando o formulário chegar até seu e-mail no assunto virá o nome que colocou aqui;
- Fromname (do nome), quando o formulário chegar até seu e-mail você o identificará com o nome que colocou aqui;
- Dynamic FromEmail (do email dinâmico), aqui você colocaria o e-mail de quem irá preencher o formulário, como você não sabe e não será somente um e-mail, você irá inserir o "name" do campo (input) correspondente ao e-mail que você irá criar para o formulário (eu vou colocar "email", desta forma quando o formulário chegar no lugar de email virá o e-mail da pessoa que preencheu o formulário.
Veja na figura abaixo os campos que acabamos de arrastar já preenchidos.
Após todos os campos devidamente preenchidos vamos ao quadro ao lado na parte inferior onde diz: "Email Properties" (Propriedade de email). Dentre as opções que temos nesse espaço vamos alterar somente uma: "Enabled". Somente escolhendo a opção (Yes) vamos tornar valido tudo que fizemos nesse menu (General).
Agora basta clicar em Apply (aplicar). Esse processo deve demorar um pouco, mas não impede de prosseguirmos.
Vamos pular o próximo menu (Emails Templates) por enquanto, sendo assim, vamos ao seguinte: Form Code (do código).
Essa parte é muito importante, pois é aqui onde colocaremos o nosso código do nosso formulário.
Para esse tutorial vamos trabalhar com um formulário de 5 campos!
Obs: Neste tutorial não iremos ensinar como desenvolver o código do formulário. O que estamos utilizando segue abaixo, como exemplo.
Obs2.: Não insira a tag <form>, normalmente utilizada em formulários, pois o próprio componente irá inserir para você corretamente.
Você deve estar se perguntando o porquê de: nome, telefone, email, assunto, mensagem, estarem em negrito... Calma! Mais a diante vamos explicar!
Nesta etapa existem 4 campos, nosso código do formulário entrará no primeiro campo: Form HTML (do HTML).
Nota: Como se trata de um formulário simples, o segundo e terceiro campo não precisar mexer. E o quarto campo: On Submit code - after sending email (Enviar código - depois de enviar e-mail) é opcional.
Se você deseja que seu cliente veja uma mensagem de agradecimento, ou qualquer outra mensagem após enviar o formulário, então você irá querer preencher esse campo! Basta criar o código com a mensagem que deseja transmitir.
Abaixo segue o Código que usamos para esse campo.
Nota: Aqui não usamos um texto e sim uma imagem de agradecimento.
Após ter feito, vamos prosseguir para o próximo menu.
Nós vamos para o menu Validation (Validação).
Nota: Pulamos 6 menus, pois eles não precisam ser alterados para este tipo de formulário.
No menu Validação vamos alterar o primeiro campo: Enable Validation (Ativar Validação). Esse campo vem como (No), vamos alterar para (Yes), para nosso formulário ser Validado.
Na lista de 1 à 12, como mostra a figura abaixo, vamos acrescentar em ordem os nomes em negrito que mencionamos em nosso código HTML acima.
Você deve está se perguntando: Por que eu tenho que preencher com esses nomes, não poderia ser outros?
Eu te responderia: Sim, poderia ser outros se esses outros estivessem em seu código. Vamos voltar no código. Se você reparar bem, todos o que está em negrito são os "names"
name="nome"
name="telefone"
name="e-mail
etc.
Você escreverá no campo: required (not blank) os campos que você deseja que não fiquem em branco. O que isso quer dizer? Quer dizer que se alguém não preencher algum campo e tentar enviar o formulário não vai conseguir, pois os campos são todos obrigatórios.
Nota1: Você pode alterar o texto da validação, inserindo uma tag "title" no campo input correspondente, exemplo: <input type="text" name="nome" id="nome" title="Preencha seu nome!" />
Nota2: Você só preenche o required (not blank) se quiser que algum campo seja obrigatório em seu formulário.
Após preencher o campo clique em salvar.
Após esse processo, nosso formulário estará pronto para ser utilizado!
Importante: Se você abrir novamente o formulário que criou, poderá verificar na aba "Emails Templates", como será o e-mail que receberá após o mesmo ser enviado. Sabendo que os textos entre {} são os values dos campos. O texto pode ser alterado livremente.
Importante2: Não se esqueça de publicar o formulário na listagem da página inicial do componente.
Espero que esse tutorial seja de grande valia para muitos!
Qualquer dúvida estou pronta para tirá-las!
Um Grande abraço e até a próxima!
Fonte Original: Portal Joomla RJ
Escrito por: Rachel Soares Pereira
Em meu último artigo sobre a resistência que desenvolvedores tem em adotar as Web Standards, muitas pessoas se manifestaram no sentido de que trabalhar com editores WYSIWYG como Fireworks ou Dreamweaver, na criação de páginas diagramadas com tabelas, seria mais produtivo, além de evitar incompatibilidade com navegadores.
As alegações são de que o uso das Web Standards aumenta o tempo de desenvolvimento, a quantidade de testes e a correção de erros. Isso realmente pode acontecer, se o desenvolvedor não possuir experiência suficiente com XHTML e CSS, e consequentemente, criar Layouts inadequados para a estruturação.
As maiores dificuldades que as pessoas têm para compreender a importância do desenvolvimento com as Web Standards é (1) imaginar que é apenas uma questão de substituir Tabelas por DIVs, e (2) não compreender a questão da Semântica.
O que é Semântica?
A Semântica, enquanto estudo da palavra, tem preocupação com o significado dos objetos (me refiro aqui a objeto como tudo que é perceptível aos sentidos).
A ideia de uma Web Semântica surgiu em 2001 a partir de um artigo publicado por Tim Berners-Lee, James Hendler e Ora Lassila, e tem como objetivo estender a Web atual, através da atribuição de significado ao conteúdo dos documentos, de forma que eles possam ser compreensíveis não só por seres humanos, mas também por máquinas. Isso possibilitaria que informações úteis em diferentes sistemas fossem integradas para facilitar a vida das pessoas.
Vamos imaginar que eu possuo uma agenda online, onde consta que tenho uma viagem marcada para Nova Yorque, assim como a data e o horário em que devo embarcar. Essas informações seriam muito claras para mim ou para qualquer outro ser humano, que poderia providenciar tudo que fosse necessário para a viagem.Agora vamos imaginar que essa agenda possui informações com significado não só para humanos, mas também para máquinas, de forma que esses dados pudessem ser integrados com outros sistemas pelo mundo, que também tivessem informações com significado para as máquinas.
Com isso, meu sistema, ao identificar o compromisso na agenda, poderia automaticamente buscar e reservar para mim uma passagem aérea para o dia e horário em que fosse necessário, assim como reservar um quarto no hotel mais próximo ao meu local de destino, e quem sabe até me recomendar passeios, livrarias e restaurantes, de acordo com meus gostos pessoais descritos no perfil de uma rede social qualquer.
Parece até coisa de filmes de ficção científica!
Para que algo assim fosse possível, para que os sistemas tivessem esse nível de automatização e funcionassem como na história acima, teríamos que pensar na evolução dos documentos, antes de pensar na evolução das tecnologias.
Teríamos que criar documentos em que as informações tivessem significado não só para humanos, mas também para máquinas.
Isso seria a Web Semântica.
Tirar o lixo e organizar a casa
Alguém sabe a quantidade de informação que existe hoje na Web, ou quanta informação é possível de ser armazenada digitalmente?
Um CD comum armazena cerca de 650 Megabytes de informação, e isso equivale a 340.000 páginas com 2000 caracteres cada. Se essas páginas fossem impressas em papel de 20 gramas em frente e verso, a pilha de papel necessária para equivaler à capacidade informativa de um CD pesaria 770 quilos. (Informação retirada do livro "Do papel até a Web", de Tony McKinley)
Acho que agora deu pra ter uma ideia!
A Web tem mais informações do que todas as bibliotecas do mundo juntas. Infelizmente a maioria dessas informações não tem significado nem sentido algum.
Uma Linguagem de Marcação como o HTML é feita de etiquetas (tags) que servem para dar significado às partes de um documento. Sendo assim, com as etiquetas <h1></h1> informamos que determinado trecho de texto é um título, com as etiquetas <p></p> indicamos que determinado trecho de texto é um parágrafo, ou então com as etiquetas <blockquote></blockquote> informamos que determinado bloco de texto é uma citação.
Sabendo disso, poderíamos acreditar que trabalhando com HTML teríamos naturalmente documentos com definições claras sobre o que é cada informação.
Porém, desde o início a Web foi sendo explorada como uma extensão da mídia impressa, com uma preocupação unicamente visual, sem levar em consideração a estrutura dos documentos e seu significado. Como os recursos do HTML eram limitados para diagramação, além de possuir algumas marcações próprias para formatação, os documentos começaram a ser adaptados de forma equivocada, e recursos como tabelas (que existem para definir dados tabulares) começaram a ser usados para diagramar páginas de sites como se fossem páginas de revistas. O uso correto das marcações era ignorado: etiquetas de parágrafo eram usadas para comportar títulos ou listas, por exemplo.
Essa forma de criar os documentos faz com que a informação fique clara para o seres humanos, porém sem sentido algum para máquinas ou sistemas que possam vir a (tentar) interpretar os documentos.
Trabalhar com Web Standards significa criar documentos onde serão usadas apenas as marcações necessárias para identificar as informações, sem que sejam inseridas marcações com finalidades visuais.
O uso de tabelas para diagramar as páginas gera um código sem significado, muitas vezes incompreensível, e várias vezes maior que o necessário, enchendo os servidores pelo mundo de Terabytes inúteis, além de fazer com que boa parte das informações úteis não seja compreendida pelas máquinas.
Devemos usar apenas marcações que forneçam significado à cada parte do documento, e toda apresentação visual deve estar em um documento separado (CSS).
Acessibilidade: máquinas informando seres humanos
Quem cria páginas para Web utilizando editores WYSIWYG e tabelas pode alegar que disponibiliza informações claras ao menos aos seres humanos.
Mas será que realmente todos os seres humanos têm acesso as informações publicadas na Web?
Algumas pessoas necessitam do suporte de tecnologias assistivas para compreender as informações da Web, seja por deficiências visuais ou motoras, necessitando do auxílio de Leitores de Tela, Teclados Alternativos, Ampliadores de Tela, Ponteiras de cabeça e Linhas Braille. Existem pessoas que dependem de máquinas para acessar as informações disponíveis na Web.
Para que um programa Leitor de Tela com síntese de voz, usado por uma pessoas cega, possa compreender as informações de um documento e convertê-las em áudio, é necessário que todos os dados possuam marcações com significados corretos, para que o programa compreenda quais são os títulos, as listas, os parágrafos e os dados tabulares, assim como ter alternativas textuais para descrever imagens e animações.
Também é importante que os documentos tenham uma sequência lógica, da mesma forma que os capítulos de um livro. Quando usa-se tabelas para diagramar um Layout, a única preocupação é com a organização visual, deixando o código com uma sequência incompreensível para máquinas, como se misturássemos os capítulos do livro.
Para que todas pessoas possam ter acesso as informações, devemos criar documentos com uma sequência coerente, com alternativas textuais para imagens e animações, atalhos de teclado para links e campos de formulários, indicações de conteúdos em outros idiomas, e tudo que possibilite às tecnologias assistivas de compreender o documento.
Trabalhando pela evolução dos Sistemas de Informação
Boa parte das justificativas dos profissionais que não trabalham com os Padrões está no fato de que navegadores antigos como o IE6 (que possui a maior fatia dos usuários) não possuem suporte adequado aos Padrões. Porém existem formas de driblar isso, que podemos encontrar com uma simples busca na Web: para PNGs transparentes, assim como para a falta de interpretação de algumas propriedades de CSS, como pseudo-elementos, podemos utilizar scripts como o IE7.js. Para diferenças de renderização entre navegadores temos técnicas de CSS Reset.
Qualquer Layout complexo é possível de ser feito com CSS, basta ter conhecimento e as armas certas engatilhadas. O fato de os navegadores antigos não fornecerem suporte adequado não pode ser pretexto para pararmos de estudar, nem pregarmos o retrocesso do Desenvolvimento para a Web. Dessa forma não estaremos contribuindo para que evolução alguma aconteça (você acha que o IE8 passou no teste ACID 2 porque a Microsoft decidiu ser legal, ou pela pressão do mercado e dos desenvolvedores?).
Outra fácil justificativa é jogar a culpa nos clientes, que não flexibilizam prazos e nem recompensam financeiramente o uso das Web Standards. Mas será que todos os clientes têm receio de investir em projetos acessíveis por terem preocupações unicamente visuais, ou porque não são esclarecidos das reais vantagens?
Estudar, argumentar e convencer os clientes está ao alcance de todos. As vantagens que podemos obter com o uso das Web Standards estão documentadas em diversos sites: arquivos menores e sites mais leves, menor consumo de banda, maior indexação pelos mecanismos de busca, maiores facilidades de manutenção e redesign, além de maior Acessibilidade.
Claro que para isso realmente acontecer, devemos compreender que trabalhar com Web Standards não é apenas uma questão de substituir tabelas por DIVs (Tableless).
Maior produtividade virá com a experiência, e com a compreensão de que os documentos não podem ser verdadeiras "sopas de tags". Se criarmos páginas com uma grande quantidade de marcações sem significado, mesmo que não usemos tabelas e editores WYSIWYG, não vamos obter essas vantagens.
É necessário criarmos documentos com significados não só para humanos, mas também para máquinas. Os sites são armazenados em máquinas, Leitores de Tela e outras Tecnologias Assistivas são máquinas, e também os mecanismos de busca são máquinas!
As possibilidades de existência de uma Web Semântica, com integração de dados entre diversos sistemas informacionais, que possam melhorar a qualidade de vida das pessoas, só serão possíveis com documentos semânticos, e claro que isso não se resume a desenvolver um HTML com devido significado. Porém, outros assuntos relacionados como RDF ou Microformatos, são temas para outro artigo.
Para que haja evolução das máquinas e dos sistemas é preciso que haja primeiro uma evolução dos profissionais que fazem a Web.
Em meu último artigo sobre a resistência que desenvolvedores tem em adotar as Web Standards, muitas pessoas se manifestaram no sentido de que trabalhar com editores WYSIWYG como Fireworks ou Dreamweaver, na criação de páginas diagramadas com tabelas, seria mais produtivo, além de evitar incompatibilidade com navegadores.
As alegações são de que o uso das Web Standards aumenta o tempo de desenvolvimento, a quantidade de testes e a correção de erros. Isso realmente pode acontecer, se o desenvolvedor não possuir experiência suficiente com XHTML e CSS, e consequentemente, criar Layouts inadequados para a estruturação.
As maiores dificuldades que as pessoas têm para compreender a importância do desenvolvimento com as Web Standards é (1) imaginar que é apenas uma questão de substituir Tabelas por DIVs, e (2) não compreender a questão da Semântica.
O que é Semântica?
A Semântica, enquanto estudo da palavra, tem preocupação com o significado dos objetos (me refiro aqui a objeto como tudo que é perceptível aos sentidos).
A ideia de uma Web Semântica surgiu em 2001 a partir de um artigo publicado por Tim Berners-Lee, James Hendler e Ora Lassila, e tem como objetivo estender a Web atual, através da atribuição de significado ao conteúdo dos documentos, de forma que eles possam ser compreensíveis não só por seres humanos, mas também por máquinas. Isso possibilitaria que informações úteis em diferentes sistemas fossem integradas para facilitar a vida das pessoas.
Vamos imaginar que eu possuo uma agenda online, onde consta que tenho uma viagem marcada para Nova Yorque, assim como a data e o horário em que devo embarcar. Essas informações seriam muito claras para mim ou para qualquer outro ser humano, que poderia providenciar tudo que fosse necessário para a viagem.Agora vamos imaginar que essa agenda possui informações com significado não só para humanos, mas também para máquinas, de forma que esses dados pudessem ser integrados com outros sistemas pelo mundo, que também tivessem informações com significado para as máquinas.
Com isso, meu sistema, ao identificar o compromisso na agenda, poderia automaticamente buscar e reservar para mim uma passagem aérea para o dia e horário em que fosse necessário, assim como reservar um quarto no hotel mais próximo ao meu local de destino, e quem sabe até me recomendar passeios, livrarias e restaurantes, de acordo com meus gostos pessoais descritos no perfil de uma rede social qualquer.
Parece até coisa de filmes de ficção científica!
Para que algo assim fosse possível, para que os sistemas tivessem esse nível de automatização e funcionassem como na história acima, teríamos que pensar na evolução dos documentos, antes de pensar na evolução das tecnologias.
Teríamos que criar documentos em que as informações tivessem significado não só para humanos, mas também para máquinas.
Isso seria a Web Semântica.
Tirar o lixo e organizar a casa
Alguém sabe a quantidade de informação que existe hoje na Web, ou quanta informação é possível de ser armazenada digitalmente?
Um CD comum armazena cerca de 650 Megabytes de informação, e isso equivale a 340.000 páginas com 2000 caracteres cada. Se essas páginas fossem impressas em papel de 20 gramas em frente e verso, a pilha de papel necessária para equivaler à capacidade informativa de um CD pesaria 770 quilos. (Informação retirada do livro "Do papel até a Web", de Tony McKinley)
Acho que agora deu pra ter uma ideia!
A Web tem mais informações do que todas as bibliotecas do mundo juntas. Infelizmente a maioria dessas informações não tem significado nem sentido algum.
Uma Linguagem de Marcação como o HTML é feita de etiquetas (tags) que servem para dar significado às partes de um documento. Sendo assim, com as etiquetas <h1></h1> informamos que determinado trecho de texto é um título, com as etiquetas <p></p> indicamos que determinado trecho de texto é um parágrafo, ou então com as etiquetas <blockquote></blockquote> informamos que determinado bloco de texto é uma citação.
Sabendo disso, poderíamos acreditar que trabalhando com HTML teríamos naturalmente documentos com definições claras sobre o que é cada informação.
Porém, desde o início a Web foi sendo explorada como uma extensão da mídia impressa, com uma preocupação unicamente visual, sem levar em consideração a estrutura dos documentos e seu significado. Como os recursos do HTML eram limitados para diagramação, além de possuir algumas marcações próprias para formatação, os documentos começaram a ser adaptados de forma equivocada, e recursos como tabelas (que existem para definir dados tabulares) começaram a ser usados para diagramar páginas de sites como se fossem páginas de revistas. O uso correto das marcações era ignorado: etiquetas de parágrafo eram usadas para comportar títulos ou listas, por exemplo.
Essa forma de criar os documentos faz com que a informação fique clara para o seres humanos, porém sem sentido algum para máquinas ou sistemas que possam vir a (tentar) interpretar os documentos.
Trabalhar com Web Standards significa criar documentos onde serão usadas apenas as marcações necessárias para identificar as informações, sem que sejam inseridas marcações com finalidades visuais.
O uso de tabelas para diagramar as páginas gera um código sem significado, muitas vezes incompreensível, e várias vezes maior que o necessário, enchendo os servidores pelo mundo de Terabytes inúteis, além de fazer com que boa parte das informações úteis não seja compreendida pelas máquinas.
Devemos usar apenas marcações que forneçam significado à cada parte do documento, e toda apresentação visual deve estar em um documento separado (CSS).
Acessibilidade: máquinas informando seres humanos
Quem cria páginas para Web utilizando editores WYSIWYG e tabelas pode alegar que disponibiliza informações claras ao menos aos seres humanos.
Mas será que realmente todos os seres humanos têm acesso as informações publicadas na Web?
Algumas pessoas necessitam do suporte de tecnologias assistivas para compreender as informações da Web, seja por deficiências visuais ou motoras, necessitando do auxílio de Leitores de Tela, Teclados Alternativos, Ampliadores de Tela, Ponteiras de cabeça e Linhas Braille. Existem pessoas que dependem de máquinas para acessar as informações disponíveis na Web.
Para que um programa Leitor de Tela com síntese de voz, usado por uma pessoas cega, possa compreender as informações de um documento e convertê-las em áudio, é necessário que todos os dados possuam marcações com significados corretos, para que o programa compreenda quais são os títulos, as listas, os parágrafos e os dados tabulares, assim como ter alternativas textuais para descrever imagens e animações.
Também é importante que os documentos tenham uma sequência lógica, da mesma forma que os capítulos de um livro. Quando usa-se tabelas para diagramar um Layout, a única preocupação é com a organização visual, deixando o código com uma sequência incompreensível para máquinas, como se misturássemos os capítulos do livro.
Para que todas pessoas possam ter acesso as informações, devemos criar documentos com uma sequência coerente, com alternativas textuais para imagens e animações, atalhos de teclado para links e campos de formulários, indicações de conteúdos em outros idiomas, e tudo que possibilite às tecnologias assistivas de compreender o documento.
Trabalhando pela evolução dos Sistemas de Informação
Boa parte das justificativas dos profissionais que não trabalham com os Padrões está no fato de que navegadores antigos como o IE6 (que possui a maior fatia dos usuários) não possuem suporte adequado aos Padrões. Porém existem formas de driblar isso, que podemos encontrar com uma simples busca na Web: para PNGs transparentes, assim como para a falta de interpretação de algumas propriedades de CSS, como pseudo-elementos, podemos utilizar scripts como o IE7.js. Para diferenças de renderização entre navegadores temos técnicas de CSS Reset.
Qualquer Layout complexo é possível de ser feito com CSS, basta ter conhecimento e as armas certas engatilhadas. O fato de os navegadores antigos não fornecerem suporte adequado não pode ser pretexto para pararmos de estudar, nem pregarmos o retrocesso do Desenvolvimento para a Web. Dessa forma não estaremos contribuindo para que evolução alguma aconteça (você acha que o IE8 passou no teste ACID 2 porque a Microsoft decidiu ser legal, ou pela pressão do mercado e dos desenvolvedores?).
Outra fácil justificativa é jogar a culpa nos clientes, que não flexibilizam prazos e nem recompensam financeiramente o uso das Web Standards. Mas será que todos os clientes têm receio de investir em projetos acessíveis por terem preocupações unicamente visuais, ou porque não são esclarecidos das reais vantagens?
Estudar, argumentar e convencer os clientes está ao alcance de todos. As vantagens que podemos obter com o uso das Web Standards estão documentadas em diversos sites: arquivos menores e sites mais leves, menor consumo de banda, maior indexação pelos mecanismos de busca, maiores facilidades de manutenção e redesign, além de maior Acessibilidade.
Claro que para isso realmente acontecer, devemos compreender que trabalhar com Web Standards não é apenas uma questão de substituir tabelas por DIVs (Tableless).
Maior produtividade virá com a experiência, e com a compreensão de que os documentos não podem ser verdadeiras "sopas de tags". Se criarmos páginas com uma grande quantidade de marcações sem significado, mesmo que não usemos tabelas e editores WYSIWYG, não vamos obter essas vantagens.
É necessário criarmos documentos com significados não só para humanos, mas também para máquinas. Os sites são armazenados em máquinas, Leitores de Tela e outras Tecnologias Assistivas são máquinas, e também os mecanismos de busca são máquinas!
As possibilidades de existência de uma Web Semântica, com integração de dados entre diversos sistemas informacionais, que possam melhorar a qualidade de vida das pessoas, só serão possíveis com documentos semânticos, e claro que isso não se resume a desenvolver um HTML com devido significado. Porém, outros assuntos relacionados como RDF ou Microformatos, são temas para outro artigo.
Para que haja evolução das máquinas e dos sistemas é preciso que haja primeiro uma evolução dos profissionais que fazem a Web.
Olá, amigos! Na última edição do Campus Party Brasil, fiquei encarregado de abrir as atividades na área de Design com a palestra sobre Web Standards.
Após a palestra, e depois de bater papo com muita gente por lá, cheguei à triste conclusão de que muitos profissionais ainda desconhecem as Web Standards, e desenvolvem sites à moda antiga (usando tabelas para diagramar o Layout).
Para contribuir na mudança desse quadro, este artigo é o primeiro de uma série sobre Web Standards que estarei escrevendo. E para ter certeza de que vou ajudar a esclarecer as dúvidas sobre esse assunto, deixo aberto o espaço para a sugestão de temas para os próximos artigos.
Resistência aos padrões, ou amor às tabelas?
Pior do que perceber que ainda hoje muitas pessoas desconhecem as Web Standards e suas vantagens, é perceber que existem pessoas que conhecem, porém resistem a elas, com argumentos (sem fundamentos) de que desenvolver sites com o uso de tabelas para diagramar o Layout é melhor e mais produtivo.
Esses dias andou pipocando pelas listas de discussão um artigo escrito por um tal de Ron Garret, no qual ele tenta justificar que o CSS não serve para diagramar Layouts (Why CSS should not be used for layout) e afirma que o uso de tabelas é melhor para tal finalidade.
Essa forma de pensar mostra que muitas pessoas têm a visão equivocada de considerar o Design como mera produção estética, e desconsideram a concepção de projeto. Como escrevi em outro artigo, além da questão estética, o Design engloba a criação de um produto funcional, usável, eficiente e economicamente viável.
Uma estrutura de informação, como documentos escritos em HTML ou XML, deve conter apenas marcações com devido significado (semântica). Adicionar marcações sem significado em um site pode ser comparado a adicionar diversas páginas em branco a um livro: aumentaria inutilmente o tamanho do mesmo, e não teriam sentido algum para o leitor. É justamente isso que acontece com o uso das tabelas para diagramar o Layout.
Podemos dizer que o HTML não é uma linguagem de marcação verdadeira, pois sua sintaxe prevê (limitadas) marcações para formatação. Uma linguagem de marcação deve apenas estruturar a informação (como o XHTML), enquanto a apresentação deve vir de um documento específico (CSS).
A maior dificuldade no uso do CSS para diagramação das páginas vem da incapacidade dos navegadores, não só no suporte à linguagem, como na padronização do efeito renderizado. O IE6 suporta apenas 51% das propriedades do CSS 2.1, o IE7 apenas 56%, o Firefox2 suporta 91%. O IE6, que ainda é o navegador mais usado, também suporta apenas 73% do HTML/XHTML, 50% do DOM e 10% do CSS3. Mais informações sobre essas estatísticas podem ser vistas em http://www.webdevout.net/browser-support).
O CSS não é perfeito, as empresas que desenvolvem os navegadores não colaboram no suporte, e a W3C não é nenhum exemplo de discussões promissoras em prol da padronização. Lembrando que a W3C não se resume apenas àquele tiozinho carismático de ideais livres que inventou a Web, mas de diversas empresas com interesses não tão nobres (quem chegou a acompanhar discussões sobre o uso dos codec's Ogg Vorbis e o Ogg Theora como padrão nos navegadores, para o uso da nova tag <video></video> no HTML5, sabe do que eu estou falando).
A vantagem do uso de Padrões Web
Recortar um layout em softwares como o Fireworks e exportar diretamente para HTML com tabelas pode parecer fácil e rápido. Porém o código gerado torna-se incompreensível, sem uma sequência lógica da informação ou significado, além de ser muito maior que o necessário.
O uso das Web Standards propicia um melhor custo-benefício. As vantagens do uso de padrões e da separação das camadas de Conteúdo (XHTML), apresentação (CSS) e Comportamento (Javascript) são evidentes:
- Com arquivos menores e as camadas de Apresentação (CSS) e Comportamento (Javascript) no cache do navegador, teremos um carregamento mais rápido das páginas, além de menores custos de hospedagem.
- Com a formatação de todas as páginas baseadas num mesmo arquivo CSS, teremos uma melhor consistência visual, e possibilidades de manutenção e redesign mais baratos e eficientes.
- Com marcações mais semânticas (usadas com seu devido significado) e com as informações do documento estruturadas em uma sequência lógica, teremos melhores resultados nos mecanismos de buscas, além de melhor acessibilidade e interoperabilidade entre diferentes dispositivos.
Exemplos práticos dessas vantagens:
- A Legal & General, uma das primeiras empresas a aplicar em seu site as "Diretivas para acessibilidade Web" (Web Content Accessibility Guidelines) da W3C, e os resultados foram que as taxas de conversão aumentaram 300%, custos de manutenção caíram 66%, listagem natural nas buscas aumentou 50% e o carregamento das páginas ficou 75% mais rápido (fonte: RevistaW).
- A ESPN, quando migrou seu site para os Padrões, reduziu cerca de 50kb em cada página, economizando 2 Terabytes de banda por dia (fonte: Mike Davidson).
Quanto à beleza dos sites feitos com CSS, é indiscutível que as possibilidades são enormes, e muito mais eficientes que a formatação possibilitada com o uso de tabelas no HTML. Exemplos disso podemos encontrar na galeria CSS Zen Garden ou em sites como o Web Leed Design.
Se as Web Standards ainda não são o ideal, é o que de melhor temos hoje para o desenvolvimento de páginas para a Web.
Linguagens como o CSS têm sempre mil possibilidades. A limitação está no Designer.
Olá, amigos! Na última edição do Campus Party Brasil, fiquei encarregado de abrir as atividades na área de Design com a palestra sobre Web Standards.
Após a palestra, e depois de bater papo com muita gente por lá, cheguei à triste conclusão de que muitos profissionais ainda desconhecem as Web Standards, e desenvolvem sites à moda antiga (usando tabelas para diagramar o Layout).
Para contribuir na mudança desse quadro, este artigo é o primeiro de uma série sobre Web Standards que estarei escrevendo. E para ter certeza de que vou ajudar a esclarecer as dúvidas sobre esse assunto, deixo aberto o espaço para a sugestão de temas para os próximos artigos.
Resistência aos padrões, ou amor às tabelas?
Pior do que perceber que ainda hoje muitas pessoas desconhecem as Web Standards e suas vantagens, é perceber que existem pessoas que conhecem, porém resistem a elas, com argumentos (sem fundamentos) de que desenvolver sites com o uso de tabelas para diagramar o Layout é melhor e mais produtivo.
Esses dias andou pipocando pelas listas de discussão um artigo escrito por um tal de Ron Garret, no qual ele tenta justificar que o CSS não serve para diagramar Layouts (Why CSS should not be used for layout) e afirma que o uso de tabelas é melhor para tal finalidade.
Essa forma de pensar mostra que muitas pessoas têm a visão equivocada de considerar o Design como mera produção estética, e desconsideram a concepção de projeto. Como escrevi em outro artigo, além da questão estética, o Design engloba a criação de um produto funcional, usável, eficiente e economicamente viável.
Uma estrutura de informação, como documentos escritos em HTML ou XML, deve conter apenas marcações com devido significado (semântica). Adicionar marcações sem significado em um site pode ser comparado a adicionar diversas páginas em branco a um livro: aumentaria inutilmente o tamanho do mesmo, e não teriam sentido algum para o leitor. É justamente isso que acontece com o uso das tabelas para diagramar o Layout.
Podemos dizer que o HTML não é uma linguagem de marcação verdadeira, pois sua sintaxe prevê (limitadas) marcações para formatação. Uma linguagem de marcação deve apenas estruturar a informação (como o XHTML), enquanto a apresentação deve vir de um documento específico (CSS).
A maior dificuldade no uso do CSS para diagramação das páginas vem da incapacidade dos navegadores, não só no suporte à linguagem, como na padronização do efeito renderizado. O IE6 suporta apenas 51% das propriedades do CSS 2.1, o IE7 apenas 56%, o Firefox2 suporta 91%. O IE6, que ainda é o navegador mais usado, também suporta apenas 73% do HTML/XHTML, 50% do DOM e 10% do CSS3. Mais informações sobre essas estatísticas podem ser vistas em http://www.webdevout.net/browser-support).
O CSS não é perfeito, as empresas que desenvolvem os navegadores não colaboram no suporte, e a W3C não é nenhum exemplo de discussões promissoras em prol da padronização. Lembrando que a W3C não se resume apenas àquele tiozinho carismático de ideais livres que inventou a Web, mas de diversas empresas com interesses não tão nobres (quem chegou a acompanhar discussões sobre o uso dos codec's Ogg Vorbis e o Ogg Theora como padrão nos navegadores, para o uso da nova tag <video></video> no HTML5, sabe do que eu estou falando).
A vantagem do uso de Padrões Web
Recortar um layout em softwares como o Fireworks e exportar diretamente para HTML com tabelas pode parecer fácil e rápido. Porém o código gerado torna-se incompreensível, sem uma sequência lógica da informação ou significado, além de ser muito maior que o necessário.
O uso das Web Standards propicia um melhor custo-benefício. As vantagens do uso de padrões e da separação das camadas de Conteúdo (XHTML), apresentação (CSS) e Comportamento (Javascript) são evidentes:
- Com arquivos menores e as camadas de Apresentação (CSS) e Comportamento (Javascript) no cache do navegador, teremos um carregamento mais rápido das páginas, além de menores custos de hospedagem.
- Com a formatação de todas as páginas baseadas num mesmo arquivo CSS, teremos uma melhor consistência visual, e possibilidades de manutenção e redesign mais baratos e eficientes.
- Com marcações mais semânticas (usadas com seu devido significado) e com as informações do documento estruturadas em uma sequência lógica, teremos melhores resultados nos mecanismos de buscas, além de melhor acessibilidade e interoperabilidade entre diferentes dispositivos.
Exemplos práticos dessas vantagens:
- A Legal & General, uma das primeiras empresas a aplicar em seu site as "Diretivas para acessibilidade Web" (Web Content Accessibility Guidelines) da W3C, e os resultados foram que as taxas de conversão aumentaram 300%, custos de manutenção caíram 66%, listagem natural nas buscas aumentou 50% e o carregamento das páginas ficou 75% mais rápido (fonte: RevistaW).
- A ESPN, quando migrou seu site para os Padrões, reduziu cerca de 50kb em cada página, economizando 2 Terabytes de banda por dia (fonte: Mike Davidson).
Quanto à beleza dos sites feitos com CSS, é indiscutível que as possibilidades são enormes, e muito mais eficientes que a formatação possibilitada com o uso de tabelas no HTML. Exemplos disso podemos encontrar na galeria CSS Zen Garden ou em sites como o Web Leed Design.
Se as Web Standards ainda não são o ideal, é o que de melhor temos hoje para o desenvolvimento de páginas para a Web.
Linguagens como o CSS têm sempre mil possibilidades. A limitação está no Designer.
O (x)html/css como ferramenta, conceito e diferencial do designer de interfaces é o tema deste artigo, em sua segunda parte. Para um melhor entendimento, sugiro, antes de mais nada, uma atenta leitura à primeira parte.
Processo de produção do código
O processo, em si, é bastante claro e objetivo: cuidar da codificação, da estrutura do lay-out desejado, obtendo, assim, um melhor resultado, carregamento rápido, amplificando os conceitos de usabilidade e acessibilidade por meio de boas e salutares técnicas.
Sendo assim, nada poderá dar errado, não é?Analisando os "gargalos" da produção
O processo rotineiro de um estúdio ou agência web inclui verbas mínimas, grandes exigências e pouca tolerância (por boa parte dos clientes) e prazos impossíveis. Não há como fugir: ou se entra em tal lógica tortuosa de cabeça, ou colhe-se as consequencias desagradáveis da falta de adaptação, que incluem o "sumiço" dos freelas e o desemprego pertinente.
Conheça, agora, os maiores "gargalos produtivos", e as melhores maneiras de evitá-los:1) Propostas infactíveis:
Tais propostas são oferecidas / desenvolvidas por profissionais de criação completamente desambientados do processo de estruturação de páginas. É certo que a criatividade precisa de espaço para "voar", porém um mínimo de "pé-no-chão" é mais do que necessário. É preciso conhecer o processo produtivo como um todo (mesmo que certas etapas não façam parte de sua rotina profissional), a fim de não propor soluções "impossíveis", que podem ser belas e competentes em termos de design, porém completamente descabidas no momento de estruturar tal conteúdo.Portanto, se a idéia e o briefing levam para o desenvolvimento em (x)html/css (com textos em formato "nativo", portanto), de nada adianta desenvolver um lay-out que, na melhor das hipóteses, só será factível em flash.
O profissional que faz design web, ao conhecer efetivamente a estruturação, poderá situar-se melhor, evitando grandes "mancadas", como apresentar e aprovar determinada proposta ao cliente impossível de ser "produzida".2) Códigos sujos:
Herança indefectível do uso "preguiçoso" de editores WSWYG, códigos sujos, não-semânticos, inadequados às web standards, estão espalhados por diversos sites, nos mais variados "níveis" de produtores. O maior problema, aqui, está na manutenção de tal código. Normalmente, sites com códigos de tal "qualidade" nascem do descuido e descaso de diversos "profissionais" completamente reativos, sem qualquer preocupação com a necessidade de edição posterior. Ao agirem assim, ignoram a máxima: "o cliente vai mudar de idéia", além de "esquecerem" que sites web são mutantes, mudam drasticamente (visualmente, conceitualmente).A solução, novamente, recai sobre a necessidade de aprender, de fato, estruturação. Assim, com conhecimentos, visão e responsabilidade, todo e qualquer código torna-se limpo, editável e expansível.
3) Falta de integração:
Por mais óbvio que seja, existem designers que simplesmente relutam na hora de conversar com os estruturadores e programadores envolvidos no mesmo projeto, resultando num grande obstáculo à integração de soluções produtivas adotadas. Ninguém está numa ilha, o sucesso de um projeto web está diretamente ligado à integração de uma equipe, capaz de trabalhar e pensar coletivamente.4) Produção desestruturada:
O maior problema, aqui, é a repetição da produção de códigos quase idênticos, somente por estarem em projetos distintos, o que, certamente, custará tempo precioso.Que tal usar módulos produtivos? Existem diversos blocos de código e muitas soluções produtivas de estruturação que normalmente se repetem, de projeto em projeto. Assim, diversas tarefas ficam mais fáceis, pois já partem de um conjunto de códigos pré-definidos, bastando a adaptação dos mesmo para que o projeto avance. Exemplos de tal idéia: códigos para separação em colunas de uma página, de menus de links, de formulários e diversos outros.
Soluções possíveis
Há uma série de ações que podem (e devem) ser adotadas pelo designer que faz web, melhorando significamente a performance em tal meio e evitando a calvície precoce (advinda do constante "arrancar" de cabelos). Sugiro, aqui, algumas idéias que podem melhorar a vida profissional:
1) Vivencie a estruturação:
Perca o medo e o receio. Mergulhe de cabeça! Experimente adotar as web standards em seus projetos, acompanhe sites desenvolvidos com padrões (como o w3csites, por exemplo) e veja as poderosas possibilidades em ação. Ao acompanhar os mais "experientes" em ação, certamente a empolgação em mergulhar fundo aumentará consideravelmente.2) Expanda seus conhecimentos:
O melhor meio para aumentar suas habilidades é o estudo. Juntamente com a pesquisa, irá possibilitar um aumento significativo da percepção profissional, em qualquer nível em que esteja. Confira algumas dicas comentadas, de sites e livros:a) W3C - Documentação traduzida: boa parte dos mais importantes documentos contendo as definições do (x)html, css, web standards e acessibilidade. Grandes colaboradores brasileiros resolveram desenvolver, gratuitamente, suas traduções, visando à expansão das web standards em terras nacionais. Faça sua parte e estude os documentos traduzidos, fazendo com que tal esforço não seja em vão.
b) Maujor: Maurício Samy Silva (Maujor) é um respeitável senhor de cabelos brancos e uma invejável bagagem em web standards no Brasil, sendo, praticamente, o oráculo de tal tema. Quando se interessou por padrões web, o tema era praticamente desconhecido no país (e não havia os milhares de sites e blogs escrevendo - ou tomando carona - sobre o tema). Portanto, trata-se do pioneiro dos padrões no Brasil, sendo que seu site possui muitas informações preciosas para estudandes e profissionais da área. Visite o site, aproveite e passe pelo blog.
c) CSS Zen Garden: conheça uma brilhante galeria de sites desenvolvidos somente com (x)html/css e veja do que esta linguagem é capaz, desde que utilizada sabiamente. O site oferece um conjunto de documentos para que qualquer pessoa se aventure na construção de um novo layout, inteiramente baseado em css, sendo que os melhores são publicados. Visite. Conheça a versão em português.
d) Livro do Maujor: o livro "Construindo Sites com CSS e (X)HTML" é o melhor livro publicado até então no Brasil. Com didática séria, dinâmica e inteligente, Mauricio Samy Silva conduz o estudante pelos caminhos do desenvolvimento com css, dando base sólida e conhecimento de verdade. Visite o site do livro.
e) CSS interativo: conheça este serviço oferecido pelo iMasters, com desenvolvimento de Mauricio Samy Silva e experimente, interativamente, todos os recursos do css. Visite!
f) W3C validator (css e xhtml): verifique seu código a fim de procurar erros e correções. Com esta ferramenta oferecida pelo W3C, você poderá verificar seus códigos por uploads (ou seja, poderá verificar antes de publicar), páginas hospedadas e conferir a relação de erros e sugestões "robóticas" para correções. Conheça a ferramenta e adicione aos seus favoritos! Você também pode instalar plugins de firefox para validação diretamente no browser como o tidy, por exemplo, e verificar seus códigos.
g) Web Developer: conjunto de ferramentas para desenvolvedores (edição em real time de css, validação e outros), oferecidas num plugin de firefox. Instale aqui e aprenda sobre a ferramenta aqui.
Conclusões
Espero que as informações e dicas acima possam ajudar a todos os designers de interface no árduo caminho rumo à padronização total de todas as páginas e sites desenvolvidos. Fico no aguardo das opiniões de todos vocês.
Boa sorte! O (x)html/css como ferramenta, conceito e diferencial do designer de interfaces é o tema deste artigo, em sua segunda parte. Para um melhor entendimento, sugiro, antes de mais nada, uma atenta leitura à primeira parte.
Processo de produção do código
O processo, em si, é bastante claro e objetivo: cuidar da codificação, da estrutura do lay-out desejado, obtendo, assim, um melhor resultado, carregamento rápido, amplificando os conceitos de usabilidade e acessibilidade por meio de boas e salutares técnicas.
Sendo assim, nada poderá dar errado, não é?Analisando os "gargalos" da produção
O processo rotineiro de um estúdio ou agência web inclui verbas mínimas, grandes exigências e pouca tolerância (por boa parte dos clientes) e prazos impossíveis. Não há como fugir: ou se entra em tal lógica tortuosa de cabeça, ou colhe-se as consequencias desagradáveis da falta de adaptação, que incluem o "sumiço" dos freelas e o desemprego pertinente.
Conheça, agora, os maiores "gargalos produtivos", e as melhores maneiras de evitá-los:1) Propostas infactíveis:
Tais propostas são oferecidas / desenvolvidas por profissionais de criação completamente desambientados do processo de estruturação de páginas. É certo que a criatividade precisa de espaço para "voar", porém um mínimo de "pé-no-chão" é mais do que necessário. É preciso conhecer o processo produtivo como um todo (mesmo que certas etapas não façam parte de sua rotina profissional), a fim de não propor soluções "impossíveis", que podem ser belas e competentes em termos de design, porém completamente descabidas no momento de estruturar tal conteúdo.Portanto, se a idéia e o briefing levam para o desenvolvimento em (x)html/css (com textos em formato "nativo", portanto), de nada adianta desenvolver um lay-out que, na melhor das hipóteses, só será factível em flash.
O profissional que faz design web, ao conhecer efetivamente a estruturação, poderá situar-se melhor, evitando grandes "mancadas", como apresentar e aprovar determinada proposta ao cliente impossível de ser "produzida".2) Códigos sujos:
Herança indefectível do uso "preguiçoso" de editores WSWYG, códigos sujos, não-semânticos, inadequados às web standards, estão espalhados por diversos sites, nos mais variados "níveis" de produtores. O maior problema, aqui, está na manutenção de tal código. Normalmente, sites com códigos de tal "qualidade" nascem do descuido e descaso de diversos "profissionais" completamente reativos, sem qualquer preocupação com a necessidade de edição posterior. Ao agirem assim, ignoram a máxima: "o cliente vai mudar de idéia", além de "esquecerem" que sites web são mutantes, mudam drasticamente (visualmente, conceitualmente).A solução, novamente, recai sobre a necessidade de aprender, de fato, estruturação. Assim, com conhecimentos, visão e responsabilidade, todo e qualquer código torna-se limpo, editável e expansível.
3) Falta de integração:
Por mais óbvio que seja, existem designers que simplesmente relutam na hora de conversar com os estruturadores e programadores envolvidos no mesmo projeto, resultando num grande obstáculo à integração de soluções produtivas adotadas. Ninguém está numa ilha, o sucesso de um projeto web está diretamente ligado à integração de uma equipe, capaz de trabalhar e pensar coletivamente.4) Produção desestruturada:
O maior problema, aqui, é a repetição da produção de códigos quase idênticos, somente por estarem em projetos distintos, o que, certamente, custará tempo precioso.Que tal usar módulos produtivos? Existem diversos blocos de código e muitas soluções produtivas de estruturação que normalmente se repetem, de projeto em projeto. Assim, diversas tarefas ficam mais fáceis, pois já partem de um conjunto de códigos pré-definidos, bastando a adaptação dos mesmo para que o projeto avance. Exemplos de tal idéia: códigos para separação em colunas de uma página, de menus de links, de formulários e diversos outros.
Soluções possíveis
Há uma série de ações que podem (e devem) ser adotadas pelo designer que faz web, melhorando significamente a performance em tal meio e evitando a calvície precoce (advinda do constante "arrancar" de cabelos). Sugiro, aqui, algumas idéias que podem melhorar a vida profissional:
1) Vivencie a estruturação:
Perca o medo e o receio. Mergulhe de cabeça! Experimente adotar as web standards em seus projetos, acompanhe sites desenvolvidos com padrões (como o w3csites, por exemplo) e veja as poderosas possibilidades em ação. Ao acompanhar os mais "experientes" em ação, certamente a empolgação em mergulhar fundo aumentará consideravelmente.2) Expanda seus conhecimentos:
O melhor meio para aumentar suas habilidades é o estudo. Juntamente com a pesquisa, irá possibilitar um aumento significativo da percepção profissional, em qualquer nível em que esteja. Confira algumas dicas comentadas, de sites e livros:a) W3C - Documentação traduzida: boa parte dos mais importantes documentos contendo as definições do (x)html, css, web standards e acessibilidade. Grandes colaboradores brasileiros resolveram desenvolver, gratuitamente, suas traduções, visando à expansão das web standards em terras nacionais. Faça sua parte e estude os documentos traduzidos, fazendo com que tal esforço não seja em vão.
b) Maujor: Maurício Samy Silva (Maujor) é um respeitável senhor de cabelos brancos e uma invejável bagagem em web standards no Brasil, sendo, praticamente, o oráculo de tal tema. Quando se interessou por padrões web, o tema era praticamente desconhecido no país (e não havia os milhares de sites e blogs escrevendo - ou tomando carona - sobre o tema). Portanto, trata-se do pioneiro dos padrões no Brasil, sendo que seu site possui muitas informações preciosas para estudandes e profissionais da área. Visite o site, aproveite e passe pelo blog.
c) CSS Zen Garden: conheça uma brilhante galeria de sites desenvolvidos somente com (x)html/css e veja do que esta linguagem é capaz, desde que utilizada sabiamente. O site oferece um conjunto de documentos para que qualquer pessoa se aventure na construção de um novo layout, inteiramente baseado em css, sendo que os melhores são publicados. Visite. Conheça a versão em português.
d) Livro do Maujor: o livro "Construindo Sites com CSS e (X)HTML" é o melhor livro publicado até então no Brasil. Com didática séria, dinâmica e inteligente, Mauricio Samy Silva conduz o estudante pelos caminhos do desenvolvimento com css, dando base sólida e conhecimento de verdade. Visite o site do livro.
e) CSS interativo: conheça este serviço oferecido pelo iMasters, com desenvolvimento de Mauricio Samy Silva e experimente, interativamente, todos os recursos do css. Visite!
f) W3C validator (css e xhtml): verifique seu código a fim de procurar erros e correções. Com esta ferramenta oferecida pelo W3C, você poderá verificar seus códigos por uploads (ou seja, poderá verificar antes de publicar), páginas hospedadas e conferir a relação de erros e sugestões "robóticas" para correções. Conheça a ferramenta e adicione aos seus favoritos! Você também pode instalar plugins de firefox para validação diretamente no browser como o tidy, por exemplo, e verificar seus códigos.
g) Web Developer: conjunto de ferramentas para desenvolvedores (edição em real time de css, validação e outros), oferecidas num plugin de firefox. Instale aqui e aprenda sobre a ferramenta aqui.
Conclusões
Espero que as informações e dicas acima possam ajudar a todos os designers de interface no árduo caminho rumo à padronização total de todas as páginas e sites desenvolvidos. Fico no aguardo das opiniões de todos vocês.
Boa sorte!