Vous voulez dire le pseudo-sélecteur :empty ?

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

Non, j'aurais probablement dû appeler ça une "règle" ;)
je veux dire ça

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

Ils sont supprimés lors de la compilation en css

Pourquoi voudriez-vous les garder? Ils ne font rien qui traîne en blanc dans le fichier CSS généré. Vous dites que vous essayez de faire du style via Firebug, mais je ne comprends pas quelle est votre approche.

1. Je crée des règles vides dans le fichier less pour un élément ou un groupe d'éléments.
2. J'ouvre firebug, je sélectionne l'élément sur lequel j'ai l'intention de travailler et je peux voir les règles vides que j'ai créées
3. J'écris des styles à l'intérieur de cette règle vide
4. Le plugin https://github.com/ronniekk/css-x-fire synchronise les modifications que j'ai apportées dans firebug vers moins de fichier, il trouve la règle vide et y met les styles que j'ai spécifiés dans firebug.

L'exigence est que la règle existe déjà pour que le plugin se synchronise correctement, et évidemment, si l'élément n'a pas eu de styles auparavant, je devrai créer une règle vide pour la première fois. Cela fonctionnait lorsque j'utilisais du CSS pur, mais maintenant, lorsque je suis passé à LESS, j'ai réalisé que le compilateur supprime les règles vides et que le plugin est incapable de synchroniser les styles.

Je me rends compte que c'est un cas d'utilisation assez étroit...

Cela semble être un cas d'utilisation _très_ spécifique. Dans la plupart des cas, les gens préféreraient MOINS optimiser leur CSS et _n'ont pas_ laissé de règles vides.

Je suggérerais d'utiliser less.watch() pour actualiser automatiquement vos styles :

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

ou ajoutez #!watch à votre URL.

Si vous rencontrez des problèmes, voici quelques suggestions : http://www.paulsprangers.com/2011/04/quick-tip-less-js-in-development-and-watch-mode/

De bons conseils de @Soviut. aussi si vous n'aimez pas ça, pour contourner le problème, ajoutez une fausse règle, par exemple

temp: ruleset;

D'accord. La solution de @agatronic fait ce dont vous avez besoin sans que chaque autre fichier LESS génère un CSS inefficace.

@agatronic c'est ce que je faisais au cours des 2 dernières semaines depuis que j'ai commencé à utiliser LESS, mais quelques fois, de telles fausses règles sont entrées en production parce que j'ai oublié de les supprimer, alors j'ai pensé qu'il y avait peut-être un moyen plus clair de résoudre ce problème :(

@Soviut, malheureusement, c'est un flux de travail entièrement différent, je ne suis pas prêt à l'abandonner pour utiliser Less... l'utilisation de moins de compilateur dans le navigateur a également causé de sérieux problèmes de performances, la charge de la page est passée de 500-700 ms à 2-3 s..

Je comprends que cette option ne sera pas ajoutée, et je suis d'accord avec vous, mais si ce n'est pas un problème, pouvez-vous me dire s'il vous plaît dans quel fichier de code source je peux changer le comportement par moi-même ?

essaie de changer ça

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

@chetzof J'ai trouvé la solution pour cela. ce n'est pas la MEILLEURE façon, mais cela fonctionne pour ce que vous recherchez.

j'ai mis ainsi :

sélecteur { /**/ }

il apparaîtra vide sur firebug.

@d4ng3rmax Point
Je pense que j'ai le même workflow de développement que @chetzof mentionné.
THX.

Cette chose est indispensable à utiliser pendant le développement avec css-modules .
C'est vraiment fastidieux de passe-partout tous les sélecteurs lors de l'échafaudage et de parvenir ensuite à les retirer.

.main {
/*! keep */
}

.loading {
/*! keep */
}

.button {
/*! keep */
}

.form {
/*! keep */
}

@garkin Quel est votre raisonnement / cas d'utilisation pour écrire vos sélecteurs comme ça avec des modules CSS ?

Sinon, ils seraient undefined lors de la phase d'importation.

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

Cela conduit à des exceptions d'exécution et ruine le remplacement de module à chaud. Empêcher les sélecteurs de supprimer résout tous ces problèmes.
Mais lors de l'échafaudage, vous devez toujours garder à l'esprit que les sélecteurs seront supprimés et que vous devez combattre un compilateur pour l'empêcher. Et puis tous ces /*! keep */ commentaires doivent être supprimés dans le futur.

@garkin Hmm... n'est-ce pas la réponse juste pour finir d'écrire votre feuille de style ? Je dis que c'est un problème causé uniquement par cette approche de développement.

Par exemple, là où je travaille, nous utilisons Less et Sass en fonction de l'équipe, et dans notre configuration de construction Sass actuelle, les sélecteurs vides ne passeront pas le linting (l'application ne compilera pas). J'ai donc été obligé de simplement changer mon approche avec les modules CSS / React.

C'est vraiment ce modèle qui pose problème :

{
     [css.loading]: isLoading
}

Si vous changez de modèle, cela ne causera pas d'exception :

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

Dans votre exemple, vous essayez de définir une propriété d'objet avec un nom qui peut être indéfini. Si vous changez la logique, votre classe peut être indéfinie et aucune exception ne sera levée.

Ce que l'on appelle « finir l'écriture de votre feuille de style » nécessite un contexte cognitif spécifique et peut prendre beaucoup de temps. C'est beaucoup plus facile à faire après l'étape d'échafaudage avec le balisage et le travail HMR à portée de main.

Ce modèle est une directive dominante et semi-officielle à utiliser, il faisait partie de la distribution React il y a quelque temps.
Et cet échantillon est évidemment distillé. Votre chemin n'est ni lisible ni évolutif.

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>

Les modules CSS sont la principale approche pour créer des styles de nos jours et ne le seront que davantage à l'avenir.
Supprimer les sélecteurs vides - modifie de manière alambiquée la sémantique du code lorsqu'il est utilisé avec des modules css.

Ce comportement doit être au moins évitable par la configuration.

C'est intéressant. Réouverture non seulement pour ce cas d'utilisation, mais parce que Less ne devrait pas s'occuper de "nettoyer" CSS. L'option compress été dépréciée pour des raisons similaires, c'est-à-dire qu'il existe de nombreux outils maintenus qui supprimeront les sélecteurs/compresseront/ajouteront des préfixes, etc.

Ce comportement a probablement été créé lorsqu'un sélecteur vide n'était pas pertinent pour le navigateur, mais il est assez valable qu'il ne soit pas sans importance en tant que données lorsque vous prenez en compte les modules CSS.

En fait, à moins que quelqu'un ne s'y oppose, je pense que cette option est sûre à mettre en œuvre. IMO, ce serait removeEmptyRulesets (pas de sélecteurs) avec une valeur par défaut de true .

Edit : ou devrait-il s'agir de keepEmptyRulesets avec une valeur par défaut de false ? 🤔 Probablement le dernier, car il facilite les vérifications de faux lorsqu'il n'est pas défini.

lorsque vous prenez en compte les modules CSS

Et ce n'est pas limité à ceux-là seulement. Considérez également des choses comme l'accès programmatique via le CSSOM .

Je dirais que keepEmptyRulesets est une bonne option à ajouter.
Un petit peu verbeux, peut-être. Pas très sympa pour la CLI : --keep-empty-rulesets

Un petit peu sur le côté verbeux, peut-être

Je ne suis pas en désaccord, mais avez-vous une autre suggestion? Cela semble être un comportement très spécifique, donc parfois il est utile d'être explicite. Rien ne l'empêche d'être keepEmptyRulesets dans l'API et --keep-rulesets dans la CLI. Ou même --keep-empty

Cela devrait-il être juste keepEmpty pour les deux ?

J'utiliserais:

1. outputEmptyRulesets : true|false comme option API ;
2. --empty-rulesets tant que bascule CLI pleine forme ; et
3. -er ou éventuellement -empty comme bascule de raccourci CLI.

@rjgotten Je suis d'accord avec ça. Je ne suis pas investi émotionnellement lol. @garkin - que pensez-vous de cela ?

Ça m'a l'air bien.

Quand pouvons-nous nous attendre à sa mise en œuvre effective ?
C'est aussi un problème pour nous.

@orchidoris PRs bienvenus!

Plugin de contournement...

Ajoute __NOOP__: 1; à chaque sélecteur, puis les supprime une fois que moins est fait.

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

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