bildirgec.org - ahmd - beğendikleri

HTML5'te Semantikler

ahmd — Sun, 01 Mar 2009 08:59:00 GMT

Bir öngörüde bulunacağım. Siz ve ben bu dünyadan göçtükten çok sonra bile HTML halen kullanılıyor olacak. Sırf bizim çağımızda arşivlenen milyarlarca sayfa değil, yaşayan ve nefes alan bir varlık olarak hayatını sürdürecek. Çok fazla gayret, enerji ve yatırım web'in araçlarına, protokollerine ve platformlarına harcandı.

Bizim buradaki sorumluluğumuzu düşünmeyi bir kenara bırakalım. Geçmişteki hatalar sebebiyle, uygarlığımızın yıllar boyunca birbirleri ile iletişim kurmak için kullanacakları önemli bir aracı geliştirmeye kendimizi adadık. Bu yüzden umursamadan ya da gerçekten umursayarak bu durumu kafamıza taktığımızda, HTML'yi iyileştirmek için, bugün verdiğimiz kararların sonuçlarının ne kadar ileriye dönük olacağını anlamamız gerekiyor.

W3C'nin HTML'nin yeni nesli için inanılmaz çaba harcadığı HTML 5, özellikle son bir iki yıldır dikkatleri üzerine çekmeye başladı. Bu gerçekten çok büyük bir proje ve sadece HTML'nin yapısını kavramakla kalmıyor, bunun yanısıra sözdizimsel analiz modelleri, hata işleme modelleri, DOM, kaynak alım modelleri, medya içeriği, 2B çizim, veri şablonlama, güvenlik modelleri, sayfa yükleme modelleri, istemci taraflı veri depolama ve çok daha fazlasını içeriyor.

Ayrıca Lachian Hunt'ın HTML 5 Ön İncelemesi yazısında da kavradığı gibi HTML'nin yapısında, kodunda ve semantiklerinde de değişiklikler yapılıyor.

Biz bu yazı için HTML'nin semantiklerini ele alacağız. Bu benim birkaç yıldır ilgilendiğim bir konu ve bunun HTML'nin geleceği için hayati önem taşıdığına inanıyorum.

BBC'nin geçtiğimiz günlerde yaptığı bir açıklamaya göre kurum, abbr tasarım şablonu'na yönelik olan kullanılabilirlik ve erişilebilirlik endişeleri nedeniyle, program listelerinden hCalendar mikrobiçimini kullanmayı bırakacak. Buradan çıkarmamız gereken ders, geçen zaman içerisinde HTML'nin amacından çok daha ötesine geçtiğimiz ve HTML'nin semantik olanaklarını zorladımız olmalıdır. Özetle daha zengin semantik belgeler oluşturabilmek için kullanabileceğimiz kodları tükettik. Eğer HTML'nin halihazırda bulunan yapılarını zeki bir şekilde kullanmaya devam edersek, daha fazla problem gün yüzüne çıkacaktır. Ancak HTML ne yazık ki semantik bir kodlama dili olmaktan çok uzaktadır, semantikleri sabittir ve geliştirilebilir değildir.

Bu sadece basit bir teori problemi değildir. Yüzbinlerce geliştirici class ve id HTML değerlerini daha zengin semantik kod yazmak için kullanmaktadırlar (ayrıca yine aynı geliştiriciler bunları CSS stilleme için birer "çengel" olarak kullanmaktadırlar ancak bu başka bir konu). Neredeyse hiç değişmeden bu geliştiriciler ad hoc (belirli bir amaç için düzenlenmiş, kendi oluşturdukları) sözlükleri kullanmaktadırlar. Kullanılan değerler, halihazırda kullanılan şemalardan alınmaktansa kendileri tarafından geliştirilmiştir. Bu en iyi ihtimalle sahte semantik kodlama olarak isimlendirilebilir.

Web üzerinde kullanılan pek çok sayfa, HTML'nin fakirleşmiş elementlerini ve değerlerini, daha iyi bir yapıya sahip semantikleri belgelerine eklemek için mikrobiçimler kullanmaktadırlar. Bu durumda, class özniteliği için kullanılan değerler kabul görmüş sözlüklerden gelmektedir, bazen ise bu değerler vCard gibi standartlardan esinlenirken, bazen de hReview gibi herhangi oturmuş ve kabul görmüş bir standardı bulunmayan, sadece belirli bir amaca hizmet eden kaynaklardan esinlenmiştir.

Geliştirilebilir Semantikler

Burada çözülmesi gereken çok gerçek bir problem bulunmaktadır. Geliştiricilerin belgelerine daha zengin ve anlamlı semantikler ekleyebilecekleri HTML mekanizmalarına ihtiyacımız bulunmaktadır, sahte semantiklere değil. HTML 5'in üzerine en büyük baskıyı oluşturan konunun bu olduğunu söylemek yalan olmaz.

Ancak bu HTML içeriğinde daha zengin semantik oluşturmak için bir mekanizma geliştirmek kadar kolay bir iş değildir, uygulanabilecek her bir çözümün bazı olumsuz tarafları bulunmaktadır. Belki de bunlardan en önemlisi geriye dönük uyumluluktur. Sunulacak çözüm, günümüzde kullanılan yüz milyonlarca aygıtı kullanılamayacak hale getirmemelidir ki bu aygıtlar, önümüzdeki yıllarda da kullanılmaya devam edecektir. Geriye dönük uyumluluğu olmayan hiçbir çözüm, geliştiriciler tarafından okurlarını kaybetmek korkusuyla geniş bir şekilde kabul görmeyecektir, aksine kısa bir süre içerisinde yok olacaktır.

Sunulacak olan çözüm ayrıca ileriye dönük olmalıdır. Burada gelecek yıllarda piyasaya sürülecek aygıtlarla uyumlu olması gerektiğinden bahsetmiyorum, bu tarayıcı geliştiricilerinin sorunudur. Burada anlatmak istediğim şey, sonucun geliştirilebilir olmasıdır. Günümüzde geliştireceğimiz herhangi bir çözümün varolan ve olası tüm sorunları çözmesini beklememiz doğru olmaz. Geliştirilebilir ve geleceğin ihtiyaçlarına yardımcı olacak bir çözüm sunabiliriz.

Bu iki kısıtlama birbirini takip etmektedir ve büyük bir zorluk oluşturmaktadır. Ancak konu iki durum arasında on yıl bulunan bir kodlama dili olduğunda ve bu kodun önemi iletişim için bir global platform çatısı altında birleşmişse, karşı karşıya olduğumuz bu zorluğun aşılması gerekmektedir.

Peki HTML 5 bu sorunu nasıl ele alıyor? HTML 5 üzerinde bir dizi yeni element bulunuyor. Bunlardan bazıları benim "yapısal" olarak adlandırdığım section, nav, aside, header ve footer elementleridir. dialog elementi bir tür içerik (content) elementidir ve blockquote'ye benzemektedir. Bunun yanısıra bazı veri elementleri de bulunmaktadır. Örneğin meter (metre) elementi "bilinen bir aralık içerisinde sayısal bir ölçümü ya da kısmi bir değeri temsil eder; örneğin disk kullanımı gibi" ve time" elementi bir tarihi ya da zamanı temsil eder.

Her ne kadar bu elementler kullanışlı olabilirken ve şimdilik ilgileri üzerine çekmişken, yukarıda bahsettiğimiz, özellikle geriye dönük ve ileriye yönelik problemleri çözebilecek kapasitede midir?

Gelin her bir kısıtlamayı ele alalım.

Geriye Dönük Uyumluluk

Peki section gibi bu yeni elementleri halihazırda kullandığımız tarayıcılar nasıl ele alıyorlar? Aslında Safari, Opera, Mozilla ve hatta IE7 bile aşağıdaki şekilde kodlanmış bir sayfayı işleyeceklerdir.

<h1>Üst seviye Başlık</h1>
<section>
<h1>İkinci seviye başlık</h1>
<p>Bu section elementi içerisinde bir metin.</p>
<section>
<h1>Üçüncü seviye başlık</h1>
</section>
</section>

Mükemmel bir başlangıç gibi görünüyor. Ancak CSS ile örneğin section elementini aşağıdaki şekilde stillemeye kalktığımızda:

section: {color: red}

...yukarıda bahsettiğimiz tarayıcıların pek çoğu stillemeyi doğru bir şekilde yapacaktır, ancak IE7 (ve muhtemelen IE6) bunu doğru şekilde uygulamayacaktır.

O zaman burada ciddi bir geriye dönük uyumluluk sorunu ile karşı karşıyayız. Günümüzde kullanılan tarayıcıların ortalama %75'i Internet Explorer sürümlerini oluşturuyor. Internet Explorer'ın yarı ömrünü göz önüne aldığımızda, önümüzdeki birkaç yıl boyunca bile kullanıcıların pek çoğunun IE6 ve IE7 kullanacağını öngörebiliriz.

Eğer HTML 5 bu yeni elementlerle gelirse, geliştiricilerin bu elementleri sitelerine entegre etmelerindeki olasılık nedir? Özellikle ziyaretçilerinin %75'inin bu kodlarla işlenmiş siteleri düzgün bir şekilde göremeyeceklerini göz önüne aldığımızda geliştiricilerin bu kodları kullanmalarındaki olasılık iyice düşmektedir.

Ne yazık ki class özniteliğini section elementleriniz üzerinde kullanarak bu sorunu gidermeyi düşünüyorsanız, bu yöntem de IE üzerinde çalışmayacaktır. Burada belki de bu sorunu çözebilecek bir yöntem geliştirilebilir ancak geliştirilmedikçe bu durum önemli bir sorun teşkil etmeye devam edecektir.

Gelin ikinci kısıtlamamız olan ileriye yönelik uyumluluk durumunu ele alalım.

İleriye Yönelik Uyumluluk
Burada bir soru ile başlayacağız: "bu yeni elementleri neden icat ediyoruz?" Bu soruya verilebilecek cevap "HTML'nin semantik zenginlikten yoksun olduğu ve bu yeni elementleri ekleyerek HTML'nin semantik zenginliğini arttırmış oluruz - bu da kötü bir şey değil, değil mi?" olacaktır.

Bu elementleri ekleyerek, HTML'nin daha iyi semantik yeteneklere sahip olmasına yönelik bir sorunu ele alıyoruz, ancak daha dar bir alan içerisinde. Ne kadar yeni elemente sırtımızı dayarsak dayayalım, HTML'ye ekleyeceğimiz daha iyi semantikleri göz önünde bulundurmaya devam edeceğiz. Bunun sonucunda da ne kadar yeni element kullanırsak kullanalım, halen sorunu çözmemiş olacağız. HTML sözlüğüne özgün terimler eklememiz gerekmiyor. Burada gereken şey, belgelere, gerektiğinde semantik zenginlik katabilecek bir mekanizma eklememiz gerekiyor. Teknik açıdan bu, HTML'yi geliştirilebilir yapmamız gerektiği anlamına geliyor. HTML 5, geliştirilebilirlik için hiçbir mekanizma sunmamaktadır.

HTML 5 bunun yerine geçerli tarayıcıların büyük bir çoğunluğunu gözden çıkaran bir özellik getiriyor ve ilgili dile hiçbir şekilde yeni semantik zenginlik katabilmemizi sağlamıyor.

Bu yeni elementlere yönelik birkaç soru halen geçerliliğini koruyor. Bu yeni elementlerin adları nereden geliyor? Yeni bir navigasyon elementi olması gerektiğine ve bunun adının "nav" olması gerektiğine nasıl karar verildi? Neden aynı terim sayfa genelinde, site genelinde ve siteler genelinde kullanılmakta?

Neden Docbook gibi halihazırda kullanılan bir sözlük kullanılmasın? Docbook, bir belge yapı sözlüğü olup HTML 5'ten çok daha zengin ve yayımlama uzmanları tarafından yıllardır kullanılıyor. Aslında bu Docbook yanlısı bir tartışma değil. Burada belirtmek istediğim şey, HTML'ye semantik zenginlik kazandırmak proje bazında bireysel çabalarla gerçekleştiriliyor ve 30 yıldan daha uzun zaman önce temelleri atılan açılımlardan en ufak bir miktarda bile esinlenilmiyor (GML üzerindeki ilk çalışmalar 1970lere dayanıyor).

Çözüme Yönelik Düşünceler
Günümüzde bu sorunları gidermeye yönelik çabalara dair eleştirilerimizi sıraladıktan sonra, bu problemi çözmek için bir önerim var mı? En azından bir tane olmalı.

Eğer HTML'ye yeni elementler eklemek olanaklar dahilinde olmasaydı, ya da en azından bu tartışma dahilinde olmasaydı, HTML'nin üzerine konsantre olabileceği bir diğer mantıksal alan öznitelikler olacaktır. Hepsi bir yana neredeyse 10 yıla yakın bir süredir, HTML'nin semantiklerini geliştirmek için class ve id özniteliklerini kullanıyoruz. Bu yüzden eğer bu problemi çözmek için öznitelikleri kullanacaksak, yeni öznitelikler geliştirmemiz gerekiyor. Bunun nasıl çalışacağını anlatmaya geçmeden önce, HTML 5'in yeni elementleri için gereksinimlerimizin bu öznitelikler için de geçerli olduğunu söylemek yerinde olur. En önemlisi, HTML'ye yeni öznitelikler eklemek geriye dönük uyumlu olacak mıdır? Eğer olacaksa HTML'de semantik geliştirilebilirlik için çalışır bir mekanizma sunacak mıdır?

Gelin yeni bir öznitelik icat edelim. Bunu ben "yapi" olarak isimlendireceğim ancak burada kullanacağımız ismin önemi yoktur. Bunu şu şekilde kullanabiliriz.

<div yapi="header">

Bunu tarayıcılarımızın nasıl algılayacağına bir bakalım.

Elbette bütün tarayıcılarımız bu elementi CSS kullanarak stillendirecektir.

div {color: red}

Peki buna ne dersiniz?

div[yapi] {font-weight: bold}

Aslında neredeyse tüm tarayıcılar, IE7 de dahil, yapi özniteliğine sahip div elementini doğru şekilde stilleyecektir, hatta yapi özniteliği olmasa bile ilgili stilleme kullanılabilecektir. Ne yazık ki IE6 bu alanda başarısız olacaktır. Ama yine de biz bu özniteliği HTML'de kullanabilir ve en azından tüm tarayıcıları onu tanıyabilmesini sağlayabiliriz. Hatta HTML'mizi stillemek için tüm modern tarayıcılar tarafından desteklenen CSS kullanabiliriz. Eğer eski tarayıcılar için de bir hile kullanmamız gerekiyorsa, stilleme için ilgili elemente class özniteliği için bir değer atayabiliriz. Bunu şu an üzerinde çalışılan HTML 5 çözümü ile kıyaslayın. Daha önce de söylediğim gibi HTML 5 üzerindeki çalışmalar, yeni elementler eklenmesi yönünde ilerliyor ancak bu elementler Internet Explorer 6 ya da 7'de stillenemeyecektir. Bu sebeple benim önerimin çok daha geriye dönük uyumlu olduğunu göreceksiniz.

Öznitelikler Üzerinden Geliştirilebilirlik

Yeni elementlerin yerine HTML 5 bir dizi yeni öznitelik içermelidir. Bu özniteliklerin her biri bir semantik kategorisine ya da türüne referans içerecektir. Örneğin HTML, yapısal semantikler, sözbilimsel semantikler, rol semantikleri (XHTML'den alınmıştır) ve diğer semantik kategorilerini ve sınıflarını içermektedir.

Bu yeni öznitelikler daha sonra tıpkı class özniteliğinin kullanıldığı gibi kullanılabilirler. Elementin doğasını tanımlamak için element semantiğine eklenebilir ya da element hakkında metaverisi dahil etmek için kullanılabilir.

Bu XHTML'nin role özniteliğinden farklı değildir, ancak tüm element semantikleri için tek bir öznitelik "sepeti" kullanmaktansa bir element için farklı semantik tiplerini tanımlayabilmemiz ve ardından onları ayırabilmemiz gerekir.

Örneğin, XHTML role özniteliği aşağıdaki şekilde çalışır:

<ul role="navigasyon siteharitasi">
<li href="indirmeler">Downloads</li>
<li href="belgeler">Belgeler</li>
<li href="haberler">Haberler</li>
</ul>

role özniteliğinin değerleri öntanımlı sözlükten ya da özel olarak oluşturulacak bir başka sözlükten alınmış ve boşluklarla ayrılmış kelimelerden oluşur.

Neden role özniteliğini olduğu gibi kullanmıyoruz? Çünkü role teriminin uygun düşmeyeceği başka semantik tipleri de bulunmaktadır. Örneğin:

<p hitabet="ironi">Mükemmel bir kişidir.</p>
"hitabet, semantiklerin teorik tipini güzel bir şekilde örneklemektedir ve bu yöntemle bir belgenin sözbilimsel kısmı kodlanabilir hale gelecektir. Bu elementin "ironi" rolünü oynayamayacağı apacak ortada. Bunun yerine elementin içeriği ironiktir.

Diğer bir örnek daha. HTML'nin insan tarafından okunabilir bir değerin makine tarafından okunabilir biçimini oluşturmak konusunda zayıf kaldığı apaçık ortada. Bu daha önce bahsettiğimiz ve BBC'nin hCalendar mikrobiçimi ile olan probleminin kökeninde yatan durumdur. <span role="2009-05-01">Önümüzdeki yıl İşçi Bayramı>/span<" bir anlam ifade etmezken <span equivalent="2009-05-01">Önümüzdeki yıl İşçi Bayramı>/span< daha anlamlı olacaktır.

Yine burada da "equivelant" ya da bir benzeri terim kullanmak bir sorun teşkil etmeyecektir. Burada dikkat çekilmesi önemli olan şey, class özniteliğinde ya da role özniteliğinde olduğu gibi kullanmasının ve adaptasyonunun kolay olmadığıdır. Düzgün bir şekilde geliştirilebilir, geriye dönük uyumlu ve gerçek anlamda esneklik sunan bir çözüm için yukarıda anlattıklarımın incelenmesi gerekir.

Bu bölümü "Çözüme Yönelik Düşünceler" olarak isimlendirdim çünkü gerçekten çalışır bir çözüm üretmek için çok büyük bir miktarda çalışma ve hazırlık gerekiyor. Cevabı açık soruları aşağıda listeledim.

Kaç tane özgün semantik öznitelik bulunmalı? Bu kategoriler geliştirilebilir olmalı mı? Evetse nasıl?
Sözlükler nasıl belirleniyor?
Geliştiricilerin class değerlerini diledikleri gibi şekillendirebildikleri gibi dilediğimiz terimleri kendimiz seçebilecek miyiz? Yoksa kullanılabilecek terimler önceden mi belirlenecek? Ya da bir tür profil kullanarak kullanılabilecek değerleri geliştirmek (ve mümkünse de paylaşmak) için bir mekanizma mı oluşturulacak?
İki sözlük arasında çıkmazda kalırsak, örneğin iki farklı sözlük arasında birbirine benzer terimler gibi, bu durum nasıl çözülecek?
İsim aralıklandırma için bir tür forma ihtiyacımız var mı ya da buna yönelik bir mekanizma halihazırda mevcut mu?

Bu soruları cevaplandırmak için acele etmektense, üzerlerine düşünmek ve hep beraber tartışmak için soruları yanıtsız bırakıyorum. HTML 5'in sonuçları ve kararların veriliş süreci çok çetrefilli olduğundan bunlara yönelik son kararı verecek olan kişilerin dil bilimi, semantikler, semiotikler ve benzer alanlarda uzman olan kişiler olması gerektiğini düşünüyorum.

Umarım "yeni elementler oluşturmanın", HTML'nin semantik kapasitesini yükseltmeye yönelik sorunun çözümü olmadığını anlatabilmişimdir.

Gelin bu kararları çabucak vermeyelim. Zaten torunlarımıza iklim değişikliği gibi büyük bir sorunla mücadele etmek zorunda bırakacak bir hata yaptık. gelin en azından onlara bırakabileceğimiz en iyi HTML'yi bırakalım.

İllüstrasyon: Kevin Cornell
Kaynak: A List Apart

Bu yazı ahmd tarafından bildirgec.org adresli sitede yayımlanmak üzere yazılmıştır. Kaynak gösterilmeksizin kopyalanamaz.

Pilli Projeleri: Pilli.com: Kolektif Bağımsız İçerik | Sosyomat.com: Arkadaşını Etiketle | Put.io: Online Cloud Storage

jQuery Sağ Tıklama ve Dosya Ağacı Çalışmaları

ahmd — Tue, 23 Dec 2008 18:18:00 GMT

Web sitelerimizde kimi zaman sağ tıklama tuşundan gelen seçenekleri düzenlemek, bir biçim vermek isteyebiliriz. Bunun için yapılmış çok hoş bir jQuery Ajax çalışması mevcut.

Context Menu - Right Click (Sağ Tıklama Menüsü)

Bu menüde cut (kes) ve copy (kopyala) seçeneklerini kapatmak isterseniz (disable) bu da düşünülmüş.

Kopyala ve Kes Kapalı

jQuery Ajax ile çalışılmış bir diğer uygulama ise Dosya Tarayıcı Ağaçları (File Browser Tree). Yine çeşitli düzenlemeler, ayarlamalar yapmak mümkün.

Ayarlanabilir Dosya Tarayıcı Ağacı

Dosyaların açılmasında, kapanmasında ve yükleme aşamasında çok esnek bir tasarım ile dikkat çeken uygulamada dosyaların açılmasında "çift tıklama" seçeneği bile koyabiliyorsunuz.

Bu yazı ahmd tarafından bildirgec.org adresli sitede yayımlanmak üzere yazılmıştır. Kaynak gösterilmeksizin kopyalanamaz.

Pilli Projeleri: Pilli.com: Kolektif Bağımsız İçerik | Sosyomat.com: Arkadaşını Etiketle | Put.io: Online Cloud Storage

Css İle Sınır Tanımayın

ahmd — Sat, 21 Jun 2008 07:44:00 GMT

her gün harika ve eşsiz css tekniklerinizi paylaşıyoruz ve akla gelicek her şeyi css ile halledebiliyoruz.

Listeler
İnanılmaz li: biraz css kodu ile li tagınını harika şekillerde kullanabilirsiniz.

Daha Güzel Listeler: kendi özgün listelerinizi oluşturabilirsiniz.

sıralı listeler
numaralandırılmış, p ve ol kullanılan listeler.

demo

Takvim
takvim yapmak için güzel bir yol.

Formlar
Form-1

E-Bay Üyelik Formu Benzeri Form
Adı üzerinde E-Bay'in üyelik sayfasına benzeyen formlar yapabilirsiniz.

UniForm

Footer
footer-1
1-2 dakika içinde css ile güzel footerlar oluşturabilirsiniz.

footera Türkçe olarak ne diyebilirim?

footer-2
resimde ki gibi footerlar yapmak için...

Css Resim Teknikleri
Yeniden Boyutlanabilir Resimler
Resmin üzerine gelince resmin boyutu büyüyor.

Damga Benzeri Çerçeve
css ile resimlerinize güzel bir çerçeve efeckti.

Menüler
Dairesel Menü

Vista Menü

İmaj Galerileri
Css İmaj Galerisi

Bazıları bunlardı tümüne ulaşmak için burayı kullanın.

30 olağanüstü css örneği
53 css tekniği
101 css tekniği

Bu yazı ahmd tarafından bildirgec.org adresli sitede yayımlanmak üzere yazılmıştır. Kaynak gösterilmeksizin kopyalanamaz.

Pilli Projeleri: Pilli.com: Kolektif Bağımsız İçerik | Sosyomat.com: Arkadaşını Etiketle | Put.io: Online Cloud Storage

Onlarsız Yapamadığımız 53 CSS Tekniği

ahmd — Mon, 09 Jun 2008 20:55:00 GMT

53 CSS Tekniği

CSS çok önemli ve gün geçtikçe kullanımı artmakta. Cascading Style Sheets bizlere tablodan bağımsız tasarımlar ve kodlamaların yazı sıra kendine has seçici ve belirleyici , arayüz efektleriyle XHTML diline yeni başlayan arkadaşların çoğunun henüz tanışmadığı fakat bu işle biraz uğraşmış bir çok webtasarımcı arkadaşın kullanmadan yapamadığı bir çok tekniği içerisinde saklamaktadır.

Geçen bir kaç yıl içinde CSS üzerine bir çok makale yazıldı çoğu HTML dilinin tablolardan ayıklanmması ya da tablosuz tasarımda büyük bir websisteminin tasarımının tek bir dosya ile nasıl saniyler içerisinde değiştirilebileceğini anlatan makalelerdi .

bütün bunların yanı sıra CSS'e derinlemesine değinen tasarımcı arkadaşlar da var elbet fakat benim için en önemlisi web programcılarının CSS'e nasıl baktıkları ve ne yönde kullandıklarıdır, biliyorum ki onlar css'in tasarım yönüyle değil kendilerine yani webprojelerine neler getirebildikleriyle ilgilenecektir işte bu notada biraz yabancı kaynakları araştırmak hepimizin önünü açacaktır, webprogramcılarının rahat durmayıp CSS'i de bir php , asp, yada Javascript gibi kullanmaya çalışmaları kaçınılmaz oldu. :)

Sonunda CSS'i yakın geçmişte de olsa programlama adına kullanmak için bir çok teknik geliştirdiler . işte vazgeçemeyeceğimiz 53 temel CSS tekniği .
1- CSS tabanlı Navigasyon

css Navigasyon tekniği

2 - Css ile Matrix Loader Navigasyon

css Matrix Navigasyon tekniği

3 - CSS Tab Menu Tekniği

css tab Menu tekniği

4 - CSS Bar Grafikler

css Bar grafikler

5 - Adam'ın CheckBox ve Rodyo Butonu Tekniği

Adam'ın Checkbox ve radio buton tekniği

6 - CSS ile production Notları yaratmak

css production notes

daha fazla kalabalık yapmamak adına ben sadece bir kaçını yazıma ekledim, diğer 47 Css tekniğini kaynağından incelemek için tıklayın

Bu yazı ahmd tarafından bildirgec.org adresli sitede yayımlanmak üzere yazılmıştır. Kaynak gösterilmeksizin kopyalanamaz.

Pilli Projeleri: Pilli.com: Kolektif Bağımsız İçerik | Sosyomat.com: Arkadaşını Etiketle | Put.io: Online Cloud Storage