Contactos
+351 911 946 965ola@avitamina.ptR. Bernardo Sequeira, 4.4710-358
Braga Portugal
Obter direçõesdesafie-nosBraga Portugal
A Lea Verou é investigadora no MIT CSAIL (Laboratório de Ciência da Computação e Inteligência Artificial) e é também, desde 2012, perita convidada no grupo de trabalho de CSS da W3C, que é o comité que cria e estende a linguagem de CSS.
No segundo dia de palestras da edição de 2018 da Mirror Conf, assistimos a uma das palestras da Lea Verou, “Even More CSS Secrets” (Ainda mais segredos de CSS). Esta é a terceira numa série de palestras que a Lea Verou tem vindo a fazer com grande sucesso, começando em 2011 com “CSS3 Secrets” (Segredos do CSS3) e em 2012/2013 com “More CSS Secrets” (Mais segredos de CSS), em que a premissa é simples: Programando ao vivo, Lea mostra-nos 10 particularidades do CSS que poderão não ser amplamente difundidas e que permitem ampliar o leque de ferramentas de quem cria estilos na web.
Esta série teve tanto sucesso que levou à publicação do livro CSS Secrets, e a mais de 100 palestras por todo o mundo.
Nesta palestra Lea mostrou-nos segredos de CSS relativamente aos seguintes assuntos:
Através da propriedade “mix-blend-mode” ao utilizarmos texto branco sobre fundo preto, sobrepostos a uma imagem de fundo, conseguimos o seguinte efeito:
Imagem de fundo: marius badstuber / https://unsplash.com/photos/jrly8X7VfAc
Este efeito funciona devido a um modo de mistura chamado “multiply” ( Um termo que os utilizadores de Photoshop devem reconhecer) e em que a cor mais escura é multiplicada pela cor mais clara, e no caso do branco, a cor de fundo fica sempre visível a 100% (uma vez que X * 100% = X).
Infelizmente, apenas funciona com esta combinação de cores (branco sobre preto).
No entanto, se usarmos o modo “screen” no parâmetro “mix-blend-mode”, podemos obter o mesmo efeito com texto preto sobre fundo branco:
Imagem de fundo: marius badstuber / https://unsplash.com/photos/jrly8X7VfAc
Estes modos são actualmente suportados pelos navegadores de cerca de 85% dos utilizadores.
2. Imagens como caracteres
Neste exemplo, aprendemos como podemos usar elementos SVG (com data-uri) como imagens de fundo em css, e uma vez que em SVG podemos usar texto, podemos inclusivamente usar emoji:
Podemos até animar os elementos através das propriedades de animação de keyframes em CSS.
Outro exemplo que a Lea Verou nos mostra é como utilizar esta propriedade para criar elementos de avaliações, combinando este truque com a tag <meter> de HTML.
3. Bordas com mais estilos
Ainda recorrendo a data-uri e SVG, Lea mostra-nos como podemos melhorar estilos e até animar bordas.
Com CSS simples, é praticamente impossível criar bordas animadas, ou mesmo com gradientes lineares, mas com SVG isso é possível.
Ao não atribuirmos definição ViewBox ao SVG, este vai assumir as dimensões do elemento em que é chamado, criando o efeito que pretendemos:
(inserir isto em html):
<style type="text-css">
.animated-borders {
background: url('data:image/svg+xml,\
<svg xmlns="http://www.w3.org/2000/svg">\
<style>@keyframes animated-border {to {stroke-dashoffset: -15;}}</style>\
<rect width="100%" height="100%" style="stroke: black; stroke-width: 4px; fill: none;\
stroke-dasharray: 10px 5px; animation:animated-border 1s infinite linear;" />\
</svg>');
background-repeat: no-repeat;
width: 50%;
margin: 50px;
padding: 20px 50px;
font-family: Arial, Helvetica, sans-serif;
font-size: 8em;
font-weight: bold;
}
</style>
<div class="animated-borders">
Bordas animadas
</div>
Podemos ainda atribuir estilos como gradientes, por exemplo, e animar da mesma forma:
(inserir isto em html):
<style type="text-css">
.animated-borders-b {
background: url('data:image/svg+xml,\
<svg xmlns="http://www.w3.org/2000/svg">\
<style>@keyframes animated-border {to {stroke-dashoffset: -50;}}</style>\
<linearGradient id="lingrad" gradientTransform="rotate(45)">\
<stop stop-color="gold"></stop>\
<stop stop-color="red" offset="1"></stop>\
</linearGradient>\
<rect width="100%" height="100%" style="stroke :url(#lingrad); stroke-dasharray: 40px 10px; stroke-width:40px; fill:none;animation:animated-border 0.5s infinite linear;" />\
</svg>');
background-repeat: no-repeat;
width: 50%;
margin: 50px;
padding: 20px 50px;
font-family: Arial, Helvetica, sans-serif;
font-size: 8em;
font-weight: bold;
}
</style>
<div class="animated-borders">
Bordas animadas
</div>
4. Cabeçalhos com Linhas dinâmicas
Utilizando as propriedades do flexbox e os pseudoelementos “::before” e “::after”, podemos obter linhas de cabeçalho dinâmicas que se ajustam automaticamente ao conteúdo, como podemos ver no seguinte exemplo:
Estes elementos irão preencher os espaços antes e depois do texto, enquanto a largura deste for inferior à largura do ecrã.
5. Menus CSS Acessíveis
Quando se criam menus exclusivamente em css, é impossível utilizar submenus e mantê-los facilmente acessíveis a utilizadores que usem apenas o teclado para navegar. O comportamento normal faz com que a pressionar a tecla TAB o foco do item do menu seja passado entre os elementos de primeiro nível, sem dar hipótese de sequer abrir o submenu.
No entanto, se recorrermos à propriedade “::focus-within”, esta permite-nos selecionar os submenus correspondentes com a tecla TAB, e passar para o próximo menu e subsequentes submenus em sequência.
6. Fontes variáveis para largura de linha não variável
Fontes variáveis são um formato de tipografia anunciado em Setembro de 2016 em que, ao invés do método corrente em que, por exemplo, para cada peso uma fonte necessita um ficheiro com a especificação correspondente, o mesmo ficheiro permite ter as variações todas que lhe estejam disponíveis (não só o peso, mas altura da fonte, serifas, entre outros).
A Lea mostra-nos como podemos, num caso em que tenhamos várias linhas com um número diferente de caracteres, alternar tamanhos de fonte, mantendo o peso das mesmas, recorrendo às fonte variáveis, uma vez que estas não estão limitadas aos pesos pré-definidos por cada ficheiro da fonte, mas sim por um valor mínimo e máximo, e todos os valores entre eles estão disponíveis.
7. Flexbox Responsiva
Com este truque, conseguimos uma forma de utilizar elementos flexbox para obter responsividade nos elementos, sem ter que recorrer a “media queries” para determinar o tamanho do ecrã.
8. Grid Auto Flow
Neste truque, a Lea recorreu ao CSS Grid (grelha) para dinamicamente, através das classes de CSS, reordenar e reorganizar elementos dispostos numa grelha.
Aqui vemos organizado tipo de desporto:
.sports {
display:grid;
grid-template-columns: 1fr 1fr;
grid-gap:5px;
grid-auto-flow:column;
}
.football {
grid-column:2;
}
.f1 {
grid-column:1;
}
Reorganizando por País / Equipa:
.sports {
display:grid;
grid-template-columns: 1fr 1fr;
grid-gap:5px;
grid-auto-flow:column;
}
.country {
grid-column:2;
}
.team {
grid-column:1;
}
9. Gráficos Circulares
Recorrendo à propriedade de gradiente cónico (“conic-gradient()”), a Lea mostrou como se podem criar gráficos circulares.
Um gradiente cónico funciona de forma semelhante a um gradiente linear, tendo em conta que os valores para cada cor não são cumulativos (em relação à cor anterior) mas sim absolutos, e que a última cor do gradiente deverá sempre ter um valor inferior ao da cor anterior.
.grafico {
background: conic-gradient(
#10069F 0% 30%, #3300ff 0% 60%, #7a7cc5 0% 75% , #c7caf1 0%
);
}
A única ressalva neste truque é que de momento, apenas o Google Chrome suporta esta propriedade.
10. Items de grelha descendentes
Neste truque final, a Lea fala-nos da nova propriedade de “display”, “contents”.
Esta é uma propriedade que permite, aos elementos ao qual está atribuída, ignorar a propagação descendente de estilos de grelha.
Portanto, num caso em que tenhamos por exemplo uma grelha com elementos de input inseridos numa etiqueta:
<form>
<label>Nome de Utilizador: <input name="username"></label>
<label>Senha: <input name="password"></label>
</form>
Ao aplicarmos “display:contents” a essa etiqueta, as propriedades da grelha atribuídas ao formulário não passam para os elementos de etiqueta, e aos inputs correspondentes.
O Bruno explica como simples se torna complexo e 5 passos se tornam rapidamente em 30.
O processo por detrás da construção de um website pode ser normalmente dividido em 5 passos simples – que frequentemente se mostram bastante complexos.
VER TAMBÉM: A IMPORTÂNCIA DE PENSAR RESPONSIVE NO MARKETING DIGITAL
Esta premissa é algo que pode parecer assustador, mas é no fundo um conceito que se for tido em conta desde o início, não só se poder tornar fácil de ultrapassar, como eventualmente até ajuda na optimização de tarefas para os projectos que daí advêm.
Podemos dividir as fases do projecto em arcos gerais com etapas bem definidas, as quais obedecem a determinadas regras que se forem cumpridas, evitam cair numa espiral dantesca de má preparação e noites mal dormidas. Estas fases poderão ser divididas em:
O briefing é a fase inicial do projecto na qual o cliente nos diz aquilo que pretende. Pode ser feito em reunião física, em videochamada ou até através de uma troca de e-mails.
Esta é a fase em que ainda não se começa efectivamente a trabalhar no projecto, mas em que se tenta perceber qual o seu futuro e de se como deverá desenvolver. Nesta fase, (e como estou a falar especificamente de desenvolvimento de websites) os pontos importantes a reter da informação que o cliente passa, são:
Digamos que esta é a fase de pôr os pontos nos “i” (sim, habitualmente só se faz quando as coisas correm mal, mas o que queremos é evitar que isso aconteça), para estabelecer as bases de arranque e começar a delinear o passo seguinte.
Nesta fase, após termos recolhido toda a informação possível no briefing, devemos ponderar bem e avaliar a quantidade de tempo que este vai requerer à equipa, tanto em horas como em energia.
Esta fase é importante por dois motivos:
Esta é a fase em que o projecto verdadeiramente arranca, no sentido de “pôr as mãos na massa”.
Pode ser feita de forma simples, desenvolvendo a arquitectura do projecto (saber que página fica em que secção do menu, ou que campos tem este tipo de conteúdo) sem qualquer guia visual que indique o aspecto final do website, ou então desenvolvido em conjunto com a parte visual do projecto, na qual o Designer desenvolve a identidade visual do site em conjunto com a arquitectura do site, com ou sem input directo do Developer, dependendo da complexidade do projecto.
Esta é a fase que pode variar mais na execução de qualquer projecto – Uma landing page à partida tem um grupo de interações e regras fundamentais muito reduzidas e bem definidas, pelo que o design e a arquitectura da mesma podem ser rapidamente desenvolvidas pelo designer, sem a necessidade de grande input do Developer que irá pegar no projecto e tratar da fase seguinte. Já um projecto mais complexo, como uma loja online ou uma web app deve ser cuidadosamente definida com layouts específicos, e todas as interações e usos de caso devem ser estudados para que a fase de desenvolvimento seja o mais fluída e unidirecional possível.
Está na hora de dar vida ao projecto e é neste momento que se começa de facto a transformar um projecto num produto final. Apesar de ser normalmente a fase em que é gasta a maior parte das horas alocadas a um projecto, é também, de certa forma, a mais simples de descrever – É aplicar um código por trás de um design e finalmente colocar o projecto a funcionar.
Raramente, ou até praticamente nunca, um projecto fica perfeito à primeira tentativa.
É preciso testar várias vezes para garantir que tudo funciona da forma esperada e que todas as variáveis definidas estão a ser tidas em conta – se todos os botões funcionam como é suposto, se tudo aparece como está definido em desktop, tablet e smartphone, e depois de testar tudo e de corrigir tudo o que não esteja correcto, voltar a testar e (re)testar para ter a certeza que nenhuma das correcções afectou de forma negativa o projecto.
É também das fases mais difíceis de executar na perfeição. Várias situações afectam o nosso discernimento na altura dos testes – familiaridade com o projecto, cansaço visual devido à quantidade de horas gastas (“sempre a ver a mesma página”), ou simplesmente pequenos vícios que adquirimos na nossa forma de utilizar a web que muitos utilizadores não têm e que dessa forma, influenciam a forma como os a interação com o produto final é feita.
Infelizmente a melhor forma de evitar isto é fazer passar o produto pelo maior número de mãos possível, estendendo a base de testers e criando uma certa redundância na altura de apanhar bugs ou pequenos erros com que aprendemos a conviver e até nos esquecemos nas fases anteriores.
VER TAMBÉM: A IMPORTÂNCIA DE PENSAR RESPONSIVE NO MARKETING DIGITAL
Concluindo, todas estas fases têm a sua importância no produto final, e nenhuma delas deve ser descurada pois pode afectar negativamente as fases seguintes e até mesmo a conclusão do projecto. E se algumas vezes esse efeito pode ser mínimo, em outras alturas pode ser catastrófico. Por isso, o ideal é nunca avançar para a fase seguinte sem ter a certeza de que tudo o que deve ser feito na fase anterior foi cumprido.
