Less.js: Não é possível criar raio de borda elíptico

Criado em 18 nov. 2010  ·  28Comentários  ·  Fonte: less/less.js

Com a especificação CSS3 revisada, é possível criar um raio de borda elíptico com a seguinte sintaxe:
-webkit-border-radius: 40px / 10px;
-moz-border-radius: 40px / 10px;
raio da borda: 40px / 10px;

Mas menos analisa isso e calcula 40/10, então na verdade torna-se 5, assim:
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
raio da borda: 5px;

Deve haver uma maneira de escrever essa sintaxe sem menos analisá-la.

bug medium priority

Comentários muito úteis

Desculpe, essa é a única maneira de corrigir isso .. ou ative a matemática estrita para que toda a matemática seja feita apenas se estiver entre parênteses OU

border-radius:0 0 100% 100% ~"/" 0 0 24px 24px;

Todos 28 comentários

Eu queria adicionar um problema semelhante / relacionado que acontece com a propriedade font ao declarar uma altura de linha

.class {
    font: 13px/1.231 arial, helvetica, clean, sans-serif;
} 

deve permanecer inalterado, mas se torna:
.aula {
fonte: 10.560519902518276px arial, helvetica, clean, sans-serif;
}

dotless também tem esse problema (https://github.com/dotless/dotless/issues/16). Seria bom chegar a um acordo sobre como proceder em ambos.

A solução mais simples que funciona fora da caixa hoje é envolvê-lo em uma string literal.

 font: ~"13px/1.231 arial, helvetica, clean, sans-serif";

ou mesmo

 font: ~"13px/1.231" arial, helvetica, clean, sans-serif;

Eu entendi que um dos objetivos do less era ser compatível com a sintaxe CSS normal. A solução alternativa quebra essa regra.

Eu entendo sua frustração. Não consigo ver uma solução fácil entre a aritmética de Less e as propriedades CSS específicas. Por exemplo, e se você realmente quiser especificar que a fonte tem metade do tamanho, ou seja,

 <strong i="6">@example</strong>: 24pt;
 .foo {
     font: normal @example/2 sans-serif;
 }

Algo precisa se comprometer. É certo que você pode alterar Less para que todas as conversões sejam agrupadas.

 font: normal (@example/2) sans-serif;

mas isso quebraria e tornaria mais prolixo qualquer folha de estilo Less existente para todos os casos, apenas para evitar casos que não são tão comuns para declarações abreviadas de fonte e raio de borda. Outra opção se você estiver preocupado com o CSS existente, você pode importar qualquer CSS existente para o seu arquivo Less:

 <strong i="13">@import</strong> "legacy.css";

Nesse caso, a importação é bem-sucedida, mas não altera ou converte o CSS.

Mais uma vez, entendo perfeitamente sua preocupação de que Less não seja um superconjunto estrito de CSS, mas não tenho ideias obviamente melhores. Você tem alguma solução potencial para este problema de sintaxe?

: +1: sobre este problema, mas também não tenho certeza de uma maneira elegante de resolvê-lo que não exija o escape de CSS válido ou a exigência de parênteses para acionar os cálculos.

@agatronic @cloudhead Estou trabalhando em uma correção para isso, mas gostaria de receber sua opinião sobre como você acha que isso deve ser tratado antes de prosseguir. SASS e Stylus lidam com isso permitindo apenas a divisão entre parênteses, todas as outras operações matemáticas podem ser feitas fora dos parênteses. Este método evitará que quaisquer implementações futuras da barra pelo W3C sejam quebradas e removerá a necessidade dos analisadores Ratio e Shorthand. Foi assim que comecei a resolver o problema. Esta é uma solução razoável para vocês dois?

Observe que este bug também quebra o atalho de fundo CSS3, que usa a barra para separar a posição do fundo (que podem ser palavras-chave ou dimensões) do tamanho do fundo. Por exemplo:

.foo {
    background: url(image.png) center / 1px 100px;
}

Também pingando @matthewdl @Synchro

Uma sugestão anterior era que '/' divide e '/' é uma razão. Seria bom obter informações de @cloudhead porque, embora fosse muito bom ser classificado, é muito assustador se isso quebrar o comportamento existente ...

@cloudhead respondeu via twitter, um tanto minimamente: "a solução dos parênteses parece decente"

O problema com a solução de espaços é que ainda quebra o CSS perfeitamente válido. Infelizmente, a única maneira de resolver isso de forma eficaz sem quebrar o comportamento existente é continuar a permitir que o CSS antigo falhe na análise correta.

que tal uma opção "temporária" para que as pessoas possam desfrutar de ambos por um período de carência?

ou

devemos fazer um lançamento antes de mesclar essa correção e subir um número de versão principal para 1.4 (e, com sorte, adicionar variáveis ​​em includes e interpolação de nomes de propriedades etc.

Acho que isso definitivamente seria uma correção que teria que ser parte de uma versão mais importante, já que quebraria o comportamento existente. Não tenho certeza se uma solução temporária (se estamos falando de espaços) é mesmo razoável, considerando que ela ainda pode quebrar o código existente e não fornece nenhum tipo de transição limpa para a solução permanente. Esta parece ser uma situação em que puxar o gatilho de uma versão é a melhor opção e as pessoas podem ser avisadas por meio do Registro de alterações e do Documentos.

Eu quis dizer sinalizar para manter o comportamento existente ... mas concordo com você.

Você tem direitos de commit? Mesmo que seja melhor como uma solicitação pull, nós
pode coordenar com lançamentos (não temos planos que eu conheça)

Pessoalmente, acho que devemos engolir a pílula e começar a listar as operações matemáticas sem parênteses como um recurso obsoleto. Existem muitos casos em que ele entra em conflito com CSS válido. @agatronic - Vale a pena uma discussão no Skype com @cloudhead (ou em outro lugar), e odeio arruinar MENOS bibliotecas de ninguém, mas MENOS não deveria estar rasgando e quebrando CSS que o autor não pretendia. O analisador LESS deve receber sinais claros de que uma operação matemática é necessária, e os parênteses são uma boa maneira de fazer isso. Entre parênteses: DO MATH. Não entre parênteses: DEIXE EM PAZ.

Como fase 1 para diminuir o golpe, poderíamos PARAR de fazer matemática SOMENTE nos casos em que a divisão for ambígua, por exemplo, em lugares onde uma barra "/" é um token válido nesse valor. Então, no caso do raio da borda, se LESS não tiver certeza, ele deixa como está. Se o autor tiver certeza de que deseja a divisão entre os dois números, ele pode substituir o comportamento padrão adicionando parênteses.

Mas, da forma como está agora, LESS está documentado como "CSS válido = LESS válido" e, com esse bug, esse não é o caso. Ele está reescrevendo falsamente o CSS válido, o que o torna um bug claro. O problema é que TAMBÉM é uma operação matemática claramente documentada. Os dois estão em conflito, e me parece claro que o segundo caso é aquele que deve ser alterado, com o CSS preservado.

Vejo que @ttfkam e @ mlms13 disseram quase a mesma coisa. Eu acho que o instinto deles está correto, e eu votaria fortemente que LESS comece uma migração lenta para parênteses como um requisito para as operações.

@matthewdl +1

@agatronic : Não tenho direitos de commit, no entanto, concordo que isso deve ser feito por meio de um PR de qualquer maneira para revisão do código e coordenação de liberação potencial.

@matthewdl : Para fins de minhas relações públicas, comecei a trabalhar permitindo apenas a divisão entre parênteses. Considere isso uma medida temporária para evitar que o LESS viole o CSS válido. Não se limita a regras específicas, portanto, em qualquer lugar que uma barra seja encontrada e não esteja entre parênteses, ela será gerada como um dilimitador literal. Depois de fazer isso, verificarei um pouco mais como restringir todas as operações para serem feitas apenas dentro dos parênteses.

Ok, já discuti isso com @cloudhead no Skype. Ele está de acordo, então aqui está o plano:

1) Na próxima versão, a documentação será atualizada de que a matemática fora dos parênteses está obsoleta. A documentação demonstrará as operações matemáticas entre parênteses. No entanto, a matemática sem divisão fora dos parênteses ainda deve ser compilada (para essa versão).

2) Na versão subsequente após a etapa 1, TODAS as operações matemáticas exigirão parênteses. A documentação mudará de "obsoleta" para "não suportada" (ou algo parecido - como comunicamos pode ser refinado).

Parece bom? Isso significa que devemos começar a planejar quais são os marcos para os próximos 2 lançamentos, mas isso está fora do escopo deste tópico aqui.

Na verdade, para esclarecer, a documentação pode ser atualizada AGORA para dizer que a matemática fora dos parênteses está obsoleta, uma vez que a matemática entre parênteses funciona bem. Portanto, essa é realmente a Etapa 0: atualizamos os documentos agora para dizer às pessoas a) A matemática deve estar entre parênteses, e não fazer isso pode quebrar no futuro, b) Demonstrar toda a matemática entre parênteses.

Funciona para mim! : +1:

então, presumivelmente, @dmcass deve fazer uma solicitação de pull contra
https://github.com/cloudhead/lesscss.org

e então devemos insistir com o

Oh, certo. Sim, vou tentar me lembrar de incomodá-lo hoje.

Em 21/08/2012, às 5h19, Luke Page [email protected] escreveu:

então, presumivelmente, @dmcass https://github.com/dmcass deve fazer uma solicitação de pull
contra
https://github.com/cloudhead/lesscss.org

e então devemos insistir com https://github.com/cloudhead para
comprometer ou nos dar direitos de comprometimento para esse projeto?

-
Responda a este e-mail diretamente ou visualize-o no
Gi tHubhttps: //github.com/cloudhead/less.js/issues/146#issuecomment -7899194.

Abri um PR para atualizar os documentos em cloudhead / lesscss.org # 29

Fixo no mestre para 1.4.0

Será assim em 1.4.0

Confira o alpha em less2css.org

Este bug ainda ocorre em 1.4.1 se você usar o seguinte CSS:
border- radius: 0 0 100% 100% / 0 0 24px 24px;

Ele produz:
border-radius: 0 0 100% Infinity% 0 24px 24px;

(Eu tentei em http://less2css.org)

@rubious , você

OK, isso funciona, no entanto estou usando o LiveReload e essa opção não parece estar ativada aqui.

Desculpe, essa é a única maneira de corrigir isso .. ou ative a matemática estrita para que toda a matemática seja feita apenas se estiver entre parênteses OU

border-radius:0 0 100% 100% ~"/" 0 0 24px 24px;
Esta página foi útil?
0 / 5 - 0 avaliações