¿Te refieres al pseudo-selector :empty ?

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

No, probablemente debería haberlo llamado "regla";)
quiero decir esto

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

Se eliminan al compilar en css

¿Por qué querrías conservarlos? No están haciendo nada en blanco en el archivo CSS generado. Dice que está tratando de diseñar a través de Firebug, pero no entiendo cuál es su enfoque.

1. Creo reglas vacías en el archivo menos para un elemento o un grupo de elementos.
2. Abro firebug, selecciono el elemento en el que pretendo trabajar y puedo ver las reglas vacías que creé
3. Escribo estilos dentro de esa regla vacía
4. El complemento https://github.com/ronniekk/css-x-fire sincroniza los cambios que hice en firebug a un archivo menos, encuentra la regla vacía y coloca allí los estilos que especifiqué en firebug.

El requisito es que la regla ya tenga que existir para que el complemento se sincronice correctamente y, obviamente, si el elemento no ha tenido estilos antes, tendré que crear una regla vacía por primera vez. Funcionó cuando usé CSS puro, pero ahora, cuando cambié a MENOS, me di cuenta de que el compilador elimina las reglas vacías y el complemento no puede sincronizar los estilos.

Me doy cuenta de que ese es un caso de uso bastante estrecho ...

Esto parece un caso de uso _muy_ específico. En la mayoría de los casos, la gente prefiere MENOS optimizar su CSS y _no_ dejar las reglas vacías.

Sugeriría usar less.watch() para actualizar automáticamente sus estilos:

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

o agregue #!watch a su URL.

Si tiene problemas, hay algunas sugerencias aquí: http://www.paulsprangers.com/2011/04/quick-tip-less-js-in-development-and-watch-mode/

Buen consejo de @Soviut. Además, si no le gusta eso, agregue una regla falsa, por ejemplo, para solucionarlo.

temp: ruleset;

Acordado. La solución de @agatronic hace lo que necesita sin causar que cualquier otro archivo LESS genere CSS ineficiente.

@agatronic, eso es lo que

@Soviut, desafortunadamente, ese es un flujo de trabajo completamente diferente, no estoy listo para renunciar a usar Less ... también usar menos compilador en el navegador causó algunos problemas de rendimiento graves, la carga de la página aumentó de 500-700ms a 2-3 s ..

Entiendo que esta opción no se agregará y estoy de acuerdo con usted, pero si eso no es un problema, ¿puede decirme en qué archivo de código fuente puedo cambiar el comportamiento por mí mismo?

intenta cambiar esto

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

@chetzof Descubrí la solución para esto. esa no es la MEJOR manera, pero funciona para lo que busca.

lo he puesto de esa manera:

selector {/ ** /}

aparecerá vacío en firebug.

@ d4ng3rmax ¡
Creo que tengo el mismo flujo de trabajo de desarrollo que mencionó @chetzof .
Gracias.

Esta cosa es imprescindible para su uso durante el desarrollo con css-modules .
Es realmente tedioso repetir todos los selectores durante el andamio y luego arreglárselas para quitarlos.

.main {
/*! keep */
}

.loading {
/*! keep */
}

.button {
/*! keep */
}

.form {
/*! keep */
}

@garkin ¿Cuál es su razonamiento / caso de uso para escribir sus selectores así con módulos CSS?

De lo contrario, serían undefined durante la fase de importación.

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>
    }
}

Esto conduce a las excepciones de tiempo de ejecución y arruina el reemplazo del módulo en caliente. Evitar que los selectores eliminen soluciona todos esos problemas.
Pero durante el andamiaje, siempre debe tener en cuenta que los selectores se eliminarán y debe luchar contra un compilador para evitarlo. Y luego todos esos /*! keep */ comentarios deben eliminarse en el futuro.

@garkin Hmm ... ¿no es la respuesta solo terminar de escribir tu hoja de estilo? Digo que es un problema causado solo por este enfoque de desarrollo.

Por ejemplo, donde trabajo usamos Less y Sass dependiendo del equipo, y en nuestra configuración actual de compilación de Sass, los selectores vacíos no pasarán el borrado (la aplicación no se compilará). Así que me vi obligado a cambiar mi enfoque con módulos CSS / React.

Es realmente este patrón el problema:

{
     [css.loading]: isLoading
}

Si cambia a este patrón, no causaría una excepción:

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

En su ejemplo, está intentando definir una propiedad de objeto con un nombre que puede no estar definido. Si cambia la lógica, su clase puede ser indefinida y no se lanzará ninguna excepción.

Este llamado "terminar de escribir su hoja de estilo" requiere un contexto cognitivo específico y podría llevar una cantidad significativa de tiempo. Es mucho más fácil de hacer después del paso del andamio con el marcado y el HMR funcional a mano.

Este patrón es una pauta dominante y semioficial de usar, fue parte de la distribución de React hace algún tiempo.
Y esta muestra, obviamente, está destilada. Tu camino no es legible ni escalable.

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>

Los módulos CSS son el enfoque principal para hacer estilos en estos días y lo serán aún más en el futuro.
Eliminación de selectores vacíos: cambia intrincadamente la semántica del código cuando se usa con módulos css.

Este comportamiento debería poder evitarse al menos mediante la configuración.

Eso es interesante. Reabrir no solo para ese caso de uso, sino porque Less no debería estar en el negocio de "limpiar" CSS. La opción compress fue obsoleta por razones similares, es decir, hay muchas herramientas mantenidas que eliminarán los selectores / comprimirán / agregarán prefijos, etc.

Probablemente, este comportamiento se creó cuando un selector vacío era irrelevante para el navegador, pero es algo válido que no sea irrelevante como datos cuando se incluyen los módulos CSS.

En realidad, a menos que alguien se oponga, creo que es seguro implementarlo como una opción. En mi opinión, sería removeEmptyRulesets (no selectores) con un valor predeterminado de true .

Editar: ¿ o debería ser keepEmptyRulesets con un valor predeterminado de false ? 🤔 Probablemente el último, ya que facilita las comprobaciones de falsey cuando no está definido.

cuando tienes en cuenta los módulos CSS

Y no se limita solo a esos. También considere cosas como el acceso programático a través de CSSOM .

Yo diría que keepEmptyRulesets es una buena opción para agregar.
Un poquito en el lado detallado, tal vez. No es muy agradable para la CLI: --keep-empty-rulesets

Un poquito en el lado detallado, tal vez

No estoy en desacuerdo, pero ¿tiene alguna sugerencia alternativa? Parece un comportamiento muy específico, por lo que a veces ayuda ser explícito. No hay nada que le impida ser keepEmptyRulesets en API y --keep-rulesets en CLI. O incluso --keep-empty

¿Debería ser keepEmpty para ambos?

Yo usaría:

1. outputEmptyRulesets : true|false como la opción API;
2. --empty-rulesets como el conmutador CLI de forma completa; y
3. -er o posiblemente -empty como el conmutador CLI abreviado.

@rjgotten Estoy de acuerdo con eso. No estoy involucrado emocionalmente jajaja. @garkin , ¿cómo te sientes con esto?

Me parece bien.

¿Cuándo podemos esperar su implementación real?
Esto también es un problema para nosotros.

@orchidoris PRs bienvenidos!

Complemento de solución alternativa ...

Agrega __NOOP__: 1; a cada selector, luego los elimina cuando se hace menos.

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 preact con menos cargador:

    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'),                   
            ];                                                    
        });