-
reset
- Tailwind’in preflight stillerini başlangıçta
tailwind.css dosyasından yaklaşık 200 satır kopyalayarak kullandı
- Tailwind reset’ine uzun süredir alışık olduğu için, tüm öğelere
box-sizing: border-box uygulayan kural öğelerin genişliğinin padding’i de içermesini sağlıyor
* { box-sizing: border-box; }
html {line-height: 1.5;} gibi diğer reset kurallarına da bilinçsizce bağımlı olma ihtimali var; bu tür kurallar olmadan CSS yazmak ciddi bir alışma süreci gerektirebilir
-
components
- CSS’in büyük kısmını Vue veya React bileşenlerine benzer şekilde bileşen başına dosyalar halinde düzenliyor
- Her bileşenin kendine özgü bir sınıfı var ve bir bileşenin CSS’inin başka bir bileşenin CSS’ini ezmemesi hedefleniyor
- Gerçekte değiştirmek istediği CSS’in yaklaşık %80’i bileşen dosyalarının içinde bulunduğu için, 100 satırlık bir bileşeni düzenlerken yalnızca o 100 satırı düşünmek yeterli oluyor
- Örneğin
.zine bileşeni şu tür bir HTML yapısına sahip olabilir
<figure class="zine horizontal">
<img src="whatever.jpg">
</figure>
- CSS tarafında iç içe seçiciler kullanılarak
.horizontal, .vertical ve :hover gibi durumlar bileşenin içinde toplanıyor
.zine {
...
&.horizontal {
...
}
&.vertical {
...
}
&:hover {
...
}
}
- Web Components veya
@scope gibi yöntemlerle bileşenler arası etkileşimi programatik olarak engellemese de, kurallar koyup bunlara uymak bile büyük bir iyileşme hissi veriyor
-
colours
colours.css dosyasında gerektiğinde kullanılabilecek CSS değişkenlerini bir arada tutuyor- Renkler zor bir konu olduğu ve bu refaktörde renk kullanımını yeniden gözden geçirmek istemediği için mevcut yaklaşımı koruyor
- Tek kural, sitede kullanılan tüm renklerin bu dosyada listelenmesi
:root {
--pink: #fea0c2;
--pink-light: #F9B9B9;
--red: #f91a55;
--orange: rgb(222, 117, 31);
...
}
-
font sizes
- Tailwind’de
text-lg, xl, 2xl gibi boyut basamakları seçildiği için em, px ve rem arasında hangisinin kullanıldığını hatırlamak gerekmiyordu
- Bunu vanilla CSS’te de sürdürmek için Tailwind’den alınan boyut değişkenlerini tanımlıyor
--size-xs: 0.75rem;
--line-height-xs: 1rem;
--size-sm: 0.875rem;
--line-height-sm: 1.25rem;
- Font boyutları değişkenlerle belirleniyor; Tailwind’e göre biraz daha uzun yazılsa da şu an için tatmin edici bir yöntem
h3 {
font-size: var(--size-lg);
line-weight: var(--line-weight-lg);
}
-
utilities
- Birden fazla bileşende tekrarlanan buton gibi öğeleri utilities olarak sınıflandırıyor
- Yalnızca ekran okuyucu kullanıcılarına görünmesi gereken öğeler için kullanılan
.sr-only gibi bazı utility sınıfları Tailwind’den kopyalandı
- Bu alanı küçük tutmaya ve değişiklik yaparken dikkatli olmaya çalışıyor
-
base
- “base” stiller, sitenin tamamına doğrudan uygulanan stiller
- Site genelinde çok sayıda stili zorlayacak kadar kendinden emin olmadığı için bu alanı oldukça küçük tutuyor
- Şu anda iyi hissettiren kurallar yalnızca
<section> ve a için; <section> kuralı daha sonra değişebilir
/* put a 950px column in the middle of each <section> */
section {
--inner-width: 950px;
padding: 3rem max(1rem, (100% - var(--inner-width))/2);
}
a {
color: var(--orange);
}
- Base stilleri başlangıçta neredeyse boş bırakıp, ortak olarak istenen şeyler ortaya çıktıkça bunları bileşenlerden base katmanına taşımak şeklindeki aşağıdan yukarı yaklaşım en kolay yöntem gibi görünüyor
-
spacing
- Padding ve margin’in nasıl yönetileceği henüz tam olarak netleşmiş değil
- Tailwind kullanırken, istediği görünüm çıkana kadar padding ve margin’i oraya buraya doğaçlama ekliyordu; şimdi ise bundan daha ilkesel bir yöntem arıyor
- Şu anda mümkün olduğunca dış düzen bileşenlerinin aralıkları üstlenmesini sağlamaya çalışıyor
- Birden fazla alt öğe içeren
<section> yapılarında, çocuklar arasında eşit boşluk bırakmak için şu kural kullanılabilir
section > *+* {
margin-top: 1rem;
}
-
responsive design
- Tailwind’de
md:text-xl gibi, belirli bir boyutun üzerinde text-xl stilini uygulayan media query tabanlı sözdizimini sık kullanıyordu
- Şimdi ise çok fazla breakpoint kullanmadan çalışabilecek daha esnek CSS grid düzenleri oluşturmaya çalışıyor
auto-fit kullanıldığında, büyük ekranlarda 2 sütun ve küçük ekranlarda 1 sütun otomatik olarak kullanılabiliyor
display: grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 400px), max-content));
justify-content: center;
-
build system
- Geliştirme sırasında ayrı bir build sistemine ihtiyaç yok
- CSS’in yerleşik
@import deyimi sayesinde dosyalar bölünüp içe aktarılabiliyor
@import "reset.css";
@import "typography.css";
@import "colors.css";
- CSS’te iç içe seçiciler de yerleşik olarak bulunuyor
.page {
h2 { ...}
}
- Üretim için CSS dosyalarını birleştirmek istenirse
esbuild kullanılabilir
esbuild style.css --bundle --loader:.svg=dataurl --loader:.woff2=file --outfile=/tmp/out.css
- Genelde CSS ve JS build sistemleri kullanmaktan kaçınıyor, ancak
esbuild web standartları temelli olduğu ve statik bir Go ikilisi sunduğu için kabul edilebilir buluyor
esbuild hakkında 2021’de esbuild ve Vue üzerine bir yazı da yazmıştı
3 yorum
zero-configolarak değişince biraz daha iyi olmuyor mu?Hacker News görüşleri
Uzun zamandır anlamsal HTML ve erişilebilir işaretleme öğretiyorum; ekran okuyucu kullanan siteler ve uygulamalarla da çok çalıştım. Bana göre Tailwind’in en büyük sorunu, HTML ve CSS’i düşünme sırasını tersine çevirmesi
HTML belgenin anlamını ifade etmek içindir; bu yüzden oradan başlamalı, ardından CSS ile stil vermelisiniz. Stil nedeniyle ek öğeler gerekiyorsa
divveyaspankullanabilirsiniz, ama önce daha uygun bir öğe olup olmadığını düşünmek gerekirTailwind geliştiricileri CSS öncelikli bir yaklaşıma itiyor; önce istediğiniz Tailwind sınıfını düşünüyor, sonra da o sınıfı eklemek için DOM’a bir
divdaha koyuyorsunuzWeb geliştiricisinin becerileri arasında, gelecekte de okunabilir kalan, tüm kullanıcıların kullanabildiği ve genel olarak HTML/CSS standartlarıyla uyumlu HTML ve CSS üretme yeteneği olmalı; Tailwind ise bu açıdan beceriyi zayıflatıyor. Tailwind sitesindeki ilk örnek bile sadece
divvespankullanıyor; bu yeni geliştiriciler için kötü bir eğitim oldu ve LLM’lerin ayrıca talimat verilmedikçe div çorbası üretmesi eğilimine de katkı sağladığını düşünüyorumHer araç yanlış kullanılabilir ve Tailwind de istisna değil. Yaklaşık 20 yıldır CSS kullanıyorum; Less, SASS/SCSS, Stylus ve PostCSS de kullandım ama son birkaç yıldır Tailwind’de kalmamın nedeni tam tersine daha sağlam uygulama stillendirmesi sağlaması
Stil/sınıf soyutlamalarını aşırı kurmak zorunda kalmıyorsunuz; stili etkilenen işaretlemenin yanına koymak bilişsel yükü azaltıyor, gevşek seçicilerin istemeden stili değiştirme ihtimali düşüyor ve hata ayıklama kolaylaşıyor. Basit siteler/uygulamalar hariç, özel CSS çatısı olan kod tabanlarına kıyasla Tailwind kod tabanları çoğu zaman daha az karmaşık ve daha az kırılgan
Tutarlı yazı tipi, renk ve boyut ölçekleri; daha küçük bundle’lar; Tailwind bilen geliştiriciler arasında tutarlılık; güçlü ekosistem ve LLM uyumluluğu da düşünülünce birçok ekip için harika bir seçenek. Sonuçta çoğu araç gibi, onu kullanan kişiye bağlı olarak iyi de kötü de kullanılabilir
HTML/CSS/JS karmaşasını, tarayıcıyı hedeflediğinizde gerekli bir kötülük olarak görüyorum; benim için sadece sunum katmanı. İşte veritabanı şeması veya backend iş mantığının doğruluğuna çok daha fazla önem veriyorum
Dağınık bir sunum katmanını mümkün olduğunca az kullanarak yine de bir ölçüde bakım yapılabilir kod elde edebiliyorsam bana yeter; Tailwind de bu amaca iyi uyuyor. LLM’ler onu iyi yazıyor, yeni geliştiriciler hızlı anlıyor ve sonradan okuyup değiştirmek de oldukça kolay
Tailwind projesinin yeni geliştiricilerin HTML/CSS öğrenmesi için en iyi yol olmadığına tamamen katılıyorum; ama yeni geliştiricilerin iyi veritabanı şemaları, sezgisel API’ler ve test edilebilir iş mantığı gibi konulara odaklanmasını daha çok tercih ederim
Tailwind’in kendisinde, uygun HTML etiketleri yerine
divvespankullanmaya zorlayan hiçbir şey yokBelge ile arayüz farklı şeylerdir ve Tailwind özellikle arayüz tarafında çok daha anlamlıdır. Arayüzlerde Tailwind kullanıp diğer içeriklerde kapsamı sınırlandırılmış HTML seçicileri kullanabilirsiniz
Karmaşık CSS kod tabanları yazmaktan yaklaşık 4 kat daha hızlı olması ve fiilen neredeyse hiç ek yük getirmemesi, nasıl değerlendirirseniz değerlendirin bir avantaj olarak kalıyor
Özetle, CSS’i özgüllük sırasına göre yazma yaklaşımı:
/scss/
├── 1-settings. <- global ayarlar
├── 2-design-tokens <- yazı tipi, renk, boşluk vb.
├── 3-tools <- Sass mixin’leri, CSS fonksiyonları vb.
├── 4-generic <- reset, box-sizing, normalize vb.
├── 5-elements <- başlıklar, butonlar, bağlantılar için temel stiller
├── 6-skeleton <- layout grid vb.
├── 7-components <- kartlar, carousel’ler vb.
├── 8-utilities <- utility ve helper sınıfları
├── _shame.scss <- sonra düzeltilecek hack’ler
└── main.scss
ITCSS, CSS kod tabanlarında özgüllük kavgalarını fiilen ortadan kaldırıyor. Genellikle
!important’ın girdiği tek yer utility katmanı oluyor[1]: https://matthiasott.com/notes/how-i-structure-my-css
Bileşen kütüphanelerine bakarsanız
ariaözniteliklerini de ekliyorlar: https://tailwindcss.com/plus/ui-blocks/marketing/sections/pr...Landing page gibi daha çok dijital broşür sayılabilecek bir şey yapmıyorsam her zaman önce işaretlemeden başlıyor, sonra üzerine CSS sınıfları ekliyorum
Tailwind’in iki iyi tarafı, AI eğitim verisinde sınıf bilgisinin zaten çok bulunması ve stil çakışmalarının olmaması
Bu yüzden AI yeni stiller oluştururken mevcut stylesheet’e başvurmak zorunda kalmıyor; bağlam yönetimi açısından iyi
Özel CSS’de AI’nin çakışma veya tekrar yazımı azaltması için mevcut stylesheet’i okuması gerekir; ama büyük stylesheet’ler AI’nin bellek alanını çok tüketebilir ve bu sorun olabilir
Julia Evans’ın yazılarını gerçekten çok seviyorum
Kırılganlık ve samimiyet üzerinden yazıyor. Birçok insan zeki görünmek için yazar ama Julia, “Ben de her şeyi bilmiyorum ama keşfettiklerim arasında paylaşmak istediklerim var” tavrıyla yazıyor. Onu şahsen tanımasam da, sevdiğiniz insanlarla bir şey paylaşması gibi hissettiriyor
Son Strange Loop’ta Randall Munroe ile birlikte sunum yaptı; sunumdan sonra onunla konuşmak için bekleyenler de vardı ama ben Julia ile konuşmak için bekledim. Bash script’lerini Perl ile yeniden yazması gerektiğine dair şakamı anlamamış gibi göründüğü için içtenlikle üzgünüm
Ben Julia değilim ama kamusal konuşma ve sunumlar konusunda neredeyse aynı felsefeye sahibim ve sunum yapmaktan zorlanan iş arkadaşlarıma da bunu aşılamaya çalıştım. İş arkadaşlarıma ve sevdiklerime, benim biraz daha aşina olduğum ve onlara yardımcı olabilecek bilgileri aktarabilmek büyük bir ayrıcalık
CSS Modules, cascading sorununa daha basit bir çözüm. Benzersiz sınıf adları üreterek sınıf çakışmalarını engelliyor [1]
Ayrıca Tailwind’in iki büyük dezavantajı olan okunabilirlik [2] ve araç desteği sorunlarını da yaşamıyorsunuz. Özellikle Chrome ve FireFox DevTools’ta hata ayıklama ve etkileşimli denemeler için araç desteğinin daha iyi olduğunu düşünüyorum
[1] https://x.com/efortis/status/1888304658080256099
[2] https://github.com/ericfortis/tailwind-eye
Tailwind’de bana hep etkileyici gelen şey, destekçilerinin neredeyse tüm argümanlarının dönüp dolaşıp “CSS’i junior seviyenin ötesinde hiç öğrenmedim” noktasına varması
“Tailwind olmazsa tek bir büyük, dağınık CSS dosyası kontrolden çıkar; eski kod ve
!importantile dolar” gibi şeyleri sık duyuyorsunuz ama CSS de diğer teknik yetkinlikler gibi bir beceriSadece göze hoş görünmesi kadar öğrenip üstünü yamalarsanız, hırsınız çok geçmeden kodu düzenli tutma becerinizi aşar
Tailwind ve CSS hakkında konuşurken, karşınızdaki kişinin “cascading”in ne demek olduğunu bırakın bilmeyi, stylesheet bağlamında bunun yararlı bir kavram olabileceğini bile hiç düşünmediğini fark ettiğiniz an gerçekten sinir bozucu
90’lardan beri yoğun biçimde CSS kullandım; sonra Tailwind’e baktım ve mantığını anladıktan sonra çoğu zaman saf CSS’ten kaçınır oldum. Bir anlamda bir karmaşayı başka bir karmaşayla değiştiriyorsunuz ama ben kişisel olarak, birden fazla dosyaya yayılmış örtüşen ve çelişen cascade yerine yerelleştirilmiş sınıf çorbası ile uğraşmayı tercih ederim
İkisi de temiz uygulanabilir; ama Tailwind karmaşasını toparlamak CSS karmaşasını toparlamaktan çok daha iyi ve genel geliştirme süreci de bana daha keyifli geliyor
Ben de 20 yılı aşkın süredir programlama yapıyorum, web geliştirme de neredeyse 15 yıl oldu; ama CSS’i gerçekten öğrenmek için motivasyon bulmak zor. Yetişmem gereken çok fazla teknik yetkinlik var ve CSS öncelik listemde oldukça aşağıda
Bunu bir uzmana bırakmak isterdim ama şirketler özel frontend geliştiricileri işe almak istemiyor
İyi ölçeklenen HTML ve CSS yazımına odaklanan temiz web geliştirme rehberi yazıyorum: https://webdev.bryanhogan.com/
Buradaki insanlar için faydalı olabilir diye düşündüm. Stil verme için Tailwind benzeri bir şey kullanmıyor; Astro veya Svelte gibi modern framework’ler ile CSS kullanıyor
Her projede
reset.css,var.css,global.css,util.cssbulunduruyor; diğer stilleri ise ilgili bileşen veya layout ile sınırlıyorumGüzel bir yazı
Dış kütüphane bağımlılıklarını kaldırıp çözümü sıfırdan kendim üretmeyi severim ama Tailwind’de bunu yapmamam için net bir neden var: üretim optimizasyonu sağlayıp gerçekten gereken en az CSS’nin dağıtılmasını garanti etmesi
globals.cssya da başka bir yerde renk, boşluk vb. tüm seçenekleri listelemiş olsanız bile, üretimde o varyasyonların hepsini gerçekten kullanıp kullanmadığınızı dert etmeniz gerekmiyor. Next.js gibi bir framework içinde çalışıyorsanız build sırasında bu küçültme adımı otomatik gerçekleşiyor; sırf bu bile Tailwind’den ayrılmamak için yeterli nedenTailwind ile inline CSS kullanırken başa çıkılamaz kısıtlar hissetmedim; Tailwind’in grid araçlarıyla ekran genişliğine iyi uyum sağlayan grid’ler kurmakta da ciddi sorun yaşamadım. Yazıdaki senaryoların hepsini Tailwind ya da Tailwind + CSS ile çözdüm;
grid-column-areas’ın varsayılan olarak gelmemesi doğru ama responsive grid layout’larda bunu henüz büyük bir kısıt olarak hissetmedimTailwind’in en büyük sorunu, onu okuyabilmeye alışmanın uzun zaman alması. Bize inline CSS kötüdür, global kapsamlı CSS iyidir diye öğretildi ve temiz HTML’e alıştık; bu yüzden gerçek Tailwind kodu, özellikle uzun satırlar, ilk başta gerçekten okunması zor görünüyor. Uzun süre kullanınca görünüşüne tamamen alıştım ve sonunda Tailwind’in benim için daha verimli, daha bakımı kolay, hatta daha okunabilir olduğuna vardım; ama bu zaman aldı
Son zamanlarda gerçekten sevdiğim yaklaşım, Tailwind ile kapsamı sınırlandırılmış stilleri birlikte kullanmak (Svelte ve Vue’da)
Böylece Tailwind’in rahatlığını korurken şablon kirlenmesini en aza indirebiliyorsunuz:
+
{{ count }}
Benim için Svelte ve LLM’ler, Tailwind ihtiyacını tamamen ortadan kaldırdı
Meğer Tailwind’i asıl kullanma nedenim, kendi kendime koyduğum kısıtlar değil; CSS çakışmalarından kaçınma ve bana daha mantıklı gelen sözdizimiymiş
Tailwind’de en iyi şey, geçici sınıf isimleri uydurmak zorunda kalmamanız. Artık BEM kullanmak zorunda değilsiniz
Lobste.rs görüşleri
Kişisel projelerde artık neredeyse hiç CSS/JavaScript framework kullanmıyorum
Bağımlılık olmayınca tedarik zinciri güvenlik açıkları da ortaya çıkamaz. Elbette açıkların tek türü bu değil ama yine de yardımcı oluyor
Bunun nedeni framework yorgunluğu,
npm audityükü ve LLM'ler sayesinde bir şeyi nasıl uyguladığıma dair başkalarının ne düşündüğünü daha az umursamamam. Mesela “Neden React ve Tailwind kullanmıyorsun?” gibi sorularBu, sadece CSS'in çalışma biçimi
Bunu bilmeden Tailwind'i körü körüne kullananları görünce dışarı çıkıp bulutlara bağırmak istiyorum. Bana göre Tailwind'in %90'ı sadece sözdizimi farklı olan inline style ve hatta
<FONT>etiketinden bir tık daha iyi denebilirBu blog yazısı benim gerçekten öğrenmem gereken şeyleri anlatıyordu
Tailwind, inline style'dan oldukça farklı çalışır ve aslında CSS'e çok daha yakındır. Yazıda da belirtildiği gibi, Tailwind'i iyi kullanmayı sağlayan iyi alışkanlıkların önemli bir kısmı etkili CSS yazmak için de gerekli alışkanlıklardır. Tailwind, her öğeye örtük bir scope'u olan CSS bloğu ekleyip bunu kendine özgü bir DSL ile yapmak fikrine daha yakındır
CSS'in çalışma biçimini iyi biliyorum ama saf CSS gözümü korkutuyor ve grafik tasarım konusunda da zayıf olduğum için hâlâ Tailwind kullanıyorum. Bu yazı, Tailwind'i temel alarak CSS'i yapılandırmaya dair fikirler veriyor
Son dönemdeki akımları çok yakından takip etmeyen biri olarak, bu yazı modern CSS pratiklerini oldukça iyi gösteriyor gibi geldi
İlham aldığı yazılara giden çok sayıda bağlantı içermesini de beğendim. Okumalık olarak iyi görünüyor; şimdilik sadece "no outer margin" yazısını okudum
Yalnız temel stilleri “aşağıdan yukarı” kurma yaklaşımına biraz şüpheyle bakıyorum. Onun yerine ne yapardım bilmiyorum ve denemeye değer görünüyor ama temel stiller doğası gereği epey zorlu
Bu yazıyı gerçekten çok beğendim
Ben de küçük siteler yapıp dururken CSS'i yavaş yavaş öğrendim; baştan beri böyle sistematik bir düşünme biçimine daha çok sahip olsaydım faydalı olurdu. Framework'lere karşı epey bir direnç hissediyorum ama kullanmayınca da istediğimi yapabiliyor olsam bile sık sık yapısız bir boşlukta asılı kalmış gibi hissediyorum
“Tailwind kötü, o yüzden sadece CSS kullan” demek yerine, “Tailwind harika ama artık gerekli olmayabilir” çizgisinde olması hoşuma gitti
CSS'i elle yapılandırmakta hep zorlandım ama bu yazı sayesinde konuya çok daha farklı bakmaya başladım
CSS'i düzenlerken şu yapılandırma tekniği oldukça işime yaradı: https://rstacruz.github.io/rscss/
Genel olarak orijinal yazıda jvns'in anlattıklarıyla iyi örtüşüyor ve bunun üstüne biraz daha yapı ve düzen ekliyor