Tufte-css: CSS-Formatierung

Ich habe den in diesem Projekt verwendeten Formatierungsstandard gewählt, weil ich keine Notwendigkeit sehe, offenen oder geschlossenen Klammern Platz zu geben, und weil ich die horizontale Staffelung als nützliche visuelle / mentale Krücke zur Unterscheidung von Auswahlblöcken empfinde.

Da die "Standard" -CSS-Einrückung für mich die Lesbarkeit verringert, besteht der einzige Mehrwert, den ich für die Verwendung sehe, darin, die Codekonsistenz mit externen Projekten zu erhöhen. Ein Grund, warum ich das nicht besonders überzeugend finde, ist, dass ich in anderen Projekten nicht viel Zeit mit CSS verbringe, sodass ich keinen mentalen Aufwand für das Wechseln des Kontexts habe. Stört die Unbekanntheit andere Menschen? Gibt es andere Vorteile für "Standard" -Einrückungen, die ich nicht sehe?

In meinem Fall habe ich viel davon für mein eigenes Projekt in SCSS konvertiert, und es war schmerzhaft, alles auf den Standard umformatieren zu müssen. Ich erinnere mich nicht, ob das nur war, um Warnungen loszuwerden, oder weil es auch Fehler verursachte. Dinge wie das Verschachteln erfordern definitiv eine Neuformatierung.

Es schreckt mich auch davon ab, nach Updates zu suchen, die sonst leichter zusammengeführt werden könnten.

Bei einem Editor mit Softwrapping mit 80 Zeichen (was ziemlich normal ist) werden die Teile mit den Medienabfragen wirklich chaotisch.

Nicht dass ich stöhnen will! :) Jeder hat seine bevorzugten Formatierungsmethoden und teilt Ihnen nur meine Erfahrungen mit.

Grüße,

@ yb66 SCSS-Konvertierung ist ein wesentlicher Grund, der mir nicht in den Sinn gekommen ist.

... aber tun Tools wie http://csstoss.com/ dies bei

Ich erkenne auch das Problem der weichen Verpackung.

Ich denke, die Angabe eines Formats und die Angabe der Spezifikation für ein bestimmtes Linter / Formatierer-Tool wäre sehr hilfreich. Ich denke, die Unterstützung eines solchen Tools und die anschließende Durchsetzung seiner Verwendung bei jedem zusammengeführten Commit würde es den Menschen tatsächlich erleichtern, Beiträge zu leisten und Anfragen zu ziehen. Ich glaube nicht, dass irgendjemand seine Zeit damit verbringen möchte, mit Einrückungen und Klammern herumzuspielen, wenn Sie einfach einen Befehl für die *.css -Datei ausführen könnten, bevor Sie sich verpflichten und damit fertig sind. Es ist mir gleichgültig, welches Format ausgewählt wird, nur dass es durch Ausführen eines einfachen Befehlszeilentools vor dem Festschreiben von Änderungen erfüllt werden kann.

Eine Option ist stylelint.io, aber es gibt auch andere.

bearbeiten: Grammatik

Ich meine, wir haben den Abschnitt CSS Style Guide in der README seit damals, als Dinosaurier die Erde durchstreiften und Commits per Schiff über den Atlantik geschickt wurden. Meine Richtlinie zur Durchsetzung dieses Standards war

1. hoffe, dass sich die Leute anpassen
2. Akzeptieren Sie PRs unabhängig davon
3. Nicht konformen Code manuell zur Konformität zwingen

Dieses Projekt umfasst weniger als 300 Zeilen. Ich sehe respektvoll keine Notwendigkeit, eine Befehlszeilen-Tool-Abhängigkeit einzuführen, um den Prozess zu automatisieren, der 90 Sekunden dauert, um die sechs bis acht Klammern zu korrigieren, die die meisten PRs haben.

Ich habe zwar Fehler und PRs nur langsam behoben, aber das liegt nicht an Stilproblemen, sondern am externen Zeitdruck und der Komplexität des Testens von Änderungen auf vielen Geräten und Szenarien.

Mein beabsichtigter ursprünglicher Punkt, den ich leider nicht klarer formuliere, ist, dass das Auge gezwungen ist, im Zick-Zack herumzulaufen, um den Code zu lesen.

Vergleichen wir die aktuelle Formatierung mit zwei anderen Optionen A und B.

Aktuell:

.table-caption { float:right;
                 clear:right;
                 margin-right: -60%;
                 width: 50%;
                 margin-top: 0;
                 margin-bottom: 0;
                 font-size: 1.0rem;
                 line-height: 1.6; }

.sidenote-number { counter-increment: sidenote-counter; }

.sidenote-number:after, .sidenote:before { content: counter(sidenote-counter) " ";
                                           font-family: et-book-roman-old-style;
                                           position: relative;
                                           vertical-align: baseline; }

.sidenote-number:after { content: counter(sidenote-counter);
                         font-size: 1rem;
                         top: -0.5rem;
                         left: 0.1rem; }

.sidenote:before { content: counter(sidenote-counter) " ";
                   top: -0.5rem; }

blockquote .sidenote, blockquote .marginnote { margin-right: -82%;
                                               min-width: 59%;
                                               text-align: left; }    

p, footer, table, div.table-wrapper-small, div.supertable-wrapper > p, div.booktabs-wrapper { width: 55%; }

Option A.

.table-caption               { float:right;
                               clear:right;
                               margin-right: -60%;
                               width: 50%;
                               margin-top: 0;
                               margin-bottom: 0;
                               font-size: 1.0rem;
                               line-height: 1.6; }

.sidenote-number             { counter-increment: sidenote-counter; }

.sidenote-number::after,
.sidenote::before            { content: counter(sidenote-counter) " ";
                               font-family: et-book-roman-old-style;
                               position: relative;
                               vertical-align: baseline; }

.sidenote-number::after      { content: counter(sidenote-counter);
                               font-size: 1rem;
                               top: -0.5rem;
                               left: 0.1rem; }

.sidenote::before            { content: counter(sidenote-counter) " ";
                               top: -0.5rem; }

blockquote .sidenote,
blockquote .marginnote       { margin-right: -82%;
                               min-width: 59%;
                               text-align: left; }    

p,
footer,
table,
div.table-wrapper-small,
div.supertable-wrapper > p,
div.booktabs-wrapper         { width: 55%; }

Option B:

.table-caption {
  float: right;
  clear: right;
  margin-right: -60%;
  width: 50%;
  margin-top: 0;
  margin-bottom: 0;
  font-size: 1.0rem;
  line-height: 1.6;
}

.sidenote-number {
  counter-increment: sidenote-counter;
}

.sidenote-number::after,
.sidenote::before {
  content: counter(sidenote-counter) " ";
  font-family: et-book-roman-old-style;
  position: relative;
  vertical-align: baseline;
}

.sidenote-number::after {
  content: counter(sidenote-counter);
  font-size: 1rem;
  top: -0.5rem;
  left: 0.1rem;
}

.sidenote::before {
  content: counter(sidenote-counter) " ";
  top: -0.5rem;
}

blockquote .sidenote,
blockquote .marginnote {
  margin-right: -82%;
  min-width: 59%;
  text-align: left;
}

p,
footer,
table,
div.table-wrapper-small,
div.supertable-wrapper > p,
div.booktabs-wrapper {
  width: 55%;
}

Nachdem ich in meinem Leben Hunderttausende von Zeilen CSS geschrieben habe, bin ich es am meisten gewohnt, Option B zu lesen, aber ich kann absolut sehen, dass ein Fall für etwas wie Option A gemacht wird. Abgesehen davon fällt es mir schwer zu sehen, wie Option A dies nicht tut Überschreiten Sie nicht die aktuelle Formatierung in Lesbarkeit. Wie Sie hervorheben, sind es natürlich <300 Zeilen, also ist es auch keine große Sache.

An diesem Punkt neige ich zu etwas Konventionellerem, damit es besser lesbar ist und den CSS-Normen in der breiteren Community entspricht. Option B scheint für die Leute besser erkennbar zu sein.

Ich würde mich auch für Option B entscheiden. Gibt es keine Möglichkeit, ein Format anzugeben, das für mehrere Formatierer / Linters lesbar und maschinenlesbar ist?

Ich bin endlich dazu gekommen. Vielen Dank, dass Sie dieses Problem angesprochen haben, Adam, und vielen Dank an alle anderen, die Ihre zwei Cent hinzugefügt haben.

Wenn Sie eine Minute Zeit haben, schauen Sie sich bitte das Commit an (https://github.com/edwardtufte/tufte-css/commit/bfbe3b5c50ee450ba09122f1506233edf6a97ffe) und lassen Sie mich wissen, ob A) Einrückungen oder Anweisungen weiter standardisiert werden könnten oder B) Sie bemerken Änderungen an der Implementierung. (Ich habe keine Möglichkeit implementiert, Änderungen zu testen, außer manuell durch das Beispieldokument zu scrollen.)

Es sieht gut aus für mich, @daveliepmann. Ich weiß, wie schwer es sein kann, die Energie zu finden, um sich alten Problemen wie diesen zu stellen, daher wird die Anstrengung sehr geschätzt! Ich bin gerade dabei, mein Blog auf einer neuen Website erneut zu veröffentlichen, daher werde ich diese Änderungen verwenden und Sie informieren, wenn ich Probleme finde.

@daveliepmann sieht

@ yb66 Hast du irgendwo dein SCSS in der

@serussell Ist CSS nicht SCSS gültig?

@adamschwartz : Achselzucken: Mir ist das nicht

Darf ich auch vorschlagen, einen Linter zu verwenden! Stylelint leuchtet wie Weihnachten, wenn ich das CSS hier benutze. Während einige davon ein Thema des Stils sind, gibt es auch viele Inkonsistenzen, die wir leicht beseitigen können.