Modern HTML/CSS'in Az Bilinen Özellikleri

 (lyra.horse)
14 puan yazan GN⁺ 2025-08-30 | 3 yorum | WhatsApp'ta paylaş
  • Son dönemde web sitelerindeki performans düşüşünün başlıca nedenleri aşırı JavaScript kullanımı ve izleme betikleridir; çoğu durumda bunların yerini yalnızca HTML/CSS ile doldurmak mümkündür
  • CSS nesting, relative colors, yeni viewport birimleri (lvh, svh, dvh) gibi yakın zamanda eklenen özellikler, geçmişte JS veya önişleyicilere bağlı olunan işleri basitçe çözebilir hale getiriyor
  • CSS, yalnızca basit bir stil aracı değil; animasyonlar, girdi doğrulama, karanlık mod teması, akordeon menüler de oluşturabilen güçlü bir dildir
  • Performans açısından da CSS, GPU hızlandırması ve ayrı bir iş parçacığında çalışması sayesinde animasyonlar ve geçiş efektlerinde JS'den daha akıcı ve verimlidir
  • Yazar, CSS'i yalnızca pratik bir araç olmanın ötesinde ifade ve sanatın bir aracı olarak vurguluyor ve web geliştiricilere modern CSS'in potansiyelinden daha fazla yararlanmalarını öneriyor

Giriş: Web'in karmaşıklığı ve yeni denemeler

  • Birçok web sitesi, JavaScript framework'lerinin aşırı kullanımı nedeniyle performans düşüşü ve karmaşıklık yaşıyor
    • React uygulamaları birkaç saniyede yükleniyor, NextJS ise hydration hataları üretiyor
    • node_modules klasörü birkaç gigabayt yer kaplıyor
  • JavaScript olmadan da yalnızca HTML ve CSS ile güçlü özellikler hayata geçirilebilir
    • E-ticaret sitelerindeki karmaşık alışveriş sepetleri veya dashboard'lar dışında JavaScript zorunlu olmayabilir
  • Bu yazı, CSS'in en yeni özelliklerini tanıtıyor ve geliştiricileri yalnızca JavaScript'e bağımlı kalmadan farklı olanakları keşfetmeye yönlendiriyor

CSS hakkındaki yanlış algılar ve bakış açısı

CSS gerçekten zor ve kullanışsız mı?

  • CSS'e yönelik olumsuz algı, temel öğrenimin eksikliğinden kaynaklanıyor
    • Pek çok geliştirici CSS temellerini atlayıp JavaScript veya TypeScript'e odaklanıyor
    • CSS, basit bir stillendirme aracı değil; güçlü yetenekler sunan alan odaklı bir dil
  • CSS, flexbox gibi araçlarla karmaşık düzenleri kolayca kurabiliyor
    • Örnek: display: flex ve justify-content: center ile bir div'i ortalamak kolaydır
    • Tarayıcı geliştirici araçları, flexbox özelliklerini görsel olarak ayarlamaya yarayan bileşenler sunar
  • Yalnızca tek bir alanı (ör. JS) derinlemesine öğrenip CSS'i ihmal ederseniz, bunun yük gibi gelmesi doğaldır
Reklam

CSS yazmanın sancısı ve değişim

  • Eskiden CSS pek rahat değildi; bu yüzden Sass, Tailwind gibi araçlar ortaya çıktı
    • Örnek: .post > .buttons .like:hover gibi uzun seçici zincirlerini yönetmek gerekiyordu
  • Son dönemde kaliteyi artıran özellikler (nesting vb.) eklendiği için artık yalnızca temel CSS ile de rahat geliştirme yapılabiliyor
    • CSS nesting, ilgili stilleri tek yerde toplayarak okunabilirliği artırır
      • Örnek: .post { & > .buttons { .like { &:hover { ... } } } }
      • Ebeveyn-çocuk ilişkisi netleştiğinden daha kısa ve basit sınıf adları kullanılabilir
  • Relative colors, renk ayarlamayı kolaylaştırır
    • hsl(from #123456 h s calc(l + 10)) ile parlaklık ayarlanabilir
    • color-mix() ile iki renk karıştırılarak dinamik renk üretilebilir
  • Media query aralık sözdizimi, (width <= 768px) gibi sezgisel koşullar tanımlamayı sağlar
  • lh birimi, satır yüksekliğine göre stillendirmeyi destekler
  • scrollbar-gutter özelliği, scrollbar nedeniyle oluşan layout kayması sorununu çözer
  • Baseline, temel tarayıcılarda özellik uyumluluğunu garanti eder
    • newly available, modern tarayıcılarda çalışır
    • widely available, 2,5 yıl önceki tarayıcılara kadar desteklenir
    • Örnek: CSS nesting, Aralık 2023'ten beri tüm tarayıcılarda destekleniyor
Reklam

Neden yalnızca CSS/HTML ile geliştirme yapılmalı?

  • Bazı kullanıcılar JavaScript'i varsayılan olarak devre dışı bırakır (güvenlik, gizlilik vb. nedenlerle)
  • Web sitesini saf CSS/HTML ile sunarsanız, bu kullanıcıların da siteyi kullanabilme olasılığı artar
  • Hem geliştirme hem de kullanıcı tarafında, yalnızca CSS/HTML kullanmanın hız, erişilebilirlik, CPU/pil kullanımı açısından avantajları büyüktür
    • CSS animasyonları compositor thread üzerinde çalıştığı için CPU yükünü azaltır
    • JavaScript event loop üzerinden çalışır; bu da küçük gecikmelere yol açabilir
  • Erişilebilirlik ve kullanım kolaylığı artar
    • Buton hover efektleri, toast animasyonları, girdi doğrulama gibi işler CSS ile kolayca yapılabilir

CSS'in pratik örnekleri ve başlıca özellikleri

@starting-style ile doğal başlangıç animasyonları oluşturma

  • Önceden bir öğenin giriş animasyonunu yapmak için keyframes, JS tetikleyicileri gibi karmaşık yapılara ihtiyaç duyuluyordu
  • @starting-style ile başlangıç durumunu tanımlamak kolaylaştı. Öğenin ilk durum animasyonu (ör. fade-in) artık rahatça yapılabiliyor
    • transition: opacity 1s; @starting-style { opacity: 0; } şeklinde ayarlanabilir
    • Ayrı bir @keyframes ya da JavaScript olmadan da çalışır
  • Yalnızca transition ile birlikte başlangıç durumunu belirtmek, animasyonun doğal biçimde uygulanmasını sağlar
    • Örnek: toast mesajlarının opaklık ve konum geçişlerini yumuşak hale getirmek

Karanlık/aydınlık mod için kolay tema ayarı

  • color-scheme: light dark, kullanıcı tercihine göre temayı otomatik değiştirir
  • light-dark(#000, #FFF) fonksiyonu, açık/koyu moda uygun renkleri belirler
  • Radio button'lar ve :has seçicisiyle kullanıcı tema seçimi desteklenebilir
    • JavaScript olmadan yalnızca CSS ile tema değişimi mümkündür
    • İstenirse temayı kaydetme/yükleme için JavaScript sonradan isteğe bağlı eklenebilir
    Reklam

Radio/checkbox ve :has, :checked ile özel UI oluşturma

  • Sekmeler, akordeonlar, toggle'lar gibi karmaşık etkileşimler bile JavaScript olmadan uygulanabilir
  • Radio button'lar, :checked ve :has ile özel biçimde stillendirilebilir
    • Örnek: label:has(input:checked) ile seçilmiş buton stili verilebilir
    • Girdi öğesi opacity: 0 ile gizlenirken ekran okuyucu erişilebilirliği korunur
  • details öğesi, SSS benzeri akordeon menüler oluşturmak için uygundur
    • name niteliğiyle yalnızca tek bir bölümün açık kalması kontrol edilebilir
    • [open] durumuna göre animasyon eklenebilir

Girdi doğrulama ve durumun yansıtılması

  • pattern, required gibi HTML nitelikleri ile CSS sözde sınıflarının (:valid, :invalid, :user-valid vb.) birleşimi, gerçek zamanlı doğrulama ve görsel geri bildirim sağlar
  • Girdi alanlarının outline/border stilini değiştirerek kullanıcı deneyimi iyileştirilebilir
  • HTML'in pattern niteliği, girdi alanı doğrulaması için kullanılabilir
    • Örnek: \w{3,16} ile 3-16 karakterlik harf/rakam/alt çizgi kabul edilebilir
  • CSS'in :valid ve :invalid durumları, geçerliliğe göre stillendirme yapar
    • :user-valid ve :user-invalid, stilleri yalnızca kullanıcı giriş yaptıktan sonra uygular
    Reklam
  • :has seçicisiyle girdi durumuna göre başka öğeler de stillendirilebilir
  • Bazı durumlarda (ör. karmaşık girdi koşulları) JS gerekebilir; ancak çoğu durumda CSS/HTML yeterlidir

Viewport birimlerini doğru kullanmak

  • vw/vh birimleri, mobilde adres (navigasyon) çubuğunun görünmesi/gizlenmesi nedeniyle doğruluk sorunları yaşar
  • lvh/svh/dvh (largest/smallest/dynamic viewport height) gibi yeni viewport birimlerinin kullanılması önerilir
    • lvh: tam ekran kullanım için (ör. tam ekran arka plan)
    • svh: her zaman ekranda görünmesi gereken butonlar, bağlantılar vb. için
    • dvh: kaydırma gibi değişimlere göre alanı dinamik biçimde ayırmak için
  • Klavye kaplaması, interactive-widget niteliği veya VirtualKeyboard API ile ele alınabilir
    • <meta name="viewport" content="width=device-width, interactive-widget=resizes-content">
    • Chromium tabanlı tarayıcılarda navigator.virtualKeyboard.overlaysContent = true

CSS istek listesi (eksik kalan veya arzu edilen özellikler)

  • Yeniden kullanılabilir bloklar: Bir sınıf içinde başka bir sınıfı uygulayabilme (ör. @apply border)
  • Birleştirilmiş media query seçicileri: @media ile sınıf seçicisinin birleşimi
  • nth-child değişkeni: span { --nth: nth-child(); } ile dinamik stillendirme
  • nth-letter seçicisi: Belirli bir harfi stillendirme (ör. p::nth-letter(2))
  • Birim kaldırma: calc(100vw / 1px) ile birimsiz değer üretmek
  • image() fonksiyonu: Yedek renk ve görsel parçaları desteği
  • body içinde style etiketi: FOUC sorununu hafifletmek için resmî standart desteği

Sonuç: CSS ve web'in sanatsal yönü

  • CSS, yalnızca bir araç değil; yaratıcı ifadenin bir aracıdır
  • Yapay zeka araçları veya build zinciri (linter, minify araçları) yaratıcılığı sınırlayabilir
  • CSS, performans, erişilebilirlik ve sanatsal ifadeyi aynı anda karşılar
  • Bu yazı, yaklaşık 49kB'lık JavaScript'siz HTML/CSS ile yazılmıştır
    • Tüm etkileşimli bileşenler ve görsel unsurlar elle uygulanmıştır
    • Örnek: CSS tıklama oyunu, CSS'in programlama dili benzeri olanaklarını kanıtlıyor

İlgili okumalar

3 yorum

 
duqduqduq 2025-09-01

Eskiden full-stack’tim ama kariyerimde seviye yükseldikçe nedense FE yapma fırsatım kalmadı; yaklaşık 10 yıl el sürmemiştim. Kısa bir tanıtım yapmak için yakın zamanda bir şirkette eğitim verme işim oldu da tekrar baktım, gerçekten şaşırtıcı derecede değişmiş. scss ile birlikte düşününce daha da nimet gibi. Ama CSS alanı gerçekten tuhaf. Öğrenmesi kolay, fakat takdir edilecek kadar iyi kullanabilmek bence kişinin estetik anlayışı ve yaratıcılığına göre ayrışıyor. Kullanılabilirlik ve tasarımın daha çok önemsendiği bugünün web çağında, publisher’ların değerinin daha yüksek takdir edilmemesi üzücü geliyor.
 
ahwjdekf 2025-09-01

Bu kez web geliştirme teknolojilerine giriş niteliğinde bir hobi çalışması olarak, en ufak bir temelim olmadan tamamen deneme yanılma usulüyle nextjs, authjs, tailwind, shadcn kullanarak basit bir ilan panosu yaptım ... en yüksek öğrenme zorluğu ise CSS'ti.
 
GN⁺ 2025-08-30
Hacker News görüşü

  • CSS’e eklenen nesting özelliği için minnettarım, ama genel olarak bakınca CSS gerçekten tuhaf ve bence kişisel olarak berbat bir dil; belki de onu düzgün kullanamıyor oluşumdandır, ama o kadar karmaşık ve dağınık ki sanki anlamını bilmediğim rünleri oradan oraya taşıyormuşum gibi geliyor; stil verme ve yerleşim sistemi birbirine karışmış durumda, kalıtım ve kapsama ilişkileri de farklı olduğu için daha da kafa karıştırıyor; stil ile yerleşimi birleştirmek bence bir hataydı, zaten temelden bozuk bir sisteme sadece yeni özellikler eklemenin çözüm olamayacağını düşünüyorum

    • Ben de son 10 yıldır CSS ile para kazandım, ama CSS sanki baştan tasarlanmış bir dil değil de o anda ihtiyaç oldukça genişletilmiş bir şey gibi duruyor; mevcut özelliklerin üstüne yeni modüller eklenmiş ve bunlar ya birbiriyle çakışıyor ya da hafif farklı davranıyor, bu da debug etmeyi zorlaştırıyor; box model ile flex layout’un farklı çalışması, gap özelliğinin flex ve grid’de farklı davranması buna örnek verilebilir (bağlantı); bir kez yerleşim kurunca pratikte neredeyse sabit hale geliyor, karmaşık native veya JS tabanlı kapsülleme olmadan esnek biçimde değiştirmek zor; sonra da beklenmedik şekilde font ağırlığı değişiyor ya da mobil menü masaüstünde de görünüyor
    • Katılmıyorum; CSS hakkında bu kadar olumsuz görüş görmemizin temel nedeni, insanların onu düzgün öğrenmemiş ya da özellikle cascade’i tam anlamamış olması bence; bir zamanlar CSS spesifikasyonunu derinlemesine incelemiştim ve markup’ın anlamı ile stili ayırma amacı açısından oldukça iyi tasarlanmış bir dil olduğu sonucuna varmıştım
    • Stil ile yerleşimi ayırmanın imkansız olduğunu düşünüyorum; UI geliştirmiş herkes bu iki unsurun özünde iç içe geçtiğini ve birbirine bağlı olduğunu hisseder; örneğin metin uzunluğu veya boyutu, overflow, margin, padding gibi şeyler birbirini etkiler; bir öğenin kenarlığını ya da boşluklarını değiştirince içeriğin alanı da değişir; bunları tamamen ayırmak mümkün değil
    • CSS’in asıl sorununun Cascading olduğunu düşünüyorum ve modern frontend geliştirmesinin büyük kısmı da zaten bu cascade’i engellemek için dönüyor; UI’ı bileşenlere ayırmak bunun örneği; yerleşim ise ayrı bir sorun ve uyumluluk yüzünden daha da karmaşıklaşıyor; eğer tüm yerleşim varsayılan olarak sadece flexbox ya da grid ile çalışsa ve inline ile non-inline aynı kapsayıcıda karıştırılmasa çok daha iyi olurdu; React Native tam olarak böyle çalışıyor; React Native’de stiller cascade etmediği için yönetmesi çok daha kolay
    • Bunların hepsi doğru, ama elimizde şu an olan bu; daha kavramsal olarak tutarlı bir model kurup onu CSS’e transpile etmek mümkün olabilir mi diye düşündüm; container queries ya da calc gibi şeylerle daha düzenli bir yerleşim sistemini matematiksel olarak kurmak mümkün olabilir; mevcut preprocessor dilleri ise CSS’te zaten yarım kalmış kavramların üstüne bir de başka yarım kalmış özellikler eklediği için durumu daha da kafa karıştırıcı hale getiriyor

  • CSS’in en kötü yanı bence, pek çok insanın onu düzgün öğrenmeden sadece bir gün kadar mecburen kullanıp sonra çok güçlü fikirler geliştirmesi

    • Benim de öyle bir “bir gün”üm olmuştu; bir podcast uygulaması yaparken yüzen bir footer yapmak istedim: (1) hep altta dursun, (2) hep görünür olsun, (3) içeriği kapatmasın ve (4) ayrı hack’ler gerektirmesin istiyordum; ama bunun CSS ile imkansız olduğunu fark ettim, gerçekten harika bir sistem
    • CSS’i 20 yıl önce öğrendim; vardığım sonuç şu: Cascading yüzünden adının Crappy Style Sheets olarak değiştirilmesi lazım; birden fazla kişi birlikte çalışınca “burada bir şeyi değiştirince orada alakasız bir şey bozuluyor” durumu varsayılan hale geliyor; kuralları override etmeye yarayan karmaşık kurallar bunun temel özelliği ama temelin bu olması iyi değil; karmaşık hedefleme yöntemleri giderek daha da karmaşıklaşıyor ve sonunda .foo > .bar:nth-child(2n) ~ .baz gibi kodlar ortaya çıkıyor; sonra da bu, ekip arkadaşının kodunu bozuyor; basit bir yerleşim bile baş ağrısı yaratıyor; son dönemde epey iyileşti ama asıl sorun en baştan bu cascade merkezli yapıydı diye düşünüyorum; sözdizimi gibi diğer eleştiriler daha ikincil; pratik ve kullanımı kolay olsa sözdizimine göz yumulabilir ama CSS öyle değildi; web yerleşimi yapmak başlı başına bir meslek olmamalıydı bence
    • “Birçok insan CSS’i öğrenmeden kullanıyor” sözüne dair, 20’den fazla spesifikasyonun hepsini öğrenmeden kullanmaya hakkın yokmuş gibi yaklaşmak bence haksız; insanlar bir aracı kullanırken sorun yaşıyorsa, sorunun araçta olup olmadığına bakmak gerekir, insanları suçlamamak gerekir; testereyi dikkatli kullanmayı zorlamak yerine güvenlik koruması eklemek daha doğrudur

  • Bu yazıda “bazı kullanıcılar JavaScript istemiyor” gerekçesi bana çok güçlü gelmiyor; ben de bir Arch kullanıcısıyım ve türlü scripting ile crawling işlerine meraklıyım ama “NoScript” ortamına odaklanmak bana pek önemli görünmüyor; bu çok küçük bir niş ve genel olarak görmezden gelinebilir diye düşünüyorum, bana biraz “kullanıcıların %10’u IE6 kullanıyor” denilen dönemi hatırlatıyor; yine de CSS’in daha iyi olması için sayısız başka neden olduğunu düşünüyorum; zaten bu ana tartışma da değil ama genel akış bana böyle hissettiriyor

    • CSS’in deklaratif olarak birkaç satırda yapabildiği bir işi JS ile imperatif yazınca onlarca satıra çıkıyor ve daha fazla tuhaf davranış, framework uyumluluk sorunu ve etkileşime geçme süresi gecikmesi ortaya çıkıyor; NoScript ortamı sadece bonus; gerçi içten içe hâlâ DSSSL’yi özlüyorum
    • Yazıda JavaScript istemeyen kullanıcılardan kısaca bahsediliyor ama metnin büyük bölümü CSS özelliklerinin kendisini göstermeye odaklanıyor; motivasyonlardan biri performans olsa da CSS tekniklerini tanıtmak çok daha üretken bir yaklaşım bence
    • Ben interneti günlük olarak NoScript ortamında kullanıyorum, yalnızca JS gerektiren sitelere istisna tanıyorum; performans, pil ve güvenlik açısından da oldukça iyi; hiç bir haftadan uzun süre NoScript ile yaşadın mı? Ben de denemeden önce aynı fikirdeydim; bu arada ben bu blog yazısının yazarıyım
    • NoScript kullanıcı kitlesinin o kadar anlamlı ya da özellikle hedeflenmesi gereken bir grup olduğunu düşünmüyorum, ama yazarın kısa değinisine ek olarak, daha az kod yazıp tarayıcı platformuna daha çok yaslanmanın muazzam bir değeri olduğunu düşünüyorum; tarayıcının yapabildiğini ona bırakmak gerçekten büyük bir verim sağlıyor
    • “Bazı kullanıcılar JavaScript istemiyor” iddiasına karşılık, bence kullanıcıların çok büyük kısmı JavaScript istemiyor

  • Nesting’in artık resmi standart olduğunu bilmiyordum; yakın zamana kadar hâlâ öneri aşamasında sanıyordum; CSS’in çok sayıda tuhaf yanı var ama JavaScript gibi giderek daha iyi bir dile dönüştüğü hissediliyor; Flexbox, :has seçicisi ve nesting sayesinde geçmişte yaşadığımız pek çok sorun epey hafifledi

  • İstek listemde olan iki CSS özelliği zaten spesifikasyonda var

  • CSS sözdiziminin berbat olduğunu düşünüyorum; 10-15 dil kullanıyorum ama CSS en zor okuyup anladığım dil, hatta x86 assembly’den bile daha anlaşılmaz; CSS render motoru için önceden token’lara ayrılmış bir girdi gibi ama aslında token da değil ve insanın yazması için de tuhaf; RFC’deki ASN.1 gibi, “işler böyle yapılmamalı” diye karşı örnek olarak gösterilmeli sanki

    • Bu dillerin arasında kaç tanesi deklaratif ya da alan-özel dil, bunu merak ediyorum; CSS ile assembly’yi karşılaştırmak pek uygun değil; CSS deklaratif, assembly ise bunun tam tersi; frontend geliştiricilerinin çoğu da imperatif dillerden CSS’e geçerken ilk başta zorlanıyor ama alışınca daha iyi hale geliyor; CSS terimleri ve kavramları çoğunlukla bilgisayar dünyasından değil, tasarım ve yayıncılık alanından geliyor; birçok geliştirici CSS’e açık komutlar kümesi gibi yaklaşıyor ama CSS birbirini etkileyen tuhaf bir sistem; tek bir özellik tüm yerleşim algoritmasını değiştirebiliyor (CSS yerleşim algoritmalarına giriş)
    • “15 dil biliyorum” desen bile, CSS’in gerçekten zor bir bilgi alanı olduğunu düşünüyorum; programlama dillerini çok kullanmış olsan da onları gerçekten “biliyorum” diyebileceğin seviyeye gelmek için muazzam miktarda pratik deneyim gerekir (açıklayıcı derinlik yanılsaması vikisi); CSS’i anlamanın en iyi yolu render sonucunu doğrudan görüp değerlendirmektir; ben onlarca yıldır böyle kullanıyorum
    • Ben de HTML/CSS/JS üçlüsü içinde en kötü olanın CSS olduğunu hissediyorum
    • “CSS önceden token’lara ayrılmış bir girdi” derken tam olarak ne kastettiğini biraz daha somut duymak isterim
    • font-size: 12px gibi bir kod insanların okuyamayacağı kadar zor değil, neden zor geldiğini anlamıyorum; bana gerçekten çok basit görünüyor

  • Radyo sekmesi örneğinin erişilebilirlik açısından iyi olup olmadığını merak ediyorum; WAI-ARIA ölçütlerine göre aria-selected, tabindex, aria-controls gibi özelliklerin sekme değiştiğinde JS ile güncellenmesi gerekiyor diye biliyorum ama emin değilim; erişilebilirlik çoğu zaman arka plana atılıyor, HTML/CSS kullanınca erişilebilirliğin otomatik olarak sağlandığı gibi bir yanılgı da olabiliyor; yaklaşımı seçerken bir kez daha düşünülmesi gereken bir nokta

    • Bildiğim kadarıyla bu radyo sekmeleri klavye navigasyonu ve ekran okuyucularla da iyi çalışıyor ve WAI-ARIA örneğindeki sekme-içerik akışını izliyor (WAI-ARIA örneği); erişilebilirlik konusunda uzman değilim ama elimden geldiğince doğrulamaya çalışıyorum, çeşitli erişilebilirlik araçlarıyla da bizzat test ettim
    • Orijinal metinde yazar erişilebilirlikle ilgili konulara birkaç kez değiniyor, hatta tarayıcı hatalarını dolaşmak için özellikle uğraşmış (ilgili dipnot)
    • Bu blog yazısının kendi erişilebilirliği, özellikle de kontrastı, o kadar kötü ki engelli örgütünde web geliştiricisi olarak çalışırken bunu referans kaynak olarak almakta zorlanırım

  • JS olmadan da bu tür etkileşimli efektler yapılabiliyor (örnek sayfa)

      • düşen konfeti animasyonu
      • kapatma işlevi olan bildirim kutusu
      • bildirimi kapatınca konfetinin de kaybolması
      • sekme davranışı da var (ama bu örnekte sunucunun yeniden yüklenmesi gerekiyor)
      • JS eklenirse animasyon daha akıcı ve zengin hale geliyor

  • 10 yıllık bir web geliştiricisi olarak, bu tür yazıların bizim yerleşik kabullerimizi sarsması gerektiğini düşünüyorum; başlık pek iyi olmadığı için neredeyse okumayacaktım; bu arada sadece CSS ile harita render edemezsin

    • CSS+SVG kullanırsan harita render etmek mümkün, tabii navigasyon gibi ek işlevleri ayrıca yapmak gerekir

  • Vega adı yüzünden önyargım olmuş olabilir ama bu siteyi gerçekten çok beğendim; genel tasarım da çok iyi, bu sayfanın içeriği de gerçekten harika; bundan sonra web geliştiren insanlarla bu bağlantıyı kesin paylaşacağım; arrupted işini de çok seviyorum, daha önce de harika şeyler üretmişti, o yüzden bu tanıdık alan adını ana sayfada görmek hoşuma gitti