@daveliepmann c15070ca84f19cfa994dd38bb92adccb1d4fbed7で作業して#90のループを閉じた後、このプロジェクトで使用されている奇妙なインデント/フォーマットを発見しました。 驚いたことに、CSSソースを実際に見たことがなかったと思います。 tufte.css
標準のインデントを使用することについてどう思いますか?
このプロジェクトで使用するフォーマット標準を選択したのは、中括弧または中括弧にスペースを与える必要がなく、水平方向のずらしがセレクターブロックを区別するための視覚的/精神的な松葉杖であることがわかったためです。
「標準的な」CSSインデントは私にとって読みやすさを_低下させる_ので、それを使用することで私が目にする唯一の付加価値は、外部プロジェクトとのコードの一貫性を高めることです。 非常に説得力がないと思う理由の1つは、他のプロジェクトでCSSにあまり時間を費やしていないため、コンテキストの切り替えに伴う精神的なオーバーヘッドがないことです。 不慣れは他の人にとって破壊的ですか? 「標準」インデントには、私には見えない他の利点がありますか?
私の場合、私は自分のプロジェクトのためにこれの多くをSCSSに変換しました、そしてすべてを標準に再フォーマットしなければならないのは苦痛でした。 それが単に警告を取り除くためだったのか、それともエラーを引き起こしたからなのかは覚えていません。 入れ子のようなものは間違いなく再フォーマットが必要です。
それはまた、そうでなければより簡単にマージされるであろうアップデートのために私が戻ってくるのを延期します。
80文字でソフトラッピングするエディター(これはかなり正常です)では、メディアクエリの部分が非常に乱雑になります。
うめき声を上げたいわけではありません! :)誰もが自分の好みのフォーマット方法を持っており、私の経験を知らせてくれます。
よろしく、
@ yb66 SCSS変換は、私の頭に浮かばなかった大きな理由です。
...しかし、さらに詳しく調べてみると、 http://csstoss.com/のようなツールはこれをかなり苦痛なく行いませんか? または、すべての中括弧を選択し、後に改行を追加してから、すべての中括弧を選択し、前に改行を追加してから、ファイルを再度インデントしますか?
ソフトラッピングの問題も認識しています。
フォーマットを指定し、特定のリンター/フォーマッターツールの仕様を提供することは非常に役立つと思います。 そのようなツールをサポートし、マージされたコミットごとにその使用を強制することで、実際に人々が貢献したりリクエストをプルしたりするのが簡単になると思います。 コミットする前に*.css
ファイル
1つのオプションはstylelint.ioですが、他にもあります。
編集:文法
つまり、恐竜が地球を歩き回り、コミットが大西洋を越えて船で送られた時代から、READMEにCSSスタイルガイドのセクションがありました。 その基準を実施することに関する私の方針は
このプロジェクトは300行未満です。 ほとんどのPRが持っている6〜8個の中括弧を修正するのに90秒かかるプロセスを自動化するために、コマンドラインツールの依存関係を導入する必要はないと思います。
私は確かにバグやPRへの対処に時間がかかっていますが、それはスタイルの問題によるものではなく、外部の時間的プレッシャーと、多くのデバイスやシナリオにわたる変更のテストの複雑さによるものです。
はっきりさせていないのが残念ですが、私の意図した本来のポイントは、コードを読むために目をジグザグに動かさなければならないということです。
現在のフォーマットを他の2つのオプションAおよび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%; }
オプション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%; }
オプション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%;
}
私の人生で数十万行のCSSを書いたことで、私はオプションBを読むことに最も慣れていますが、オプションAのようなケースが作成されていることは絶対にわかります。読みやすさで現在のフォーマットを超えないでください。 もちろん、ご指摘のとおり、300行未満なので、どちらにしても大したことではありません。
この時点で、私はより従来型のものに傾倒しているので、より読みやすく、より広いコミュニティのCSS基準に沿っています。 オプションBは、人々にとってより認識しやすいように思われます。
私もオプションBに行きます。 いくつかのフォーマッター/リンターに対して、人間が読み取れる形式と機械が読み取れる形式を指定する方法はありませんか?
私はついにこれに取り掛かりました。 この問題を提起してくれてありがとうアダム、そしてあなたの2セントを追加してくれた他のみんなに感謝します。
時間があれば、コミット(https://github.com/edwardtufte/tufte-css/commit/bfbe3b5c50ee450ba09122f1506233edf6a97ffe)を見て、A)インデントやステートメントをさらに標準化できるかどうかをお知らせください。 B)実装の変更に気づきました。 (サンプルドキュメントを手動でスクロールする以外に、変更をテストする方法は実装していません。)
@daveliepmann、私には良さそうです。 このような古い問題に直面するエネルギーを見つけるのがどれほど難しいかを知っているので、努力は大いに感謝されます! ブログを新しいサイトに再公開している最中なので、これらの変更を使用して、問題が見つかった場合はお知らせします。
@daveliepmannは
@ yb66 Do ...どこかにSCSSがありますか? のように、githubで? HTMLMIMEパーツを表示するときにスタイルをオーバーライドできる電子メールツールを使用しています。これはSCSSを使用します。 これにはTufteを使用したいと思います。誰かがすでにSCSS変換を行っている場合は、それがはるかに簡単になります。
@serussell CSSは有効なSCSSではありませんか?
@adamschwartz :
リンターの使用もお勧めします。 ここでcssを使用すると、Stylelintがクリスマスのように点灯します。 それらのいくつかはスタイルの問題ですが、私たちが簡単に取り除くことができる多くの矛盾もあります。
最も参考になるコメント
この時点で、私はより従来型のものに傾倒しているので、より読みやすく、より広いコミュニティのCSS基準に沿っています。 オプションBは、人々にとってより認識しやすいように思われます。