O Grupo de Trabalho CSS no TPAC: O que há de novo em CSS?

Na semana passada, participei do W3C TPAC, bem como da reunião do CSS Working Group. Várias mudanças foram feitas nas especificações, e houve discussões que considero de interesse para web designers e desenvolvedores. Neste artigo, explicarei um pouco sobre o que acontece no TPAC e mostrarei alguns exemplos e demonstrações das coisas que discutimos no TPAC para CSS em particular.

O que é TPAC?

A TPAC é a Semana de Reuniões do Plenário Técnico / Advisory Committee do W3C. Uma chance para todos os vários grupos de trabalho que fazem parte do W3C se reunirem sob o mesmo teto. O evento acontece em uma parte diferente do mundo a cada ano, este ano foi realizado em Lyon, na França. No TPAC, Grupos de Trabalho como o CSS Working Group têm suas próprias reuniões, assim como fazemos em outras épocas do ano. No entanto, como estamos todos em um prédio, isso significa que pessoas de outros grupos podem vir mais facilmente como observadores, e os interesses dos grupos de trabalho cruzado podem ser discutidos.

Os participantes do TPAC normalmente são membros de um ou mais Grupos de Trabalho, trabalhando em tecnologias W3C. Eles serão representantes de uma organização membro ou especialistas convidados. Como em qualquer outra reunião dos Grupos de Trabalho do W3C, as atas de todas as discussões realizadas no TPAC estarão disponíveis abertamente, geralmente como logs de IRC escritos durante as reuniões.

O Grupo de Trabalho CSS

O Grupo de Trabalho do CSS se reúne pessoalmente no TPAC e em pelo menos duas outras ocasiões durante o ano; isso é um acréscimo aos nossos telefonemas semanais. Em todas as nossas reuniões, as várias questões levantadas sobre as especificações são discutidas e as decisões tomadas. Algumas questões são mantidas para discussões cara a cara devido aos benefícios de poder tê-las com todo o grupo, ou apenas poder contornar um quadro branco ou ver uma demonstração na tela.

Quando um problema é discutido em qualquer reunião (presencial ou por teleconferência), o problema relevante do GitHub é atualizado com as atas da discussão. Isso significa que, se você tiver um problema que deseja acompanhar, poderá marcá-lo com uma estrela e ver quando ele for atualizado. As atas completas do IRC também são postadas na lista de discussão em estilo www.

Aqui está uma seleção das coisas que discutimos que acho que serão de maior interesse para você.

Barras de rolagem CSS

A especificação CSS Scrollbars procura fornecer uma maneira padrão de estilizar o tamanho e a cor das barras de rolagem. Se você tiver o Firefox Nightly, poderá testá-lo. Para ver os exemplos abaixo, use o Firefox Nightly e ative os sinalizadores layout.css.scrollbar-width.enabled e layout.css.scrollbar-color.enabled visitando https://about:config no Firefox Nightly.

A especificação nos dá duas novas propriedades: scrollbar-width e scrollbar-color . A propriedade scrollbar-width pode ter um valor de auto , thin , none ou length (como 1em ). Parece que o valor do length pode ser removido da especificação. Como você pode imaginar, seria possível para um desenvolvedor da web criar uma barra de rolagem muito inutilizável brincando com a largura, então pode ser melhor permitir que o navegador decida a largura exata que faz sentido, mas, em vez disso, mostre fina ou grossa barras de rolagem. O Firefox não implementou a opção de comprimento.

Se você usar auto como o valor, o navegador usará as barras de rolagem padrão: thin fornecerá uma barra de rolagem fina e none não mostrará nenhuma barra de rolagem visível (mas o elemento ainda será rolável).

Em um navegador com suporte para barras de rolagem CSS, você pode ver isso em ação na demonstração:

A propriedade scrollbar-color lida com — como seria de esperar — cores da barra de rolagem. Uma barra de rolagem tem duas partes que você pode querer colorir independentemente:

• dedão
  O controle deslizante que se move para cima e para baixo à medida que você rola.
• acompanhar
  O fundo da barra de rolagem.

Os valores para a propriedade scrollbar-color são auto , dark , light e <color> <color> .

Usar auto como um valor de palavra-chave fornecerá as cores padrão da barra de rolagem para esse navegador, o dark fornecerá uma barra de rolagem escura, seja no modo escuro dessa plataforma ou em um modo escuro personalizado, light o modo claro da plataforma ou um modo de luz personalizado .

Para definir suas próprias cores, adicione duas cores como valor separadas por um espaço. A primeira cor será usada para o polegar e a segunda para a faixa . Você deve tomar cuidado para que haja contraste suficiente entre as cores, caso contrário, a barra de rolagem pode ser difícil de usar para algumas pessoas.

Em um navegador com suporte para barras de rolagem CSS, você pode ver isso na demonstração:

Unidades de proporção

Estamos usando o padding hack em CSS há algum tempo para obter caixas de proporção, no entanto, com o advento do Grid Layout e melhores formas de dimensionar o conteúdo, ter uma maneira real de fazer proporções em CSS tornou-se uma necessidade mais premente .

Há dois problemas levantados no GitHub relacionados a esse requisito:

• Unidades de proporção de aspecto necessárias
• Proporção da tela.

Há agora uma especificação preliminar no Nível 4 de dimensionamento de CSS, e a decisão da reunião foi que isso precisava de mais discussão no GitHub antes que qualquer decisão pudesse ser tomada. Portanto, se você estiver interessado nisso ou tiver casos de uso adicionais, o CSS Working Group estaria interessado em seus comentários sobre essas questões.

A pseudoclasse funcional :where()

No ano passado, o CSSWG resolveu adicionar uma pseudo-classe que agia como :matches() , mas com especificidade zero, facilitando a substituição sem precisar inflar artificialmente a especificidade de elementos posteriores para substituir algo em uma folha de estilo padrão.

A pseudo-classe :matches() pode ser nova para você, pois é um seletor de nível 4, no entanto, ela permite que você especifique um grupo de seletores para aplicar algum CSS. Por exemplo, você poderia escrever:

 .foo a:hover, pa:hover { color: green; }

Ou com :matches()

 :matches(.foo, p) a:hover { color: green; }

Se você já teve uma grande pilha de seletores apenas para definir as mesmas regras, verá como isso será útil. O CodePen a seguir usa os nomes prefixados de webkit-any e -moz-any para demonstrar a funcionalidade matches() . Você também pode ler mais sobre matches() no MDN.

Onde geralmente fazemos esse tipo de empilhamento de seletores e, portanto, onde :matches() será mais útil é em algum tipo de folha de estilo inicial padrão. No entanto, precisamos ter cuidado ao substituir esses padrões para que qualquer substituição seja feita de uma maneira que garanta que seja mais específico do que os padrões. É por esta razão que uma versão de especificidade zero foi proposta.

A questão que foi discutida na reunião foi em relação à nomeação desta pseudo-classe, você pode ver a resolução final aqui, e se você se pergunta por que vários nomes foram descartados, dê uma olhada no tópico completo. Nomear as coisas em CSS é muito difícil — porque todos nós vamos ter que conviver com isso para sempre! Depois de muito debate, o grupo votou e decidiu chamar este seletor de :where() .

Desde a reunião, e enquanto eu escrevia este post, surgiu uma sugestão para renomear matches() para is() . Dê uma olhada na questão e comente se você tem algum sentimento forte de qualquer maneira!

Abreviações lógicas para margens e preenchimento

Sobre o assunto de nomear as coisas, eu escrevi sobre Propriedades e Valores Lógicos aqui na Smashing Magazine no passado, dê uma olhada em “Entendendo Propriedades e Valores Lógicos”. Essas propriedades e valores fornecem mapeamentos relativos ao fluxo. Isso significa que, se você estiver usando modos de escrita diferentes do modo de escrita horizontal de cima para baixo, como o inglês, itens como margens e preenchimento, larguras e altura seguem a direção do texto e não estão vinculados às dimensões físicas da tela.

Por exemplo, para margens físicas temos:

• margin-top
• margin-right
• margin-bottom
• margin-left

Os mapeamentos lógicos para estes (assumindo horizontal-tb) são:

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

Podemos ter dois atalhos de valor. Por exemplo, para definir margin-block-start e margin-block-end como um atalho, podemos usar margin-block: 20px 1em . O primeiro valor representa a aresta inicial na dimensão do bloco, o segundo valor a aresta final na dimensão do bloco.

Encontramos um problema, no entanto, quando chegamos à margin abreviada de quatro valores. Esse nome de propriedade é usado para margens físicas — como denotamos a versão lógica de quatro valores? Várias coisas foram sugeridas, incluindo uma opção na parte superior do arquivo:

 @mode "logical";

Ou, para usar um bloco que se parece um pouco com uma consulta de mídia:

 @mode (flow-mode: relative) { }

Em seguida, várias sugestões para modificadores de palavras-chave, usando algum caractere de pontuação ou criando um novo nome de propriedade:

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

Você pode ler a edição para ver as várias coisas que estão sendo consideradas. Os problemas discutidos foram que, embora a versão lógica possa acabar sendo geralmente o padrão, às vezes você desejará que as coisas se relacionem com a geometria da tela; precisamos ser capazes de ter ambas as opções em uma folha de estilo. Ter uma configuração @mode no topo do CSS pode ser confuso; falharia se alguém copiasse e colasse um pedaço da folha de estilo.

Minha preferência é ter algum tipo de valor de palavra-chave. Dessa forma, se você observar a regra, poderá ver exatamente qual modo está sendo usado, mesmo que pareça um pouco deselegante. É o tipo de coisa que um pré-processador pode resolver para você; se você realmente deseja que todas as suas propriedades e valores usem as versões lógicas.

Não conseguimos resolver o problema, portanto, se você tiver dúvidas sobre qual deles pode ser o melhor ou se encontrar problemas com eles que não descrevemos, comente sobre o problema no GitHub.

Discussão sobre testes de plataforma web

Na reunião do CSS Working Group e depois durante o Technical Plenary Day estilo não-conferência, eu estava envolvido na discussão de como envolver mais pessoas na escrita de testes para especificações CSS. O projeto Web Platform Tests visa fornecer testes para toda a plataforma web. Esses testes ajudam os fornecedores de navegadores a verificar se seus navegadores estão corretos quanto à especificação. No Grupo de Trabalho CSS, o objetivo é que qualquer mudança normativa em uma especificação que tenha alcançado o status de Recomendação Candidata (CR) seja acompanhada por um teste. Isso faz sentido, pois uma vez que uma especificação está em CR, pedimos aos navegadores que implementem essa especificação e forneçam feedback. Eles precisam saber se alguma coisa na especificação muda para que possam atualizar seu código.

O problema é que temos muito poucas pessoas escrevendo especificações, então para os escritores de especificações ter que escrever todos os testes irá diminuir o progresso do CSS. Adoraríamos ver outras pessoas escrevendo testes, pois é uma forma de contribuir com a plataforma web e obter um conhecimento profundo de como as especificações funcionam. Então nos encontramos para pensar em como poderíamos incentivar as pessoas a participar do esforço. Já escrevi sobre este assunto no passado; se a ideia de escrever testes para a plataforma lhe interessa, dê uma olhada no meu artigo 24 Ways sobre “Testing the Web Platform”.

Com O Trabalho!

O TPAC aumentou consideravelmente minha lista pessoal de tarefas. No entanto, consegui obter dicas sobre edição de especificações, redação de testes e elaborar um plano para obter a especificação de layout de várias colunas - da qual sou coeditor - de volta ao status CR. Como alguém que não é fã de reuniões, vi o quanto essas reuniões presenciais são valiosas para a plataforma web, dando a quem contribui com ela a chance de compartilhar o conhecimento que estamos desenvolvendo individualmente. No entanto, sinto que é importante levar esse conhecimento e compartilhá-lo fora do grupo para ajudar mais pessoas a se envolverem no desenvolvimento e no uso da plataforma.

Se você estiver interessado em como o CSS Working Group funciona e como o novo CSS é inventado e acaba nos navegadores, confira minha apresentação CSSConf.eu de 2017 “De onde vem o CSS?” e as informações de fantasai em seus posts “Uma visão interna do CSS Working Group no W3C”.