Çözünürlüğe göre tasarlamayın


Geçtiğimiz hafta, iOS geliştiricilerimizden biri, varolan iPhone uygulamamızı iPad’e sadece birkaç ayarla oynadıktna sonra derleyerek çalışır hale getirdi, sonuç tabi ki götü başı dağılmış bir uygulama, ama fonksiyonel. Tabi ki iPhone ve iPad arasında deneyim tasarımı farklılıkları var fakat teknik olarak çok küçük problemler var. Uygulamanın uyumsuzluğunun 95%’i sadece görsel problemler ve bu problemler tasarımın özellikle iPhone ekran çözünürlüğüne göre yapılmış olmasında.

Mobil uygulamalar çok iyi örnekler değiller bu yazı için çünkü uygulamanın çalışacağı cihazlar belirli ve çözünürlükleri belirli, yazılan uygulamalar da çalışacakları cihazlara oldukça bağlılar.

Web’de ise durum biraz daha farklı, cihazları veya ekran çözünürlüklerini kontrol edemezsiniz, ayrıca web uyuglamalardan daha universal bir içerik türü, çok farklı cihazlar tarafından okunabilen çok daha geniş bir kitleye hitap edebildiginiz bir içerik dağıtım türü. Bu yazıda size bu farklılıkların bazı çıkış noktaları anlatacağım ve farklı bir arayüz geliştirme yaklaşımdan bahsedeceğim.

Az önce mobil uygulamalar bu problemin açık şekilde görüleceği ortamlar olmayabilir demiştim fakat Android işletim sistemi üsütnde çalışan uygulamalar bu yazıya daha yakın örnekler olabilirler çünkü piyasadaki farklı ekran çözünürlüğüne sahip cihaz sayısı oldukça yüksek, dolayısıyla web örneğine daha yakınlar.

Farklı çözünürlüklere sahip kullanıcı kitlesine üretilen klasik bir tasarım senaryosunda, kullanıcı analitikleri analizi yapılıp en çok kullanılan ekran çözünürlüğü belirlenir. Vazgeçilebilecek ekran çüzünürlüklerinden kurtulduktan sonra kabul edilebilecek minimum ve maksimum ekran çözünürlüğü tanımlandıktan sonra buna göre bir tasarım çalışması yapmak genel yaklaşımdır. Kullanıcı deneyimi tasarlandıktan sonra arayüz tasarımı yapılır ve arayüz tasarımı bittikten sonra tasarlanan asset’ler (resimler, ikonlar, butonlar, arka plan grafikleri vs) çoğu zaman arayüz geliştiricisinin ekran çözünürlüğünde test edilir ve az sonra belirteceğim deneyler yapılmaz.

Okumaya devam et “Çözünürlüğe göre tasarlamayın”

Radio butonları CSS ile makyajlamak

Bildiğiniz gibi bazı form elementlerine (radio butonlar, check butonlar ve birkaç diğer element) kozmetik olarak müdahale edemiyoruz veya kısıtlı şekilde müdahale edebiliyoruz. Sonuç olarak bu elementlerin görüntüsü ve çizilmesi tamamen tarayıcı kontrolünde, çoğu işletim sisteminin arabirim elementleriyle uyumlu şekilde görünecek şekilde ayarlanmış. Web arayüzünde standart elementlere dokunmamak genellikle farklı tarayıcı, farklı cihaz ve farklı işletim sistemlerinde sorunsuz çalışmasını sağlaycaktır.

Fakat bazen bir sayfayı sadece bir cihaz için veya belirli bir tarayıcıda görünecek şekilde tasarlarsınız ve bu noktada kullandığınız tüm elementlere istediğiniz tasarımı giydirmek isteyebilirsiniz. Örnegin mobil bir tarayıcıda görüntülenecek bir oyun arayüzü tasarlıyor olabilirsiniz.

Bunun için javascript çözümleri mevcut fakat birkaç css3 özelliği kullanarak sadece css ile çözebilirsiniz. Bu yazıda size radio butonları istediğiniz şekilde şekillendirmeyi anlatacağım. Radio butonları standart kullanımda, yani çoklu secenekten yapılan seçimler için bir örnek üzerinde göstereceğim.

Okumaya devam et “Radio butonları CSS ile makyajlamak”

CSS before ve after sözde elementleri

CSS2 ile gelen en faydalı özelliklerden biri de yeni sözde seçiciler, bunlardan ikisi “before” ve “after” seçicileri birçok minimal yaklaşıma olanak sağladı.

Özelliğin çıkış noktası bir elementin öncesi veya sonrasına noktalama gibi işaretçiler yerleşitrebilmekti. Yani en sade kullanımıyla:

Bu kod ile bir alıntı yazısının başına ve sonuna çift tırnak ekleyebiliyorsunuz:

Kırmızı ile işaretlediğim karakterler css ile eklendi. Ya da devamı olan bir yazı basarken ekrana:

kodu ile “…” ekleyebiliyorsunuz:

Fakat bu yeni sözde seçicileri akıllıca kullanarak bir element üretebilirsiniz. Yani bu seçici “content” özniteliği aldığı zaman dom üstünde yerleşmese de görsel olarak bir element oluşturuyor. Doğal olarak bu elementi block level yapabilir, genişlik yükseklik tanımlayabilir, posizyonlamasını istediğiniz gibi ayarlayabilirsiniz.

Çok yaygınlaşan bir kullanımla, bir elementin başına veya sonuna eklemek istediğiniz ufak simgeleri, resimleri veya işaretçileri bu sözde seçicilerle yaratabilirsiniz.

Basit örnekle size linklerinize simgeler koyabilmeyi anlatacağım. Biliyorsunuz HTML öznitelik seçicileri var css’de ve “target” özniteliği “_blank” olan bir linki diğerlerinden ayrı bir şekilde seçebilirsiniz. a[target=”_blank”] seçicisi dış bağlantıları seçecektir.

Bu kod dış baglantıyı gösteren bir a elementinin sonuna inline-block türünde bir element ekleyecek ve içeriğini boş bir şekilde ayarlayacaktır. Genişlik ve yüksekliğini 16px olarak ayarlayıp art alanını da bir simgeyi olarak ayarladığımızda linkin sonunda bu simgeyi görebileceğiz:

Bu sözde elementlerini şu tarayıcılar destekliyor:

  • Chrome 2+
  • Firefox 3.5+
  • Safari 1.3+
  • Opera 9.2+
  • IE8+ (Ufak problemlerle beraber)

Bu sözde elementlerle yarattığınız içeriğin sadece görsel amaçlarla kullanılmasi gerektiğini unutmayın, birçok erişilebilirlik okuyucusu veya tarayıcısı bu elementleri okuyamadığı için fonksiyonalitenizi bozacak içerikleri bu elementlerle kullanmamaya dikkat edin.

Bu yazıda çok yaratıcı örneklerini görmediniz fakat ne işe yaradıklarını bilmeniz ileride deney yapmanızı kolaylaştıracaktır veya karşılaştığınızda daha kolay anlamanızı sağlayacaktır.

CSS çatısı kullanmanın faydaları

Uzun bir süre bütün arayüzlerimi hiç bir framework veya arayüz kütüphanesi kullanmadan kendim yazdım. Özellikle mobil cihazların kullanımının yaygınlaşmasından dolayı, aynı html içeriğini farklı ekran çözünürlüklerine uygun arayüzlerde gösterme ihtiyacı çoğaldı. Hala mfyz.com’daki arayüzü tamamen sıfırdan yazılmış bir css ile çizdiriyorum. Evet herşeyi sıfırdan yapmanın avantajları var fakat avantajları kadar belki daha fazla dezavantajları ve daha derin bilgi birikimi gerektirmesi gibi yanları da var.

Her kodu tamamen elde hazırlamanın en büyük dezavantajı, kararlılıgını korumak ve çok popüler olan, bilinen hataları gidermek için zaman harcamak zorunda olmanızdır. Yani çok basit bir IE hatasını düzeltmek için gereksiz zaman kaybeder daha da tehlikelisi bu küçük şeyler için ayırdığınız zaman sizin genel motivasyonunuzu kırması gibi tehlikeleri göze almış olursunuz. Özellikle tek geliştiricinin bulunduğu projelerde (ki bir freelancer’in elinin altında her zaman tek başına yürürttüğü proje olur) büyük bir motivasyon bozukluğuna neden olabilir. Dolayısıyla hazır yapılar, kütüphaneler sadece zaman kazanmak şeklinde görülmekten çok, birçok geliştiricinin katkıda bulunduğu ve aslında birçok hammallık işini yapmak zorunda kalmamanız olarak algılanmalıdır. CSS veya başka bir dil farketmeksizin bu geçerli diyebiliriz.

Şimdi gelelim arayüz dillerindeki çatılara. Birkaç yıl öncesine kadar CSS için çok yaygın kullanılan veya birçok geliştiricinin ürettiği bir arayüz çatısı yoktu. Nedeni ise hem css3’den önceki versiyonlarda bir çatı gerektirecek genel ihtiyaçlar yoktu bir diğer nedeni de farklı çözünürlüklerdeki ekranlar bu kadar farklı varyasyonlara sahip değildi.

Bir CSS çatısına ihtiyaç duymanızı gerektirecek en büyük bir başka neden ise özellikle standartlara kabul edilmemiş css3 özelliklerinin (animasyonlar vs) hala tarayıcı spesifik on ekler istemesi olabilir. Örneğin, standartlara kabul edilmesi çok eskilere dayanmayan border-radius özelliğini kullanmak ve bütün tarayıcılarda çalışmasını sağlamak için aynı satırı -moz -webkit -o ve -ms gibi on eklerde kullanmak zorunda kalıyorduk. border-radius çok basit bir özellik ve tek parametre gerektirdiği için bunu örneklemem, bu problemin gözünüzde çok canlanmasını sağlamayabilir ama başka bir örnek olarak, bir elemanınızın arka plan rengini doğrusal geçiş (linear gradient) ile şekillendirmek isterseniz uzun bir satır yazmanız ve bunu 4-5 tekrarda css dosyanızın içine koymanız gerekecektir.

Malesef, bu özellik, standartlara geçene kadar bu şekilde kullanılmak zorunda. Yukarıdaki kodda aslında standartlara başvurulan model ilk satırdaki linear-gradient ile başlayan modelidir. Ancak daha standartlara kabul edilmediği için tarayıcılar kendi on eklerini diretmektedir. Çok basit bir geçiş için bu kodları ezberlemek veya tekrar tekrar kodlamak çok anlamsız. Aynı durum birkaç css3 özelliği için de söz konusu.

Peki bir css çatısı kullanmak bunu önleyecek mi? Eğer bir yorumlanan özel bir dil değilse hayır önlemeyecek ama muhtemelen buna benzer hazır geçişleri veya on tanımlı bazı kolay yollar sunacaktır. Eğer yorumlanan bir yapı kullanıyorsanız evet kesinlikle bu kodu çok kısaltmanın yolu var. Bunun için LESS veya SASS’i inceleyebilirsiniz.

Bir çatı kullanmadaki bir diğer fayda da on tanımlı bir çok uygulama eklentisi sunmasıdır. Yani bir web uygulamasında muhtemel olarak kullanacağınız her element için düzgün bir kozmetik hazırlık bulabilirsiniz. Size bunu bir css çatısı önererek anlatmaya çalışacağım.

Twitter bootstrap

Twitter deyince hemen bunun arayüzle ne ilgisi var diyebilirsiniz. Twitter ekibi, twitter’da kullandıkları arayüz kozmetiği ve bazı jquery eklentilerini paketleyerek açık kaynak kodlu bir çatıya dönüştürmüşler. Su an 2+ sürümüne sahip twitter bootstrap aslında bir web uygulaması için başlangıç arayüzleri oluşturmak için tasarlanmış. Yani ufak bir web uygulamanız var ise bunu twitter bootstrap kullanarak çok kolay şekilde şekillendirebilir, eklentilerini kullanarak zenginleştirebilir ve html yapınızı biraz oynayarak arayüzünüzü farklı cihazlarda ve ekran çözünürlüklerinde düzgün görüntülenebilir bir şekle getirebiliyorsunuz.

Örnegin bir RSS kaynağından aldığınız müzik dosyalarını işleyerek bir web arayüzü hazırlamak istiyorsunuz. Sunucu tarafını php ile yazdığınızı düşünürsek, php ile yazacağınız şeyleri yazdıktan sonra, sunucu tarafına ayırdığınızdan belki katlarca daha fazla zamanı arayüzü kodlamakla harcama ihtimaliniz var. Twitter bootstrap kullanarak formlarınızı, butonlarınızı, gridlerinizi, tab veya fare imlecine göre görünüp kaybolan ipuclari ile uygulamanızı zenginleştirebilirsiniz. Farklı tarayıcı uyumlulukları, farklı çözünürlükler gibi şeylere kafa yormanıza genel konular dahilinde gerek kalmıyor.

İstediğiniz özel stilleri, varolan stillere eklemeler yapacağınız gibi varolan stilleri de değiştirebiliyorsunuz. Hatta kaynak koda girip tüm yapıyı da oynama seçemediğiniz var. Ancak twitter bootstrap size sadece önceden kodlanmış bir arayüz sunuyor, yaptığınız eklentilerde veya değişikliklerde yine css3’un hammal yanını göreceksiniz.

CSS Çatıları (framework) tek seçenek mi?

Hayır, çatılar birçok işinizi kolaylaştırsa da temeldeki css dilinin getirdiği yapıyı değiştiremeyeceği için tekrar eden kodlardan kurtulamayacaksınız ayrıca matematiksel çarpanlı yani mimari arayüzler hazırlamanızda size daha önce tanımlı olduklari değerler kadar esneklik sağlayacaktır.

CSS’i dil olarak daha öteye taşıyan ve birbirine benzeyen birkaç yapıdan bir tanesini kısaca anlatarak bahsedeceğim.

Ben, kişisel olarak projelerimde LESS kullanıyorum. Less, css dökümanlarınızda iç içe tanımlamalar yapabilmenizi, fonksiyonlar tanımlayıp fonksiyonları kullanarak renk değişimleri, matematiksel işlemler yapabilmeyi ve benzer programatik şeyler yapabilmenizi sağlıyor, yabnı kısaca css’e bazı programsal özellikler ekliyor. Birkaç farklı method ile kullanılabiliyor. En yaygın kullanımı bir javascript dosyası ile css’inizi tarayıcıda derleyebiliyorsunuz. En pratik kullanımı bu. Fakat tarayıcıdaki ön bellek, geliştirme esnasında baş ağrısı yapabildiği için kodunuzu yazdığınız gibi css dosyalarına derleyerek kullanmanızı tavsiye ediyorum. LESS hakkında biraz daha detaylı yazdığım su yazıyı inceleyebilirsiniz: http://mfyz.com/less-ile-hiyerarsik-ve-fonksiyonel-css-yazmak

Benzer şeyleri yapan ve çok derinlerine inmediğim SASS’i da deneyebilirisiniz. http://sass-lang.com/

Neden sadece twitter bootstrap ve less’den bahsettim?

Çünkü twitter bootstrap kaynak kodlarında less ile yazılmış. Yani kaynak kodunu indirip less kodlarındaki kuralları değiştirerek esnek bir grid’i isteğinize göre üretebilirsiniz, renk kurallarını veya kenar boşlukları, gibi bir çok şeyi less ile çok daha kolay şekilde değiştirebilirsiniz.

İster bir çatı kullanın ister sadece LESS, SASS gibi diller kullanın, yazdığınız css’lerinizi daha hızlı üretmenizi sağlayacak çok güzel araçlar var.

Web projeleriniz için güçlü bir UI kit: Twitter Bootstrap

Sürekli yeni projeler üretiyor, çoğunlukla hızlı bir şekilde basit arayüzler hazırlıyorsanız elinizin altında bir ui library oluşturmuşsunuz veya hazır bir arayüz setini kullanıyor olabilirsiniz. İnternette onlarcasını bulabileceğiniz kitlerin hepsi farklı amaçlara hizmet eden farklı çözümler sunan kitler genelde.

Çok basit bir örnek senaryo vereceğim, php tabanlı bir proje hazırlıyorsunuz, on yüzünü yazdınız ve implemente ettiniz. Sırada bir yönetim paneli hazırlamak var yazdığını koda ve veritabanına. Bunun için çok farklı yollar izledim yıllardır, son birkaç yıldır artık oturttuğum bir html4, less/css altyapım var. Basit bir MVC ile phptal ile view’lar phptal templateleri olarak buluyor ve less’leri derleyerek sade bir arayüzde kullanıyorum herşeyi.

Ama twitter bootstrap fikirlerimi biraz değiştirmeye başladı. View’larima çok fazla dökünmadan sadece html çıktılarımı biraz oynayarak twitter bootstrap’i projelerimden birine çok pratikçe entegre etmeyi başardım ve her geçen gün isimi daha kolaylaştırdığını görüyorum.

Güzel yani twitter tarafından geliştirilen bir arayüz kiti, daha da güzel yani açık kaynak kodlu ve birçok kişinin geliştirilmesine katkıda bulunduğu bir proje. Dolayısıyla crossbrowser problemleri çok fazla yok. Hatta eğer arayüzünüzü doğru tasarlarsanız responsive bir arayüzü de çok kafa yormadan sağlayabiliyorsunuz. http://twitter.github.com/bootstrap/scaffolding.html

Neredeyse bütün arayüz elementlerini düşünmüşler. Dolayısıyla bir web uygulaması için birçok hammal is yükünü üstünüzden alıyor. http://twitter.github.com/bootstrap/components.html

Neyse, proje sayfasından örnek uygulamaları, jquery geliştirmelerini ve github deposuna ulaşacağınız linki bulabilisiniz.

http://twitter.github.com/bootstrap/

Eski IE surumlerini, HTML5 etiketlerini anlar hale getirmek

“Yil 20XX olmuş hala IE ile uğraşıyoruz” diyeceğiz herhalde yıllar sonra da. Bu süreçte ie’ye tekmeyle de olsa html5’i en azından etiketleri tanıması için en basit çözüm olarak iki şey yapmanız gerekiyor.

Birincisi IE’nin dom ağacında html5 etiketlerine ait hiçbir initialization yok. Bunu tetiklemek için kullandığınız her html5 etiketi için en az bir tane element üretmeniz yetiyor. Sonrasında IE dökümandaki tüm elementleri dom ağacınızda tanımaya başlıyor. Bunun için:

Tamam etiketler tanınır hale geldi ama daha büyük problem ise IE görsel olarak bu etiketlerle ne yapacağını bilemediği için default stillerini uyguluyor. Anlam veremeyeceğiniz marginler, değişik element türleri olarak bütün etiketler birbirine girmiş oluyor arayüzde. CSS ile tüm html5 etiketlerini blok element ayarlayıp basitçe resetlemek için:

yapabilirsiniz. Bu sayede IEnin eski sürümleri 6,7,8 (emin değilim belki 9 da) html5i bir parça olsun tanır ve insan gibi gösterir hale gelebiliyor. Ama unutmayın daha birçok sorunu düzeltmeye çalışmak uğraşmak zorunda kalabilirsiniz.

LESS ile hiyerarşik ve fonksiyonel css yazmak

LESS bir çeşit css derleyicisi ve aslında css sytax’ı üstüne ek özelliklerin eklenmiş olduğu bir araç. Çıktığı dönemden beri bütün projelerimde less dosyaları ile çalışıyorum ve son dönemdeki birkaç uygulama sayesinde çok daha kolay kullanılabilir olmasından dolayı herkese öneriyorum.

Neden LESS kullanmalısınız?

Aslında LESS kullanmak için genel ve çok önemli ihtiyaç yok bana kalırsa. Fakat artık web uygulamaları eskisi gibi basit veya küçük css dosyaları ile şekillendirilen uygulamalar olmaktan çıktılar. Güçlü css seçicileri olsa bile her (grup) element için bir sınıf tanımladığınızı düşünürseniz orta ölçekli bir stil dosyası binlerce satıra ulaşması çok normal.

Dosyanızın uzunluğundan çok iç içe tanımlı grup tanımlaları arasında kaybolmak çok kolay. Dolayısıyla css dosyanızı hiyerarşik bir şekilde organize edecek bir araca sahip olmak her zaman bir artı. Sadece bu ihtiyacınızı kullandığınız gelişitirici uygulamayı degiştirerek sağlamak da mümkün.

Örneğin çok basit bir css dosyanızda

Böyle bir CSS yapısı sık sık yazdığınız bir navigasyon kodu olabilir. Böyle bir yapı, tipik hiyerarşik modele uygun bir örnek. Böyle bir yapıyı LESS ile daha anlaşılır yazmak mümkün:

Gördüğünüz gibi herşey doğru şekilde indent edilmiş ve & gibi referanslar ile bütün css kurallarınızı hiyerarşik hale getirmeniz kolay. Böyle bir yapının sınıf isimlerinden bağımsızlaşması da işinizi kolaylaştıracaktır.

LESS’in diğer birkaç özelliği gercekten alışkanlık yapmaya yeterli. Eğer bir arayüz tasarımcısıysanız genelde matematiksel veya mimari modellere, gridlerle calışıyor olmalısınız. Aynı şeyler tipografi kuralları için de geçerli. Görsel her öğe bir şekilde birbirleriyle çok doğru orantılılar. Font boyutları, renkler vs.

Mesela font boyutunuz 16px iken satır aralığınız bunun 1.5 katı, padding’leriniz 1.5 katı belki koyduğunuz arayüz kuralına göre de kenarlıklarınız 0.2 katı olabilir veya ürettiğiniz grid arayüzünde bir grid genişliğini tanımlayıp sidebarınızı 2 kolon, ana içerik alanınızı 10 kolon olarak ayarlamış olabilirsiniz. Bunları düz CSS’de hesaplayıp tanımlamak durumundasınız.

Kuralların bu kadar net belirlenebildiği bir ortamda CSS’de statik renk kodlarına, sürekli hesaplama yaparak font boyutu, padding, margin, border radius hesaplamak zorunda kalıyor olabilirsiniz. LESS size bu matematiği LESS dosyanız içinde yapmanızı sağlıyor. Bir rengi belli bir contrast değeriyle daha açık veya daha koyu bir renge dönüştürebilir, matematiksel değerleri formülasyona sokabilir veya başka sınıfları kendi sınıfınıza dahil edebilirsiniz.

Örnek vermek gerekirse siteniz için genel bir oran ve başlangıç rakamı belirleyebilirsiniz, veya 3-4 renkten oluşan bir renk paletiniz var olabilir. Düz CSS’de her varyasyonu hesaplayarak yazmak zorunda kalabilirisiniz:

Yorumlarda kurallari yazmaya çalıştım ve normalde bir arayüz tasarımcısı böyle arayüzler geliştirirken bu tarz kurallara sahiptir, en büyük örnegini Apple arayüzlerinde görebilirsiniz. Mimari bir ürün gibidir.

Böyle kurallarla donatılmış bir arayüzün css’lerini yazarken her değeri hesaplamak zorunda kalabilirsiniz fakat LESS ile bu işlemlerin hepsini matematiksel olarak hesaplatmanız mümkün. Yukarıdaki örnek çok küçük bir örnek ama büyük bir css dosyasını düşünürseniz başa çıkılamaz bir iş haline gelebilir.
Ayrıca kuralları matematiksel yazmanın ikinci avantajı, bütün parametreleri birkaç değişken ile yönetip değiştirebilme olanağına sahip olmanızdır. Yukarıdaki örneğin LESS ile yazılmış hali:

Bu özellikleri çok kullanabilirsiniz fakat daha hiyerarşik bir yapıda ortak kullanılan parçaları gruplamak isteyebilirsiniz hatta bazı grupları parametrik olarak değiştirebilmeyi isteyebilirsiniz.

Örneğin bir kutu modeli ürettiniz, kenarları köşeli, içindeki h1 başlığını şekillendirdiniz ve bu kutu modelinin farklı boyutlarını ve renklerini üretiyorsunuz sürekli. Genel kutu modelinizde kullandığınız tipografik tanımlamaları, kenar boşluğu kurallarını tekrar tekrar yazmak istemiyorsunuz.

Ya da CSS3 kurallarının farklı tarayiıcılarla çalışması için yazmanız gereken 4 farklı kuralı farklı değerlerle sürekli tekrarlamak yerine fonksiyon şeklinde tanımlayıp LESS’e ürettirebilirsiniz.

Bunu açıklamak için CSS örnegi yazacağım son olarak.

Bu ornegin LESS ile hazirlayabileceginiz versiyonu.

Bu örnek yukarıdaki CSS’i üretecektir. Gördüğünüz gibi borderRadius tanımlarını da bir fonsiyon olarak tanımlayıp kullandım. Bunu yapmadan doğrudan kutu tanımlaması içinde de kullanabilirdim. Fakat uygulamanız içindeki tüm border radius kullanımınızı bu fonksiyon üzerinden ürettirebilirsiniz.

Son olarak, yazdığınız LESS dosyalarınızı css’e render ettirmenin bir çok yolu olduğunu unutmayın. Bunun için kullanıcının tarayıcısında javascript ile derletebilir, php veya diğer sunucu taraflı kütüphanelerle sunucunuzda derletip css’leri sunabilir veya LESS.app gibi uygulamalarla masaustünüzde yazarken eş zamanlı olarak css’lere derletip kullanabilirsiniz.

@font-face kullanmak oldukça güvenli

Bu aralar cufon, flir gibi web syfalarında kendi fontunuzu kullanabilmenizi sağlayan araçların kullanılabilirliği konusunda yeni nesil css çözümüne alternatif olarak kullanılabilirliğini test ediyordum. Aslında biraz sevindirici bir sonuç aldım. Çünkü css2 ile gelen font-face’in css3 ile tekrar gündeme gelmesinin yanı sıra aslında birçok tarayıcıda sorunsuz kullanılabildiğini gördüm.

Aşağıda @font-face attribute’u ve hangi tarayıcıların hangi sürümden beri desteklediğini görebilirsiniz.

Kaynak: http://is.gd/id6se

Aslında bu bu tercih edilebiliriği sağlayan bir etken de Microsoft’un herkesten önce bunu implemente etmiş olması. Çünkü IE cephesinin birçok yeni feature’u desteklememesinin yanı sıra XmlHttpRequest gibi birçok tarayıcıdan önce davranmış olduğu konular var. Doğal olarak bu, geliştiricilerin önünü tıkamadığı için webde örnekleri çoğaldıkça kullanımı hızlı yayılıyor. Çünkü her zaman karşımıza çıkan ie problemleri olmuyor.

Tabi bir sorunumuz var, kullanmak istediğiniz fontun her tarayıcının render edebileceği formatlarda sunuyor olmanız gerek. Bu öyle kolay bir iş değil. Zira zaten font kullanımının birçok lisans bağlantısı ve kullanımının açık olmaması gibi bir durum yaygın. Tabi ki SVG gibi formatlar bunu kırıyor fakat yine de bu crossbrowser destek verebilmenizi sağlamıyor. En azından fontunuzun, EOT, SVG, TTF ve OTF formatlarında sunuyor olmanız gerek.

Tabi ücretsiz ve non-commercial kullanımı ücretsiz olan fontları size kit olarak sunan siteler var. Aralarından en sevdiğim olan Fonts Squirrel’i kullanabilirsiniz. Hatta bu ücretsiz font-face kitlerini inceleyip indirebileceğiniz bir sayfaları da var: http://www.fontsquirrel.com/fontface

Sonuç olarak cufon, flir gibi alternatifleri kullanmayı düşünmeden önce fontunuzu bu şekilde çok formatlı sunabiliyor musunuz bunu test etmelisiniz.

CSS3 supportta bariz olan: IE’nin hala adam olamamış olması

Yeşil kolonlar her tarayıcının son sürümündeki css3 property desteği, kırmızı bölge değişmemekte ısrar eden ie’nin css3 property destek tablosu.

Yukarıdaki tabloda açıkça görülen şu ki, ie15 de çıksa adam olmayacağı.

Artık son dakika teknolojileriyle yaşayan hatta yaşam tarzı bunun üstüne yani anlık tüketim üzerine kurulu internet popülasyonunun bu tarayıcıya hala nasıl tahammül ettiğine şaşırmamak elde değil. Bunu bırakın microsoft gibi kapitalist bir şirketin bu şekilde aksiyon alamaması nasıl oluyor anlamış değilim.