Você quer dizer o pseudo-seletor :empty ?

http://reference.sitepoint.com/css/pseudoclass-empty

Não, provavelmente eu deveria ter chamado de "regra";)
eu queria dizer isso

.selector {}
a.nother{
   .selector {}
}

Eles são excluídos na compilação para css

Por que você deseja mantê-los? Eles não estão fazendo nada em branco no arquivo CSS gerado. Você diz que está tentando estilizar através do Firebug, mas não entendo qual é a sua abordagem.

1. Eu crio regras vazias no arquivo less para um elemento ou grupo de elementos.
2. Abro o firebug, seleciono o elemento no qual pretendo trabalhar e posso ver as regras vazias que criei
3. Eu escrevo estilos dentro dessa regra vazia
4. O plug-in https://github.com/ronniekk/css-x-fire sincroniza de volta as alterações que fiz no firebug para o arquivo less, encontra a regra vazia e coloca lá os estilos que especifiquei no firebug.

O requisito é que a regra já exista para que o plugin sincronize corretamente e, obviamente, se o elemento não tiver estilos antes, terei que criar uma regra vazia pela primeira vez. Funcionou quando eu usei CSS puro, mas agora, quando mudei para LESS, percebi que o compilador exclui as regras vazias e o plug-in não consegue sincronizar de volta os estilos.

Eu percebo que esse é um caso de uso bastante restrito ...

Este parece ser um caso de uso _muito_ específico. Na maioria dos casos, as pessoas preferem MENOS otimizar seu CSS e _não_ deixam as regras vazias.

Eu sugeriria usar less.watch() para atualizar automaticamente seus estilos:

<script type="text/javascript">
     less.env = "development";
     less.watch();
</script>

ou acrescente #!watch ao seu URL.

Se você tiver problemas, há algumas sugestões aqui: http://www.paulsprangers.com/2011/04/quick-tip-less-js-in-development-and-watch-mode/

Bom conselho de @Soviut. também se você não gosta disso, para contornar adicione uma regra falsa, por exemplo

temp: ruleset;

Concordou. A solução da @agatronic faz o que você precisa sem fazer com que todos os outros arquivos LESS gerem CSS ineficiente.

@agatronic é o que eu estava fazendo nas últimas 2 semanas desde que comecei a usar o LESS, mas algumas vezes essas regras falsas entraram em produção porque eu esqueci de removê-las, então pensei que talvez houvesse uma maneira mais clara de consertar isso :(

@Soviut, infelizmente, é um fluxo de trabalho totalmente diferente, não estou pronto para desistir por usar menos ... também usar menos compilador no navegador causou alguns problemas de desempenho sérios, o carregamento da página aumentou de 500-700ms para 2-3 s ..

Eu entendo que esta opção não será adicionada e concordo com você, mas se isso não for um problema, você pode me dizer em qual arquivo de código-fonte eu posso alterar o comportamento sozinho?

tente mudar isso

https://github.com/cloudhead/less.js/blob/master/lib/less/tree/ruleset.js#L187

@chetzof Eu descobri a solução para isso. essa não é a MELHOR maneira, mas funciona para o que você procura.

eu coloquei dessa forma:

seletor {/ ** /}

ele aparecerá vazio no firebug.

@ d4ng3rmax Ponto legal!
Acho que tenho o mesmo fluxo de trabalho dev que @chetzof mencionou.
Valeu.

Esta coisa é obrigatória para uso durante o desenvolvimento com css-modules .
É realmente cansativo para padronizar todos os seletores durante o andaime e, em seguida, conseguir removê-los.

.main {
/*! keep */
}

.loading {
/*! keep */
}

.button {
/*! keep */
}

.form {
/*! keep */
}

@garkin Qual é o seu raciocínio / caso de uso para escrever seus seletores dessa forma com módulos CSS?

Caso contrário, eles seriam undefined durante a fase de importação.

import * as React from 'react'
import * as cx from 'classnames';
import css from './home.less';

export class Home extends React.Component {
    render() {
        const isLoading = true;
        return <div className={cx(css.main, {
            [css.loading]: isLoading
         })}>
            Home
        </div>
    }
}

Isso leva às exceções de tempo de execução e destrói a substituição do módulo quente. Impedir que os seletores removam corrige todos esses problemas.
Mas durante o scaffolding, você sempre precisa ter em mente que os seletores serão removidos e você precisa lutar contra um compilador para evitá-lo. E então todos aqueles /*! keep */ comentários precisam ser removidos em algum momento no futuro.

@garkin Hmm ... a resposta não é apenas terminar de escrever sua folha de estilo? Estou dizendo que é um problema causado apenas por essa abordagem de desenvolvimento.

Por exemplo, onde eu trabalho, usamos Less e Sass dependendo da equipe, e em nossa configuração de compilação atual do Sass, seletores vazios não passam linting (o aplicativo não compila). Então, fui forçado a apenas mudar minha abordagem com módulos CSS / React.

É realmente esse padrão que é o problema:

{
     [css.loading]: isLoading
}

Se você alterasse para este padrão, não causaria uma exceção:

<div className={`${isLoading && css.loading}`}></div>

Em seu exemplo, você está tentando definir uma propriedade de objeto com um nome que pode ser indefinido. Se você mudar a lógica, sua classe pode ser indefinida e nenhuma exceção será lançada.

Esse processo chamado "termine de escrever sua folha de estilo" requer um contexto cognitivo específico e pode levar muito tempo. É muito mais fácil de ser feito após a etapa de andaime com marcação e HMR trabalhando em mãos.

Este padrão é uma diretriz dominante e semi-oficial para uso, fazia parte da distribuição do React há algum tempo.
E esta amostra é obviamente destilada. Seu caminho não é legível e não escalável.

return <div className={cx(css.post, sharedCss.frame, {
    [css.support]: post.isSupport,
    [css.foreign]: showTranslation,
    [css.private]: post.isInternal,
    [css.cached]: post.status.isLoading
    ...
})}>...</div>

Módulos CSS são a abordagem primária para fazer estilos hoje em dia e serão ainda mais no futuro.
Removendo seletores vazios - altera a semântica do código de forma complicada quando usado com módulos css.

Este comportamento deve ser pelo menos evitável por meio da configuração.

Isso é interessante. Reabrindo não tanto apenas para aquele caso de uso, mas porque Less não deveria estar no negócio de "limpar" CSS. A opção compress foi descontinuada por razões semelhantes, ou seja, existem muitas ferramentas mantidas que irão remover seletores / compactar / adicionar prefixos etc.

Provavelmente, esse comportamento foi criado quando um seletor vazio era irrelevante para o navegador, mas é válido que não seja irrelevante como dados quando você fatorar os módulos CSS.

Na verdade, a menos que alguém se oponha, acho que é seguro implementar como uma opção. IMO seria removeEmptyRulesets (não seletores) com um valor padrão de true .

Editar: ou deveria ser keepEmptyRulesets com um valor padrão de false ? 🤔 Provavelmente o último, uma vez que facilita as verificações de falsey quando indefinido.

quando você leva em consideração os módulos CSS

E não se limita apenas a eles. Considere também coisas como acesso programático por meio do CSSOM .

Eu diria que keepEmptyRulesets é uma boa opção para adicionar.
Um pouquinho do lado prolixo, talvez. Não é muito bom para o CLI: --keep-empty-rulesets

Um pouquinho do lado prolixo, talvez

Não discordo, mas você tem alguma sugestão alternativa? Parece um comportamento muito específico, então às vezes ajuda ser explícito. Não há nada que o impeça de ser keepEmptyRulesets na API e --keep-rulesets na CLI. Ou mesmo --keep-empty

Deve ser apenas keepEmpty para ambos?

Eu usaria:

1. outputEmptyRulesets : true|false como a opção de API;
2. --empty-rulesets como alternância CLI de forma completa; e
3. -er ou possivelmente -empty como alternância CLI abreviada.

@rjgotten , estou bem com isso. Eu não estou envolvido emocionalmente lol. @garkin - o que você acha disso?

Parece bom para mim.

Quando podemos esperar a implementação real dele?
Este é um problema para nós também.

@orchidoris PRs bem-vindos!

Plugin de solução alternativa ...

Adiciona __NOOP__: 1; a cada seletor e os remove depois que menos for feito.

class NoopPreProcessor {      
    process = (css, extra) => css.replace(/}/g, ';__NOOP__: 1;}');                                                                      
}      

class NoopPostProcessor {      
    process = (css, extra) => css.replace(/__NOOP__: 1;/g, '');                                                                               
}                                                                                                                       

const NoopPlugin = {                                                                                                    
    install: (less, pluginManager) => {                             
        pluginManager.addPreProcessor(new NoopPreProcessor());        
        pluginManager.addPostProcessor(new NoopPostProcessor());      
    },                                                                
}; 

Para pré-ação com less-loader:

    helpers.getLoaders(config)                                                             
        .filter(item => item.ruleIndex===1)      
        .map(item => {                           
            item.loaders[0].options.options.stictMath = true;      
            item.loaders[0].options.options.plugins = [            
                NoopPlugin,                                        
            ];                                                     

            item.loaders[0].options.options.paths = [      
                ...item.loaders[0].options.options.paths[0],      
                path.resolve(__dirname, 'src'),                   
            ];                                                    
        });