Less.js: A função calc () do CSS3 não funciona com LESS
Eu sei que já foi relatado, mas bugs foram fechados devido a informações insuficientes.
Eu tenho o seguinte código CSS:
#id1 {
position: fixed;
left: 0; top: 0;
width: 130px;
}
#id2 {
position: fixed;
right: 0; top: 0;
width: calc(100% - 130px);
}
Eu queria transformá-lo em LESS usando 130px como parâmetro, mas calc é internpretado por LESS e este:
<strong i="11">@id1width</strong>: 130px
#id1 {
position: fixed;
left: 0; top: 0;
width: @id1width;
}
#id2 {
position: fixed;
right: 0; top: 0;
width: calc(100% - @id1width);
}
transforma a penúltima linha em width: calc(-30%); que claramente não é o desejado. Tentei usar width: ~"calc(100% - @id1width)"; mas @id1width não foi interpretado.
Acho que o LESS não deveria usar coisas reservadas pelo CSS3 para seu uso interno ...
mgol
Todos 51 comentários
eles provavelmente foram fechados como duplicatas .. embora eu não consiga encontrar um sobre calc .. consulte # 146 # 122 e # 915
solução alternativa: width: ~"calc(100% - @{id1width})"; - observe os colchetes ao redor da variável.
Estamos mudando para um sistema em que apenas as coisas entre colchetes serão avaliadas para corrigir esse problema.
lukeapage
em 8 out. 2012
: +1:
shankarcabus
em 18 dez. 2012
<strong i="5">@rows</strong>: 10;
<strong i="6">@row1</strong>: 1 / <strong i="7">@rows</strong> * 100%;
.featured1
{
top: ~'-webkit-calc(@{row1} + 20px)';
right: 0;
bottom: @row5;
left: @col9;
}
Este bit de LESS processará o valor de ' @ row1 ' em 10%, o que é ótimo. Mas quando está dentro de uma seção com escape de LESS e embrulhado em curvas para reter a variável LESS, ele retorna '10' sem o '%'.
Eu encontrei uma solução alternativa que ainda não me falhou. Se você colocar outro '%' após a curva de fechamento da variável 'row1' dentro do código de escape, ele funcionará corretamente ...
~'-webkit-calc(@{row1}% + 20px)';
Mas isso parece um grande truque para adicionar outro tipo de unidade que já deve estar na variável.
jonjohnjohnson
em 19 dez. 2012
@jonjohnjohnson isso é corrigido na cabeça e estará em 1.3.2
o resto deste bug será resolvido em 1.4.0
lukeapage
em 19 dez. 2012
Não tenho certeza se é o mesmo problema, mas estou tendo um problema com o seguinte. Observe que não há coisas menos específicas aqui, menos 1.3.3 está munging CSS válido de outra forma.
Aqui está o CSS
html, body {
margin:0, padding:0, border:0;
height: 100%;
}
#content {
height: -webkit-calc(100% - 40px);
height: calc(100% - 40px);
background-color:gray;
}
#footer {
background-color:black;
}
E aqui está o HTML para incluí-lo
<!doctype html>
<html lang="en">
<head>
<link rel="stylesheet/less" type="text/css" href="test.css" />
<script src="less-1.3.3.min.js"></script>
<body>
<div id="content"></div>
<div id="footer" style="height:40px"></div>
</body>
</html>
"conteúdo" está sendo definido para uma altura de 60%, então menos está analisando e resolvendo incorretamente a expressão calc em vez de passá-la inalterada para o navegador. Testado no Safari 6.0.2 e Firefox.
faceless2
em 14 jan. 2013
Fixo no mestre para 1.4.0
lukeapage
em 2 fev. 2013
height: ~"calc(100% - 50px)";
ainda produz:
height: calc(50%);
para mim. Eu quero:
height: calc(100% - 50px);
OliverJAsh
em 3 jun. 2014
Além do mais, ele ainda produz height: calc(50%); mesmo com matemática estrita definida como on .
OliverJAsh
em 3 jun. 2014
@OliverJAsh Não consigo reproduzir seus resultados com Less 1.7.0 (ambos os valores de escape e --strict-math:on funcionam conforme o esperado) ... Você poderia fornecer mais detalhes sobre o compilador / ambiente / scripts que usa? (Apenas no caso de haver um problema de script de construção do Bootstrap que poderia levar a tais resultados incorretos: https://github.com/twbs/bootstrap/issues/13604, talvez este seja o seu caso também?).
seven-phases-max
em 3 jun. 2014
Eu estava tendo esse problema no 1.6.3 (por algum motivo, o WinLESS está com problemas de compilação quando atualizo para o 1.7.x, então estou me fixando no 1.6.x por enquanto)
Minha correção foi apenas para escapar de uma parte da equação como:
height: calc(~"100%" - unit(<strong i="7">@var</strong>, px));
Isso funciona até mesmo para variáveis, como <strong i="10">@var</strong>: 50 . Ou você pode escapar de todo o cálculo como calc(~"100% - 50px");
twiginteractive
em 26 jul. 2014
@twiginteractive Se você tiver que usar o escape com --strict-math option off (configuração padrão), então não é um problema, mas o comportamento esperado. Veja --strict-math .
seven-phases-max
em 26 jul. 2014
@ seven-phase-max Hmmm - de acordo com os documentos, com SM desligado (padrão), então isso _deve_ ser analisado corretamente (ou seja, intocado)
height: calc(100% - 10px);
Mas isso não acontece. O CSS de saída é height: calc(90%); , que não é o resultado desejado. Talvez isso esteja corrigido no 1.7, mas como eu disse, não posso usar essa versão agora até descobrir o que está quebrando a compilação do WinLESS.
(A menos que eu esteja lendo incorretamente os documentos quando diz "será processado corretamente" ... LESS não poderia saber o valor de 100%, então não deveria fazer um cálculo matemático em '100% - 10px')
twiginteractive
em 26 jul. 2014
@twiginteractive
de acordo com os documentos, com o SM desligado (padrão), isso deve ser analisado corretamente (ou seja, sem alterações)
Não, a palavra lá é currently não correctly (ou seja, "será _ser processado_ atualmente").
seven-phases-max
em 26 jul. 2014
@ seven-phase-max Ah - que pena, faz sentido agora. Obrigado pelo esclarecimento.
twiginteractive
em 27 jul. 2014
altura: ~ "calc (100% - 50px)"; Funcionou para mim.
aamirshahzad
em 5 set. 2014
É aqui que Less.js começa a bagunçar seu código.
height: _calc(50%);
height: calc(100% - 50%); /* browser-native */
stevenvachon
em 5 set. 2014
@stevenvachon
Supostamente, a v2.0 terá a opção de prefixar suas funções da seguinte forma:
Isso não afetará calc forma alguma. Não há função calc embutida, Less está apenas avaliando uma expressão matemática de acordo com suas regras (de Less). É isso. Se você não quiser essa "bagunça", use --strict-math .
seven-phases-max
em 5 set. 2014
Ps a solução para este problema é matemática estrita. E talvez devêssemos
forçar matemática estrita quando em uma chamada para calcular?
lukeapage
em 5 set. 2014
O problema se estende ao usar Myth after Less.
stevenvachon
em 5 set. 2014
Porque? O mito remove os parênteses? A matemática estrita torna menos um superconjunto adequado
de css.
lukeapage
em 5 set. 2014
E talvez devêssemos forçar matemática estrita quando em uma chamada para cálculo?
Discutimos isso em # 1872 e existem alguns argumentos contra as soluções alternativas "local strict- math: on ". A solução proposta (ainda não totalmente decidida) está em # 1880.
seven-phases-max
em 5 set. 2014
@stevenvachon
Mesmo com strictMath, precisamos ~ "calc (...)" para que Less o ignore.
Exemplo? Ou seja, um trecho em que Less fixa uma expressão dentro de calc com --strict-math=on .
seven-phases-max
em 5 set. 2014
Desde quando v2 prefixa funções? Decidimos isso e eu esqueci?
lukeapage
em 6 set. 2014
Desde quando v2 prefixa funções? Decidimos isso e eu esqueci?
Não. Acho que isso foi apenas um pouco superestimado https://github.com/less/less.js/issues/2102#issuecomment -50286985.
seven-phases-max
em 6 set. 2014
Sim, desculpe, não "a opção de", mas "a capacidade de escrever um plug-in com a opção de". Terei que testar alguns códigos novamente com e sem Devo ter me enganado há um tempo e apenas continuei avançando com esse mal-entendido. Eu tenho alguns códigos mais antigos que terei que modificar agora.~"" em calc() .
stevenvachon
em 6 set. 2014
Notei algo estranho acontecendo com calc quando usado em conjunto com width . Coloquei tudo em um codepen apenas para tornar mais fácil: http://codepen.io/anon/pen/OVpJvP
alenb
em 2 jun. 2015
@alenb
Então, o que há de estranho aí? O código em seu código é compilado conforme o esperado ...
seven-phases-max
em 2 jun. 2015
@ sete fases-máx.
Está compilado, mas não é o esperado. Verifique o código CSS um pouco mais de perto.
É estranho porque ainda tem uma lacuna na extrema direita, embora deva se esticar totalmente com as 3 colunas. As duas primeiras colunas devem ter 33,33% menos 20 px, com a última coluna sendo 33,33%. As primeiras 2 colunas teriam um preenchimento à direita de 20 px, mas isso não é refletido, pois há obviamente uma lacuna na extrema direita.
Joguei mais com ele ontem à noite e margin-right em vez de padding-right resolve o problema.
alenb
em 3 jun. 2015
@alenb
Está compilado, mas não é o esperado. Verifique o código CSS um pouco mais de perto.
Claro, eu fiz. Portanto, se você espera algo diferente, especifique.
As primeiras 2 colunas teriam um preenchimento à direita de 20 px, mas isso não é refletido
padding não afeta a largura de forma alguma (a menos que você defina [ box-sizing ] específico (https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing )), consult [CSS specs](http://www.w3.org/TR/REC-CSS2/box.html). So you simply get :
(33% - 20px) + (33% - 20px) + 33% = 99% - 40px -> 40px` gap conforme esperado.
De qualquer forma, isso está relacionado apenas ao CSS e não tem nada a ver com como Less compila calc . Clique no botão "ver compilado" no código do código e lá você verá que suas calc instruções foram compiladas por Less exatamente de acordo com o que você especificou).
seven-phases-max
em 3 jun. 2015
@ sete fases-máx.
Eu teria pensado que o codepen tornaria isso aparente, mas sem nenhum problema.
Obrigado pela informação!
alenb
em 3 jun. 2015
Hoje ainda não funciona com a instalação padrão de less (usando npm).
Eu tive que usar:
min-height: ~"calc(100% - 262px)"; //calc(100% - 262px);
Não sei se é normal, pois o bug está marcado como "fechado", mas só queria avisar.
rkyoku
em 8 abr. 2016
@RenaudParis --strict-math
seven-phases-max
em 8 abr. 2016
Ok, vou tentar isso, obrigado! Mas não seria melhor que seja por
predefinição? Porque é bastante surpreendente, quando você não sabe sobre isso
parâmetro.
Obrigado mesmo assim!
Le ven. 8 AVR. 2016 à 20:48, Max Mikhailov [email protected] a
écrit:
@RenaudParis https://github.com/RenaudParis --strict-math
http://lesscss.org/usage/#command -line-usage-strict-math-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/less/less.js/issues/974#issuecomment -207553212
rkyoku
em 8 abr. 2016
Mas não seria melhor que seja por padrão?
Torná-lo o padrão quebrará muitas das bases de código Less existentes. Uma vez (em ~ v1.4.0 ), houve uma tentativa de torná-lo padrão, mas então foi revertido por causa da compatibilidade com versões anteriores ... Um método mais novo e menos intrusivo foi desenvolvido em # 1880 (mas ainda não foi implementado).
seven-phases-max
em 9 abr. 2016
Ok, obrigado por me explicar isso, Max!
Le sam. 9 AVR. 2016 13:46, Max Mikhailov [email protected] a
écrit:
Mas não seria melhor que seja por
predefinição?Torná-lo o padrão quebrará muitas das bases de código Less existentes. Uma vez
(em ~ v1.4.0) houve uma tentativa de torná-lo padrão, na verdade, mas
então é revertido por causa da compatibilidade com versões anteriores ... Um mais recente,
método menos intrusivo foi desenvolvido em # 1880
https://github.com/less/less.js/issues/1880 (mas não está implementado
ainda)).-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/less/less.js/issues/974#issuecomment -207776654
rkyoku
em 9 abr. 2016
Eu resolvi isso:
.calc(<strong i="6">@prop</strong>, @val) {
@{prop}: ~"calc(~'@{val}')";
@{prop}: ~"-moz-calc(~'@{val}')";
@{prop}: ~"-webkit-calc(~'@{val}')";
@{prop}: ~"-o-calc(~'@{val}');"
}
.calc(width, "80% - 36px");
Quando eu uso command line , está correto. Apenas less-loader não está correto. Então eu encontrei esta solução no stackoverflow
Eu copio para o meu código, infelizmente também não está correto. Então eu modifiquei algo. Funciona!
Infelizmente, a linha de comando não está correta !! 😂 😂 😂
mqliutie
em 1 set. 2016
Não sei por que esse problema foi encerrado. Não faz sentido que Less mude um comportamento nativo de CSS.
vincentmorneau
em 3 nov. 2016
... Menos mudaria o comportamento nativo do CSS.
Não seria. Basta definir --strict-math=on (não habilitado por padrão devido à compatibilidade com uma quantidade gigantesca de projetos Less dependendo de --strict-math=off , além de algumas considerações mencionadas em # 1880).
seven-phases-max
em 4 nov. 2016
oshihirii
em 6 ago. 2017
Funcionou para mim ao escrever no arquivo * .less https://github.com/less/less.js/issues/974#issuecomment -9229470
Obrigado @lukeapage ! 🥇
quytm2239
em 16 out. 2017
Olá @mqliutie, obrigado por adicionar a sugestão de mixin para calc, mas há um ~ extra em seu Mixin que estava interrompendo a compilação:
o mixin deve ser
.calc(<strong i="8">@prop</strong>, @val) {
@{prop}: ~"-webkit-calc('@{val}')";
@{prop}: ~"-moz-calc('@{val}')";
@{prop}: ~"calc('@{val}')";
}
Insira da seguinte forma:
.calc (largura, "100% - 60px");
Saída da seguinte forma:
largura: calc (100% - 60px);
ciaranlp
em 19 out. 2017
Por que este problema foi encerrado ?! Não está consertado.
Ainda estou recebendo calc(30%) quando escrevo calc(50% - 20px) . Isso nunca é o que ninguém quer. Além do fato de que é errado calcular às cegas com unidades diferentes, deve deixá-lo como está em um cálculo (), a menos que possa ser calculado com 100% de confiabilidade (por exemplo, mesmas unidades). Estou usando MENOS 2.7.3.
Reabra este problema.
thany
em 25 jan. 2018
@thany
Consulte esses comentários, eles descrevem como isso não é exatamente um problema, por mais que a configuração padrão do processamento matemático seja um subproduto da história e você sempre pode alterar a configuração padrão.
https://github.com/less/less.js/issues/974#issuecomment -207553212
https://github.com/less/less.js/issues/974#issuecomment -207776654
jonjohnjohnson
em 25 jan. 2018
@jonjohnjohnson Isso é apenas repetir o problema. Se o modo estrito corrige (não tentei ainda, não deve ser necessário habilitar todos os tipos de sinalizadores não padrão para contornar os bugs), então ele deve estar ativado por padrão.
Não importa como você diga, esse problema não é corrigido por nenhuma definição.
thany
em 26 jan. 2018
@thany, eu só estava tentando ajudá-lo a entender que os desenvolvedores decidiram que não é um problema de acordo com eles. Esses comentários não apenas reafirmam o problema, eles descrevem a posição dos desenvolvedores sobre o assunto. Boa sorte.
jonjohnjohnson
em 26 jan. 2018
@thany
então ele deve estar ativado por padrão.
Não pode ser porque isso quebraria imediatamente um milhão de projetos por aí. Portanto, se você tratar o comportamento padrão como um problema, apenas defina a opção documentada e pronto. Por qualquer definição.
Por que este problema foi encerrado ?!
Porque a discussão atualizada de como melhorar o comportamento padrão está aqui .
seven-phases-max
em 26 jan. 2018
@thany Como @ seven-
matthew-dean
em 27 jan. 2018
width: 15%;
height: ~"calc(width)";
como fazer altura = largura
xiaomizhou66
em 18 nov. 2018
@ xiaomizhou66
Isso não tem nada a ver com MENOS, nem com esse problema. É puramente uma questão de CSS. Por favor, procure algo como "css keep aspect" e você encontrará algumas respostas.
thany
em 26 nov. 2018
Então, isso ainda está quebrado. calc (100vh - 138px) sai para -38px.
willatathena
em 15 mar. 2019
@willatathena
Se você experienciar este problema com Less 3.x, crie um relatório de bug separado.
Para versões anteriores do Less, esse é o comportamento esperado por padrão (leia as postagens acima para saber como lidar com isso).
seven-phases-max
em 16 mar. 2019
Questões relacionadas
BrianMulhall
·
4Comentários
MarkSG93
·
4Comentários
chricken
·
6Comentários
awebdev
·
4Comentários
rejas
·
6Comentários
Comentários muito úteis
eles provavelmente foram fechados como duplicatas .. embora eu não consiga encontrar um sobre calc .. consulte # 146 # 122 e # 915
solução alternativa:
width: ~"calc(100% - @{id1width})";- observe os colchetes ao redor da variável.Estamos mudando para um sistema em que apenas as coisas entre colchetes serão avaliadas para corrigir esse problema.