Less.js: Código CSS Condicional

vá para http://www.lesscss.org/ e procure por guardas.

para evitar ter que usar mixins, olha a solicitação de recurso para permitir guardas em qualquer css.

Sim, eu sei disso, mas se estamos escrevendo muito MENOS, temos que escrever e gerenciar centenas de .mixins
Eu não acho que o mixin resolve esse problema. Mesmo mixins terão muito poder com esse recurso.
Menos CSS quase tem todos os recursos que alguma linguagem de programação tem, então por que não isso?

.button-maker (<strong i="8">@style</strong>: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(<strong i="9">@style</strong> == 'light'){
        /* adds light styling */
    }

    if(<strong i="10">@style</strong> == 'dark'){
        /* adds dark styling */
    }
}

Eu adicionaria um grande +1 para esse recurso que estou realmente perdendo. Manter guardas com uma grande base de código é realmente um pesadelo. Isso facilitaria muito as coisas...

Podemos até adicionar a instrução switch ..

@lukeapage você pode reabrir este problema. Acho que devemos discutir esse problema/recurso

LESS não é uma linguagem de script. A sintaxe/estilo se assemelha ao CSS.

LESS deve ser declarativo, o que significa que não deve ser capaz de situações complexas com lógica de ramificação, loops, etc.

@pierresforge você tem algum exemplo em que os guardas são insuficientes?

e onde não seria resolvido por poder ter guardas em qualquer seletor?

a discussão está aberta .. se você puder me persuadir (ou outro membro da equipe principal) eles são necessários, eu reabrirei o problema .. mas a conversa já foi realizada antes e muito tempo foi gasto nisso .

A frase de http://lesscss.org/
"LESS estende CSS com comportamento dinâmico, como variáveis, mixins, operações e funções."

Sim LESS não é uma linguagem de script, mas ainda possui recursos como variáveis, funções e operações.
O que falta é lógica condicional.

Acho que o CSS Media Query não é nada além da lógica condicional.

<strong i="11">@media</strong> all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

Se CSS pode ter lógica condicional como guardas. Então qual é a diferença. Guardas apenas estendendo-o para mixins.
Guards só permite condições fora do bloco de código CSS e não dentro do bloco de código.
Consulte https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701 para obter uma instância, os guardas não podem ajudar com esse requisito.

Mesmo o HTML tem lógica condicional, sim, e é uma linguagem de marcação, não uma linguagem de script.

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

@lukeapage obrigado..

Os guardas são análogos ao que as consultas de mídia fazem. Observe que em CSS comum você não pode aninhar media queries dentro de seletores; Você só pode colocá-los na raiz do documento.

Não, não tenho nenhum exemplo em que os guardas não sejam suficientes. No entanto, há muito em que os guardas não são realmente os melhores para manutenção.

Um exemplo:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="7">@coreBackgroundColor</strong>, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="8">@coreBackgroundColor</strong>, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="9">@coreBackgroundColor</strong>, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

é no meu sentido mais conciso e autoexplicativo (principalmente nos casos em que não faz sentido tornar o código reutilizável, pois o algoritmo depende de muitos fatores) do que:

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(<strong i="13">@coreBackgroundColor</strong>, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

Concordo que isso está sujeito a discussão, mas isso seria uma adição muito boa, se não envolver muitas mudanças principais. Ele permite agrupar a maioria das regras para aplicar a um único elemento sem exigir a adição de mixins.

Esse tipo de situação é o motivo pelo qual escrevi a função de contraste - ela atua como um tipo de operação condicional que não está disponível de outra forma e é muito mais organizada do que usar guardas, como você diz. Acho que poderíamos implementar algum tipo de função genérica que atua como uma espécie de seletor, em vez de adicionar sintaxe para condições.

Advogado do @Soviut Devil - Em LESS, você pode realmente colocar sua consulta de mídia dentro de um seletor, o que geralmente é bastante útil.

Eu tenho sido contra ifs, porque isso começa a aumentar exponencialmente a complexidade do seu código, e LESS é projetado para ser simples e direto. Neste momento, há algum esforço para estabilizar a linguagem ao adicionar novos recursos.

No entanto... novamente o advogado do diabo, com base na lógica de que as consultas de mídia agora aparecem dentro dos seletores, os guardas poderiam, teoricamente, seguir o mesmo princípio.

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  <strong i="9">@when</strong> (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="10">@coreBackgroundColor</strong>, 20%);
  }
  <strong i="11">@when</strong> (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="12">@coreBackgroundColor</strong>, 15%);
  }
  <strong i="13">@when</strong> (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(<strong i="16">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(<strong i="17">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

Mais declarativo do que ifs, sintaxe mais próxima do LESS existente e avalia cada instrução independentemente (como LESS / CSS é definido).

Alternativamente (ou além de), de forma semelhante, anexar a avaliação de um mixin ao ponto de avaliação:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(<strong i="22">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(<strong i="23">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(<strong i="24">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

Indiscutivelmente, os guardas de nível de instrução não são mais/menos complexos ou lógicos diferentes do que os guardas de nível de mixin IMO. Provavelmente os exemplos 2 e 3 são menos expansivos para a linguagem. Apenas pensei em jogar isso lá para reflexão / discussão.

Acho que ninguém tinha muito a dizer sobre minha proposta de guardas de declaração. ;-)

Na verdade, não, não há muito a dizer. Isso seria ótimo, IMO :)

Sim, se eles já estiverem em mixins, e consultas de mídia podem estar dentro de elementos, parece que a lógica para estendê-los é razoável. Curioso o que @lukeapage e @jonschlinkert e outros pensam.

@matthewdl :+1:

Acho que já os apoiei na questão em que são discutidos .... :)

@lukeapage Você está falando da edição nº 748? Em caso afirmativo, adicionei um pouco à sintaxe. ;-)

Eu gostaria de expressar meu desejo por alguma forma de if ou @when .

Não concordo com o sentimento de que os guardas são universalmente melhores e tornam o código MENOS menos complexo do que usar condicionais. Estou encontrando situações práticas em que os guardas de fato tornam meus arquivos LESS mais feios e difíceis de ler, mas um if / @when seria realmente excepcionalmente legível. Guardas e condicionais if / @when são inerentemente apenas ferramentas, ambos podem ser usados ​​para fazer coisas bonitas ou feias e são mais adequados para diferentes situações. Inferno, eu posso criar um arquivo ~300b .less que usa apenas o recurso de expansão de seletor mais básico do LESS para consumir mais de 1 GB de RAM e deixar a CPU girando por minutos.

Em um projeto recente em que estava trabalhando com a intenção de oferecer suporte pesado tanto para desktop quanto para dispositivos móveis, acabei decidindo que fazer isso com consultas de mídia inline não era bom o suficiente. Servir CSS extra para qualquer modo que ele nem usaria não parecia bom, além de todo o problema de tentar cascatear o carregamento duplo de imagens de fundo e ter que contornar isso enquanto ainda não conseguia incorporar um URI de dados sem perder tempo servindo uma imagem inteira que um modo não usaria. E lidar com isso tentando cascatear duas folhas de estilo apenas tornaria minha menos uma bagunça, já que agora haveria dois lugares declarando os estilos para uma classe.

Minha decisão foi pegar uma página de como o MediaWiki lida com RTL, servindo duas folhas de estilo de uma. O MediaWiki faz isso escrevendo folhas de estilo em LTR e depois invertendo a folha de estilo para criar uma segunda folha de estilo RTL. Não há necessidade de tentar substituir tudo especificado para que o LTR lide com o RTL. Da mesma forma, decidi escrever meus estilos primários em um main.less (e potencialmente os arquivos referenciados a partir dele para separar os estilos), esse arquivo não seria compilado diretamente. Em vez disso, eu teria duas folhas de estilo um desktop.less e um mobile.less, ambos definiriam coisas como <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; e também substituiriam algumas variáveis ​​menos como os tamanhos das coisas. Dessa forma, meu main.less acaba se transformando em um desktop.css e mobile.css, e posso lidar com a consulta/teste de mídia determinando qual carregar em outro lugar (se eu REALMENTE quisesse, poderia determinar qual carregar mesmo em um dispositivo que nem suporta consultas de mídia).

O único problema, no entanto, são os blocos condicionais. Há partes do código que decido "mobile não precisa desses estilos" ou "desktop não precisa desses estilos". Atualmente, a única maneira de fazer isso em menos é com:
((Ok, tecnicamente esses estilos são hipotéticos, pois não estou usando uma navegação de acordeão, mas eles são verdadeiros para o que estou fazendo))

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  .dummy() when (<strong i="21">@desktop</strong> = true) {
    .accordion-styles();
  }
  .dummy();
}

Nesta situação, seria muito mais compreensível usar algo como @when .

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  <strong i="26">@when</strong> (<strong i="27">@desktop</strong> = true) {
    .accordion-styles();
  }
}

Na verdade, pensei em pré-processar meus menos arquivos para transformar algo como uma sintaxe @when em um hack onde um mixin+guard gerado dinamicamente é criado e incluído diretamente após ele.
Escusado será dizer que, se a ideia de pré-processar um pré-processador soa como uma boa ideia que tornará as coisas mais fáceis de entender... algo está errado com o pré-processador atual.

E a verdade é que isso não se aplica apenas à minha técnica de desktop/mobile. Isso também pode se aplicar a esquemas de temas. Escreva um arquivo menos principal com o seu tema. Em seguida, tenha um monte de menos arquivos nos quais você simplesmente inclua esse menos arquivo e, em seguida, defina algumas variáveis ​​a menos para controlar coisas como o esquema de cores. Ajustes de cores funcionarão bem, mas você imediatamente cairá em um penhasco quando descobrir que realmente poderia usar algo como @use_horizontal_nav .

@dantman a partir de 1.5.0 e guardas nos estilos css que estão vinculados, você pode fazer isso

.navigation {
  & when (<strong i="7">@desktop</strong> = true) {
    color:red;
  }
}

que é o açúcar para o seu exemplo.

A única desvantagem é que no momento ele pensa que é um novo seletor, então não o mescla com o seletor anterior. No entanto, acho que é improvável que isso cause problemas e será algo que eu/nós corrigiremos em versões futuras.

Ok, obrigado, podemos ter isso documentado como um recurso?

Para ser honesto, também não tenho certeza se é muito compreensível em comparação com @when , não tenho certeza de que se eu tivesse visto anteriormente & when(...) em um arquivo .less eu teria entendido o que é fez de relance. @when como açúcar por & when() pode ser bom.

Eu concordo com @matthew-dean adicionar esse tipo de estrutura condicional provavelmente tornará os arquivos principais LESS mais difíceis de manter e testar. E os arquivos .less mais difíceis de depurar e assim por diante.

O que temos agora é uma obra de arte, as pessoas podem entender e aprender o básico de LESS em literalmente menos de 10 minutos (estou falando sobre aninhamento e mixagem), adicionar declarações condicionais apenas torna as coisas mais difíceis de digerir para outros tipos de pessoas como designers e entusiastas. tentar usar guards para imitar ou simular instruções IF é apenas tentar exacerbar um problema que não existe e não precisa de solução.

Se um desenvolvedor precisa de mais complexidade e controle sobre seus arquivos MENOS antes de compilá-los, não há nada que os impeça de usar linguagens como PHP para pré-processar alguns arquivos a menos para obter maior controle, flexibilidade e complexidade, há muitas maneiras de fazer isso é apenas uma questão de usar a imaginação para fazer isso da maneira mais correta ou conveniente.

Por exemplo, para não dizer que eu tenho um arquivo chamado "myfile.less.php" que tem um código maluco com condicionais, switches, arrays e todas as coisas extravagantes que você pode ver no PHP e, em seguida, desse arquivo ".less.php" cuspir outro arquivo chamado "myfile.less" que tem o código LESS final, desta forma eu posso consultar todos os vars do servidor com PHP, decidir o que @imports meu novo arquivo .less incluirá ou excluirá, não há mais necessidade de passar grande quantidade de vars bobos para o compilador LESS e não há necessidade de escrever guardas bobos feios e difíceis de ler para imitar estruturas IF ou Switch simuladas.

Um fluxo de trabalho básico poderia ser assim

1- verifique se o cache expirou
1- chame o script para encontrar e pré-processar todos os arquivos ".less.php"
2- chame o script para compilar todos os arquivos ".less"
3- atualizar cache

@enav Eu discordo fervorosamente. além de desenvolver menos eu uso em soluções corporativas baseadas em top of node, onde não queremos ter que usar 2 linguagens para resolver um problema.

@dantman existem algumas coisas não documentadas e sim, precisamos documentar isso. há um esforço em andamento em less-docs para expandir a documentação e tornar o site muito melhor. Vou adicionar um problema lá.

@lukeapage , sim, notei isso recentemente. Eu dei uma olhada no changelog e notei coisas como svg-gradient e propriedade se fundindo com +.

Estritamente falando & when ... já está documentado, pois é apenas uma combinação simples de dois recursos documentados & e CSS Guards . Mas um exemplo dedicado não prejudicará, é claro.

@seven-phases-max, eu não conhecia essa documentação. Pelo que parece, esse é um novo conjunto de documentação incompleto para substituir o site antigo, passando pelo "Isto será movido para o repositório lesscss.org em breve! Recomendamos que você evite vincular a este site até que tudo esteja ativo". Comente. O que é bom saber que algo assim está em andamento.

Eu estava me referindo à documentação atual no lesscss.org, que eram os únicos documentos que eu conhecia, e atualmente apenas documenta os guards como um recurso de mixin, não sugerindo que ele esteja disponível em qualquer outro lugar.

Os guardas não são tão bons assim. :(

Este é um recurso obrigatório e também presente no scass.

+1 para isso

Justamente como este comentário de hoje foi levantado alguns anos depois que esta questão foi aberta, uma coisa que me vem à mente no momento.

Parte da resistência a @when na discussão original é a regra adicional. No entanto, pensando nisso agora, não deveria ser necessário.

Considerando que esses dois blocos são iguais:

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

Então, essas duas instruções também devem ser aceitas pelo analisador como iguais.

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

Se por nenhuma outra razão que & when é sintaticamente muito estranho. Omitir & para ainda implicar uma junção de seletor com o seletor pai sempre existiu, então omitir & para implicar um guarda no seletor pai não parece um salto. Além disso, as funções block-root agora são aceitas pelo analisador para uso com plugins, então não parece mais tão estranho quanto poderia ter sido em 2013.

Não vejo motivo para reabrir isso. Afinal já temos #2072

when (1=1) { color: blue; }

Abrindo uma grande caixa de confusão apenas para economia de dois personagens?

Os guardas não são tão bons assim.

Achei que nem valeria a pena comentar um comentário aleatório e irracional. Qualquer posição deve ter algo por trás disso (caso contrário, eu diria que qualquer código condicional é manco e if s são bobos só porque eu sei escrever _qualquer coisa_ sem uma única condição em quase todos os idiomas).

Não vejo motivo para reabrir isso. Afinal já temos when (1=1) { color: blue; }

Errr... não, não temos?

Mas é razoável que devêssemos. Poderíamos apenas permitir e acabar com isso.

Espere, até eu encontrar a solicitação de recurso para a qual ela deveria vincular (desculpe, eu acidentalmente cliquei em entrar antes de terminá-la)

Então, mesclando isso com #2072.

@seven-phases-max

Esse problema é chamado de "Permitir redefinição de variável dentro de blocos de execução automática protegidos" e a discussão tangencial na parte inferior desse problema continha casos de uso análogos a um select / case e um vbscript iif([ifcond], [then], [else]) funcionam mais do que apenas o quando nu, embora talvez seja um ponto de partida mais lógico para a discussão. Buuut... provavelmente deveria ser levantada como uma nova questão apenas com a questão when () vs & when () .

apenas com a pergunta quando () vs & quando ().

Você não pode estar falando sério sobre isso, pode? Por causa do que exatamente? when não se tornará if (veja #2072 para todos os motivos) se você remover & . Então deixe como está e pronto.

Ei, você pode diminuir um pouco o tom? Se você está chateado com isso, reserve um momento e volte mais tarde para ver o raciocínio que publiquei na nova edição. Algumas coisas evoluíram desde essas discussões originais.

Eu não quis ofender ou algo assim.
Meu:

Então deixe como está e pronto.

foi apenas uma resposta para:

Poderíamos apenas permitir e acabar com isso.

@seven-phases-max Ok, o tom se perde no texto. De qualquer forma, eu não estava muito apegado a essa ideia e, no geral, a proposta @when existente é melhor / mais versátil de qualquer maneira.

Acho que 'ass' é melhor do que menos. Já tem if-else. É realmente difícil e muitas linhas de codificação a menos. Quando funciona, mas não preenche a necessidade. Além disso, podemos fazer loops em menos, mas a linguagem deve ter seu próprio recurso.

@aukgit Use a ferramenta certa para o trabalho. Se o SCSS for melhor para você, é melhor usá-lo. Sass e Less são projetos muito diferentes.

@matthew-dean depois de aprender menos por meses e escrever muito menos se a comunidade 'menos' não quiser ser melhor, será uma perda para nós dois. Acho que é por isso que o bootstrap mudou para 'sass' (https://github.com/twbs/bootstrap/tree/v4-dev) de menos (o motivo inicial foi uma compilação mais rápida). Considerando que a fonte inicial estava em 'menos'. Agora eles escrevem sua fonte original em 'sass' e depois a convertem para menos (enquanto era o contrário).

Outra coisa :

"Ferramenta certa para o trabalho certo"

não deve se aplicar aqui

Menos | Scss | Stylus projetos semelhantes. Começou com um que era popular na época, agora parece que a comunidade 'menos' não quer se aprimorar.

A ideia por trás do 'menos' é escrever menos e fazer mais. Em algum lugar faz redução, mas em algum lugar requer mais escrita.

Obrigado por seus comentários.

Propaganda desatualizada fanboyish. Seria uma perda de tempo discutir todas essas declarações tendenciosas ou simplesmente falsas.

Por exemplo:

Não há como fazer código condicional realmente compilado.

Sim, "Eu preciso de uma ferramenta para escrever meu código de espaguete" - assim . Se você escrever um código como este, Less definitivamente não é sua ferramenta.

Eu acho que "menos" faz 'x' algo muito diferente do que atrevimento e caneta. Todos os outros fazem coisas semelhantes, enquanto 'menos' afirma que não é um tipo semelhante. :)

@aukgit

Eu acho que "menos" faz 'x' algo muito diferente do que atrevimento e caneta.

_Por que_ deveria fazer o mesmo? Veja por exemplo [1] e [2] para encontrar as principais diferenças entre os designs. Então você pode não gostar do conceito, mas ninguém te obriga a usar uma ferramenta que você não gosta.

Agora eu entendi. Obrigada. Na verdade, é realmente a linguagem mais incompreendida de todos os tempos. Mesmo javascript não é tão incompreendido como diz Douglas Crockford.

As pessoas cometem erros em js, mas há muita conscientização. Para 'Less' deve estar na primeira página (less.org) descrevendo o que menos é e o que não.

Obrigada.

Escreveu um mix:

Menos:

.if-value-present(@attribute; <strong i="7">@value</strong>: '') {
    .x (@value) when not (<strong i="8">@value</strong> = '') {
        @{attribute}: @value;
    }

    .x(@value);
}

.if-value-present-multi(@attributes; @values) {
    .iter(@i) when (<strong i="9">@i</strong> > 0) {
        .iter(<strong i="10">@i</strong> - 1);
        // loop

        <strong i="11">@attr</strong>: extract(<strong i="12">@attributes</strong>, @i);
        <strong i="13">@value</strong>: extract(<strong i="14">@values</strong>, @i);

        .if-value-present(<strong i="15">@attr</strong>, @value);
    }

    <strong i="16">@len</strong>: length(@values);
    .iter(@len);
}
.x {
    <strong i="17">@var</strong>: c1,c2, c3;
    <strong i="18">@val</strong>: v1, '', 'wddww';
    .if-value-present-multi(@var;@val);
}
.x{
    .if-value-present(content, 'new val');
}

Saída CSS:

.x {
  c1: v1;
  c3: 'wddww';
}
.x {
  content: 'new val';
}

se a comunidade 'menos' não quer ser melhor, então é uma perda para nós dois

Eu acho que é um erro supor que "o recurso X que eu quero não é suportado" == "Menos comunidade não quer ser melhor". Isso não nos leva a lugar nenhum.

Existem várias discussões no Github para trabalhar na melhoria dos fluxos de controle. Na verdade, este tópico não foi rejeitado, ele foi mesclado ao #2072. Você comentou em um tópico fechado de 3 anos. Eu tinha algumas outras ideias que achei que poderiam ter feito isso um pouco diferente do #2072, mas estava essencialmente convencido do contrário.

agora parece que o like não tem recursos melhores

Less não tem _more_ características, isso é verdade. Isso é por design. Isso é para que você possa aprender menos em um dia, e os recursos do Less cobrem 99% dos casos de uso típicos. Sass tem uma curva de aprendizado mais acentuada. O Sass tinha tantos recursos que eles tiveram que construir um compilador baseado em C de baixo nível apenas para poder continuar a compilá-lo. O que é uma grande conquista. Mas não é um grande testamento para algo que, no final das contas, é apenas fazer uma folha de estilo.

Agora eles escrevem sua fonte original em 'sass' e depois a convertem para menos (enquanto era o contrário).

É verdade, mas isso se baseia em vários fatores, e você pode perguntar quais seriam. Pessoalmente, sinto que abandonar usuários do Less é um erro, já que hoje há muitas pessoas usando o Bootstrap no Less.

No final das contas, suas reclamações sobre os aros necessários para escrever condicionais _não estão erradas_. Os exemplos oferecidos aqui são simplesmente inadequados para a linguagem. Eu sugiro que você leia o tópico em #2072.

(este é realmente um pouco offtopic, mas eu estou apenas querendo saber)

<strong i="7">@var</strong>: c1, c2, c3;
<strong i="8">@val</strong>: v1, '', 'wddww';

E qual seria a utilidade dessas variáveis ​​além de chamar .if-value-present-multi ?
(E _se_ essas variáveis ​​_são_ usadas para outra coisa) Não faria sentido usar apenas pares de propriedade/valor, por exemplo:

<strong i="14">@rules</strong>:
    c1 v1,
    c3 'wddww';
   // no need for c2 since it has no effect

Além disso, qual poderia ser o propósito de escrever .x {.if-value-present(content, 'new val')} se você precisa apenas .x {content: 'new val'} ? E escrever .x {.if-value-present(content)} se não fizer nada?

(Embora honestamente eu olhei para [1] - bem, sem comentar nada, exceto apenas uma coisa: (_apenas para economizar seu tempo_) considere jogar fora libs antigas como elements e lesshat - e use autoprefixer . Não precisamos de bibliotecas de prefixo de fornecedor para nenhum pré-processador CSS por um tempo).

Geralmente é assim que a maioria das "solicitações de recursos" vem: "Problema XY" . (Outros bons exemplos de falhas semelhantes na área relacionada: #1400 e #1894, não é que os recursos sejam totalmente inúteis (portanto, ambos são mantidos abertos), mas quando alguém começa a perguntar por seus casos de uso reais, geralmente revela estava apenas errado Y na tentativa de resolver X).

Bem, aqui está o caso de uso:
Eu tentei fazer mixn com 3 parâmetros, se o último não for fornecido, ele deve criar seu atributo dentro do mixn, por isso as condições foram úteis.

Aqui https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less Eu tentei implementar o mesmo mixen repetidamente onde eu poderia ter conseguido com condições muito facilmente.

Eu tenho agora .. Obrigado a todos.

@aukgit Você deve conseguir recolher esses mixins facilmente.

https://gist.github.com/matthew-dean/e617bc1f71528843ef9fa73d70427bcf

Obrigado @matthew-dean por dedicar seu tempo e me ajudar. :) Estou grande cheio de você.

:)

Acho que 'ass' é melhor do que menos. Já tem if-else.

Ambas as linguagens têm seus próprios problemas.

A falta de importações dinâmicas - e sua relutância em implementá-las - é a principal razão pela qual eu gostaria de mudar de Sass para Less. Menos tem esse recurso há anos!

No entanto, a falta de estruturas de controle tradicionais (como o loop FOR ou instruções IF-ELSE) e a sintaxe digna de constrangimento é o que me impede de fazer esse movimento.

Eu me sinto preso entre uma rocha e um lugar duro...

@jslegers Mesmo comentário que em # 249. Less tem várias formas (mais e mais na versão mais recente) de restrições condicionais desde a v1.x.

@seven-phases-max

Estou ciente de mixins protegidos como uma alternativa para instruções IF e mixagens recursivas como uma alternativa para loops em Less. Mas isso é tudo que consegui encontrar nos documentos sobre estruturas de controle em Less. E como alguém com experiência em programação em muitas linguagens, acho sua sintaxe confusa e - para ser honesto - bastante digna de constrangimento.

Se houver outras estruturas de controle além daquelas que valem a pena mencionar, não consegui encontrá-las nos documentos.

De qualquer forma, algo como...

scss a { <strong i="11">@if</strong> $time == morning { color: red; } <strong i="12">@else</strong> if $time == afternoon { color: blue; } <strong i="13">@else</strong> { color: grey; } }

... ou algo assim...

scss <strong i="17">@each</strong> $author in $list .photo-#{$author} background: image-url("avatars/#{$author}.png") no-repeat

... ou isto...

scss <strong i="21">@for</strong> $i from 1 through 8 { $width: percentage(1 / $i) .col-#{$i} { width: $width; } }

... em Sass é muito mais legível e muito mais elegante na minha opinião do que ter que escrever algo semelhante com mixins guardados ou mixins recursivos em Less.

A falta de tais declarações e a sintaxe geral menos legível de Less (em comparação com Sass) são as duas principais razões pelas quais prefiro ficar com Sass e estou relutante em considerar Less para um dos meus projetos.

E considerando que Sass se tornou muito mais popular que Less, eu claramente não sou o único que se sente assim.

@jslegers Para seus exemplos - tente aprender o que já está disponível antes de publicá-los.
De resto (popularidade e assim por diante) - não faz sentido discutir algo de maneira tão simplificada (Stylus tem tudo isso e daí?), além de que Less nunca foi declarado para substituir outros pré-processadores CSS nem para se tornar seu clone. E, finalmente, o erro mais comum é pensar que a popularidade de algo é o objetivo principal e único dos autores desse algo.

tente aprender o que já está disponível antes de publicá-los.

Tente documentar melhor ou direcionar as pessoas diretamente para o que estão procurando, caso não encontrem.

De resto (popularidade e tal) - não adianta discutir algo de forma tão simplista [...] E por fim, o erro mais comum é pensar que a popularidade de algo é o objetivo principal e único dos autores desse algo.

Para sua informação, nunca sugeri que a popularidade é um forte indicador de qualidade ou utilidade. Na verdade, muitas vezes é o contrário.

Ainda assim, se você olhar por que as pessoas mudam de Less para Sass, é bem direto ...

Pessoalmente não consigo ver nada além do usual "Quero meu espaguete PHP" (veja posts sobre a ferramenta errada acima), nem mesmo contando seu 2012 (já insinuei que a maioria desses exemplos fica bem compacta no Less moderno, mas parece que você não quer acordar).
Mas não importa, geralmente eu apenas argumento uma clara desinformação, discussões de opiniões pessoais de por que algo acontece ou não acontece são totalmente fora do meu interesse.

Pessoalmente, não consigo ver nada além do habitual "quero meu espaguete PHP"

Parece-me que usar Less em vez de Sass faz com que seu código inevitavelmente pareça "espaguete PHP" (se você acha que PHP é o epítome do código espaguete, obviamente nunca fez nenhuma programação ABAP) assim que quiser fazer algo mais complexo do que variáveis ​​básicas e mixins, mas estou disposto a considerar que estou errado aqui.

Eu já insinuei que a maioria desses exemplos fica bem compacta no Less moderno, mas parece que você não quer acordar

Então, por que não fazer um esforço para me acordar e me dar uma fonte ou duas que possam me aliviar de minha ignorância?

Há pouca coisa que eu ache mais excitante do que alguém provando que estou errado. Na minha experiência, essa é a melhor maneira de crescer...