CSS Patlamasını Yönetme


682

Üzerinde çalıştığım bir web sitesi için CSS'ye çok güveniyorum. Şu anda, tüm CSS stilleri etiket başına uygulanıyor ve bu yüzden şimdi gelecekteki değişikliklere yardımcı olmak için daha fazla harici stile taşımaya çalışıyorum.

Ama şimdi sorun "CSS Patlaması" aldığımı fark ettim. CSS dosyasındaki verilerin en iyi nasıl organize edileceğine ve özetleneceğine karar vermek benim için zorlaşıyor.

divYoğun bir tablo tabanlı web sitesinden hareket ederek, web sitesinde çok sayıda etiket kullanıyorum . Bu yüzden şöyle görünen bir sürü CSS seçicisi alıyorum:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

Henüz çok kötü değil, ama ben yeni başlayan biri olarak, bir CSS dosyasının çeşitli bölümlerini en iyi nasıl organize edeceğiniz konusunda önerilerde bulunup bulunamayacağını merak ediyordum. Web sitemdeki her öğe için ayrı bir CSS özelliğine sahip olmak istemiyorum ve her zaman CSS dosyasının oldukça sezgisel ve okunması kolay olmasını istiyorum.

Nihai hedefim, CSS dosyalarının kullanımını kolaylaştırmak ve web geliştirme hızını artırmak için güçlerini göstermektir. Bu şekilde, gelecekte bu sitede çalışabilecek diğer bireyler de benim yaptığım gibi almak yerine iyi kodlama uygulamaları kullanma pratiğine gireceklerdir.


122
Bu harika bir soru ama birçok şirket için gerçekten çözülemeyen bir problem. Ağırlıklı olarak CSS terimlerin farkında olmayabilir grafik tasarımcıları tarafından kaleme ve yönetilen ediliyor çünkü simplicity, complexity, maintenance, structureve refactoring.
cherouvim

8
@cherouvim - Bu soruyu sormamın tüm sebebi, bir grafik sanatçısı tarafından tasarlanan bazı korkunç CSS'leri görmeye başladığı için söylemelisiniz. Belki onlar için daha iyi bir eğitime ihtiyacımız var?
JasCav

13
Benim çözümüm (ideal bir dünyada) ekibinizdeki insanları PSD'yi html + css olarak kesip daha sonra bakımını sağlamaktır. Bu insanlar programcılara ve tasarımcılara yakın olmalıdır.
cherouvim

@cherouvim Kabul etmek zorundasınız - özellikle CSS daha karmaşık hale geldikçe, ajansların gittiği yol budur.
John Parker

27
@JasCav, Grafik sanatçıları CSS'ye dokunmamalıdır. Web Tasarımcıları ve ön uç Web Geliştiricileri CSS ile ilgilenmelidir. Grafik Tasarımcının işi grafikleri yapmaktır.
zzzzBov

Yanıtlar:


566

Bu çok iyi bir soru. Baktığım her yerde, CSS dosyaları bir süre sonra kontrolden çıkma eğilimi gösteriyor - özellikle sadece bir ekipte çalışırken.

Kendime uymaya çalıştığım kurallar şunlardır (her zaman başarabildiğimden değil).

  • Refactor erken, sık refactor. Sık sık CSS dosyalarını temizleyin, aynı sınıfın birden fazla tanımını birleştirin. Eski tanımları derhal kaldırın .

  • Hataları düzeltmek için CSS eklerken, değişikliğin ne yaptığına dair bir yorum bırakın ("Bu, kutunun IE <7'de hizalı kalmasını sağlamak içindir)"

  • Fazlalıklardan kaçının, örn. .classnameVe içindeki aynı şeyi tanımlayın .classname:hover.

  • /** Head **/Net bir yapı oluşturmak için yorumları kullanın .

  • Sabit bir stilin korunmasına yardımcı olan daha güzel bir araç kullanın. Ben çok mutlu olduğum Polystyle kullanın (15 $ maliyeti ama iyi harcanan para). Etrafta ücretsiz olanlar da var (örneğin , açık kaynaklı bir araç olan CSS Tidy'e dayanan Code Beautifier ).

  • Hassas sınıflar oluşturun. Bununla ilgili birkaç not için aşağıya bakın.

  • Anlambilim kullanın, DIV çorbasından kaçının - <ul>örneğin menüler için s kullanın .

  • Her şeyi olabildiğince düşük bir seviyede tanımlayın (örneğin, varsayılan yazı tipi ailesi, içindeki renk ve boyut body) ve inheritmümkün olduğunca kullanın

  • Çok karmaşık bir CSS'niz varsa, belki bir CSS ön derleyicisi yardımcı olabilir. Yakında aynı nedenden dolayı xCSS'ye bakmayı planlıyorum . Etrafta birkaç tane daha var.

  • Bir ekipte çalışıyorsanız, CSS dosyaları için kalite ve standartların gerekliliğini de vurgulayın. Herkes programlama dillerinde kodlama standartlarında büyüktür, ancak bunun CSS için de gerekli olduğuna dair çok az farkındalık vardır.

  • Takım çalışması ise do Sürüm Kontrolü kullanmayı düşünün. İzlemeyi çok daha kolay hale getirir ve çözülmesi çok daha kolay olan anlaşmazlıkları düzenler. HTML ve CSS'de "sadece" olsanız bile buna gerçekten değer.

  • İle çalışma !important. Sadece IE = <7 ile başa çıkamadığından değil. Karmaşık bir yapıda, !importantkaynağı genellikle bulunamayan bir davranışı değiştirmek için caziptir, ancak uzun süreli bakım için zehirlidir .

Mantıklı sınıflar oluşturma

Duyarlı sınıflar inşa etmeyi böyle seviyorum.

Önce global ayarları uyguluyorum:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Sonra, sayfa düzeninin ana bölümlerini tanımlarım; örneğin üst alan, menü, içerik ve altbilgi. İyi biçimlendirme yazsaydım, bu alanlar HTML yapısıyla aynı olur.

Sonra, CSS sınıfları oluşturmaya, mümkün olduğu kadar çok soy atayarak ve ilgili sınıfları mümkün olduğunca gruplandırmaya başlıyorum.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Tüm CSS yapısını , gittikçe daha fazla tanımlandığınız köklerden daha uzakta olan bir ağaç olarak düşünün . Sınıf sayısını mümkün olduğu kadar düşük tutmak istiyorsunuz ve kendinizi mümkün olduğunca nadir tekrarlamak istiyorsunuz.

Örneğin, üç düzey gezinme menünüz olduğunu varsayalım. Bu üç menü farklı görünüyor, ancak belirli özellikleri de paylaşıyorlar. Örneğin, hepsi <ul>aynı yazı tipi boyutuna sahiptir ve öğelerin tümü yan yanadır (varsayılan a görüntüsünün aksine ul). Ayrıca, menülerin hiçbirinde madde işareti ( list-style-type) yoktur.

İlk olarak, bir sınıftaki ortak özellikleri tanımlayın menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

ardından üç menünün her birinin belirli özelliklerini tanımlayın. Seviye 1 40 piksel yüksekliğinde; düzey 2 ve 3, 20 piksel.

Not: bunun için birden fazla sınıf da kullanabilirsiniz, ancak Internet Explorer 6'nın birden çok sınıfla ilgili sorunları vardır , bu nedenle bu örnekte ids kullanılmıştır.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

Menü işaretlemesi şu şekilde görünecektir:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Sayfada anlamsal olarak benzer öğeleriniz varsa - bu üç menü gibi - önce ortak yönleri çözmeye çalışın ve bunları bir sınıfa yerleştirin; ardından belirli özellikleri çalışın ve sınıflara uygulayın veya Internet Explorer 6'yı desteklemeniz gerekiyorsa kimlikler.

Çeşitli HTML ipuçları

Bu semantikleri HTML çıktınıza eklerseniz, tasarımcılar daha sonra web sitelerinin ve / veya uygulamaların görünümünü saf CSS kullanarak özelleştirebilir, bu da büyük bir avantaj ve zaman tasarrufu sağlar.

  • Mümkünse, her sayfanın gövdesine benzersiz bir sınıf verin: <body class='contactpage'>bu, stil sayfasına sayfaya özgü ince ayarlar eklemeyi çok kolaylaştırır:

    body.contactpage div.container ul.mainmenu li { color: green }
  • Menüleri otomatik olarak oluştururken, daha sonra kapsamlı şekillendirmeye izin vermek için mümkün olduğunca fazla CSS içeriği ekleyin. Örneğin:

    <ul class="mainmenu">
     <li class="item_first item_active item_1"> First item </li> 
     <li class="item_2"> Second item </li> 
     <li class="item_3"> Third item </li> 
     <li class="item_last item_4"> Fourth item </li> 
    </ul>
    

    Bu şekilde, her menü öğesine stil için anlamsal bağlamına göre erişilebilir: Listedeki ilk veya son öğe olsun; Şu anda etkin olan öğe olup olmadığı; ve sayı ile.

Not Örnek l'de belirtilen çok sayıda sınıfların atama bu Yukarıdaki IE6 düzgün çalışmıyorsa . IE6'nın birden fazla sınıfla başa çıkabilmesi için bir geçici çözüm vardır . Geçici çözüm bir seçenek değilse, sizin için en önemli sınıfı (öğe numarası, etkin veya ilk / son) ayarlamanız veya kimlikler kullanmaya başvurmanız gerekir.


3
@Andrew esas olarak dinamik bir ortamda (CMS gibi) bir kimlik kullanarak kolayca çarpışmalara yol açabilir (örneğin, bir sayfayı "kişi" olarak yeniden adlandıran bir kullanıcı, bu adın gövde kimliği olarak kullanılmasına ve iletişim formuyla çarpışmasına neden olabilir "kişi" olarak da adlandırılır). Bu nedenle genellikle kimliklerin mümkün olduğunca az kullanılmasını öneririm.
Pekka

4
@Pekka, www.oocss.org adresine burada bahsettiklerinize karşı bir sürü şey kontrol etmelisiniz, ancak CSS şişkinliğini yönetmenin en iyi yolu. Aşağıdaki cevabımı da görün: stackoverflow.com/questions/2253110/how-to-manage-css-explosion/…
Moin Zaman

2
@Sam teşekkürler! Bu yönergeleri kendimi takip etmek çok zor olsa da oldukça hoşuma gidiyor . CSS stil sayfaları zaman içinde berbat etmek çok kolay - burada bir renk değişimi, font-weight: boldorada .... disiplin tek ilaçtır :)
Pekka

1
Css patlaması çalışmasında yeni biri olarak konuşan "benzersiz sınıf" ifadesi kafa karıştırıcıdır. Bunun bir şey olmadığı hissine kapılıyorum idama kesinlikle bir tane gibi geliyor. Belki kavram açıklığa kavuşturulabilirdi?
ari gold

2
@ari, teknik olarak bir de olabilir haklısın id.
Pekka

89

İşte sadece 4 örnek:

Tüm 4 cevabımda Natalie Downe'nin PDF CSS Sistemlerini indirmek ve okumak için tavsiyeler yer aldı . (PDF, slaytlarda olmayan tonlarca not içerir, bu yüzden PDF'yi okuyun!). Organizasyon için önerilerini not edin.

EDIT (2014/02/05) dört yıl sonra şunu söyleyebilirim:

  • Bir CSS ön işlemcisi kullanın ve dosyalarınızı kısmi olarak yönetin (şahsen Compass ile Sass'ı tercih ediyorum, ancak Az da oldukça iyi ve diğerleri var)
  • OOCSS , SMACSS ve BEM veya getbem gibi kavramları okuyun .
  • Bootstrap ve Zurb Foundation gibi popüler CSS çerçevelerinin nasıl yapılandırıldığına bir göz atın . Ve daha az popüler çerçeveleri indirim yapmayın - Inuit ilginç bir çerçeve ama çok daha fazlası var.
  • Sürekli bir entegrasyon sunucusunda ve / veya Grunt veya Gulp gibi bir görev çalıştırıcısında bir oluşturma adımı ile dosyalarınızı birleştirin / küçültün.

CSS ön işlemcileri, sorunun çözümü yerine sorunun nedenidir. Basamaklı konseptte gerçekten ustalaştığınızda şişkinliği azaltırsınız.
Daniel Sokolowski

@DanielSokolowski uygun olmayan bir şekilde kullanılan herhangi bir araç bir çözümden ziyade bir sorun olabilir. Ancak% 100, çağlayana hakim olma konusunda hemfikir.
Andy Ford

73

CSS'de başlık yazma

Sadece bölümleri dosyalara ayırın. Herhangi bir CSS yorumu, sadece bu olmalı, yorumlar.

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

Bunları birleştirmek için bir komut dosyası kullanın; Eğer gerekliyse. Hatta güzel bir dizin yapısına sahip olabilir ve betiğinizin .cssdosyaları tekrar tekrar taramasını sağlayabilirsiniz .

Başlık yazmanız gerekiyorsa, dosyanın başında bir İçindekiler oluşturun

İçindekiler'deki başlıklar daha sonra yazacağınız başlıklara tam olarak eşit olmalıdır. Başlık aramak acı verici. Soruna eklemek için, ilk başlığınızdan sonra başka bir başlığınızın olduğunu tam olarak nasıl bilebilirsiniz? ps. İçindekiler yazarken her satırın başına doc benzeri * (yıldız) eklemeyin, metni seçmeniz daha can sıkıcı olur.

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

Blok dışında veya kuralların içinde veya dışında yorum yazın

Öncelikle, komut dosyasını düzenlediğinizde, kural bloğunun dışında olanlara dikkat edin (özellikle büyük bir metin küresi;)). İkincisi (neredeyse) dışında bir "yorum" ihtiyacınız olacağını hiçbir durumda yoktur. Dışarıda ise, bir unvanın% 99'udur, bu yüzden böyle tutun.

Sayfayı bileşenlere bölme

Bileşenler olmalıdır position:relativehayır paddingve hayır margin, çoğu zaman. Bu basitleştirir% çok, hem de çok daha basit sağlayan kuralları absolute:positionbir mutlak konumlu konteyner varsa hesaplanırken mutlak konumlu eleman kabı kullanacağından, elementlerin ing' top, right, bottom, leftözellikleri.

HTML5 belgesindeki çoğu DIV genellikle bir bileşendir.

Bileşen aynı zamanda sayfada bağımsız bir birim olarak kabul edilebilecek bir şeydir. Laymen'in terimleriyle, bir kara kutu gibi bir şeyi tedavi etmek mantıklıysa, bir bileşen gibi davranın .

KG sayfası örneğiyle tekrar gitmek:

#navigation
#question
#answers
#answers .answer
etc.

Sayfayı bileşenlere bölerek, çalışmanızı yönetilebilir birimlere böldünüz.

Aynı satıra kümülatif etkisi olan kurallar koyun.

Örneğin border, marginve padding(ancak outline) sen stil olan elemanın boyutları ve boyutuna tüm eklenti.

position: absolute; top: 10px; right: 10px;

Bir satırda o kadar okunabilir değillerse, en azından onları yakın bir yere koyun:

padding: 10px; margin: 20px;
border: 1px solid black;

Mümkün olduğunca steno kullanın:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

Asla bir selektörü tekrarlamayın

Aynı seçiciden daha fazla örneğiniz varsa, aynı kuralların birden fazla örneğiyle kaçınılmaz olma şansınız yüksektir. Örneğin:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

İd / sınıflarını kullanabildiğinizde, TAG'leri seçici olarak kullanmaktan kaçının

İlk olarak DIV ve SPAN etiketleri istisnadır: bunları asla kullanmamalısınız! ;) Bunları yalnızca bir sınıf / kimlik eklemek için kullanın.

Bu...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

Bu şekilde yazılmalıdır:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Çünkü orada sarkan ekstra DIV'ler seçiciye hiçbir şey katmıyor. Ayrıca gereksiz bir etiket kuralını zorlarlar. Eğer, örneğin, bir değişim olursa .answerbir gelen divbir etmek articleiçin stil kırar.

Veya daha fazla açıklık istiyorsanız:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

border-collapseMülkiyet olmasının sebebi , sadece a'ya uygulandığında mantıklı olan özel bir özelliktir table. Eğer .statisticsolmayan bir tablezaman uygulama olmamalıdır.

Genel kurallar kötülüktür!

  • mümkünse genel / büyü kuralları yazmaktan kaçının
  • CSS sıfırlama / sıfırlama için değilse, tüm genel sihiriniz en az bir kök bileşene uygulanmalıdır

Size zaman kazandırmazlar, başınızı patlatırlar; bakım yapmak da bir kabus. Kuralı yazarken, nerede uygulandıklarını biliyor olabilirsiniz, ancak bu kuralınızın daha sonra sizinle uğraşmayacağının garantisi yoktur.

Bu jenerik kurallara eklemek kafa karıştırıcı ve okunması zor, şekillendirdiğiniz belge hakkında bir fikriniz olsa bile. Bu, genel kurallar yazmamanız gerektiği anlamına gelmez, sadece genel olmasını istemediğiniz sürece bunları kullanmayın ve hatta seçiciye olabildiğince çok kapsam bilgisi ekleyin.

Bunun gibi şeyler ...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

... global değişkenleri bir programlama dilinde kullanmakla aynı soruna sahiptir. Onlara kapsam vermelisin!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

Temel olarak şu şekilde okunur:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

Bildiğim bir bileşen bir sayfada bir tekil olduğunda kimlikleri kullanmayı seviyorum; ihtiyaçlarınız farklı olabilir.

Not: İdeal olarak, yeterince yazmalısınız. Ancak seçicide daha fazla bileşenden bahsetmek, daha az bileşenden bahsetmeye kıyasla daha affedici bir hatadır.

Bir paginationbileşeniniz olduğunu varsayalım . Sitenizdeki birçok yerde kullanıyorsunuz. Bu, ne zaman genel bir kural yazacağınıza iyi bir örnek olacaktır. Size display:blockbireysel sayfa numarası bağlantılarını söyleyelim ve onlara koyu gri bir arka plan verelim. Görünür olmaları için aşağıdaki kurallara sahip olmanız gerekir:

.pagination .pagelist a {
    color: #fff;
}

Şimdi çağrılarınızı yanıtların bir listesi için kullandığınızı varsayalım, böyle bir şeyle karşılaşabilirsiniz

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

Bu, beyaz bağlantılarınızı istemediğiniz siyah yapar.

Bunu düzeltmenin yanlış yolu:

.pagination .pagelist a {
    color: #fff !important;
}

Düzeltmenin doğru yolu:

#answers .header .pagination .pagelist a {
    color: #fff;
}

Karmaşık "mantık" yorumları çalışmıyor :)

"Bu değer blah-blah'ın blah-blah'ın yüksekliğiyle birleşimine bağlıdır" gibi bir şey yazarsanız, bir hata yapmanız kaçınılmazdır ve hepsi bir kart evi gibi düşecektir.

Yorumlarınızı basit tutun; "mantıksal işlemlere" ihtiyacınız varsa SASS veya LESS gibi CSS şablonlama dillerinden birini düşünün .

Renk paletini nasıl yazarım?

Bunu sonuna kadar bırak. Tüm renk paletiniz için bir dosyaya sahip olun. Bu dosya ile stiliniz hala kurallarda kullanılabilir bir renk paletine sahip olmalıdır. Renk paletinizin üzerine yazılmalıdır. Seçicileri çok yüksek seviyeli bir üst bileşen (örn. #page) Kullanarak zincirlendirir ve stilinizi kendi kendine yeterli bir kural bloğu olarak yazarsınız. Sadece renk veya daha fazlası olabilir.

Örneğin.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

Fikir basittir, renk paletiniz, içine bastığınız temel stilden bağımsız bir stil sayfasıdır .

Daha az ad, daha az bellek gerektirir ve kodun okunmasını kolaylaştırır

Daha az isim kullanmak daha iyidir. İdeal olarak çok basit (ve kısa!) Kelimeler kullanın: metin, gövde, başlık.

Ayrıca basit kelimelerin kombinasyonunu anlamak daha kolay, sonra uzun "uygun" kelimelerin bulunduğu bir çorbaya sahip olmak: postbody, posthead, userinfo, vb.

Kelime haznesini küçük tutun, bu şekilde biraz yabancı bir kişi stil çorbanızı okumak için gelse bile (birkaç hafta sonra kendiniz gibi), her seçicinin kullanıldığı yerde kelimelerin nerede kullanıldığını anlaması yeterlidir. Örneğin .this, bir öğenin sözde "seçilen öğe" veya "geçerli öğe" vb.

Kendinizden sonra temizleyin

CSS yazmak yemek gibidir, bazen geride bir karmaşa bırakırsınız. Bu karışıklığı temizlediğinizden emin olun, yoksa çöp kodu yığılır. Kullanmadığınız sınıfları / kimlikleri kaldırın. Kullanmadığınız CSS kurallarını kaldırın. Her şeyin güzel olduğundan ve çakışan veya yinelenen kuralların olmadığından emin olun.

Önerdiğim gibi, bazı kapları stilinizde kara kutular (bileşenler) olarak ele aldıysanız, bu bileşenleri seçicilerinizde kullandıysanız ve her şeyi tek bir dosyada tuttuysanız (veya bir TOC ve başlıklarla bir dosyayı düzgün bir şekilde böldüyseniz), o zaman iş çok daha kolay ...

Css nukes ve carnies gizli gizli önemsiz bazı bulmanıza yardımcı olmak için firefox uzantısı Dust-Me Selectors (ipucu: sitemap.xml adresine yönlendirin) gibi bir araç kullanabilirsiniz.

unsorted.cssDosya tut

Bir KG sitesi oluşturduğunuzu ve "yanıtlar sayfası" için arayacağımız bir stil sayfanız olduğunu varsayalım answers.css. Şimdi çok fazla yeni css eklemeniz gerekiyorsa, unsorted.cssstil sayfasına ekleyin ve ardından answers.cssstil sayfanıza yeniden bakın .

Bunun birkaç nedeni:

  • bitirdikten sonra yeniden düzenlemek daha hızlıdır, o zaman kuralları aramak (muhtemelen mevcut değildir) ve kod enjekte etmek
  • kaldıracağınız şeyler yazacaksınız, kod enjekte etmek sadece bu kodu kaldırmayı zorlaştırıyor
  • orijinal dosyaya kolayca eklemek kural / seçici çoğaltmasına yol açar

1
etiket olmayan seçiciler, etiket tabanlı seçicilerden çok daha yavaştır. Tüm tarayıcılarda örneğin 'div' (veya başka bir etiket) almak için yerel yöntemler bulunur. Çok genel olmasına izin verirseniz ('.class'), oluşturma motorunun bir eşleşme olup olmadığını görmek için DOM'un tüm öğelerini yürümesi gerekir.
Miguel Ping

@Miguel Görüntü oluşturma motorunun neden DIV olup olmadığını görmek için DOM'daki tüm öğeleri yürümek zorunda kalmasın? Bazı özel optimizasyonlar varsa neden sınıflara / kimliklere uygulanmaz? Kaynağın var mı? CSS ile fark ettiğim tek görünür performans katili kayan spam nedeniyle oldu - bu, sayfayı kaydırırken oluşturma motorunun bazı tarayıcılarda korkunç bir şekilde gecikmesine neden olabilir (muhtemelen çok fazla hesaplama).
11:53

3
Ben tagNames (yay!) Hedef değil söyleyerek için oy verecekti ama sonra jenerik (boo!)
Olmamakla

1
@Miguel, bu şekilde çalışmıyor. Tarayıcılar bir CSS dizesini geriye doğru okur, bu nedenle: "div .myclass" ve tüm ".myclass" sınıflarını bulur ve sonra bunun div'ın atası olup olmadığını kontrol eder.
mwilcox

5
Genel kuralları global değişkenlerle karşılaştırmak CSS hakkında duyduğum en büyük yanlış anlamadır.
gblazex

55

Bir göz atın 1. SASS 2. Pusula


11
Milyonlarca kez. Sass kullanmak beni her zamankinden daha organize ve güçlü bir css wrangler yaptı. Stilleri birden fazla dosyada, yuva stillerini, değişkenleri vb. Vb. Kullanarak organize etmeme izin veriyor.
Alan H.

2
sass, pusula ve daha azı, günün sonunda hala çirkin ve patlayabilecek normal CSS üretir. Kendi başına CSS şişkinliğine bir çözüm değil.
Moin Zaman

8
@Moin_Zaman Benim düşünceme göre, efendim, ifadeniz saf bir aldatmaca. sass / compass / less yazarak kodunuzu dosyalarında düzenlersiniz. css çıktısının nasıl göründüğü umurumda değil. ayrıca, en az daha az (daha az uygulama yoluyla) büyük çıktı minimize edebilir.
bzx

1
@bzx benim fikrimi kanıtlıyorsunuz :) Bir tarayıcı sass / pusula / daha az anlamıyor. bunların tümü ya istemci tarafında ya da yapınızın bir parçası olarak düz eski CSS'ye derlenmelidir. Sonunda CSS olarak ne ürettiklerini bilmeden bu gibi araçları kullanmak, onları bilmeden kötüye kullanmayı ve en uygun CSS dosyalarından daha büyük olmasını sağlar.
Moin Zaman

Burada gzip sıkıştırması devreye giriyor… Çoğu web sunucusu ve tarayıcı mümkün olduğunda gzip içeriği ile iletişim kuracak. Bir seçici parçasını birden çok kez tekrarlarsanız, bu tek bir karma tablo girişine sıkıştırılır. Tek gerçek sorun, tarayıcıdaki CSS kurallarını ayrıştırmak için gerekli RAM miktarıdır.
üçüncü

31

CSSŞişkinliğe karşı koymanın en iyi yolu Nesneye Dayalı CSS ilkelerini kullanmaktır.

Dışarıda oldukça iyi bir OOCSS çerçevesi bile var.

Bazı ideolojiler burada en iyi yanıtlarda söylenenlerin çoğuna karşı çıkıyor, ancak bir kez CSSnesne yönelimli bir şekilde nasıl mimar yapılacağını bildiğinizde , bunun aslında kodu yalın ve ortalama tutmaya çalıştığını göreceksiniz.

Buradaki anahtar şey, sitenizdeki 'Nesneleri' veya yapı taşı desenlerini tanımlamak ve onlarla birlikte mimar.

Facebook , ön uç kodlarında (HTML / CSS) çok fazla tasarruf elde etmek için OOCSS'nin yaratıcısı Nicole Sullivan'ı kiraladı . Eğer bir dönüştürme sayılabilir olarak Evet aslında CSS'nizde fakat Ses getiren, sizin için çok mümkündür da HTML'nizin, içinde sadece tasarruf elde edebilirsiniz tablebir sürü içine tabanlı düzeni div's

Başka bir harika yaklaşım, OOCSS'ye bazı yönlerde benzerdir, CSS'nizi başlangıçtan itibaren ölçeklenebilir ve modüler olacak şekilde planlamak ve yazmaktır. Jonathan Snook , SMACSS - CSS için Ölçeklenebilir ve Modüler Mimari hakkında mükemmel bir yazma ve kitap / e-kitap hazırladı

Sizi bazı bağlantılarla bağlayayım:
5 büyük CSS hatası - (Video)
5 büyük CSS hatası - (Slaytlar)
CSS Bloat - (Slaytlar)


16

Ayrıca kaskad ve ağırlığı ve bunların nasıl çalıştığını da anlamalısınız.

Yalnızca sınıf tanımlayıcıları (div.title) kullandığınızı fark ediyorum. Kimlikleri de kullanabileceğinizi ve bir kimliğin bir sınıftan daha fazla ağırlık taşıdığını biliyor muydunuz?

Örneğin,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

tüm bu öğelerin yazı tipi boyutu, diyelim, bir renk veya kurallarınız ne olursa olsun paylaşmasını sağlar. Hatta # page1'in torunları olan tüm DIV'lerin belirli kuralları elde etmesini sağlayabilirsiniz.

Ağırlık olarak, CSS eksenlerinin en genel / en hafiften en spesifik / en ağır olana hareket ettiğini unutmayın. Diğer bir deyişle, bir CSS seçicide, bir öğe belirleyici bir sınıf belirleyici tarafından geçersiz kılınır, bir kimlik belirleyici tarafından geçersiz kılınır. Sayılar sayılır, bu nedenle iki öğe belirticisine (ul li) sahip bir seçici, yalnızca tek bir belirticiye (li) sahip olandan daha fazla ağırlığa sahip olacaktır.

Bunu rakamlar gibi düşünün. Birler sütunundaki 9 değeri hala onlarca sütundaki bir sütundan daha azdır. Kimlik belirtecine, sınıf belirtecine ve iki öğe belirtecine sahip bir seçici, kimliği olmayan bir seçiciden, 500 sınıf belirleyicisinden ve 1.000 öğe belirtecinden daha fazla ağırlığa sahip olacaktır. Bu elbette saçma bir örnek, ama fikri anladınız. Mesele şu ki, bu kavramı uygulamak birçok CSS'yi temizlemenize yardımcı olur.

BTW, class = "title" olan diğer öğelerle çakışmadığınız sürece, element tanımlayıcısını sınıfa (div.title) eklemek gerekmez. Gereksiz ağırlık eklemeyin, çünkü bu ağırlığı daha sonra kullanmanız gerekebilir.


Kimlik kullanmak, Visual Basic kodunuzdaki genel değişkenleri kullanmak gibi kötüdür.
alpav

2
@alpav: Üzgünüm, bu yanlış. Kimlikler, benzer öğelerin sayfanın farklı bölümlerinde yeni sınıf adları oluşturmalarına gerek kalmadan farklı görünmesini sağlamanın müthiş bir yoludur.
Robusto

@Robusto: Yeni kimlik adı oluşturmak neden yeni sınıf adı yapmaktan daha zor?
alpav

@Robusto: Yeni sınıf isimleri yapmak aslında kimlik isimlerinden daha kolaydır, çünkü kimliklerde küresel kapsam hakkında endişelenmeniz gerekir ve sınıf adları ile sadece yerel kapsamdaki benzersizlik hakkında endişelenmeniz gerekir, yerel değişkenlerle aynı fayda.
alpav

1
@alpav “Bu, kapsülleme amacını yeniyor - küresel düşünmeden yerel olarak adlandırabilme.” Doğru, ancak CSS seçicileri doğası gereği küreseldir: yazdığınızda .myclasssınıfla her şeyi seçersiniz myclass. CSS'de, sınıflar bu açıdan kimliklerle aynıdır.
Paul D.Waite

12

Daha Az CSS Dinamik çerçevesi önerebilir miyim

Daha önce de belirtildiği gibi SASS ile benzerdir.

Ana sınıf başına CSS'nin korunmasına yardımcı olur.

Örneğin

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

Bu ne yapar: Genişliği uygular: # child1 ve # child2 için% 100.

Ayrıca # child1 spesifik CSS, #parent'a aittir.

Bu,

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

1
Ben sass kullanın ve bu sass ve daha az arasındaki bir fark olabilir, ama eminim #parent {width: 100%; } #parent # child1 {arka plan: # E1E8F2; dolgu: 5 piksel; } #parent # child2 {arka plan: # F1F8E2; dolgu: 15 piksel; } ``
emik

12

Zor olanın bir site için gerekli tasarımı bir dizi kurala çevirmek olduğunu düşünüyorum. Sitenin tasarımı açık ve kurallara dayalıysa, sınıf adlarınız ve CSS yapınız bundan akabilir. Ancak insanlar, zamanla, siteye çok fazla anlam ifade etmeyen rastgele küçük bitler eklerse, CSS'de bu konuda yapabileceğiniz çok şey yoktur.

CSS dosyalarımı kabaca şöyle düzenleme eğilimindeyim:

  1. Eric Meyer’e göre CSS sıfırlaması . (Aksi takdirde, çoğu öğe için, yalnızca varsayılan tarayıcı stillerini sıfırlayan en az bir veya iki kuralım olduğunu düşünüyorum - listelerimin çoğu, listeler için varsayılan HTML stili gibi görünmüyor.)

  2. Grid sistemi CSS, site onu çağırırsa. (Madeni 960.gs'ye dayandırıyorum )

  3. Her sayfada görünen bileşenler için stiller (üstbilgiler, altbilgiler vb.)

  4. Sitenin çeşitli yerlerinde kullanılan bileşenler için stiller

  5. Yalnızca tek tek sayfalarla alakalı stiller

Gördüğünüz gibi, bunların çoğu sitenin tasarımına bağlıdır. Tasarım açık ve düzenli ise, CSS'niz olabilir. Değilse, mahvoldun.


7

Cevabım, sorunuzda dile getirdiğiniz üst düzey endişeleri ele almak için üst düzey. Daha güzel hale getirmek için yapabileceğiniz düşük seviyeli organizasyon hileleri ve ince ayarlar olabilir, ancak bunların hiçbiri metodolojik eksiklikleri gideremez. CSS patlamasını etkileyen birkaç şey vardır. Açıkçası sitenin genel karmaşıklığı, aynı zamanda anlambilim adlandırma, CSS performansı, CSS dosya organizasyonu ve test edilebilirlik / kabul edilebilirlik gibi şeyler.

Anlambilim adlandırma ile doğru yolda görünüyorsunuz, ancak bir adım daha ileri götürülebilir. Sitede yapısal değişiklikler yapılmadan ("modüller" olarak bilinir) tekrar tekrar görünen HTML bölümleri seçici kökler olarak kabul edilebilir ve oradan dahili düzeni bu köke göre kapsayabilirsiniz. Bu, nesne yönelimli CSS'nin temel ilkesidir ve bir Yahoo mühendisi tarafından bu konuşmada daha fazla okuyabilir / izleyebilirsiniz .

Bu temiz yaklaşımın , id veya etiket adına dayalı kısa seçicileri destekleyen performans endişesinin tersine gidebileceğini belirtmek önemlidir . Bu dengeyi bulmak size kalmış, ancak büyük bir siteniz yoksa, bu sadece kafanızın arkasındaki seçicilerinizi kısa tutmanızı hatırlatan bir rehber olmalıdır. Performans hakkında daha fazla bilgi burada .

Son olarak, sitenizin tamamı için tek bir CSS dosyanız mı yoksa birden çok dosyanız mı (sayfa başına veya bölüm dosyaları ile kullanılan tek bir temel dosya) olacak mı? Tek dosya performans için daha iyidir, ancak birden çok ekip üyesi ile anlaşılması / bakımı zor olabilir ve sınanması daha zor olabilir. Test için, çarpışmaları ve istenmeyen basamakları test etmek için desteklenen her CSS modülünü içeren tek bir CSS test sayfanız olmasını tavsiye ederim .

Alternatif olarak , CSS kurallarını bir sayfaya veya bölüme dahil etmek için çoklu dosya yaklaşımınız olabilir . Bu, tarayıcının bir performans sorunu olan birden fazla dosyayı indirmesini gerektirir. CSS dosyalarını dinamik olarak tek bir dosyada belirtmek ve toplamak (ve küçültmek) için sunucu tarafı programlamayı kullanabilirsiniz. Ancak bu dosyalar ayrı olduğundan ve sınamaları ayrı olacağından, sayfalarda / bölümlerde tutarsız görünüm ve his verme olasılığını ortaya koyarsınız. Böylece test yapmak zorlaşır.

Müşterinin özel ihtiyaçlarını analiz etmek, bu endişeleri buna göre dengelemek size kalmıştır.


5

Benden önce söylediğim gibi: OOCSS'ye gir. Sass / Less / Compass kullanmak caziptir, ancak vanilya CSS doğru şekilde kullanılana kadar Sass / Less / Compass işleri daha da kötüleştirir.

Her şeyden önce, verimli css hakkında bilgi edinin. Google Page Speed'i deneyin ve Souders'ın verimli css hakkında yazdıklarını okuyun.

Ardından, OOCSS girin.

  • Art arda sıralı çalışmayı öğrenin. (Sonuçta buna Basamaklı Stil Sayfaları diyoruz ).
  • Ayrıntı düzeyini nasıl doğru elde edeceğinizi öğrenin (yukarıdan aşağıya değil aşağıdan yukarıya)
  • Yapıyı ve cildi nasıl ayıracağınızı öğrenin (benzersiz olan nedir ve bu nesnelerin varyasyonları nelerdir?)
  • Kapsayıcı ve içeriği nasıl ayıracağınızı öğrenin.
  • Izgaraları sevmeyi öğrenin.

Css yazma ile ilgili her bitte devrim yaratacak. Tamamen yenileniyorum ve seviyorum.

GÜNCELLEME: SMACSS, OOCSS'ye benzer, ancak genel olarak konuşmaya uyum sağlamak daha kolaydır.


2
"Sass / Less / Compass işleri daha da kötüleştirecek" - bu oldukça öznel ve projeye bağlı. Bunlardan birini OOCSS ile birlikte kullanmanın birçok büyük projenin (özellikle stilleri sık sık değiştirilebilecek olanlar) sürdürülebilirliğine gerçekten fayda sağlayacağını
öne sürdüm

Zach L: Doğru kullanılan OOCSS (veya bu konuda SMACSS), Pusula / Az / Sass'ı yalnızca satıcı önekleri için gerekli kılar.
madr

Bunu çok fazla tartışmaya çalışmayacağım (özellikle şu anda ön işlemci kullanmadığım için), ancak kombinasyon halinde bile bu tür şeyleri yararlı bulabilen bir grup insan olduğundan eminim / SMACSS ile satıcı öneki sorunları dışında
Zach Lysobey

4

CSS Refactoring'den çıkarılan mantıklı CSS için temel ilkeler : Yalnızca ekliden modüler CSS'ye

SASS yazınız. Değişkenlerin, karışımların vb. Avantajlarından vazgeçmek için delirmiş olursunuz.

Stil için asla bir HTML kimliği kullanmayın; daima sınıfları kullanın . HTML kimlikleri, doğru kullanıldıklarında, sayfanın tamamında yalnızca bir kez görünür. Bu, yeniden kullanılabilirliğin tam tersidir - makul mühendislikteki en temel ürünlerden biri. Dahası, kimlikler içeren seçicileri geçersiz kılmak gerçekten zordur ve genellikle bir HTML kimliğini aşmanın tek yolu başka bir kimlik oluşturmaktır, bu da kimliklerin kod tabanında zararlı böcekler gibi yayılmasına neden olur. Değişmeyen Javascript veya entegrasyon test kancaları için HTML kimliklerini bırakmak daha iyidir.

CSS sınıflarınızı uygulamaya özgü işlevleri yerine görsel işlevlerine göre adlandırın. Örneğin, ".bundle-product-discount-box" yerine ".highlight-box" deyin. Bu şekilde kodlama yapmak, yan işletmelerin rolünü üstlendiğinizde mevcut stil sayfalarınızı yeniden kullanabileceğiniz anlamına gelir. Örneğin, hukuk notları satmaya başladık ancak son zamanlarda hukuk öğretmenlerine geçtik. Eski CSS sınıflarımız ".download_document_box" gibi isimlere sahipti, dijital belgeler hakkında konuşurken mantıklı olan ancak yalnızca özel öğretmenlerin yeni etki alanına uygulandığında karışacak bir sınıf adı. Hem mevcut hizmetlere hem de gelecekteki hizmetlere uyan daha iyi bir ad ".pretty_callout_box" olacaktır.

Belirli ızgara bilgilerinin ardından CSS sınıflarını adlandırmaktan kaçının. CSS topluluklarında CSS çerçevelerinin tasarımcılarının ve yaratıcılarının (öksürük Twitter Bootstrap ) "span-2" veya "cols-8" in CSS sınıfları için makul isimler olduğuna inandıkları (ve hala da) korkunç bir anti-desen vardı . CSS'nin amacı, işaretlemeyi etkilemeden tasarımınızı değiştirme olanağı sunmaktır (çok). Sabit kodlama boyutları HTML içine bu hedefi engeller, bu nedenle bir hafta sonu daha uzun sürmesi beklenen herhangi bir projede tavsiye edilmez. Daha sonra ızgara sınıflarından nasıl kaçınıldığımız hakkında daha fazla bilgi.

CSS'nizi dosyalar arasında bölün . İdeal olarak, her şeyi "bileşenler" / "widget'lara bölerek tasarımın bu atomlarından sayfalar oluşturursunuz. Gerçekçi olmakla birlikte, web sitesi sayfalarınızdan bazılarının kendine özgü ifadeler (örneğin, özel bir düzen veya yalnızca bir makalede görünen garip bir fotoğraf galerisi) olduğunu fark edeceksiniz. Bu gibi durumlarda, söz konusu sayfayla ilgili bir dosya oluşturabilirsiniz; bu, yalnızca öğenin başka bir yerde yeniden kullanılacağı açık olduğunda tam gelişmiş bir widget'a yeniden düzenleme yapabilirsiniz. Bu, pratik bütçe kaygılarıyla motive edilen bir ödünleşmedir.

Yuvalamayı en aza indirin. Yuva seçiciler yerine yeni sınıflar ekleyin. SASS'ın yuvalama sırasında tekrarlayan seçicilerin acısını ortadan kaldırması, beş seviyeyi derinlere yuvalamanız gerektiği anlamına gelmez. Asla bir seçiciyi aşırı nitelendirmeyin (örneğin, ".nav" aynı işi yapabilen "ul.nav" kullanmayın.) Ve özel sınıf adının yanında HTML öğeleri belirtmeyin (örn. "H2.highlight"). Bunun yerine sadece sınıf adını kullanın ve temel seçiciyi bırakın (örneğin, önceki örnek ".highlight" olmalıdır). Aşırı nitelikli seçiciler herhangi bir değer katmaz.

Yalnızca tüm uygulamada tutarlı olması gereken temel bileşenleri biçimlendirirken HTML öğeleri için stiller oluşturun (örn. "H1"). "Header ul" gibi geniş seçicilerden kaçının çünkü bazı yerlerde onları geçersiz kılmanız muhtemeldir. Söylediğimiz gibi, çoğu zaman belirli bir stili istediğinizde belirli, iyi adlandırılmış bir sınıf kullanmak istersiniz.

Block-Element-Modifier'ın temellerini kucaklayın. Örneğin burada okuyabilirsiniz. Oldukça hafif kullandık, ama yine de CSS stillerini düzenlememize çok yardımcı oldu.


2

Bir çok kez bireyler bölümler arasında bir başlık yorum ile dosyayı bölümlere ayrılır göreceksiniz.

Gibi bir şey

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

Oldukça iyi çalışıyor ve daha sonra geri dönüp üzerinde çalıştığınız şeyi bulmanızı kolaylaştırabilir.


Bu, soruyu soran kişinin "her bir şey için ayrı bir CSS özelliğine" ilişkin endişesi hakkında hiçbir şey söylemez.
G-Wiz

1

BEM'e bakmalısın .

teori

BEM, işleri daha yeniden kullanılabilir ve modüler hale getirmek ve genellikle spagetti koduna ve özgüllük baş ağrılarına yol açan tür seçiciler arasındaki çatışmaları önlemek amacıyla css seçicilerini düzenlemek ve adlandırmak için bir dizi talimat sağlama girişimidir.

Doğru kullanıldığında bazı çok olumlu etkileri vardır.

  • Stiller, bir öğeye eklendiğinde beklediğiniz şeyi yapar
  • Stiller sızdırmaz ve yalnızca eklendiklerini etkilemez
  • Stiller belge yapısından tamamen ayrılmıştır
  • Tarzların birbirlerini aşırı sürmeye zorlanması gerekmez

BEM, CSS'ye neredeyse nesneye yönelik bir stil getirmek için SASS ile iyi çalışır. Tek bir kullanıcı arabirimi öğesinin görüntülenmesini işleyen ve renkler ve iç öğelerin nasıl işlendiği gibi 'yöntemler' gibi değişkenler içeren modüler dosyalar oluşturabilirsiniz. Sert bir OO programcısı bu fikre karşı koyabilirken, aslında uygulanan kavramlar, OO yapılarının modülerlik, gevşek bağlantı ve sıkı kohezyon ve bağlamsız yeniden kullanılabilirlik gibi daha güzel kısımlarını getirmektedir. Sass ve &operatörünü kullanarak kapsüllenmiş bir nesneye benzeyen bir şekilde bile inşa edebilirsiniz .

Smashing Magazine'den daha ayrıntılı bir makaleyi burada bulabilirsiniz ; ve CCS Sihirbazı'ndan Harry Roberts'tan (css ile ilgilenen herkesin okuması gereken) burada .

Uygulamada

SMACSS ve OOCSS kullandığımla birlikte birkaç kez kullandım, yani onları karşılaştırmak için bir şeyim var. Ayrıca, çoğu zaman deneyimsiz yaratımım olan büyük karışıklıklarda da çalıştım.

BEM'i gerçek dünyada kullandığımda tekniği birkaç ekstra prensiple güçlendiriyorum. Yardımcı sınıfları kullanıyorum - iyi bir örnek bir sarıcı sınıftır:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

Ve ben de bir şekilde kaskat ve özgüllüğe güveniyorum. Burada BEM modülü belirli bir aşırı sürüş için bağlam olacaktır .primary-boxve.header

.header {
  .primary-box {
    color: #000;
  }
}

(Her şeyi olabildiğince genel ve bağlamdan bağımsız hale getirmek için elimden geleni yapıyorum, yani iyi bir proje, neredeyse her şey yeniden kullanılabilir modüllerde)

Burada yapacağım son nokta, projeniz ne kadar küçük ve karmaşık olsa da, başından itibaren bunu iki nedenden dolayı yapmanız gerektiğidir:

  • projeler karmaşıklığı arttırır, bu nedenle iyi temeller atmak önemlidir, css dahil
  • WordPress üzerine kurulu olduğu için basit görünen bir proje bile CSS'de çok az JavaScript'e sahip olabilir - Tamam, herhangi bir sunucu tarafı kodlaması yapmak zorunda değilsiniz, bu yüzden bölüm basit, ancak broşür giymek ön ucu yirmi modül ve her birinin üç varyasyonu vardır: orada çok karmaşık bir css var!

Web Bileşenleri

2015 yılında Web Bileşenleri'ne bakmaya başlıyoruz. Bunlar hakkında henüz çok şey bilmiyorum, ancak tüm ön uç işlevlerini bağımsız modüllerde bir araya getirmeye çalışıyorlar, BEM'den bir tür prensipleri etkili bir şekilde bir bütün olarak ön uca ve bileşen dağılmış ancak tamamen eşleştirilmiş olarak uygulamaya çalışıyorlar. hepsi aynı UI widget'ını oluşturan DOM parçaları, Js (MVC) ve CSS gibi öğeler.

Bunu yaparak, BEM gibi şeylerle çözmeye çalıştığımız css ile ilgili bazı orijinal sorunları ele alırken, diğer ön uç mimariden bazılarını daha aklı başında hale getireceğiz.

Burada biraz daha okuma var ve burada da görülmeye değer bir çerçeve Polimer var

En sonunda

Ayrıca , büyük css projelerinin dağınık olmasını önlemek için özel olarak tasarlanmış mükemmel, modern bir en iyi uygulama css kılavuzu olduğunu düşünüyorum . Bunların çoğunu takip etmeye çalışıyorum.



0

Burada bazı harika malzemeler var ve bazıları bu soruya cevap vermek için çok zaman aldı, ancak ayrı veya bireysel stil sayfalarına gelince, geliştirme için ayrı dosyalar ile giderim ve daha sonra tüm genel css'lerinizi oturtulmuş birleştirilmiş olarak kullanmaya başlarım dağıtıldığında tek bir dosyaya.

bu şekilde her iki dünyanın da en iyisini elde edersiniz, performansı artırır (tarayıcıdan daha az HTTP isteği istenir) ve geliştirirken kod endişelerinin ayrılması.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.