Öğe Sorguları ve Bunları Bugün Nasıl Kullanabilirsiniz?

Bir an için fiziksel bir yapı düşünün. Zayıf malzeme ile büyük bir yapı inşa ediyorsanız, onu bir arada tutmak için çok fazla dış desteğe ihtiyaç vardır ve sağlam kalması için her şeyin aşırı inşa edilmesi gerekir. HTML, CSS ve JavaScript'ten bir web sitesi oluştururken, bu harici destek çerçeveler, eklentiler, ön işlemciler, aktarıcılar, düzenleme araçları, paket yöneticileri ve oluşturma süreçleri gibi görünebilir.

Yığının en üstüne başka bir eklenti eklemek yerine , temel dillerden biri olan CSS'yi genişleterek , web sitelerinin oluşturulduğu materyali güçlendirip, daha az harici destek ve araç gerektiren daha iyi, daha güçlü web siteleri geliştirip geliştiremeyeceğimizi merak ettim. inşa etmek.

Öğe Sorgularının Mevcut Durumu

CSS ön işlemcileri gibi araçlarla, daha sonra tam biçimine genişletilmek üzere (bir tarayıcıda görüntülenmeden önce) CSS'yi steno olarak yazarız. Eklentiler, etkiledikleri öğelerin yanında sayfada çalışabilirler, ancak stilleri uygulamak için ya CSS stillerini doğrudan HTML'ye yazarlar ya da farklı CSS kuralları uygulayan sınıf adlarını değiştirirler. Her iki durumda da sayfa yüklenmeden önce ihtiyacımız olacak CSS'yi yazmamız veya oluşturmamız gerekir.

Sorun

Bu yöntemle ilgili sorun, en iyi eklentilerin bile kullandığınız her düzende genellikle özelleştirme ve yapılandırma gerektirmesidir . Ayrıca JavaScript sizin için stiller yazarken, kodu yeniden düzenlerken veya yeniden kullanırken eklenti tabanlı mantığınızı ve CSS stillerinizi bir arada tutmak zor olabilir.

Önişlemcilerle ilgili bir başka sorun da, stenografiyle yazılan hataların, CSS tam biçimine genişletildiğinde hızla çok daha büyük bir karmaşaya dönüşmesidir. Eklentileri kullanırken, birçok olası başarısızlık noktası ekliyoruz. CSS biraz daha güçlü olsaydı gereksiz olabilecek birkaç farklı şeyi başarmak için birden fazla eklenti kullanıyor olabiliriz. Bu, geliştiricilerin sürdürmesi, tarayıcıların oluşturması ve kullanıcıların indirmesi için ekstra bir yük oluşturur.

Web Geliştirmenin Geleceği İçin Herhangi Bir Umut Var mı?

2013 yılında Tyson Matanich, öğe sorguları kavramını geniş bir kitleye tanıtan “Medya Sorguları Cevap Değil: Öğe Sorgusu Çoklu Doldurma” başlıklı bir makale yazdı. CSS'nin eksikliklerini gidermek için eklentilerin ve çoklu dolguların nasıl oluşturulabileceği hakkında bir tartışma başlattı.

O zamandan beri, CSS özelliklerinin ilerlemesini beklerken, geliştiricilerin öğe sorgularını birkaç farklı şekilde kullanmasına olanak tanıyan bir dizi eklenti yayınlandı.

Öğe Sorguları Nelerdir?

Öğe sorguları, medya sorguları gibidir, ancak kurallarının tarayıcının görünüm penceresininkiler yerine gerçek öğelerin özelliklerine uygulanması dışında.

EQCSS Nasıl Ortaya Çıktı?

2013'ün sonlarında kendimi bir Ruby on Rails web uygulamasının ön ucunda çalışırken buldum. Uygulamanın kullanıcılara ayrıntılı bilgi göstermesi gerekiyordu ve amaç, telefonlarda, tabletlerde ve masaüstü tarayıcılarda eşit derecede iyi performans gösterecek duyarlı bir arayüz oluşturmaktı. Bu, birkaç zorluk çıkardı; bunlardan biri, görüntülenecek önemli içeriğin çoğunun en iyi şekilde tablolarda görüntülenmesiydi - evet, gerçek table öğeleri (finansal işlemleri, spor kayıtlarını vb. göstermek için).

Farklı boyutlardaki tarayıcılar için table öğesini doğru şekilde görüntüleyen medya sorgularını kullanarak duyarlı stiller oluşturdum. Ancak, bu duyarlı tablolardan biri bir kenar çubuğu içeren bir şablonda görüntülendiğinde, aniden tüm duyarlı kesme noktalarım duyarlı kırılma noktalarına dönüştü. 200 piksel genişliğindeki kenar çubuğunu hesaba katmadılar, bu da şeylerin üst üste gelmesine ve bozuk görünmesine neden oldu.

Başka bir engel: Kullanıcı adlarının uzunluğu 3 ila 20 karakter arasında değişiyordu ve kendimi, içerdiği karakter sayısına göre her kullanıcı adının yazı tipi boyutunu otomatik olarak ayarlayabilmeyi isterken buldum. Her kullanıcı adını kenar çubuğuna koymam gerekiyordu ve 20 karakterlik bir kullanıcı adına sığacak kadar küçük, ancak izleyicinin 3 karakterli bir kullanıcı adını görebileceği kadar büyük bir yazı tipi boyutu seçmek zordu.

Bunun gibi sorunları çözmek için, her düzende duyarlı stilleri uygulamak için daha akıllı bir yola ihtiyacım olduğundan, genellikle kendimi tüm medya sorgularını kopyalarken, kod tabanımın büyük bölümlerini çoğaltırken bulurdum. Başka bir geçici çözüm olarak JavaScript'e güvendim, bir sayfayı izleyecek ve CSS'nin ulaşamadığı yerlerde stiller uygulayacak neredeyse aynı işlevleri yazdım. Bir süre sonra, tüm bu kopya kodların ek yükü, kod tabanını ağırlaştırmaya başladı ve değişiklikleri yapmayı zorlaştırdı.

Daha iyi bir çözüm olması gerektiğini biliyordum ve bir süre sonra düşünmeye başladım: Medya sorgularına ihtiyacım yok - ihtiyacım olan şey eleman sorguları!

Araştırma ve Geliştirme

2014 boyunca, daha iyi stiller uygulayabilmem için, sayfada göründükleri gibi öğelerin özellikleri hakkında CSS'yi bilgilendirmenin farklı yollarını denemeye başladım. CSS'nin güzelliğini JavaScript'in gücüyle birleştiren stiller yazmamı sağlayacak bir yaklaşım keşfetmeyi umuyordum.

Vazgeçtiğim bazı terk edilmiş yaklaşımlar, duyarlı destek eklemek için HTML etiketlerine nitelikler eklemeyi ve JavaScript'ten bir araya getirilmiş bir tür Frankenstein canavarı üretmek için tüm CSS kod bloklarını JavaScript tabanlı if ifadelerinin içine yerleştirmenin yollarını bulmaya çalışmayı içeriyor. ve CSS.

Ancak, işleri kolaylaştırmak yerine, başarısız yaklaşımlarımın hepsinin ortak bir yanı vardı: Daha fazla iş eklediler! Doğru çözümün yapılması gereken işleri basitleştireceğini ve azaltacağını biliyordum, bu yüzden araştırmaya devam ettim. Bu deneyler sayesinde, öğe sorgularının iyi çalışması için gerekli olacak sözdizimi türü hakkında rafine bir fikir edindim.

Belirtildiği gibi, HTML, CSS ve JavaScript'ten oluşturulmuş bir web sitesi için dış destek, çerçeveler, eklentiler, ön işlemciler, aktarıcılar, düzenleme araçları, paket yöneticileri ve oluşturma süreçleri şeklinde gelir. Yığının en üstüne başka bir eklenti eklemek yerine, temel dillerden biri olan CSS'yi genişleterek, web sitelerinin oluşturulduğu materyali güçlendirip, daha az harici destek gerektiren daha iyi, daha güçlü web siteleri inşa edip edemeyeceğimizi merak ettim. inşa etmek için araçlar.

Bir Sözdiziminin Doğuşu

2014'ün sonunda, gereken sözdizimine ilişkin daha iyi bir vizyonla donatılmış olarak, olağanüstü bir JavaScript kod golfçüsü olan Maxime Euziere ile iletişime geçtim ve çalışma zamanında tarayıcıda JavaScript kullanarak CSS'yi genişletme olasılığı hakkında fikrini sordum. Bana sadece bunun mümkün olduğunu bildirmekle kalmadı, aynı zamanda bunu yapmama yardım etmeyi teklif etti! EQCSS sözdizimine "eleman sorgusu CSS"nin kısaltması olan EQCSS adını verdik. Ad aynı zamanda "fazlalık" kelimesine de bir göndermedir çünkü yaptığı her şey CSS'nin yapabileceğinden fazladır.

İhtiyaç

Sözdizimi için benim şartım, CSS'ye mümkün olduğunca yakın olmasıydı - o kadar yakın ki, sözdizimi vurgulayıcıları, standart CSS olduğunu düşünmek için kandırılacaktı. Bu yüzden, anlamlı olan öğe sorguları için CSS sözdiziminin haritasını çıkardım - insanların şaşırdığı türden bir sözdizimi zaten mevcut değil.

JavaScript kullanarak CSS için tarayıcı desteğini genişletecek olsaydık, işi halletmek için eklentinin mümkün olduğunca hafif ve basit olması gerektiğini biliyordum, bu da eklentiyi oluşturmak için jQuery gibi kitaplıkları kullanma olasılığını ortadan kaldırdı. Gelecekte istediğim özellikleri bugün desteklemem gereken tarayıcılara ekleyecek saf bir JavaScript kitaplığına ihtiyacım vardı.

Şu anda, CSS topluluğundaki tartışma özel @ kurallarına odaklanıyor ve öğe sorguları hakkında konuşmak henüz başlangıç ​​aşamasında. Bunun gibi özellikler için herhangi bir resmi CSS spesifikasyonundan muhtemelen hala yıllarca uzaktayız ve bir spesifikasyondan sonra bile, bu özellikleri web sitelerinde kullanabilmek için hala yeterli tarayıcı desteği için beklememiz gerekecek.

Bugün web siteleri oluşturmak ve düzeltmek için bu işlevselliğe ihtiyacımız olduğunda, bu özelliklerin CSS'ye eklenmesini beklemek mantıklı değil.

Sonuç

Bu araştırmanın sonucu, yeni bir dizi gelişmiş duyarlı koşul, kapsamlı stiller ve hedefleme öğeleri için yeni seçiciler ile EQCSS.js adlı salt bir JavaScript kitaplığı içeren bir sözdiziminin oluşturulması olmuştur. Ayrıca, isteğe bağlı bir harici çoklu dolguda Internet Explorer (IE) 8 desteği sağlanmıştır. Hem eklenti hem de çoklu doldurma, MIT lisansı altında yayınlandı ve herkesin kullanması için ücretsiz.

Öğe Sorguları İçin Kullanım Örnekleri

Eklenti Geliştiricileri

UI bileşenleri ve widget'ları oluştururken, geliştiriciler genellikle kendilerini medya sorgularıyla sınırlı bulurlar. Genellikle, eklentiyi kullanan kişi tarafından yapılandırılabilen birçok farklı düzen oluşturmak ile arayüzü, en uygun tek boyutlu bir çözüm oluşturabileceğiniz noktaya kadar basitleştirmek arasında seçim yapmak zorunda kalırız.

Ancak, öğe sorgularıyla eklentiler ve arayüzler tasarlarken, beklediğimiz tüm durumları kapsayan duyarlı stiller yazabilir ve kullanıcının içine hangi içeriği koyarsa koysun veya eklenti nerede görünürse görünsün onları gerçekten kurşun geçirmez hale getirebiliriz. 150 ila 2000 piksel genişliğinde bir düzene sahip bir widget'ı stillendirebileceğimizi varsayalım. Ardından, bu widget bir web sitesinde nerede gösterilirse gösterilsin, her zaman harika görünür.

Şablon Oluşturucular

Bir web sitesinin prototipini oluştururken, sayfadaki tasarım öğelerini yeniden düzenlemek ve tasarımı modüler bileşenlerden oluşan bir koleksiyon olarak düşünmek yaygındır. CSS medya sorguları yazdıysanız, bu bazen erken bir optimizasyon durumu olabilir. Öğe sorgularıyla tasarım yaparak, yanıt veren koşulları düzenden bağımsız tutar ve stilleri çok fazla yeniden çalışmak zorunda kalmadan işleri hareket ettirmek için size çok daha fazla esneklik sağlarsınız.

Öğe sorgularını kullanarak tasarlamayı veya taklit etmeyi özellikle yararlı bulduğum şeyler şunları içerir:

• gezinme çubukları,
• modlar,
• kayıt ve giriş formları,
• altbilgiler,
• fiyatlandırma çizelgeleri,
• açılış sayfaları,
• tablolar,
• sekme kutuları,
• akordeonlar,
• kenar çubuğu widget'ları,
• medya oynatıcılar,
• referans bölümleri.

Herhangi bir tasarım öğesi "kapsamlı" olabilir ve sayfadan sayfaya veya web sitesinden web sitesine herhangi bir yere taşınabilir.

Cihaz Desteği

Web'i mobil cihazlarda desteklerken karşılaştığınız sorunlardan biri donanımın bolluğudur. Cihaz pazarı her zamankinden daha fazla parçalanmış durumda ve her gün yeni cihazlar ortaya çıkıyor. Artık desteklediğimiz tarayıcıların ve cihazların bir listesini tutamıyoruz, bu nedenle bir tasarımın her yerde, hatta henüz piyasaya sürülmemiş cihazlarda bile çalıştığını bilmek çok önemlidir.

Öğe sorgularını kullanarak web sitelerini daha iyi tasarlayabilir ve bu tarayıcılar arası farklılıkların bazılarını ortadan kaldırabilirsiniz.

Son zamanlarda öğe sorgularına duyulan ihtiyaç hakkında yazılan birçok makale, kullanım durumlarının çoğunu ayrıntılı olarak göstermektedir. O halde bunları nasıl kullanacağımıza geçelim!

Eleman Sorguları Nasıl Yazılır

EQCSS'yi kullanmaya başlamak kolaydır. EQCSS sözdizimini kullanmaya başlamak için ihtiyacınız olan tek şey JavaScript'i HTML'nizin bir yerine eklemektir.

EQCSS.js'yi indirme

EQCSS projesini GitHub'dan klonlamak istiyorsanız şunu yazabilirsiniz:

 git clone https://github.com/eqcss/eqcss.git

npm kullanıyorsanız, aşağıdaki komutla projenize EQCSS ekleyebilirsiniz:

 npm install eqcss

HTML'nize EQCSS.js Ekleme

EQCSS'yi indirdikten sonra, onu bir script etiketi ile HTML'nize ekleyebilirsiniz:

 <script src="EQCSS.js"></script>

Bu dosya ( EQCSS.js ), IE 9 ve sonraki sürümleri de dahil olmak üzere mevcut tüm tarayıcılar için destek içerir. IE 8'i desteklemek için birçok başka çoklu dolgu kullanmamız gerekirdi. IE 8'in çoklu dolgu olmadan CSS medya sorgularını bile desteklemediğini unutmayın, bu nedenle orada da eleman sorgularını çalıştırabilmemiz oldukça şaşırtıcı. EQCSS kullanan bir web sitesine IE 8 desteği eklemek için ana eklenti bağlantınızın önüne aşağıdaki bağlantıyı ekleyin:

 <!‐‐[if lt IE 9]><script src="EQCSS‐polyfills.js"></script><![endif]‐‐>

EQCSS'yi Çalıştırma

Varsayılan olarak, EQCSS eklentisi, sayfa yüklendiğinde ve ayrıca medya sorgularına benzer şekilde tarayıcının yeniden boyutlandırıldığını algıladığında bulduğu stilleri hesaplayacaktır. Stilleri istediğiniz zaman yeniden hesaplamak için JavaScript ile EQCSS.apply() manuel olarak da çağırabilirsiniz; bu, sayfadaki içerik güncellendikten sonra faydalı olabilir.

Öğe Sorgusu CSS Yazma

EQCSS.js eklentisi stilleri birkaç farklı şekilde okuyabilir. EQCSS'yi bir HTML sayfasındaki herhangi bir style etiketine dahil edebilirsiniz. EQCSS'yi harici bir CSS stil sayfasına da yazabilirsiniz.

EQCSS destekli kodunuzu CSS'nizden ayrı tutmak istiyorsanız, type olarak text/eqcss olarak ayarlanmış script etiketini kullanarak EQCSS sözdizimini yükleyebilirsiniz. Bunun gibi bir etikete satır içi stiller ekleyebilir veya style.eqcss adlı bir dosya yükleyecek olan <script type=“text/eqcss” src=styles.eqcss></script> ile harici bir .eqcss stil sayfasına bağlantı styles.eqcss .

Bir Eleman Sorgusunun Anatomisi

Stil Kapsamı

Öğe sorguları yazmak için EQCSS'deki sözdizimi, CSS ortam sorgularının biçimlendirmesine çok benzer, ancak @media yerine sorguya @element ile başlıyoruz. Sağlamamız gereken diğer bilgi parçası, bu stillerin uygulanması gereken en az bir seçicidir. <div class=“widget”> adlı bir öğe için yeni bir kapsamı nasıl oluşturacağınız aşağıda açıklanmıştır:

 @element '.widget' { }

Tırnak işaretleri arasındaki öğe (bu durumda .widget ) herhangi bir geçerli CSS seçicisi olabilir. Bu sorgu ile .widget elemanı üzerinde yeni bir kapsam oluşturduk. Kapsam için henüz herhangi bir duyarlı koşul eklemedik, bu nedenle böyle bir sorgudaki herhangi bir stil, kapsamlı öğe için her zaman geçerli olacaktır.

Stilleri bir veya daha fazla öğeye (tek seferde tüm sayfa yerine) kapsama yeteneği olmadan, yalnızca bu öğelere duyarlı sorgular uygulayamazdık. Bu öğe düzeyinde kapsamı oluşturduktan sonra, EQCSS sözdiziminin daha gelişmiş özelliklerini kullanmak kolay hale gelir - örneğin $parent meta seçicisi gibi - çünkü JavaScript'in artık kapsamlandırılmış öğenin parentNode gibi şeyleri hesaplamak için bir referans noktası vardır. öğe. Bu cok büyük!

Doğru, CSS zaten belirtilen öğenin doğrudan çocukları olan öğeleri seçmemize izin veren > ile birlikte bir doğrudan soydan gelen seçici içerir. Ancak CSS şu anda soy ağacında diğer yönde ilerlemenin, üst öğe olarak adlandırılacak başka bir öğe içeren bir öğeyi seçmenin bir yolunu sunmaz. “CSS Seçici Düzey 4” belirtimi artık jQuery'nin :has() seçicisine benzer şekilde çalışan bir :has() seçici içerir, ancak şu anda tarayıcı desteği sıfırdır. Kapsamlı CSS, farklı türde bir üst öğe seçiciyi mümkün kılar.

Artık .widget öğesi bağlamında bir kapsam açtığımıza göre, kendi üst öğesini hedeflemek için onun perspektifinden stiller yazabiliriz:

 @element '.widget' { $parent { /* These styles apply to the parent of .widget */ } }

Herhangi bir öğe sorgusunda kullanılabilecek başka bir özel seçici örneği, önceki ve sonraki kardeş öğeleri temsil eden $prev ve $next seçicileridir. CSS, widget'ımızın bir sonraki kardeşine .widget + * gibi bir seçiciyle ulaşabilse de, CSS'de geriye doğru uzanıp doğrudan başka bir öğeden önce gelen öğeyi seçmenin bir yolu yoktur.

 <section> <div>This will be the previous item</div> <div class="widget">This is the scoped element</div> <div>This will be the next item</div> </section> <style> @element '.widget' { $prev { /* These styles apply to the element before .widget */ } $next { /* These styles apply to the element after .widget */ } } </style>

Öğe Sorguları

Geliştiriciler, tarayıcı görünüm alanının yüksekliğine veya genişliğine dayalı stiller uygulayarak duyarlı tasarım için en sık CSS medya sorgularını kullanır. EQCSS sözdizimi, birçok yeni yanıt koşulu türünü destekler. Yalnızca tarayıcının genişliği ve yüksekliğiyle çalışmak yerine, kaç tane alt öğe içerdiği veya o anda öğede kaç karakter veya metin satırı olduğu gibi kendi özelliklerine göre öğelere uygulanan stiller yazabilirsiniz. .

Kapsamlı stillerinize bu duyarlı koşulları eklemek, medya sorgularını nasıl biçimlendireceğinize benzer: Kontrol etmek istediğiniz her koşul için and (condition: value) eklersiniz. Bu örnekte, herhangi bir .widget öğesinin sayfada en az 500 piksel genişliğinde görüntülenip görüntülenmediğini kontrol edeceğiz.

 @element '.widget' and (min‐width: 500px) { /* CSS rules here */ }

Bir öğe sorgusunun sözdizimi aşağıdaki gibi parçalanır:

• eleman sorgusu @element selector_list [ condition_list ] { css_code }
• seçici listesi " css selector [ "," css selector ]* "
• koşul listesi and ( query_condition : value ) [ "and (" query condition ":" value ")" ]*
• değer number [ css unit ]
• sorgu koşulu min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x min-height | max-height | min-width | max-width | min-characters | max-characters | min-lines | max-lines | min-children | max-children | min-scroll-y | max-scroll-y | min-scroll-x | max-scroll-x
• css birimi % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax % | px | pt | em | cm | mm | rem | ex | ch | pc | vw | vh | vmin | vmax

Başka bir örnek olarak, .widget öğesi 500 piksel genişliğe ulaştığında body öğesini kırmızıya çeviren bir sorgunun nasıl yazılacağı aşağıda açıklanmıştır:

 @element '.widget' and (min‐width: 500px) { body { background: red; } }

.widget belirli bir genişliğe ulaştığında, .widget öğesinin kendisinin değil, body öğesinin değiştiğini unutmayın!

Öğe Sorgu Koşulları

Aşağıda, EQCSS'nin desteklediği yanıt veren koşulların tam listesi bulunmaktadır.

Genişliğe Dayalı Koşullar

• pikseller için min-width demosu, yüzdeler için demo
• pikseller için max-width demosu, yüzdeler için demo

Yüksekliğe Dayalı Koşullar

• pikseller için min-height demosu, yüzdeler için demo
• pikseller için max-height demosu, yüzdeler için demo

Sayıma Dayalı Koşullar

• blok elemanları için min-characters demosu, form girişleri için demo
• blok elemanları için max-characters demosu, form girişleri için demo
• min-lines demosu
• max-lines demosu
• min-children demosu
• max-children demosu

Kaydırma Tabanlı Koşullar

• min-scroll-y demosu
• max-scroll-y demosu
• min-scroll-x demosu
• max-scroll-x demosu

Gerçekten çok boyutlu duyarlı stiller için bu koşulların herhangi bir sayısını öğe sorgularınızda birleştirebilirsiniz. Bu size öğelerin nasıl oluşturulduğu konusunda çok daha fazla esneklik ve kontrol sağlar. Örneğin, görüntülenebilecek 600 pikselden daha az alan olduğunda 15 karakterden fazla olan bir başlığın yazı tipi boyutunu küçültmek için, max‐characters: 15 ve max‐width: 600px 600 piksel için koşulları birleştirebilirsiniz:

 h1 { font‐size: 24pt; } @element 'h1' and (min‐characters: 16) and (max‐width: 600px) { h1 { font‐size: 20pt; } }

Meta Seçiciler

Duyarlı koşullarla kapsamlı stiller yazmaya başladığınızda karşılaşabileceğiniz sorunlardan biri, aynı seçicinin birden çok örneği bir sayfada olduğunda, bu seçiciyi öğe sorgunuzda kullanmanın, o seçicinin tüm örneklerine stilleri uygulayacağıdır. sayfa, bunlardan herhangi biri koşullarla eşleştiğinde. Daha önceki .widget örneklerimizi alarak, sayfada iki widget'ımız olduğunu (belki biri kenar çubuğunda ve diğeri tam genişlikte görüntüleniyor) varsayalım ve eleman sorgumuzu şu şekilde yazdık:

 @element '.widget' and (min‐width: 500px) { .widget h2 { font‐size: 14pt; } }

Bu, sayfadaki .widget öğelerinden herhangi biri en az 500 piksel genişliğinde olduğunda, stilin her iki .widget öğesine de uygulanacağı anlamına gelir. Bu muhtemelen çoğu durumda olmasını istediğimiz şey değildir. Meta seçicilerin devreye girdiği yer burasıdır!

Öğe sorgumuzu oluşturan iki kısım seçici ve duyarlı koşuldur. Bu nedenle, yalnızca sayfadaki hem seçici hem de yanıt veren koşullarla aynı anda eşleşen öğeleri hedeflemek istiyorsak, meta seçiciyi $this kullanabiliriz. Stilin yalnızca min‐width: 500px koşuluyla eşleşen .widget öğelerine uygulanabilmesi için son örneğimizi yeniden yazabiliriz:

 @element '.widget' and (min‐width: 500px) { $this h2 { font‐size: 14pt; } }

Normal CSS'de olmayan bir dizi yeni seçici, EQCSS sözdizimi tarafından desteklenir. İşte tam liste:

• $this demo
• $parent demosu
• $root demosu
• $prev demo
• $next demo

Bu seçiciler yalnızca bir öğe sorgusunda çalışır.

JavaScript ve CSS Arasındaki Portalı Açmak

• eval(') demosu

EQCSS'nin son ve son özelliği en çılgın olanıdır: eval(') . JavaScript'in tüm gücü, CSS'den erişilebilen bu kapıdan geçmektedir. JavaScript, öğelere stiller uygulayabilse de, şu anda :before ve :after sözde öğeler gibi bazı şeylere ulaşmakta zorlanıyor. Peki ya CSS JavaScript'e diğer yönden ulaşabilirse? JavaScript'in CSS özelliklerini ayarlamak yerine, CSS JavaScript'in farkında olabilseydi ne olurdu?

eval(') işte burada devreye girer. İster CSS'nizdeki bir JavaScript değişkeninin değerini kullanın, ister tek satırlık bir JavaScript yürütün ( eval('new Date().getFullYear()') gibi) için herhangi bir JavaScript'e erişebilir ve bunları değerlendirebilirsiniz. eval('new Date().getFullYear()') ), JavaScript'in ölçebileceği tarayıcı ve diğer öğelerle ilgili değerleri belirlemek ( eval('innerHeight') gibi) veya bir JavaScript işlevi çalıştırıp CSS stillerinizde döndürdüğü değeri kullanmak için. İşte bir <footer> öğesinde 2016 çıktısı veren bir örnek:

 @element 'footer' { $this:after { content: " eval('new Date().getFullYear()')"; } }

eval(') içinde $it kullanma

JavaScript'i değerlendirirken, eval(') , $this için stillerin geçerli olduğu aynı öğe olan aktif olarak kapsamlandırılmış öğe bağlamından da çalışır. Kodu yapılandırmanıza yardımcı oluyorsa, kapsamlı öğe için yer tutucu olarak eval(') ile yazılmış JavaScript'te $it kullanabilirsiniz, ancak atlanırsa, aynı şekilde çalışır. Örneğin, içinde "merhaba" kelimesi olan bir div olduğunu varsayalım. Aşağıdaki kod "merhaba merhaba" çıktısı verir:

 <div>hello</div> <style> @element 'div' { div:before { content: "eval('$it.textContent') "; } } </style>

Burada $it , şu anda kapsamlı seçici olduğundan div atıfta bulunur. Ayrıca $it it'i atlayabilir ve aynı şeyi görüntülemek için aşağıdaki kodu yazabilirsiniz:

 @element 'div' { div:before { content: "eval('textContent') "; } }

eval(') , CSS'nin yüklendikten sonra sayfada meydana gelen ölçümlerden veya olaylardan haberdar olmadığı durumlarda yardımcı olabilir. Örneğin, YouTube videolarını gömmek için kullanılan iframe öğeleri belirli bir genişlik ve yükseklikte gelir. CSS'de genişliği auto olarak ayarlayabilseniz de, video mevcut alanı dolduracak şekilde genişlediğinde genişlik ve yükseklik arasındaki doğru en boy oranını korumanın kolay bir yolu yoktur.

Ölçekleme sırasında duyarlı en boy oranlarını korumaya yönelik yaygın bir çözüm, en boy oranını koruması gereken içeriği bir sarmalayıcıya yerleştirmek ve ardından sarmalayıcıya, korumak istediğiniz genişlik/yükseklik oranına dayalı bir değerle dolgu eklemektir. Bu işe yarar, ancak tüm videoların en boy oranını önceden bilmenizi ve duyarlı bir şekilde gömmek istediğiniz her video için daha fazla HTML işaretlemesi (bir sarma öğesi) gerektirir. Duyarlı videoları olan her web sitesinde bunu çarpın ve bu, CSS biraz daha akıllı olsaydı, orada olması gerekmeyecek çok fazla saçmalık.

Belki de duyarlı en boy oranlarına daha iyi bir yaklaşım, her videoyu dolgu olmadan bir sarmalayıcıya yerleştirmeyi ve ardından bulduğu her videonun en boy oranını hesaplayan ve her sarmalayıcıya doğru miktarda dolgu uygulayan bir JavaScript kitaplığı yazmayı içerir.

Peki ya CSS bu ölçümlere doğrudan erişebilseydi? Tüm farklı en boy oranları için CSS'yi tek bir kuralda birleştirmekle kalmayıp, sayfa yüklendikten sonra değerlendirebilirsek, gelecekte ona vereceğimiz herhangi bir videoyu duyarlı bir şekilde yeniden boyutlandıran bir kural yazabiliriz. Ve hepsini herhangi bir sarmalayıcı olmadan yapabilirdik!

Bu gerçek olamayacak kadar iyi görünüyorsa, bunu kontrol edin. EQCSS'de iframe öğelerini duyarlı bir şekilde yeniden boyutlandırarak sarmalayıcı olmadan yazmanın ne kadar basit olduğu aşağıda açıklanmıştır:

 @element 'iframe' { $this { margin: 0 auto; width: 100%; height: eval('clientWidth/(width/height)'); } }

Burada, width ve height , HTML'deki iframe'deki width=“” ve height=“” niteliklerini ifade eder. JavaScript, bize en boy oranını veren (width/height) hesaplamasını yapabilir; ve herhangi bir genişlikte uygulamak için, iframe öğesinin mevcut genişliğini orana bölerdik.

Bu, CSS'nin özlü ve okunaklılığına ve JavaScript'in tüm gücüne sahiptir. Fazladan sarmalayıcı gerekmez, fazladan sınıf yok ve fazladan CSS yok.

Yine de eval(') ile dikkatli olun. Geçmişte CSS ifadelerinin tehlikeli olarak görülmesinin bir nedeni var ve bu fikri denememizin de bir nedeni var. Bunları sayfada kaç öğeye uyguladığınıza veya stilleri ne sıklıkta yeniden hesapladığınıza dikkat etmezseniz, JavaScript gerekenden yüzlerce kez daha fazla çalışmaya başlayabilir. Neyse ki, EQCSS, stilleri manuel olarak yeniden hesaplamak için EQCSS.apply() veya EQCSS.throttle() 'ı çağırmamıza izin verir, böylece stillerin ne zaman güncelleneceği üzerinde daha fazla kontrolümüz olur.

Tehlike Bölgesi!

Çakışan koşullar veya stiller içeren sorgular oluşturursanız başka sorunlar ortaya çıkabilir. EQCSS, CSS gibi, bir özgüllük hiyerarşisi kullanılarak yukarıdan aşağıya okunur. CSS bir bildirim dili olmasına rağmen, bazı gelişmiş özellikler içerir. Bir programlama dili olarak Turing-tamamlayıcı olmaktan sadece birkaç adım ötede. Şimdiye kadar, CSS'de hata ayıklamak oldukça basit bir iş oldu, ancak EQCSS, CSS'yi yalnızca yorumlanmış bir bildirim dili olmaktan çıkarıp, CSS ile tarayıcı arasında ek bir yorumlama katmanıyla dinamik bir stil sayfası diline dönüştürüyor. Bu yeni bölge ile birlikte çeşitli potansiyel yeni tuzaklar geliyor.

İşte, normal CSS medya sorgularının tasarım gereği bağışık olduğu bir şey olan EQCSS'deki bir karşılıklı döngü örneği:

 @element '.widget' and (min‐width: 300px) { $this { width: 200px; } }

Ben buna jekyll: hide; CSS. Ancak sürekli olarak kendini tetikleyen bir stile ek olarak, “çift ters çevrilmiş karşılıklı döngü” dediğimiz, en kötüsü dediğimiz, birbirini tetikleyen birden fazla sorgu yazma olasılığı da vardır:

 @element '.widget' and (min‐width: 400px) { $this { width: 200px; } } @element '.widget' and (max‐width: 300px) { $this { width: 500px; } }

Teorik olarak, bu talihsiz widget, zamanın sonuna kadar 200 ile 500 piksel arasında yeniden boyutlandırılarak bir genişliğe yerleşemeyecek bir döngüde sıkışıp kalacaktı. Bunun gibi durumlar için, EQCSS kuralları değerlendirildikleri sıraya göre basitçe hesaplar, kazananı ödüllendirir ve devam eder. Bu kuralların göründüğü sırayı yeniden düzenlerseniz, eşit özgüllükte olmaları durumunda ikinci stil her zaman kazanır.

Bazı insanlar döngüler (hatta çift ters çevrilmiş karşılıklı döngüler) oluşturma yeteneğinin bir tasarım kusuru olduğunu söylüyor, ancak döngülerin mümkün olmasını önlemek için, EQCSS'nin gücünü çoğunu kaldıracak şekilde sınırlamanız gerekir. sözdiziminin sağladığı değer. Öte yandan, JavaScript'te sonsuz döngüler oluşturmak çok kolaydır, ancak bu dilin bir kusuru olarak görülmez - gücünün kanıtı olarak görülür! Öğe sorguları ile aynıdır.

Öğe Sorgularında Hata Ayıklama

Şu anda, hata ayıklama öğesi sorguları, bize stilleri sayfada hesaplandıkları şekliyle göstermek için web denetçisi gibi araçlara sahip olmadan önce, medya sorgularında hata ayıklamaya benziyor. Şimdilik, hata ayıklama ve öğe sorguları geliştirme, geliştiricinin hangi duyarlı davranışın olması gerektiğine dair zihinsel bir model sürdürmesini gerektirir. Gelecekte, EQCSS'ye duyarlı geliştirici araçları oluşturmak mümkün olabilir, ancak şu andan itibaren, tüm büyük tarayıcılardaki geliştirici araçları, yalnızca EQCSS'nin sayfadaki öğelere zaten uyguladığı stillerin farkındadır ve farkında değillerdir. EQCSS'nin izlediği duyarlı koşullar.

Öğe Sorgularıyla Nasıl Tasarım Yapılır?

Öğe sorgularından yararlanmanın en basit yolu, medya sorgularını kullanan mevcut tasarımları öğe sorgularına dönüştürmek, öğeleri ve bunların duyarlı stillerini tek bir düzenden "özgürleştirmek" ve bu kodun diğer sayfalarda ve projelerde yeniden kullanılmasını kolaylaştırmaktır. Aşağıdaki medya sorgusu ve öğe sorgusu aynı anlama gelebilir:

 footer a { display: inline-block; } @media (max‐width: 500px) { footer a { display: block; } }

 footer a { display: inline-block; } @element 'footer' and (max‐width: 500px) { $this a { display: block; } }

Aradaki fark, orijinal örnekte, altbilgi bağlantılarının tarayıcı en az 500 piksel genişliğinde olana kadar display: block olarak kalmasıdır. Öğe sorgularını kullanan ikinci örnek, yalnızca footer öğesi tam genişlikteyse aynı görünür.

Bu stili orijinal medya sorgusundan kurtardıktan sonra, artık altbilgiyi herhangi bir genişlikteki bir kaba yerleştirebilir ve altbilginin duyarlı stilin uygulanması gerektiğinde (yani, 500 pikselden daha dar olduğunda), altbilginin uygulanacağından emin olabiliriz. uygulamalı.

1. Hedef belgenin HTML'sinde EQCSS.js mevcut olduğundan emin olun.
2. CSS'de @element @media değiştirin.
3. Her @element sorgusunun kapsamına bir CSS seçici ekleyin.
4. İsteğe bağlı: Kapsamlı öğenin oluşumlarını öğe sorgularında $this ile değiştirin.

Dönüştürdüğünüz tasarım bileşeni orijinal olarak tarayıcının görüntü alanının tam genişliğini kullanarak görüntülenecek şekilde tasarlanmadıysa, öğe sorgularına dönüştürdükten sonra kesme noktalarında ince ayar yapmanız gerekebilir.

Kilitlenmeyi Önlemek

EQCSS stilleri yazma deneyimi, normal CSS yazma deneyimine benzer: En sevdiğiniz CSS özelliklerinin ve tekniklerinin tümü, yalnızca birlikte yeni şekillerde çalışmalarına yardımcı olan bazı ek özelliklerle birlikte, hala oradadır. EQCSS, tarayıcıya standart CSS çıktısı verdiği için, tarayıcınızın yerleşik desteğine sahip herhangi bir CSS özelliği, EQCSS ile kullanıldığında çalışacaktır. Öğe sorguları ve kapsamlı stiller gibi bir gün özellikler CSS'de belirtilirse ve tarayıcılarda desteklenirse, bunları hemen EQCSS kodunuzda kullanmaya başlayabilirsiniz, ancak yine de tarayıcının kullanmadığı diğer özellikler için EQCSS'ye güvenebilirsiniz. yine de yerel olarak destekleyin.

EQCSS sözdizimini hem doğrudan CSS'de hem de kendi komut dosyasında text/eqcss için, CSS yerel öğe sorguları için bir sözdizimi geliştirirse, yine de EQCSS'yi komut dosyası olarak yükleyebilir ve çakışmaları önleyebilirsiniz. .

İleriye dönük olarak, tarayıcı geliştiricilerinin şu anda denemekte olduğu bir çözüm, eklenti geliştiricilerinin CSS'yi tarayıcının kendisine destek eklemek gibi yeni yollarla genişletmesine erişim sağlayacak olan Houdini'dir. Bir gün, EQCSS sözdizimini yorumlayan ve bu özellikleri tarayıcılara mevcut JavaScript kitaplığının izin verdiğinden daha doğrudan ve performanslı bir şekilde getiren daha verimli eklentiler yazmak mümkün olabilir.

Öyleyse, Hala Medya Sorguları Kullanmalı mıyız?

Evet, öğe sorguları, stilleri olan öğeleri hedeflemek için birçok yeni ve heyecan verici yol sağlasa da, medya sorguları (sınırlı olsa da) tarayıcıda her zaman, hesaplamak için JavaScript'e dayanan bir stile göre daha hızlı çalışır. Bununla birlikte, CSS medya sorguları, ekranlar için HTML'yi biçimlendirmekten daha fazlası içindir. CSS medya sorguları, baskı tabanlı sorguları ve web sitelerinin bilgileri görüntülemesinin diğer yollarını da destekler. EQCSS, baskı stilleri gibi şeyler için medya sorguları ile birlikte kullanılabilir, bu nedenle medya sorgusunu kullanımdan kaldırmaya gerek yoktur, çünkü artık eleman sorguları da kullanılabilir!

²⁰ ⁄ ₂₀ Vizyon ile Tasarım

CSS'nin geleceği için yapabileceğimiz en iyi şey, bugün mümkün olduğunca bu fikirleri denemektir. Bu özellikler hakkında hiçbir beyin fırtınası ve teori oluşturmak, onları gerçekten uygulamaya ve kullanmaya çalışmak, onları faydalı ve güçlü kılan teknikleri keşfetmek kadar faydalı olmayacaktır.

EQCSS.js, öğe sorguları için bir çözüm sağlamanın yanı sıra, umarım CSS'yi genişletmede diğer deneyler için bir platform görevi görür. If you have an idea for a new responsive condition, a new CSS property or a new selector to use in your code, forking EQCSS.js and modifying it to include your idea can get you most of the way there with little effort.

Modular Design

In designing layouts using element queries, the biggest shift is learning how to stop viewing the DOM from the top down and from the perspective of only the root HTML element, and to start thinking about individual elements on the page from their own perspectives within the document.

The old paradigms of “desktop-first” and “mobile-first” responsive design aren't relevant any longer — the new way of building layouts approaches design “element-first.” Using element queries enables you to work on the individual parts that make up a layout, in isolation from one another, styling them to a greater level of detail. If you are using a modular approach for your back-end code already but have so far been unable to package your CSS with your modules because of the difficulties of styling with media queries alone, then element queries will finally allow you to modularize your styles in the same way.

Thinking Element-First

Element-first design is in the same spirit as the atomic design principle but looks different in practice from how most people have implemented atomic design in the past.

For example, let's say you have some HTML like the following, and the desired responsive behavior can be explained as, “The search input and button are displayed side by side until the form gets too narrow. Then, both the input and the button should be stacked on top of each other and displayed full width.”

 <form> <input type=search> <input type=button value=Search> </form>

Desktop-First Approach

In a desktop-first mindset, you would write styles for the desktop layout first and then add responsive support for smaller screens.

 input { width: 50%; float: left; } @media (max‐width: 600px) { input { width: 100%; float: none; } }

Mobile-First Approach

In a mobile-first mindset, you would design the mobile view first and add support for the side-by-side view only when the screen is wide enough.

 input { width: 100%; } @media (min‐width: 600px) { input { width: 50%; float: left; } }

Element-First Approach

In the first two examples, the media breakpoint was set to 600 pixels, and not because that's how wide the inputs will be when they switch. Chances are, the search input is probably inside at least one parent element that would have margins or padding. So, when the browser is 600 pixels wide, those inputs might be somewhere around 550 or 525 pixels wide on the page. In a desktop-first or mobile-first approach, you're always setting breakpoints based on the layout and how elements show up within it. With an element-first layout, you're saying, “I don't care how wide the browser is. I know that the sweet spot for where I want the inputs to stack is somewhere around 530 pixels wide.” Instead of using a media query to swap that CSS based on the browser's dimensions, with element-first design, we would scope our responsive style to the form element itself, writing a style like this:

 input { width: 100% } @element 'form' and (min‐width: 530px) { $this input { width: 50%; float: left; } }

The code is similar to that of the two previous methods, but now we are free to display this search input anywhere — in a sidebar or full width. We can use it in any layout on any website, and no matter how wide the browser is, when the form itself doesn't have enough room to display the inputs side by side, it will adapt to look its best.

Resources For Getting Started

EQCSS-Enabled Template

 <!DOCTYPE html> <html> <head> <meta charset="utf‐8"> <title></title> <style></style> </head> <body> <!‐‐[if lt IE 9]><script src="https://elementqueries.com/EQCSS‐polyfills.min.js"></script><![endif]‐‐> <script src="https://elementqueries.com/EQCSS.min.js"></script> </body> </html>

Demos

• Responsive Aspect Ratio
• Sticky Scroll Header
• Blockquote Style
• Takvim
• Content Demo
• Counting Children Demo
• Date Demo
• Zastrow-style Element Query Demo Demo
• Flyout Demo
• Headline Demo
• Media Player Demo
• Message Style Demo
• Modal Demo
• Nav Demo
• Parent Selector Demo
• Pricing Chart Demo
• Responsive Tables Demo
• Scroll-triggered Blocker Demo
• Signup Form Demo
• Testimonials Block Demo
• Tweet-Counter Demo
• JS Variables Demo
• Responsive Scaling Demo
• Geometric Design Demo
• Responsive Order Form
• Element Query Grid
• JS Functions in CSS
• Responsive Content Waterfall

Daha fazla okuma

You can find the EQCSS project on GitHub, demos, documentation and articles on the EQCSS website. An ever-growing number of Codepens use EQCSS, and you can create your own pen by forking the batteries-included template that comes hooked up with EQCSS. You can also play with the EQCSS tool that I built to preview if your EQCSS code is working as expected.

Happy hacking!