CSS: auskommentieren ganzer Bereiche (incl. Kommentare)

Ist das nicht Geschmackssache?
Übrigens kann man auch mit einem doppelten Schrägstrich auskommentieren... dies gilt für die jeweilige Scriptzeile..

:root {
//Kommentar 1
--var-f1: rot;
//Kommentar 12 
usw.

Edit: siehe den Hinweis von Andi

Zitat von Boersenfeger

auch mit einem doppelten Schrägstrich auskommentieren

In Scripten ja, in css Codes nein.

Ich nutze mit Notepad++ auch diese Methode und da wird in.css-Dateien das Auskommentierte grün dargestellt... aber wie gesagt: es ist Geschmackssache... dem Fuchs wirds eh egal sein...
[attachment=0]Unbenannt.PNG[/attachment]

Zitat von Boersenfeger

da wird in.css-Dateien das Auskommentierte grün dargestellt

Richtig, aber nicht durch 2 // sondern durch /*..*/

@ 2002Andreas, HT-Frogger: siehe mein Screenshot... den Doppelstrich hatte ich weiter unten für CSS ja schon wieder rausgenommen...

Zitat von HT-Frogger

Wenn ich einen ganzen Bereich als Vorbereitung auskommentiert haben möchte, der wiederum auch Kommentare beinhaltet, dann ist das schwierig. Kommentare sind ja leider nicht verschachtelbar.

Ja, das ist bei CSS etwas unflexibel. Im Sinne von Auskommentieren kannst Du so etwas tun – dein Beispiel:
(Nebenbei: Was ist eigentlich ein Kommetar? :wink: Ich vertippe mich übrings auch oft.)

/*
:root {
 /* Kommetar 1 */
/*
 --var-f1: rot;
 /* Kommetar 12 */
/*
 --var-f2: gruen;
 ...
}
*/

Zitat

Wenn das jetzt als Vorbereitung auskommentiet sein soll, was ist dann besser bzw was wird empfohlen?

Code

1: :root.auskommentiert {...}
2: :root:empty {...}
3: #auskommentiert {...}
4: auskommentiert {...}
5: {...}
6. /* :root */ {...}

Funktionieren tut alles, aber was ist sinnvoll und sowohl für den FF als auch für den User am verständlichsten und am einfachsten zu interpretieren?

Mit dem Funktionieren ist es so eine Sache: Nur Variante 6 nutzt wirklich die Methode des Auskommentierens, erzeugt aber eine defekte Regel, weil der Selektor nun fehlt. Methode 5 verstehe ich nicht, bei 1,3 und 4 wird ein/-e Klasse, ID oder Element verwendet, wo man darauf hoffen muss, dass sie nicht existieren und außerdem ist das im Code nicht so offensichtlich – für dich allein mag das in Ordnung sein, aber nicht beim Veröffentlichen. Sehr ähnlich Meth. 2, die davon ausgeht, dass es keine leere root gibt, was, äähm, der Normalfall sein sollte, aber nicht einfach verständlich ist. Das allerdings kann man in einem Kommentar davor erläutern, weshalb ich diese bevorzugen würde. Letzteres gilt aber auch für Methode 1.

/*
 * Zum Aktivieren Kommentar tauschen:
 * Vor erster Zeile / und * ergänzen und vor der zweiten Zeile entfernen,
 * zum Deaktivieren umgekehrt vorgehen.
 */
:root.auskommentiert { /* inaktiv, da keine Klasse "auskommentiert" existiert */
/* :root { /* aktiv */
 --var-f1: rot; /* Kommentar 1 */
 --var-f2: gruen; /* Kommentar 12 */
 ...
}

oder

/*
 * Zum Aktivieren Kommentar tauschen:
 * Vor erster Zeile / und * ergänzen und vor der zweiten Zeile entfernen,
 * zum Deaktivieren umgekehrt vorgehen.
 */
:root:empty { /* inaktiv, da root üblicherweise nicht leer ist */
/* :root { /* aktiv */
 --var-f1: rot; /* Kommentar 1 */
 --var-f2: gruen; /* Kommentar 12 */
 ...
}

Ich arbeite eigentlich nur noch mit Präprozessoren wie SASS oder LESS (in der Regel SASS [1]) und lasse mir dann die CSS-Datei automatisch bei Änderungen neu generieren. Damit sind einzeilige Kommentare mit "//", Verschachtelung und noch viele weitere coole Dinge möglich, die CSS nicht kann. Ich erhalte am Ende automatisch valides CSS.

[1] http://sass-lang.com/

Zitat von HT-Frogger

Ein deutsch geschriebener Name ist zumindest in der useCrome.css unüblich und deshalb nicht vorhanden.

useCrome.css? :wink:

Ääh, ja. Das bezieht sich auf die Firefox-Interna und eine deutschsprachige Klasse ist dort sehr unwahrscheinlich.

Zitat

5 und 6 sind an sich gleich, es ist kein Name angegeben, ob gar nicht oder auskommentiert ist ja egal. Ob der fehlende Selektor schlimmer ist als einer den es nicht gibt?

Ach so, bei Nr. 5 würdest Du :root entfernen. Das ist neben dem Fehler sogar noch unübersichtlicher als mit Nr. 6. Ein fehlender Selektor erzeugt einen Fehler, eine Regel mit einem nicht existierenden oder bisher nicht genutzten Selektor wird einfach ignoriert, also ist die Antwort: Ja, es ist schlimmer. Genauer ist es schlimm versus nicht schlimm.

Zitat

Die Frage zielte ja auch darauf, ob es evt eine (inoffizielle) Norm-Lösung dafür gibt oder was der FF lieber mag.

Solange es ohne Fehler ist, ist dem Firefox egal. Eine Standardlösung gibt es meines Erachtens nicht.

Zitat

Ich nehme z.Z. Lösung 6.

Solange Du das nicht veröffentlichst, tu, was Du willst. Du bist gewarnt, dass das syntaktisch fehlerhaft ist, so dass es von heute auf morgen zu unerwarteten Ergebnissen führen kann.

Zitat von HT-Frogger

Wenn ich einen ganzen Bereich als Vorbereitung auskommentiert haben möchte, der wiederum auch Kommentare beinhaltet, dann ist das schwierig. Kommentare sind ja leider nicht verschachtelbar.

Hm, irgendwie stehe ich gerade auf dem Schlauch. Was muss ich mir denn unter "ganzen Bereich als Vorbereitung" vorstellen?

Zitat von HT-Frogger

@ Sören:
Sass oder sowas würde doch hier in der useCrome.css bestimmt nicht laufen, oder?

Es ist vollkommen egal, was das für eine CSS-Datei ist. Die Eingabe-Datei ist nicht gleich die Ausgabe-Datei, sondern eine andere Datei. Man schreibt SASS, der Präprozessor kompiliert daraus eine CSS-Datei.

Zitat von HT-Frogger

Auf meiner Webseite schicke ich die CSS-Datei auch über den PHP-Parser und mache da PHP-Kommentare rein, die werden auch nicht mit gesendet und sparen Bandbreite.

Ich bezweifle allerdings, dass du Performance auf diese Weise einsparst, wenn du deine CSS-Dateien serverseitig verarbeitest, und dann auch noch in PHP, was ja nun nicht gerade für seine Geschwindigkeit berühmt ist. Auf dem Server sollte bereits eine fertige CSS-Datei liegen. Die ganze Verarbeitung sollte Teil des Deployment-Prozesses sein, d.h. ein einmaliger Vorgang nach jeder Änderung am Code und wenn es keine Änderung gibt, wird die fertige CSS-Datei geladen.

Zitat von HT-Frogger

Die Frage zielte ja auch darauf, ob es evt eine (inoffizielle) Norm-Lösung dafür gibt oder was der FF lieber mag. Ich nehme z.Z. Lösung 6.

Für den Browser ist das vollkommen egal, wenn du mit allen Lösungen dein Ziel erreichst. Wir reden hier ja nicht von Millionen Zeilen, nehme ich an. Du wirst an dieser Stelle nichts im spürbaren Bereich optimieren können.

Zitat von HT-Frogger

Die Frage ist nur, was ist besser bzw schneller? Erkennbar ist das für mich nicht...

Wie gesagt, von der Performance her ist das egal, wie du das machst.

Zitat von HT-Frogger

@ Sören:
Ich kann bei meiner Webseite die .htaccess nur sehr eingeschränkt nutzen. Deshalb benutze ich eben viel PHP, auch um Dateien (auch die css- und js-Dateien) gepackt auszuliefern und um mit Variablen arbeiten zu können etc. Das klappt alles gut und browserunabhängig.

.htaccess ist ein ganz anderes Thema. Ich sprach ja von Deployment und dieser Begriff bezeichnet den Prozess, eine neue Version der Webseite auf den Server zu bringen. Die ganze Verarbeitung sollte spätestens in diesem Schritt passieren, damit du serverseitig überhaupt nichts mehr verarbeiten musst. Das kostet nämlich reale Performance.

Zitat von HT-Frogger

Um SASS muß ich mich noch mal schlau machen was damit alles geht. Aber ich glaube, daß ist eher was für den, der seine Brötchen damit verdienen muß. Ich möchte lieber selbst optimieren, auch wenn es länger dauert...

Nein, das hat überhaupt nichts damit zu tun, ob man damit seine Brötchen verdienen muss oder nicht. Es hat damit zu tun, ob man effizient arbeiten will. Präprozessoren vereinfachen das Leben. Wenn man noch nie damit gearbeitet hat, bedeutet das natürlich Einarbeitung. Und ob nun beruflich oder als Hobby: das ist letzten Endes eine Zeitfrage für diesen einmaligen Aufwand, sich damit zu beschäftigen. Die Zeit kann und will man aufbringen oder nicht.

Zitat von HT-Frogger

Ich benutze ja auch Linux, weil:
Linux ist fuer Leute, die wissen wollen, warum ihr Rechner funktioniert.
MacOS ist fuer Leute, die nicht wissen wollen, warum ihr Rechner funktioniert.
DOS ist fuer Leute, die wissen wollen, warum ihr Rechner nicht funktioniert.
Windows ist fuer Leute, die nicht wissen wollen, warum ihr Rechner nicht funktioniert.

Ich hoffe mal, dass das als Scherz gemeint war, aber auch dann muss ich sagen, dass dieser Scherz extrem schlecht ist. Übrigens ist gerade im Entwickler-Segment macOS extrem verbreitet und du merkst sicher, dass die Aussage dazu nicht passt.

Zitat von HT-Frogger

@ EffPeh:
Ja, aktuell gerade über 100 Zeilen mit Variablen-Wertzuweisungen und etlichen Kommentaren wenn man ein anderes Farbschema probiert. Aber auch sonst wenn man was ausprobiert und erst nächste Woche oder noch später weitermachen möchte. Also größere Bereiche inclusive diverser Kommentare.

Und warum lagerst du das dann nicht einfach per include aus?
Dann musst du doch nur die eine include-Zeile auskommentieren.

Ne, tut mir Leid. Aber wenn ich das lese, wird klar, dass dein Verständnis von macOS als Betriebssystem wirklich gegen null geht. Du hast ein Vorurteil nach dem Motto "Schicki-Micki-System für dumme Designer" und das trifft's halt überhaupt nicht. Das hat dann auch nichts mehr mit Ironie zu tun. Vor allem, was du mit Linux erreichen willst, was du mit macOS nicht möglich sein soll, ist mir ein absolutes Rätsel. Also bitte erst einmal mit macOS befassen, bevor du dich mit Scherzen darüber befasst. Lustig ist's wirklich nur, wenn es einen wahren Kern gibt.