Tufte-css: Pemformatan CSS

Saya memilih standar pemformatan yang digunakan dalam proyek ini karena saya melihat tidak perlu memberi ruang pada kurung kurawal buka atau tutup, dan karena menurut saya garis horizontal yang mengejutkan menjadi penopang visual / mental yang berguna untuk membedakan blok pemilih.

Karena indentasi CSS "standar" _decreases_ dapat dibaca bagi saya, satu-satunya nilai tambah yang saya lihat untuk menggunakannya adalah meningkatkan konsistensi kode dengan proyek eksternal. Bagian dari alasan saya tidak menemukan hal yang sangat meyakinkan adalah karena saya tidak menghabiskan banyak waktu dengan CSS di proyek lain, jadi saya tidak memiliki beban mental yang terlibat dalam pengalihan konteks. Apakah ketidaktahuan itu mengganggu orang lain? Apakah ada manfaat lain dari lekukan "standar" yang tidak saya lihat?

Dalam kasus saya, saya mengonversi banyak ini ke SCSS untuk proyek saya sendiri, dan menyakitkan harus memformat ulang semuanya ke standar. Saya tidak ingat apakah itu hanya untuk menghilangkan peringatan, atau karena itu juga menyebabkan kesalahan. Hal-hal seperti bersarang pasti membutuhkan format ulang.

Itu juga membuat saya tidak kembali untuk pembaruan yang seharusnya lebih mudah digabungkan.

Pada editor dengan softwrapping pada 80 karakter (yang cukup normal) bagian dengan kueri media menjadi sangat berantakan.

Bukannya aku ingin mengeluh! :) Setiap orang memiliki cara yang mereka sukai untuk memformat, hanya memberi tahu Anda pengalaman saya.

Salam,

@ yb66 Konversi SCSS adalah alasan penting yang tidak terlintas dalam pikiran saya.

... tetapi pada pemeriksaan lebih lanjut, bukankah alat seperti http://csstoss.com/ melakukan ini dengan mudah? Atau bahkan hanya memilih semua kurung kurawal buka, tambahkan baris baru setelahnya, lalu pilih semua kurung kurawal tutup, tambahkan baris baru sebelumnya, lalu indentasi ulang file?

Saya juga mengenali masalah soft-wrapping.

i think menentukan format dan memberikan spesifikasi untuk alat linter / formatter tertentu akan sangat membantu. Saya pikir mendukung alat semacam itu dan kemudian menegakkan penggunaannya dengan setiap komit gabungan sebenarnya akan mempermudah orang untuk memberikan kontribusi dan menarik permintaan. Saya tidak berpikir ada orang yang ingin menghabiskan waktu mereka mengutak-atik indentasi dan tanda kurung, ketika Anda bisa menjalankan perintah pada file *.css sebelum melakukan dan menyelesaikannya. Saya tidak peduli tentang format mana yang dipilih, hanya saja itu dapat dipenuhi dengan menjalankan alat baris perintah sederhana sebelum melakukan perubahan.

Salah satu opsinya adalah stylelint.io tetapi ada juga yang lain.

edit: tata bahasa

Maksud saya, kami telah memiliki bagian Panduan Gaya CSS di README sejak kembali pada hari-hari ketika dinosaurus menjelajahi bumi dan melakukan pengiriman dengan kapal melintasi Atlantik. Kebijakan saya dalam menegakkan standar itu telah

1. berharap orang menyesuaikan diri
2. terima PR apa pun
3. memaksa kode yang tidak sesuai secara manual agar sesuai

Proyek ini kurang dari 300 baris. Saya dengan hormat tidak melihat kebutuhan untuk memperkenalkan ketergantungan alat baris perintah untuk mengotomatiskan proses pengambilan 90 detik untuk memperbaiki enam hingga delapan kurung kurawal yang dimiliki kebanyakan PR.

Saya memang lambat menangani bug dan PR, tetapi itu bukan karena masalah gaya, itu karena tekanan waktu eksternal dan kompleksitas pengujian perubahan di banyak perangkat dan skenario.

Poin asli yang saya maksudkan, yang saya minta maaf karena tidak menjelaskannya, adalah bahwa mata seseorang dipaksa untuk berputar-putar untuk membaca kode.

Mari bandingkan pemformatan saat ini dengan dua opsi A dan B.

Arus:

.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%; }

Opsi 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%; }

Opsi 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%;
}

Setelah menulis ratusan ribu baris CSS dalam hidup saya, saya paling terbiasa membaca Opsi B, tetapi saya benar-benar dapat melihat kasus dibuat untuk sesuatu seperti Opsi A. Meskipun demikian, saya kesulitan melihat bagaimana Opsi A tidak tidak melampaui format saat ini dalam keterbacaan. Tentu saja, seperti yang Anda tunjukkan, <300 baris jadi juga bukan masalah besar.

Pada titik ini saya condong ke sesuatu yang lebih konvensional, sehingga lebih mudah dibaca dan sejalan dengan norma CSS di komunitas yang lebih luas. Opsi B sepertinya akan lebih mudah dikenali orang.

Saya akan memilih opsi B juga. Apakah tidak ada cara untuk menentukan format yang dapat dibaca manusia dan dapat dibaca mesin untuk beberapa pemformat / linter?

Saya akhirnya berhasil melakukannya. Terima kasih telah mengangkat masalah ini Adam, dan terima kasih kepada semua orang karena telah menambahkan dua sen Anda.

Silakan , jika Anda punya waktu sebentar, lihat komit (https://github.com/edwardtufte/tufte-css/commit/bfbe3b5c50ee450ba09122f1506233edf6a97ffe) dan beri tahu saya jika A) lekukan atau pernyataan apa pun dapat distandarkan lebih lanjut, atau B) Anda melihat adanya perubahan implementasi. (Saya belum menerapkan cara apa pun untuk menguji perubahan kecuali menggulir dokumen sampel secara manual.)

Ini terlihat bagus untuk saya, @daveliepmann. Saya tahu betapa sulitnya menemukan energi untuk menghadapi masalah lama seperti ini sehingga upaya ini sangat dihargai! Saya sedang dalam proses menerbitkan kembali blog saya ke situs baru, jadi saya akan menggunakan perubahan ini dan memberi tahu Anda jika saya menemukan masalah.

@Davelmann tampak hebat. Terima kasih banyak telah melakukan ini.

@ yb66 Apakah ... apakah Anda memiliki SCSS di suatu tempat? Seperti, di github? Saya menggunakan alat email yang memungkinkan menimpa gaya saat menampilkan bagian mime HTML, dan itu menggunakan SCSS. Saya ingin menggunakan Tufte untuk ini, dan jika seseorang sudah melakukan konversi SCSS, itu akan jauh lebih mudah.

@serussell Bukankah CSS valid SCSS?

@adamschwartz : mengangkat bahu: Itu tidak terpikir oleh saya; Saya bukan pengembang web. Tetapi tampaknya Anda benar: SCSS adalah superset dari CSS. Kabar baik, semuanya!

Bolehkah saya menyarankan juga untuk menggunakan linter! Stylelint menyala seperti hari Natal saat saya menggunakan css di sini. Sementara beberapa di antaranya adalah masalah gaya, ada banyak ketidakkonsistenan juga yang bisa kita singkirkan dengan mudah.