Meinst du den Pseudoselektor :empty ?

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

Nein, wahrscheinlich hätte ich es "Regel" nennen sollen ;)
ich meine das

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

Sie werden beim Kompilieren in CSS gelöscht

Warum willst du sie behalten? Sie tun nichts, was in der generierten CSS-Datei leer herumliegt. Sie sagen, dass Sie versuchen, das Styling über Firebug durchzuführen, aber ich verstehe Ihren Ansatz nicht.

1. Ich erstelle leere Regeln in der less-Datei für ein Element oder eine Gruppe von Elementen.
2. Ich öffne Firebug, wähle das Element aus, an dem ich arbeiten möchte, und ich kann die leeren Regeln sehen, die ich erstellt habe
3. Ich schreibe Stile innerhalb dieser leeren Regel
4. Das https://github.com/ronniekk/css-x-fire-Plugin synchronisiert die Änderungen, die ich in Firebug vorgenommen habe, mit der less-Datei, findet die leere Regel und legt dort die in Firebug angegebenen Stile ab.

Voraussetzung ist, dass die Regel bereits vorhanden sein muss, damit das Plugin korrekt wieder synchronisiert wird. Wenn das Element zuvor noch keine Stile hatte, muss ich zum ersten Mal eine leere Regel erstellen. Es funktionierte, wenn ich reines CSS verwendet habe, aber jetzt, als ich zu LESS gewechselt habe, habe ich festgestellt, dass der Compiler die leeren Regeln löscht und das Plugin die Stile nicht zurücksynchronisieren kann.

Mir ist klar, dass das ein ziemlich schmaler Anwendungsfall ist...

Dies scheint ein _sehr_ spezifischer Anwendungsfall zu sein. In den meisten Fällen würden die Leute ihr CSS lieber WENIGER optimieren und _nicht_ leere Regeln hinterlassen.

Ich würde vorschlagen, less.watch() zu verwenden, um Ihre Stile automatisch zu aktualisieren:

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

oder fügen Sie #!watch an Ihre URL an.

Bei Problemen finden Sie hier einige Vorschläge: http://www.paulsprangers.com/2011/04/quick-tip-less-js-in-development-and-watch-mode/

Guter Rat von @Soviut. auch wenn Ihnen das nicht gefällt, fügen Sie zur Umgehung eine gefälschte Regel hinzu, z

temp: ruleset;

Einverstanden. Die Lösung von @agatronic macht, was Sie brauchen, ohne dass jede andere LESS-Datei ineffizientes CSS generiert.

@agatronic das habe ich in den letzten 2 Wochen gemacht, seit ich anfing, weniger zu verwenden, aber ein paar Mal kamen solche gefälschten Regeln in Produktion, weil ich vergessen habe, sie zu entfernen, also dachte ich, vielleicht gibt es einen klareren Weg, das zu beheben :(

@Soviut leider ist das ein völlig anderer Workflow, ich bin nicht bereit, ihn für die Verwendung von Less aufzugeben...

Ich verstehe, dass diese Option nicht hinzugefügt wird, und stimme Ihnen zu, aber wenn das kein Problem ist, können Sie mir bitte sagen, in welcher Quellcodedatei ich das Verhalten selbst ändern kann?

versuch das mal zu ändern

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

@chetzof Ich habe die Lösung dafür gefunden. Das ist nicht der BESTE Weg, aber es funktioniert für das, was Sie suchen.

ich habe es so formuliert:

Selektor { /**/ }

es wird auf Firebug leer erscheinen.

@d4ng3rmax Cooler Punkt!
Ich glaube, ich habe den gleichen Entwicklungsworkflow , den
Danke.

Dieses Ding ist ein Muss für die Verwendung während der Entwicklung mit css-modules .
Es ist wirklich mühsam, während des Gerüstbaus alle Selektoren zu blocken und sie dann zu entfernen.

.main {
/*! keep */
}

.loading {
/*! keep */
}

.button {
/*! keep */
}

.form {
/*! keep */
}

@garkin Was ist Ihre Argumentation / Ihr Anwendungsfall, um Ihre Selektoren mit CSS-Modulen so zu schreiben?

Andernfalls wären sie während der Importphase undefined .

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

Dies führt zu Laufzeitausnahmen und ruiniert den Austausch von Hot-Modulen. Das Verhindern des Entfernens von Selektoren behebt all diese Probleme.
Beim Scaffolding müssen Sie jedoch immer bedenken, dass Selektoren entfernt werden und Sie einen Compiler bekämpfen müssen, um dies zu verhindern. Und dann müssen all diese /*! keep */ Kommentare irgendwann in der Zukunft entfernt werden.

@garkin Hmm ... ist die Antwort nicht nur, um Ihr Stylesheet fertig zu schreiben? Ich sage, es ist ein Problem, das nur durch diesen Entwicklungsansatz verursacht wird.

Wo ich beispielsweise arbeite, verwenden wir je nach Team Less und Sass, und in unserem aktuellen Sass-Build-Setup werden leere Selektoren kein Linting passieren (die App wird nicht kompiliert). Daher war ich gezwungen, einfach meinen Ansatz mit CSS-Modulen / React zu ändern.

Es ist wirklich dieses Muster, das das Problem ist:

{
     [css.loading]: isLoading
}

Wenn Sie zu diesem Muster wechseln, würde dies keine Ausnahme verursachen:

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

In Ihrem Beispiel versuchen Sie, eine Objekteigenschaft mit einem möglicherweise nicht definierten Namen zu definieren. Wenn Sie die Logik ändern, kann Ihre Klasse undefiniert sein und es wird keine Ausnahme ausgelöst.

Dieses sogenannte "Schreiben Ihres Stylesheets fertigstellen" erfordert einen bestimmten kognitiven Kontext und kann viel Zeit in Anspruch nehmen. Es ist viel einfacher, nach dem Gerüstschritt mit Markup und Arbeits-HMR zur Hand zu gehen.

Dieses Muster ist eine dominante und halboffizielle Richtlinie, die vor einiger Zeit Teil der React-Distribution war.
Und diese Probe ist offensichtlich destilliert. Ihr Weg ist nicht lesbar und nicht skalierbar.

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>

CSS-Module sind heutzutage der primäre Ansatz, um Stile zu erstellen und werden es in Zukunft nur noch mehr sein.
Leere Selektoren entfernen - ändert die Code-Semantik umständlich, wenn sie mit CSS-Modulen verwendet wird.

Dieses Verhalten sollte zumindest durch Konfiguration vermeidbar sein.

Das ist interessant. Das Wiedereröffnen nicht nur für diesen Anwendungsfall, sondern weil Less nicht im Geschäft mit der "Säuberung" von CSS sein sollte. Die Option compress wurde aus ähnlichen Gründen veraltet, dh es gibt viele gewartete Tools, die Selektoren entfernen / komprimieren / Präfixe hinzufügen usw.

Wahrscheinlich wurde dieses Verhalten erzeugt, als ein leerer Selektor für den Browser irrelevant war, aber es ist einigermaßen gültig, dass er als Daten nicht irrelevant ist, wenn Sie CSS-Module berücksichtigen.

Wenn nicht jemand Einwände hat, denke ich, dass dies als Option sicher implementiert werden kann. IMO wäre es removeEmptyRulesets (keine Selektoren) mit einem Standardwert von true .

Bearbeiten: oder sollte es keepEmptyRulesets mit einem Standardwert von false ? 🤔 Wahrscheinlich letzteres, da es im undefinierten Zustand eine einfachere Prüfung auf falsche Werte ermöglicht.

wenn Sie CSS-Module einbeziehen

Und es ist nicht nur auf diese beschränkt. Berücksichtigen Sie auch Dinge wie den programmgesteuerten Zugriff über das CSSOM .

Ich würde sagen, dass keepEmptyRulesets eine gute Option zum Hinzufügen ist.
Ein bisschen wortkarg vielleicht. Nicht sehr schön für die CLI: --keep-empty-rulesets

Ein bisschen auf der ausführlichen Seite vielleicht

Ich bin anderer Meinung, aber haben Sie einen alternativen Vorschlag? Es scheint ein sehr spezifisches Verhalten zu sein, daher hilft es manchmal, explizit zu sein. Nichts hindert es daran, keepEmptyRulesets in der API und --keep-rulesets in der CLI zu sein. Oder sogar --keep-empty

Sollte es nur keepEmpty für beide sein?

Ich würde ... benutzen:

1. outputEmptyRulesets : true|false als API-Option;
2. --empty-rulesets als Vollform-CLI-Umschalter; und
3. -er oder möglicherweise -empty als Abkürzung für die CLI-Umschaltung.

@rjgotten Ich bin damit @garkin - wie

Sieht gut aus für mich.

Wann können wir mit der tatsächlichen Umsetzung davon rechnen?
Auch für uns ist dies ein Thema.

@orchidoris PRs willkommen!

Problemumgehungs-Plugin...

Fügt __NOOP__: 1; zu jedem Selektor hinzu und entfernt sie dann, nachdem weniger getan wurde.

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

Für Preact mit weniger Lader:

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