Rumah > hujung hadapan web > tutorial css > Pembuatan CSS Atom: Temu bual dengan Thierry Koblentz

Pembuatan CSS Atom: Temu bual dengan Thierry Koblentz

Lisa Kudrow
Lepaskan: 2025-03-14 09:44:17
asal
911 orang telah melayarinya

Pembuatan CSS Atom: Temu bual dengan Thierry Kobleentz

Artikel ini wawancara Thierry Kobleentz, pencipta CSS Atom, untuk mendapatkan pandangan yang mendalam mengenai sejarah dan konteks di sebalik kerangka CSS yang popular ini. Thierry kini bersara dan mempunyai pengalaman yang luas dalam menulis CSS yang besar, dan telah bekerja sebagai jurutera depan di Yahoo.

Thierry secara meluas dianggap sebagai membawa konsep CSS atom ke arus perdana untuk artikel klasiknya 2013 "Praktik Terbaik CSS yang mencabar" pada Smashing Magazine. Artikel ini membuka jalan untuk banyak perpustakaan CSS yang popular selama bertahun -tahun. Dalam wawancara ini, Thierry mengkaji sejarah CSS atom dan mencerminkan kesannya yang berterusan.

Kembali pada awal abad ke -21, bagaimana anda memasuki bidang pembangunan web, terutama bagaimana anda membuat hidup dengan menulis CSS?

Thierry Kobletz: Selepas berpindah ke Amerika Syarikat pada tahun 1997, saya mengajar diri saya HTML, CSS dan JavaScript sebagai hobi.

Pada masa itu, saya menggunakan FrontPage dan sangat bergantung pada kumpulan berita untuk bimbingan. Saya dengan cepat menjadi pelanggan biasa kumpulan berita Macromedia dan CSS-Discuss. Awalnya, saya menyokong Falsafah Projek Standard Web dan mengembangkan minat yang kuat dalam kebolehaksesan. Selama bertahun -tahun, hujung depan hanya hobi bagi saya (pekerjaan sebenar saya adalah peniaga antik). Saya akan membuat laman web sekali -sekala, tetapi saya terutamanya menulis dan menerbitkan (banyak) teknik perkongsian artikel yang saya pelajari atau "ditemui".

Ini berbayar untuk panggilan Yahoo pada tahun 2007, bertanya kepada saya jika saya dapat membantu membetulkan dan membina lembaran gaya untuk Template Laman Web Penyelesaian Laman Web (YSS). Penerangan Pekerjaan: Tiada HTML, tiada JavaScript, hanya CSS! Dan banyak!

Apakah pekerjaan harian anda di yahoo?

TK: Peranan saya di Yahoo telah banyak berubah sejak bertahun -tahun.

Tugas pertama saya adalah untuk membuat lembaran gaya untuk templat YSS (serupa dengan CSS Zen Garden). Kemudian, sebelum YSS "dihantar" ke Bangalore (India), saya menulis semula tanda -tanda dan gaya laman web YSS - di mana rakan -rakan saya dan saya dihantar untuk "pemindahan pengetahuan".

Dengan cara ini, ia adalah cabaran untuk menggantikan stylesheets untuk membuat reka bentuk yang berbeza untuk YSS yang memaksa kita untuk mencari penyelesaian ringan (bukan JS) untuk mengubah saiz video dengan cepat;

Selepas YSS, saya berpeluang hanya mengambil bahagian dalam projek bermula dari awal (menulis semula atau sebaliknya), dan saya semakin terlibat dalam kerja front-end Yahoo. Saya mengedit dan membuat banyak dokumen pengekodan CSS) Tulis cadangan;

Satu lagi nota tambahan bahawa dalam lapan tahun saya di Yahoo, saya mungkin tidak mempunyai 100 baris kod JavaScript. Jika saya tidak berhenti atau dipecat, terima kasih kepada Lingyan Zhu dan Renato Iwashima;

Apakah amalan penulisan CSS yang popular pada masa itu?

TK: Pada hari-hari awal, tidak ada perpustakaan atau kaedah yang diterbitkan; Di laman web lama saya, saya juga mempunyai komen seperti ini:

<code></code>
Salin selepas log masuk

Segala -galanya adalah persaingan yang adil, semuanya disalahgunakan kerana kita hanya mempunyai set alat yang sangat terhad dan perlu melakukan banyak perkara.

Tetapi apabila saya menyertai Yahoo, perkara berubah secara dramatik. Pemaju dari UK adalah penyokong piawaian web yang kuat dan saya berterima kasih kepada mereka atas pengaruh mereka terhadap bagaimana HTML dan CSS Yahoo ditulis. Penandaan semantik adalah realiti, dan CSS adalah "t" yang ditulis mengikut prinsip pemisahan kebimbangan (SOC) (walaupun kadang -kadang terlalu berminat untuk saya).

Yui mempunyai komponen CSS, tetapi tidak mempunyai rangka kerja CSS lagi. Terdapat perpustakaan CSS dalaman (dipanggil LEGO) tetapi saya tidak pernah menggunakannya. OOCSS, SMACSS, ECSS (Salut kepada Ben), BEM, Bootstrap, Kaedah dan Perpustakaan dan Perpustakaan lain akan muncul tidak lama lagi.

Bagaimanakah idea CSS atom berlaku?

TK: Sebelum YSS berpindah ke India, pengurus saya Michael Montesano bertanya sama ada ada cara untuk mendapatkan pasukan di Bangalore untuk mengelakkan lembaran gaya penyuntingan, dengan itu mengurangkan risiko kerosakan . Saya fikir pengalaman templat YSS (pelanggan berbayar mengadu tentang halaman yang rosak) menjadikannya sangat paranoid apabila membuat sebarang perubahan pada lembaran gaya.

Oleh itu, dengan semangat perpustakaan EZ -CSS saya, saya mencipta "Jadual Utiliter" - meja yang direka untuk membolehkan pemaju melaksanakan gaya mereka tanpa mengedit atau menambah peraturan ke lembaran gaya .

Beberapa tahun kemudian, Michael, kemudian pengarah kejuruteraan, bertanya kepada saya jika saya boleh mengubah reka bentuk laman web Yahoo menggunakan kelas utiliti hanya kerana dia tahu bahawa sekali lagi kita tidak akan bertanggungjawab untuk penyelenggaraan laman web. Kami membincangkan mengutamakan kelas utiliti ke atas kelas semantik, dan saya tidak fikir bahawa pada tahap itu tidak wujud pada masa itu. Ini adalah langkah yang sangat berani.

Latihan besar -besaran ini dengan cepat menjadi bukti konsep, menunjukkan banyak manfaat gaya dengan tag . Ia memeriksa banyak kotak yang kami memutuskan untuk mengubah reka bentuk Yahoo!

Apakah garis panduan yang hendak diikuti apabila mereka bentuk CSS atom (ACSS)? Siapa yang terlibat?

TK: Perpustakaan Stensil kami adalah statik, dan ia adalah alat yang hebat untuk menguatkuasakan gaya reka bentuk - kami fikir Yahoo akan menggunakan gaya ini dalam semua sifatnya. Kami dengan cepat menyedari bahawa ini tidak akan berlaku. Setiap pasukan reka bentuk Yahoo mempunyai pendapat sendiri mengenai saiz fon yang sempurna, margin sempurna, dan lain -lain. Kami terus menerima permintaan untuk menambah gaya yang sangat spesifik ke perpustakaan.

Keadaan ini tidak dapat dipastikan, jadi kami memutuskan untuk membangunkan alat yang membolehkan pemaju membuat gaya mereka sendiri dengan cepat sambil menghormati sifat atom kaedah kreatif. Ini adalah bagaimana pengabut dilahirkan. Kami berhenti menambah pengisytiharan gaya-CSS-dan sebaliknya memberi tumpuan kepada mewujudkan perbendaharaan kata yang kaya yang menyediakan pemaju dengan pelbagai gaya seperti pertanyaan media, pemilih keturunan, kelas pseudo, dan banyak lagi.

Dengan ACSS, pemaju bebas menggunakan apa sahaja yang mereka mahu; Dan terdapat beberapa manfaat langsung baru untuk gaya yang digunakan oleh pemaju. Mereka tidak lagi perlu bimbang tentang gaya mereka yang memecahkan halaman, dan tidak perlu bimbang tentang menulis pemilih untuk gaya komponen mereka.

ACSS pada asalnya dibina untuk menyelesaikan masalah Yahoo dan bekerja di persekitaran Yahoo.

Orang yang terlibat dalam CSS atom termasuk Renato Iwashima, Steve Carlson dan saya sendiri. Renato dan Steve mencipta pengabut.

Apakah salah faham tentang CSS apabila orang tidak menulis CSS untuk perusahaan besar?

TK: Apabila saya menyertai Yahoo pada tahun 2007, saya dengan cepat mengetahui betapa besarnya kod kod. Terdapat banyak lokasi/zon masa yang sama

Kebanyakan ini adalah jenama baru kepada saya dan saya perlu belajar sama ada dan bagaimana ia mempengaruhi cara saya menulis CSS. Saya mula meninjau semula dan mencabar semua kepercayaan saya kerana banyak teknik atau kaedah yang menjadi amalan biasa bagi saya nampaknya tidak sesuai, atau sekurang -kurangnya tidak produktif untuk aplikasi yang kompleks.

"Pemeriksaan realiti" berkaitan dengan abstraksi gaya. Kita semua telah membaca artikel yang mengatakan bahawa pemetaan kelas M-10 ke margin: 10px bukan idea yang baik, kerana ia bermakna mengedit kedua-dua HTML dan CSS untuk mengubah gaya. Malangnya, inilah yang berlaku dalam projek besar/kompleks:

  • Pereka: saya mahukan jurang 15 piksel
  • Pemaju: Ok, itu M-3X (kenaikan 5 piksel)
  • Pereka: Sudah tentu, apa sahaja!
  • Pemaju: Sudah selesai!
  • Pereka: Sebenarnya, 15 piksel agak terlalu besar, bolehkah anda mengubahnya menjadi 12 piksel?
  • Pemaju: Tidak, kami tidak mempunyai itu, sama ada 10 piksel atau 15 piksel.
  • Pereka: Maaf, ini tidak berfungsi untuk saya. Bolehkah kita menukar M-3x menjadi 12 piksel?
  • Pemaju: Tidak! Kita tidak boleh berbuat demikian, kerana pasukan lain mengharapkan M-3X menjadi 15 piksel.
  • Pereka: Ok, cuba cari jalan, kerana kita mahu margin menjadi 12 piksel. 15 piksel terlalu banyak, 10 piksel terlalu sedikit.
  • Pemaju: (pergi mati!)

Untuk meramalkan masalah sedemikian, adalah perlu untuk memahami niat pereka di sebalik permintaan mereka: Adakah gaya yang dipilih kerana abstraksi, seperti warna utama, atau kerana nilai spesifiknya, seperti margin 15 piksel dalam kes M-3X kami? Sekiranya terdapat panduan gaya untuk menguatkuasakan prinsip reka bentuk, kelas seperti M-3X mungkin baik-baik saja, tetapi jika pasukan reka bentuk boleh meminta gaya yang mereka inginkan, lebih baik untuk mengelakkan konvensyen penamaan yang akan membawa kepada gaya kabur. Dalam pengalaman saya, sebarang kekaburan boleh menyebabkan kerosakan.

Bergantung pada struktur dokumen atau komponen untuk tetapan gaya -melalui kombiner seperti> atau -bulat seperti cara yang kemas untuk menulis lembaran gaya, tetapi ia mengabaikan fakta bahawa dalam persekitaran yang kompleks, ia tidak dapat diandaikan bahawa mana -mana tag atau struktur tertentu tidak berubah.

Adakah anda fikir Z-indeks rumit? Fikirkan sekali lagi apabila anda tidak mempunyai pelbagai timbunan di mana komponen anda berada. Ini adalah salah satu isu yang paling kompleks untuk diselesaikan dalam projek besar di mana pasukan bertanggungjawab untuk bahagian yang berlainan halaman. Saya pernah menulis cadangan mengenai perkara ini.

Pemilih yang berkelayakan -seperti input.Required dan .Input.Required -kelihatan bagus dan semantik, tetapi ia mewujudkan tahap kekhususan yang tidak perlu -seperti 0.1.1 dan 0.2.0 -dan menghalang perubahan tag;

Bergantung pada pemilih Wildcard* untuk menetapkan gaya skop global? Dalam projek yang sangat besar, ini mungkin bermakna anda menggayakan komponen orang lain. Jangan membuat keputusan gaya untuk orang lain melainkan jika anda memahami keperluan mereka.

Saya percaya anda membaca ID adalah buruk, kekhususannya adalah buruk, tetapi. Sebenarnya. Kekhususan yang tinggi tidak begitu bermasalah kerana bilangan tahap kekhususan yang dibuat oleh peraturan anda. Ia lebih mudah untuk gaya dalam persekitaran di mana hanya terdapat dua atau tiga tahap kewujudan -contohnya, 1.1.0, 0.1.0, 0.2.0 -sebaliknya dalam persekitaran dengan kekhususan yang agak rendah tetapi berikutan pendekatan "persaingan bebas", contohnya,

Buta berikutan nasihat komuniti CSS boleh menyebabkan kejutan yang tidak menyenangkan. Jangan sekali -kali mengguna pakai teknologi baru yang belum diuji dalam amalan. Ingat akan berubah? Dan sentiasa tahu apa gaya yang anda gunakan atau apa yang boleh mencetuskannya. Sebagai contoh, kedudukan boleh membuat konteks penyusunan dan blok yang mengandungi, manakala limpahan boleh membuat konteks pemformatan blok.

Dalam pengalaman saya, pemahaman yang mendalam tentang CSS tidak mencukupi untuk organisasi besar untuk menulis CSS dengan cekap. Semasa saya di Yahoo, saya sering mendapati diri saya bertentangan dengan orang -orang yang pernah bersama saya beberapa tahun yang lalu. Persekitarannya sangat kejam dan memerlukan sangat pragmatik untuk mengelakkan banyak perangkap. Kali seterusnya anda melihat kod sumber projek besar dan melihat sesuatu yang tidak masuk akal untuk anda, ingat tweet ini dari Nicholas Zakas:

Jangan menganggap bahawa orang bodoh, jahil, membuat kesilapan, mengandaikan bahawa mereka pintar, melakukan yang terbaik, dan anda tidak mempunyai latar belakang.

- Nicholas C. Zakas (@Slicknet) 10 Februari 2013

Bagaimanakah peralihan Yahoo ke CSS atom diterima secara dalaman?

TK: Pasukan laman utama saya menerima ACSS dengan baik, tetapi ia tidak berjalan lancar. Interaksi pertama kami adalah dengan pasukan sukan yang terletak di Santa Monica. Steve dan saya cuba meyakinkan pemaju dalam panggilan persidangan yang tidak mengikuti prinsip pemisahan kebimbangan adalah perkara yang betul untuk dilakukan dan ia tidak menyebabkan kekeliruan.

Kami menegaskan kepada mereka artikel baru -baru ini oleh Nicolas Gallagher bahawa ia akan membantu dari "orang luar", tetapi tidak! Perkara tidak berjalan lancar dan terdapat banyak geseran. Masalah utama ialah perpustakaan terdiri daripada kelas utiliti, tetapi sintaksnya tidak membantu meringankan perbualan.

Saya masih ingat bertemu dengan pasukan e -mel, yang tidak membantah idea CSS atom, tetapi ingin menghasilkan kaedah JavaScript mereka sendiri untuk menggunakan pengisytiharan CSS "biasa" - kerana mereka tidak dapat menahan sintaks ACSS. Walau apa pun, data yang menyokong perpustakaan (kira -kira 36% pengurangan CSS dan HTML) mengatakan semuanya dengan sendirinya, jadi ACSS adalah akhir. Hari ini, lebih daripada tujuh tahun kemudian, laman utama Yahoo, Yahoo Sports, Yahoo News, Yahoo Finance dan produk Yahoo lain masih menggunakan ACSS.

Untuk lebih memahami bagaimana pendekatan seperti projek manfaat ACSS di mana kebolehgunaan semula komponen adalah kritikal, salin markup komponen dari Yahoo Finance dan tampalkannya ke Yahoo News. Komponen sepatutnya kelihatan seperti itu milik bahagian halaman. Ini kerana ACSS menjadikan komponen ini bebas dari halaman.

Bagaimanakah kaedah kurungan sebagai nama kelas berasal? Adakah sintaks diilhamkan oleh bagaimana fungsi ditulis?

TK: Kami telah mengenal pasti dua set "calon" yang digunakan sebagai pemisah nilai atribut melalui pelbagai lelaran: tanda kurung () dan kurungan persegi [].

Renato mengingatkan bahawa kami memilih kurungan di atas kurungan persegi kerana kami sudah biasa dengan fungsi dalam JavaScript, walaupun dengan mengorbankan ketukan kekunci tambahan. Sintaks ACSS dimaksudkan untuk:

  • Menggalakkan peraturan generasi automatik melalui pengabut
  • Benarkan pemaju membuat gaya sewenang -wenang atau kompleks yang mereka mahukan
  • Kurangkan lengkung pembelajaran

Nampaknya ini:

 <code>[<context> [:<pseudo-class> ]<combinator> ][(<value> ,<value> ?,...)][][:<pseudo-class> ][::<pseudo-element> ][--<breakpoint_identifier> ]</breakpoint_identifier></pseudo-element></pseudo-class></value></value></combinator></pseudo-class></context></code>
Salin selepas log masuk

Pemaju membina kelas mereka mengikut struktur di atas. Sintaks teras didasarkan pada Toolkit Emmet yang popular. Kami menggunakan kaedah Emmet untuk mengurangkan ciri -ciri, kerana kelas teras adalah pasangan harta/nilai yang jelas, bukan rentetan sewenang -wenangnya .

Kami juga telah mencipta lebih daripada sedozen kelas tambahan. Ini menggunakan pengisytiharan gaya berganda dan sama ada pintasan, seperti kandungan yang menyembunyikan pengguna yang cacat penglihatan, atau hacks, seperti ClearFix menggunakan .cf. Kami juga menyediakan pemaju dengan lebih banyak kebebasan dengan menggunakan fail konfigurasi di mana mereka boleh membuat pembolehubah -seperti .primarycolor -breakpoints dan banyak lagi.

Orang yang tidak pernah menggunakan ACSS akan memberitahu anda bahawa sintaks terlalu pelik (paling baik), tetapi orang yang biasa dengannya akan memberitahu anda bahawa ia adalah pandai dalam banyak cara.

Bercakap tentang bagaimana artikel "Cabaran CSS Terbaik" anda untuk Majalah Smashing dilaksanakan?

TK: Saya telah menulis banyak dalam pelbagai penerbitan dalam talian sebelum ini, jadi adalah wajar untuk menulis artikel mengenai pendekatan "mencabar" ini.

Yahoo menaja persidangan depan pada Oktober 2013, di mana Renato mengatur ucapan untuk memperkenalkan penyelesaian kami, dan saya cuba menerbitkan artikel ini sebelum itu. Saya memilih untuk tidak menyiarkannya di rangkaian pemaju Yahoo! kerana laman web ini tidak menyediakan bahagian komen. Senarai selain tidak dapat menerbitkannya dalam masa, tetapi Smashing Magazine telah mempercepatkan proses semakannya untuk dapat menerbitkan artikel menjelang akhir bulan Oktober.

Pendekatan saya untuk memilih penerbit dengan bahagian komen yang dibayar kerana jawatan itu menerima lebih daripada 200 komen, yang sangat memakan masa dan mengecewakan bagi saya-dan saya terpaksa menjawab komen tersebut.

Jawatan ini masih membawa penafian mengenai teknologi yang dipersoalkan, dan walaupun ia sudah popular dalam industri sekarang, adakah ia berasa pelik?

TK: Apabila artikel itu diterbitkan, saya memberitahu Vitaly [Friedman, pengasas bersama Smashing Magazine] nota itu terdengar seperti beberapa jenis penafian; Tetapi saya tidak benar -benar menyangkalnya kerana saya memahami idea Vitaly. Saya dapati nota ini masih menarik, dan pendekatan ini telah menjadi arus perdana sekarang.

Memandangkan penglihatan, apakah aspek CSS atom yang anda mahu berubah?

TK: Selalu ada ruang untuk penambahbaikan, terutamanya selepas anda mempelopori penyelesaian ini. Anda tidak dapat melihat apa yang dilakukan oleh orang lain untuk mengetahui tentang kesilapan atau kekurangan mereka. Anda tidak mempunyai bahan yang lebih baik. Jadi jika kita fikir kita berjaya buat kali pertama, ia akan menjadi sombong.

Kami mempunyai pengalaman yang luas dengan CSS atom kerana kami telah menggunakan helaian gaya "statik" dalam projek besar selama lebih setahun. Tetapi dari segi dinamik - alat - kita nampaknya tidak banyak inspirasi. Ingat, ia mengambil masa enam tahun untuk perpustakaan lain untuk mengikutinya.

Dalam bahasa Perancis kita katakan: Essuyer les plâtres . (Lap debu)

Satu kesilapan yang kami buat adalah menggunakan "CSS Atomik" sebagai tajuk ACSS.IO kerana, seperti yang ditunjukkan oleh John Polacek, ini menimbulkan kekeliruan. Sejak itu, kami telah menukar tajuk.

Satu -satunya perkara yang saya menyesal adalah bagaimana komuniti telah merawat CSS/ACSS atom selama bertahun -tahun, yang baru -baru ini membawa kepada pertukaran aneh di mana seseorang menjelaskan kepada saya apa yang "CSS Atom" bermaksud:

Perpustakaan CSS Atom [ACSS] menggunakan nama ini, tetapi saya fikir ia mengelirukan kerana fungsi yang anda bicarakan adalah penjanaan gaya dinamik. "CSS Atom" adalah istilah biasa yang menentukan pemilih kecil sebagai atom, tetapi mereka adalah statik.

Bercakap tentang dipadamkan. ;)

Terima kasih banyak untuk Thierry kerana menyertai wawancara ini dan membolehkan kami menyiarkannya kepada masyarakat.

Atas ialah kandungan terperinci Pembuatan CSS Atom: Temu bual dengan Thierry Koblentz. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan Laman Web ini
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Artikel terbaru oleh pengarang
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan