CSS: Kaçınılmaz Kötü Yanlar

• Web sayfası stillendirmesinde basit bir blog veya GUI için öğrenilebilir küçük bir alt küme yeterli olsa da, tarayıcı varsayılanları ve yerleşim gibi tuzaklar günler süren debug süreçlerine yol açabilir
• Önce anlamlı HTML5 etiketlerini kullanıp sarmalayıcıları azaltırsanız, CSS’in mevcut işaretlemeye uyumlu çalışmasını sağlamak daha kolay olur
• CSS yerleşiminde evrensel tek bir algoritma yoktur; her sistemin hangi yerleşim türlerine izin verdiğini anlamaya dayalı bir yaklaşım gerekir
• box-sizing, margin, font-size, line-height, word-break sezgiye aykırı çalışır; küçük değişiklikler tüm yerleşim ya da okunabilirlik sorunlarına dönüşebilir
• Basit sayfalar için CSS reset, classless CSS, flexbox ve aşırıya kaçmayan duyarlı kurallar pratik bir başlangıç noktası olabilir

---

CSS öğrenmenin kapsamı ve temel bakış açısı

• CSS, HTML ve Web API çok geniş alanlardır ve uzmanlık gerektirir; ancak programlama blogu ya da basit GUI gibi işler için modern web’in makul bir alt kümesi yeterlidir
• Basit işler için gereken alt kümeyi öğreten bir kaynak görülmemiş olsa da, MDN takip edilerek belli ölçüde kavranabilir
• Sorun, varlığı önceden tahmin edilmeyen tuzakların sayfayı bozabilmesi ve nedenini bulmanın günler sürebilmesidir
• Bu sitenin stillendirmesi yaklaşık 200 satır okunabilir CSS ile oluşturulmuştur

İyi taraflar: anlamlı HTML ve classless CSS

• HTML5 semantik etiketleri

  • MDN’in Elements Reference sayfasına göz atmaya değer; HTML öğelerinin sayısı çok da fazla değildir
  • main, article, nav, kbd gibi etiketler sayfa yapısını kurmayı kolaylaştırabilir
  • ul, header > nav içindeki site bölümleri gibi her türlü liste için kullanılabilir
  • details, içindekiler tablosu için kullanılabilir; MDN kaynağına bakılabilir
  • dl ve dt, eşli listelerde kullanılabilir

• Sarmalayıcıları azaltan yaklaşım

  • Gerçek web sitelerinin kaynaklarına bakıldığında çok katmanlı sarmalayıcı öğeler görülebilir; bu da yerleşim sorunlarının sarmalayıcılarla çözüldüğü izlenimi verebilir
  • Production CSS deneyimi hakkında hüküm vermek ertelense de, yalnızca anlamlı semantik etiketleri kullanmakla kendini sınırlayıp ardından o işaretlemeye uyan CSS’i bulma yaklaşımı daha anlaşılır bulunmuştur

• Classless CSS

  • Stilleri tamamen nötr bir “hiçbir şey yok” durumuna sıfırlamak mümkün değildir; beyaz ya da saydam metin de sonuçta bir stildir
  • Sıfırlamadan sonra, ortak HTML öğelerini doğrudan stillendirme yaklaşımı kullanılabilir
  • main, header, footer, nav etiketleri kullanılırsa çok sayıda CSS seçicisi yazmadan tüm sayfa yerleşimi kurulabilir
  • Bu yaklaşım CSS’in HTML yapısını varsaymasına yol açar; ancak HTML ve CSS size aitse, sonuç hoşunuza gitmediğinde değiştirebilirsiniz

Kötü taraflar: yerleşim, tarayıcı varsayılanları, seçiciler

• Yerleşim

  • Yerleşim sorunları sadece web’e özgü değildir; birçok GUI çatısında da zorlu bir problemdir
  • Sabit boyutlu raster görselleri ve bunları açıklayan metin paragraflarını bir ekran dikdörtgenine yerleştirmenin birçok yolu vardır
  • Genel GUI, yüksek derecede “yerleşim serbestliği” olan kutuların hiyerarşik yapısıdır
  • Her kutunun yerleşimi diğer tüm kutuların yerleşimini etkiler ve genelde tüm kutuların boşluk ya da çakışma olmadan tam oturması gerekir
  • Evrensel tek bir yerleşim algoritması yoktur; RectCut, constraint solvers ve bu ara bölge dahil olmak üzere sistemler farklı sezgisel yöntemler kullanır
  • “Verilen sistemde yerleşimi nasıl kurarım?” diye düşünmektense, “Bu sistem hangi yerleşimlere izin veriyor?” diye düşünmek daha iyidir

• Tarayıcı varsayılanları ve CSS reset

  • CSS olmadan yazılmış anlamlı HTML bile tarayıcıda renk, yazı tipi, boyut, büyük başlıklar, altı çizili bağlantılar gibi varsayılan stillerle görüntülenir
  • Varsayılan stiller faydalıdır, ancak tarayıcılar arasında farklıdır; yazmadığınız varsayılanlara dayanırsanız başka tarayıcılarda farklı sonuçlar görebilirsiniz
  • Yaygın çözüm, başlangıçta açık kurallarla varsayılanları ezmek için kullanılan CSS reset veya normalleştirme yaklaşımıdır
  • Sorun varsayılanların kendisi değil, birbirleriyle tutarsız olmalarıdır
  • Pratikte hangi kuralların ezilmesi gerektiğini anlamak için mevcut CSS reset’lerini karşılaştırmak daha iyidir

• Web sayfası stillendirilmek zorunda mı

  • Web platformunda hem onu esnek ve uyarlanabilir bir görsel ortam olarak gören yaklaşım, hem de içeriği ulaştırmaya odaklanıp ifadenin kullanıcı tarafından özelleştirilmesi gerektiğini savunan yaklaşım vardır
  • Varsayılan olarak stilsiz bir sayfa kullanışsızdır ve iyi görünmez
  • CSS’siz sayfaların olduğu gibi kolay okunabildiği bir dünya daha iyi olurdu, ancak mevcut ortamda içeriğe stil uygulamak faydalıdır
  • İleri düzey kullanıcıların kendi CSS’lerini getirmesine izin vermek iyidir
  • HTML işaretlemesi makul olmalı, HTML CSS’e aşırı uyumlu hale getirilmemeli ve sayfa reader mode’da çalışmalıdır

• CSS seçicileri

  • Temel CSS güçlü bir kalıtım sistemi gibi çalışır; web sayfasındaki her tasarım öğesi birden fazla kuraldan etkilenir
  • CSS dosyasına ekleme yaparak mevcut bir öğeyi her zaman “monkey patch” edebilirsiniz
  • CSS seçicilerinin yanlış eksende soyutlama gücü eklediği düşünülürse, classless CSS ve inline style kullanan bir yaklaşım mümkündür
  • Tailwind gibi araçlarla inline yazımın zahmeti azaltılabilir; JSX ya da bileşim destekleyen şablon motorlarıyla HTML tekrarları azaltılabilir
  • CSS nesting kullanıldığında uzağa uzanan seçiciler azaltılabilir ve bileşen bazlı stillendirme yapılabilir

Kutu modeli ve yerleşim: box-sizing, margin, varsayılan flow, flexbox

• box-sizing

  • Arayüz, özyinelemeli bir dikdörtgenler yapısıdır ve yerleşim her dikdörtgenin nereye konulacağını belirleme sürecidir
  • HTML varsayılanlarında öğelerin width ve height değerleri border ve padding’i içermez; bu sezgisel değildir
  • Bir yerde padding artırıldığında, başta kusursuz görünen tüm yerleşim beklenmedik biçimde kayabilir
  • * { box-sizing: border-box; }, bir CSS reset’in ilk satırı olmayı hak eder ve border eklemeyi yerel bir değişikliğe dönüştürür

• margin collapsing

  • Bir öğenin etrafında 8px boşluk istiyor olmanız, padding kullandığınızda iki komşu öğe arasındaki boşluğun 16px olmayacağı anlamına gelmez
  • margin, iki komşu margin’i toplamak yerine max ile birleştiren şekilde çalışır
  • Margin collapsing çok faydalıdır, ama şaşırtıcı davranışlar da üretebilir
  • Çocuğun margin’inin ebeveynin dışına taşabildiği düşünülür, ancak margin’e dair sezgisel kavrayışın yeterli olmadığı belirtilir
  • Julia Evans’ın Moving away from Tailwind, and learning to structure my CSS yazısı, genel olarak öğenin kendisine margin vermek yerine ebeveynin çocuklar arasındaki margin’i kontrol ettiği owl selector yaklaşımını ele alır
  • section içindeki ilk çocuk hariç tüm çocuklara margin ekleme yaklaşımı, margin sorunlarını azaltan bir fikir olarak anlaşılır
  • Bu tür bilgilerin, profesyonel web geliştiricisi olmadan ya da başka CSS çatılarını tersine mühendislikle incelemeden öğrenilmesinin zor olması rahatsız edicidir

• Varsayılan flow yerleşimi

  • Varsayılan yerleşim algoritması, HTML’in belge dili kökeniyle ilişkilidir ve metin ile görsel ağırlıklı kâğıt belge üretim kullanımına göre şekillenmiş görünür
  • Gövde metni için varsayılan flow gerçekten istenen davranışa yakındır
  • Sayfa öğelerinin mekânsal düzenini doğrudan kontrol etmek için varsayılan flow dışında bir yaklaşıma ihtiyaç vardır

• flexbox

  • flexbox, bir dizi öğeyi dikey ya da yatay yerleştirip kullanılabilir alana göre uyarlayan bir yerleşim modelidir
  • Geçmişte “bu solda, şu sağda” gibi yerleşimler için bile derin CSS bilgisi ya da opak CSS framework’leri gerekirdi
  • flexbox oldukça karmaşıktır; MDN’e sık sık dönmek gerekir, ancak genelde istenen işi tamamlamayı sağlar

• Duyarlı tasarım

  • Modern CSS, ekran boyutunu sorgulayabilir ve kullanıcı aracısı kısıtlarına göre koşullu mantık uygulayabilir
  • HTML özünde duyarlıdır; PostScript ya da PDF’den farklı olarak pencere boyutu değiştiğinde paragrafları otomatik yeniden akıtır
  • Açık duyarlı kurallardan kaçınmak ve yerleşimin makul davranmasına izin vermek daha iyidir
  • Bu blog, açık @media sorguları olmadan mobil, tablet ve masaüstünde kabul edilebilir görünür
  • Gövde metninin ana sütununa koşulsuz bir max-width vermek yeterli olabilir

Boyut ve metin: piksel, yazı tipi, satır yüksekliği, satır sonu

• Piksel

  • 1px beklenen işi yapar, ama ekranın tek bir fiziksel pikseli anlamına gelmez
  • CSS’te 1px, görsel açı birimidir; her ekranda algısal olarak benzer görünmesi için tasarlanmıştır
  • Ekran boyutu, piksel yoğunluğu ve tipik izleme mesafesine göre farklı sayıda fiziksel piksele dönüştürülür
  • Bu yüzden farklı ekranların piksel yoğunluğunu ayrı ayrı düşünmeden tüm boyutları piksel cinsinden belirtebilirsiniz
  • CSS’te santimetre ve inç gibi “gerçek” birimler de piksele göre tanımlandığından açı gibi davranır

• font-size

  • font-size: 16px içindeki 16px, belirli bir glif boyutu değil, glif çevresindeki sanal kutunun boyutudur
  • Bu kutu glife tam oturmaz ve gerçek glif boyutu yazı tipine göre değişir
  • font-size-adjust, yazı tipleri arasında font-size davranışını daha tutarlı hale getirebilir
  • Şu anda font-size-adjust çok niş bir özellik gibi görünür; kişisel olarak box-sizing yanına font-size-adjust: ex-height 0.53; koymak istenir, ancak bunu yapan sayfa azdır
  • font-size varsayılanı tarayıcılar arasında görece tutarlıdır ve baskın varsayılan 16px’tir
  • Yazı tipine bağlı olarak 16px küçük görünebilir ve bazı varsayılan yazı tipleri özellikle küçüktür
  • Apple tarafında font-family: serif, sans-serif’e göre çok daha küçük görünür; 16px ile neredeyse rahatsız edici derecede zor okunur
  • CSS’te font-size ayarlamak, tarayıcının varsayılan yazı boyutunu değiştirme mekanizmasını devre dışı bırakır
  • Metnin varsayılan olarak okunabilir olacağını varsaymayın; farklı ayarlarda kontrol edin
  • font-size-adjust ile serbestlik derecesi azaltılıp font-size anlamı sabitlendikten sonra, varsayılan 16px yazı boyutunda iyiyse iş tamamdır
  • Değilse font-size daha büyük bir değere ayarlanmalı, ardından reader mode’da da okunabilir olup olmadığı kontrol edilmelidir

• line-height

  • Adına rağmen line-height, tek bir satırın yüksekliğini ayarlamaz
  • line-height, aynı yazı tipiyle ayarlanmış glif grubunun yüksekliğidir
  • Tüm metin aynı yazı tipindeyse satır yüksekliği ile glif grubunun yüksekliği çakışır
  • Bazı kelimeler monospace yazı tipiyle ayarlanırsa beklenmedik sonuçlar ortaya çıkabilir
  • font-size-adjust, kutu içindeki glif boyutunu düzeltir, ama göreli konumlarını belirlemez
  • Farklı yazı tiplerine sahip metin grupları ortak baseline paylaşacak şekilde dikey hizalandığında, her birinin line-height line-box’ı birbirinden kayar
  • Sonuçta toplam satır yüksekliği bir birleşim gibi oluşur ve beklenenden büyük olabilir
  • Bu etki, Deep dive CSS: font metrics, line-height and vertical-align yazısında ayrıntılı olarak ele alınır

• vertical rhythm

  • vertical rhythm, başlıklar ve görseller olsa bile paragraflar arasındaki satır konumlarının aynı göreli hizayı koruması fikridir
  • Bu, web sayfasının arkasında görünmeyen bir satır kılavuzu varmış gibi anlatılır
  • Tek sütunlu yerleşimde bunun yararlı olmadığı düşünülür
  • İki sütunlu yerleşimde iki taraftaki satırların hizalanması istenebilir
  • Tek sütunda bunun için karmaşık çaba harcamak mantıklı değildir

• word-break

  • Flow yerleşiminin güzel yanı, pencere daraldığında metnin satırlara düzgün biçimde bölünmesidir
  • Satırlar yalnızca boşluklarda ya da tireleme ekleme noktalarında kırılabilir
  • inline code ya da URL gibi uzun parçalar kırılmayabilir
  • Bu sorun mobil cihazlarda yatay taşmaya yol açar ve genelde ancak yayımlandıktan sonra fark edilir
  • Bunu düzeltmek için tek bir sihirli çözüm yoktur, ancak Against Horizontal Scroll içinde bazı ipuçları vardır

Pratik sonuç

• Basit bir blog oluşturmak için HTML ve CSS’in yeterli kısmını kısa biçimde anlatan kaynaklara ihtiyaç vardır
• Sonuç olarak, margin collapsing gibi sorunlar karşısında dağılmadan basit bir blog yapmaya yetecek HTML ve CSS’i anlatan 100 sayfalık kısa bir kitap talebiyle bitirilir

[GN⁺]

Lobste.rs görüşleri

• Küçük bir itiraz ama responsive design tanımı, “çeşitli cihazlarda ve pencere/ekran boyutlarında iyi render edilerek kullanılabilirlik ve memnuniyeti garanti etmek”tir.
  Media query ya da container query bunun uygulanması için kullanılan araçlardan yalnızca biridir; duyarlı tasarım ise “her şeye media query kullanalım”dan çok bir düşünme biçimine yakındır.
  Bu yüzden “kötü olan” şeyin duyarlı tasarımın kendisi değil, media query’lerin ya da breakpoint aşırı kullanımının olduğunu söylemek daha doğru görünüyor.

• “Browser defaults” bölümü epey yanlış anlamaya açık. Reset stylesheet ve normalize stylesheet amaç ve çalışma biçimi açısından çok farklı; yazı ise bunları birbirine karıştırıyor.
  Reset, tarayıcılar arası farkları gidermekten ziyade öğeler arasındaki varsayılan farkları siler; ol için padding-inline-start ya da buttonın varsayılan görünümü gibi şeyleri kaldırır ve kullanıcı aracısı stil sayfasının üstünde değil, boş bir sayfadan stil oluşturmaya imkân verir.
  Normalize ise kullanıcı aracısı stil sayfasıyla iş birliği yapmayı amaçlayan bir yaklaşımdır; tarayıcılar arası farkları eşitleyen kısımlarla, “daha makul” görülen varsayılanlara çeviren kısımlar iç içedir.
  Günümüzde tarayıcı varsayılanlarının anlamlı biçimde farklı olduğu durum çok fazla değil; bu yüzden genel web içeriği yazanlar bunu neredeyse tamamen göz ardı edebilir. İstisna olarak Chromium has the wrong table border-color, WebKit fixed theirs 1½ years ago, bazı form öğelerinin boşluk/boyut farkları, appearance ve WebKit’in <summary> ::marker stillendirmesi kalıyor.
  box-sizing: border-box kullanımına da karşı olan taraftayım. border-box layout merkezlidir, content-box ise content merkezlidir; bu yüzden layout’u ebeveynin üstlenmesi ve tasarımın içerik temelinde yapılması daha iyi bence. Oranlarla çalışırken content-box gerekir ve border-boxın gerçekten yararlı olduğu durumlar çoğunlukla bodyyi viewport’a doldurmak kadardır.
  font-size-adjust konusunda da şüpheliyim. Yaygın olarak bilinen bir sorunu daha az doğrulanmış bir sorunla değiştiriyor; bazı insanlar için biraz daha iyi, başkaları için biraz daha kötü olabilir. Temel sorunu çözemiyor ve kullanıcının font oranları ile metrikleri hakkında temelsiz varsayımlar yapıyor.
  line-height ve “aynı fontla ayarlamak” ifadesi de çok kesin değil. Gerçekte font boyutu, dil değişimi, font-family: monospace, vertical-align, <sup>, <sub> ve font metrikleri birbirine giriyor; dolayısıyla bunu sadece aynı font sorunu olarak görmek zor.
  Margin collapsing yazıdakinden daha karmaşık olsa da oldukça pratiktir. Genel içerikte flex ya da grid kullanırsanız gap veya margin’lerle sürekli oynamanız gerekir ve bu da yapıyı kırılganlaştırır. display: flow-root kullanırsanız çocuk margin’lerinin ebeveyn margin’iyle birleşmesini engelleyebilirsiniz.
  Duyarlı tasarıma ilişkin genel çerçeveye katılmıyorum ama gereksiz media query’leri azaltmak ve tarayıcıyla kavga etmemek yönü doğru. Layout değişimlerini içerik temelinde ifade edebiliyorsanız, çoğu durumda o yol daha iyidir.
  Son zamanlarda viewport birimlerini kullanan clamp doğrusal enterpolasyonunu çok kullanıyorum: margin-inline: --vw-lerp(1rem at 20rem, 2.5rem at 60rem); ifadesini margin-inline: clamp(1rem,1rem + ((2.5 - 1)/(60 - 20)*(100vw - 20rem)),2.5rem); olarak genişletmek gibi.
  Bunu geçen yıl implemented this as a LightningCSS visitor şeklinde uyguladım; viewport 20rem ve altındayken 1rem oluyor, 60rem’e kadar 2.5rem’e yumuşakça artıyor ve sonra duruyor; böylece breakpoint olmadan kullanıcının font boyutuna da uyum sağlıyor ve hissiyatı güzel oluyor.

  • font-size-adjustın gerçekten böyle çalışıp çalışmadığından emin değilim. Adı yüzünden kafa karıştırıyor ama benim anlayışıma göre font-size em kutusunun boyutunu, font-size-adjust ise em kutusunun içindeki glyph boyutunu değiştiriyor.
    Bu yüzden em ve rem aynı kalırken ch değişiyor. Ama ch zaten fonta bağlı olduğu için değişmesi normal.
    font-size-adjust hakkında bir yazı yazılmasını isterdim. Uzman değilim, bu yüzden güvenim düşük; ama şimdiye kadar neredeyse hiç bilinmeyen ama muazzam bir iyileştirme gibi görünen bir şey oldu benim için. Herhangi iki fontu her bağlamda otomatik olarak eşleştiremez ama em kutusunu değil de x boyutunu eşitlemek bile fontların/bağlamların %90’ını kapsıyor gibi geliyor.

• Yazının niyeti iyi ve HTML/CSS’e tamamen dalmış olmayan insanların bakış açısı da önemli, ama “kötü” denen şeylerin önemli bir kısmı bağlama göre iyi olabilir.
  CSS selectors kötüye kullanıma açık ama özünde kötü değiller. A ya da B diye sonuçlandırmak yerine genel kurallar/seçiciler koyup gerektiğinde istisna temelli class’lar veya utility class’lar serpiştirebilirsiniz.
  Yazının içinde de iyi bir seçici örneği var:

  section > *+* {  
    margin-top: 1rem;  
  }  
  

  Media query’ler de eğer container queries ile çözülebiliyorsa gereksiz olabilir.
  CSS yüzey alanı açısından inanılmaz geniş gelebilir; ama bu kadar yaygın kullanılıp bu kadar çok iş yapabildiği için görüş ayrılıkları da sık yaşanıyor. Yine de CSS’in ne kadar ilerlediğini ve kavramları benimsediğinizde görece az kodla neler yapılabildiğini de görmek gerek.
  Daha fazla öğrenmek isterseniz https://every-layout.dev/ , CSS’te çeşitli öğelerin nasıl birbirine geçtiğini anlamamda oldukça yardımcı olmuştu.

  • Every Layout tavsiyesine ben de katılıyorum. Hâlâ CSS’i sevdiğimi söyleyemem; kişisel olarak cascade’in bir layout modeli olarak temelden sorunlu olduğunu düşünüyorum, ama artık masaüstü ve mobilde çoğunlukla makul ve duyarlı görünen şeyler yapmak mümkün.
    Web layout’unu anlamaya başlamamı sağlayan kırılma noktası, iyi bir web sitesinin temelde dikey tasarım olduğunu fark ettiğim andı. Öğeler varsayılan olarak yukarıdan aşağıya dizilmeli; önce mobil ekran tasarlanmalı, sonra büyük ekranlarda bu yapı bonus olarak genişletilmeli.

• Bu iddiaya katılmak zor. CSS nesting sadece sözdizimsel bir şekerleme ve aşırı derecede spesifik seçici sorununu anlamlı biçimde önlemiyor.
  15 yıl önce de Sass ile seçici iç içe geçirmeyi çok kullandık ve sonunda CSS seçicilerini HTML yapısına fazla sıkı bağlayarak kendi ayağımıza kurşun sıktığımız sonucuna tek tek vardık.
  İç içe geçirmenin tuzağı projenin başında pek görünmez. Yeni özelliklerin üretildiği greenfield aşamasında CSS’i bu şekilde yazmak çok iyi görünür.
  Birkaç ay sonra büyük yerleşim değişiklikleri ve tasarım yenilemesi başlayınca HTML’de wrapper öğeler yer değiştirir ve CSS’i buna uydurmak LSD almışken Rubik Küpü çözmeye benzer.
  Seçici özgüllüğünü yönetmede zirvenin, çoğunu tek bir class gibi basit seçicilerle düşük seviyede tutup yalnızca az sayıda birleşik seçici ve a:hover gibi bağlanmış seçici kullanmak olduğunu düşünüyorum. Bu, BEM ve OOCSS gibi bir çizgiydi; sonrasında ilgi hızla JS merkezli araçlara kaydı.

• İlginç bir yazı ama yazar sanki iç içe seçicileri hiç etkisi olmayan bir yerde kullanıyor.

  header { /* Site Header */  
    margin-bottom: 2rem;  
    & nav { /* ampersand redundant here? */  
      /* Styles, specific to nav in the Header. */  
    }  
  }  
  

  • & işaretinin atlanabilmesini bir hata sayıp her zaman & kullananlar da var. Bence oldukça makul bir yaklaşım.
    Ben kişisel olarak hâlâ kararsızım. Başta bunun hata olduğunu düşünmüştüm ama bir sürü stil yazdıktan sonra hepsini header { … } ile sarıp kapsamı daraltabilmek oldukça kullanışlı. @keyframes gibi seçici tabanlı olmayan at-rule’leri de bunun içine yazabilmek güzel olurdu.

• Bu, dürüst olmak gerekirse gerçekten çok kötü bir tavsiye. Maklad’ın yazılarını severim ama bunu yazanın profesyonel olarak hiç CSS kullanmamış biri olduğu çok belli görünüyor.
  Neredeyse tamamı, profesyonel CSS yazımında kaçınılan amatör kötü pratikler.

  • Daha somut söylersek, amatörler için ana tasarım hedefi içerik kutusudur. CMS paragraflar, vurgular, bağlantılar ve listeler üretir; zamanın çoğu bunları stillendirmekle geçer.
    Bunları seçicisiz stillendirince <main> ya da <nav> de seçicisiz biçimlendirilmeye başlanır.
    Buna karşılık profesyonel ortamda içerik kutusu tasarlamaya çok az zaman harcanır. Projenin başında bir kez yapılır, sonra da küçük hatalar yavaş yavaş düzeltilir.
    Zamanın büyük kısmı özel bileşenler veya yeniden kullanılabilir bileşenler üretmeye gider. Yeniden kullanılabilir bileşenler daha zordur ve fiilen siteye özel bir Bootstrap klonu yapmaya dönüşür.
    Özel bileşenler daha kolaydır ama kod çoğalır; başka bileşenlerle istemeden çakışmaması için BEM, OOCSS veya Tailwind tarzı utility class’lar gibi stratejiler gerekir.
    Sonuç olarak her tekniğin uygun olduğu ölçek farklıdır. Profesyonel CSS yazım tarzı işe yaramaz görünüyorsa muhtemelen siz farklı ölçekte bir problemi çözüyorsunuzdur.
  • Yazıda da açıkça “production CSS yazmışlığım yok” deniyor.
    Yine de Bad: Wrappers kısmına katılıyorum. Tüm siteyi bir iki dosyada yazan CSS uzmanları da gördüm, çok yoğun şekilde CSS kullananlar da gördüm.
    İkinci yol, sonunda çok miktarda CSS’i yönetebilmek için BEM gibi yanlış yaklaşımlara kaymaya daha yatkın.

• Yazıda birbiriyle çelişen tavsiyeler var gibi görünüyor.
  Good: Classless CSS ile Bad: CSS selectors yan yana duruyor ama class’sız CSS kullanacaksanız aslında CSS seçicilerine daha fazla bağımlı olmanız gerekir.
  Referans: https://www.keithcirkel.co.uk/css-classes-considered-harmful/

• “Web sayfasının arkasında görünmez çizgili bir defter varmış gibi” denilen vertical rhythm, EM değerleri kullanılarak gayet sağlanabilir.
  Farklı fontlar karıştırılırsa metrik farkları yüzünden biraz oynayabilir ama o durumda da flex’in align-items: baseline özelliği kullanılabilir.