bu “sistem-ui” bölümü CSS Yazı Tipleri Modülü Düzey 4 spesifikasyonu, bir system-ui geliştiricilerin yerleşik, turbo için optimize edilmiş, yerelleştirilmiş, mega yüksek kaliteli, indirme gerektirmeyen, varsayılan işletim sistemi yazı tipini doğrudan sitelerinde ve uygulamalarında kullanmalarına olanak tanıyan yazı tipi anahtar sözcüğü.
body {
font-family: system-ui;
}
Bu tipografi seçimi, “bu kullanıcının geçerli yerel ayarı için varsayılan sistem yazı tipini kullan” demeye benzer.
macOS’ta, system-ui yazı tipi, bir tasarım ekibinin incelediği, test ettiği ve… yakın zamanda yükselttiği bir yazı tipi olan San Francisco’dur! İlk önce Catalina’daki yeni heyecan verici değişken yazı tipi özelliklerisonra birkaçını ele alacağız hatalar ve Chromium mühendislerinin bunları nasıl çözdüğü.
Bu gönderi, değişken yazı tiplerine zaten aşina olduğunuzu varsayar. Değilse, web’deki değişken yazı tiplerine giriş bölümüne ve aşağıdaki videoya göz atın.
Tarayıcı Uyumluluğu #
Yazma sırasında, system-ui Chromium (56’dan beri), Edge (79’dan beri), Safari (11’den beri) ve Firefox’tan (43’ten beri) destek alıyor, ancak -apple-system anahtar kelime. Görmek Değişken yazı tiplerini kullanabilir miyim? güncellemeler için.
Yeni güçler #
Catalina’nın sistem yazı tipine getirdiği yeni yetenekler, Chromium 83’ten itibaren web geliştiricilerinin kullanımına sunuldu. system-ui şimdi yazı tipi daha değişken ayarlara sahip: optik boyutlandırma ve 2 benzersiz ağırlık ayarı:
Mojave
h1 {
font-family: system-ui;
font-weight: 700;
font-variation-settings:
'wght' 750
;
}
Katalina
h1 {
font-family: system-ui;
font-weight: 700;
font-variation-settings:
'wght' 750,
'opsz' 20,
'GRAD' 400,
'YAXS' 400
;
}
Mojave’de, system-ui yalnızca değişken bir yazı tipidir wght ayarlar. Sırasında system-ui Catalina’da değişken bir yazı tipi vardır. wght, opsz, GRADVe YAXS ayarlar.
Bana bazı düzgün aşamalı geliştirme tasarım fırsatları gibi görünüyor! İsterseniz sistem yazı tipinin inceliklerini gerçekten araştırın.
wght #
Arasında bir yazı tipi ağırlığını kabul eder 0 Ve 900 ve tüm karakterlere eşit olarak uygulanır.
/* 0-900 */
font-variation-settings: 'wght' 750;
opsz #
Optik boyutlandırma, karakter aralığına veya harf aralığına benzer, ancak boşluk matematik yerine insan gözü tarafından yapılır. bir değeri 19 veya altı, metin ve gövde kopyası aralığı için tasarlanmıştır; 20 veya üstü, ekran başlıklarını ve başlıklarını boşluk bırakmak içindir.
/* 19 or 20 */
font-variation-settings: 'opsz' 20;
GRAD #
Ağırlığa benzer, ancak yatay boşluklara dokunmadan. arasındaki değerleri kabul eder. 400 Ve 1000.
/* 400-1000 */
font-variation-settings: 'GRAD' 500;
YAXS #
Glifi dikey olarak uzatır. arasındaki değerleri kabul eder. 400 Ve 1000.
/* 400-1000 */
font-variation-settings: 'YAXS' 500;
seçenekleri birleştirmek #
Birkaç satırlık CSS ile, yazı tipi ayarlarında ince ayar yaparak kendi tercihimize göre bir kalın yazı yazabilir veya diğer ilginç kombinasyonları deneyebiliriz:
font-weight: 700;
font-weight: bold;
font-variation-settings: 'wght' 750, 'YAXS' 600, 'GRAD' 500, 'opsz' 20;
Ve tıpkı bunun gibi, macOS’taki Chromium kullanıcıları, yükseltilmiş, özel 750 ağırlığınızı bazı eğlenceli ayarlarla görüyor 👍
Oyun alanı #
Tıklamak Düzenlemek için Remix Glitch’in düzenlenebilir bir kopyasını almak için aşağıdaki Glitch’te ve ardından yenisini düzenleyin font-variation-settings yazı tipinizi nasıl etkilediğini görmek için seçenekler. Bu Glitch’in yalnızca bir macOS Catalina cihazı kullanıyorsanız çalışacağını unutmayın.
macOS 10.15, sistem yazı tipine yeni özellikler ekledi ve macOS 10.15’te zorlu system-ui hata, Chromium hata izleyicisine kaydedildi. Acaba akrabalar mı!?
Ek: system-ui gerileme #
Bu hikaye farklı bir hatayla başlıyor: #1005969. Bu, macOS 10.15’e karşı bildirildi çünkü system-ui yazı tipi aralığı dar ve sıkışık görünüyordu.
Arka plan #
macOS 10.14’te, boyut büyüdüğünde veya küçüldüğünde paragraflarınızın veya başlıklarınızın farklı görünen bir yazı tipine nasıl “kırpıldığını” hiç fark ettiniz mi?
Mojave’de (macOS 10.14), system-ui yazı tipi, hedef yazı tipi boyutuna bağlı olarak iki yazı tipi arasında geçiş yaptı. Metin altındayken 20px, macOS “San Francisco Metin” kullandı. metin ne zamandı 20px veya üzeri, macOS “San Francisco Display” kullandı. Optik boyutlandırma statik olarak iki ayrı yazı tipine yerleştirildi.
Catalina (macOS 10.15), San Francisco için yeni bir birleşik değişken yazı tipi gönderdi. Artık “Metin” ve “Ekran”ı yönetmek yok. Ayrıca yeni varyasyon ayarını da kazandı opsz daha önce açıklanan
h1 {
font-variation-settings: 'opsz' 20;
}
Ne yazık ki, varsayılan opsz yeni Catalina yazı tipindeki değer: 20ve Chromium mühendisleri başvurmaya hazır değildi opsz sistem yazı tipine. Bu, çok dar görünen daha küçük boyutlara yol açtı.
Bunu düzeltmek için Chromium’un uygulanması gerekiyordu opsz sistem yazı tipine doğru şekilde. Yol açtı Sayı #1005969 sabitleniyor Zafer! Yoksa…?
Henüz bitmedi #
İşin zorlaştığı yer burası: Chromium uygulandı opsz ama bir şeyler hala doğru görünmüyordu. Mac’teki sistem yazı tiplerinde ek bir yazı tipi tablosu bulunur. trak, bu da yatay aralığı değiştirir. Düzeltme üzerinde çalışırken Chromium mühendisleri, macOS’ta bir bilgisayardan yatay ölçümler alırken bunu fark ettiler. CTFontRef nesne, trak metrikler zaten metrik sonuçlarına dahil ediliyordu. Chromium’un şekillendirme kitaplığı HarfBuzz metriklere ihtiyaç duyar trak değerler henüz hesaba katılmamıştır.
dahili olarak, kayak (grafik kitaplığı, aynı adlı yazı tipini değil) hem CGFontRef gelen sınıf CoreGraphics ve CTFontRef gelen sınıf CoreText. Bu nesneler arasındaki gerekli dahili dönüşümler nedeniyle (geriye dönük uyumluluğu korumak ve her iki sınıfta da gerekli API’lere erişmek için kullanılır), Skia belirli durumlarda ağırlık bilgilerini kaybeder ve kalın yazı tipleri çalışmayı durdurur. Bu takip edildi Sayı #1057654.
Skia’nın hala macOS 10.11’i desteklemesi gerekiyor çünkü Chromium onu hâlâ destekliyor. 10.11’de “San Francisco Text” ve “San Francisco Display” yazı tipleri değişken yazı tipleri bile değildi. Bunun yerine, her biri mevcut her ağırlık için ayrı bir yazı tipi ailesiydi. Bir noktada glif kimlikleri birbiriyle senkronize olmadı. Dolayısıyla, Skia “San Francisco Text” ile metin şekillendirme (metni çizilebilecek gliflere dönüştürme) yaptıysa, “San Francisco Display” ile çizilirse anlamsız olur ve bunun tersi de geçerlidir. Ve Skia az önce farklı bir boyutta istese bile, macOS diğerine geçebilir. Her zaman yazı tiplerinden birini kullanmak ve onu ölçeklendirmek mümkün olmalıdır (daha büyük bir boyut istemek yerine onu büyütmek için bir matris kullanarak), ancak CoreText sbix (renkli emoji) gliflerini yukarı (yalnızca aşağı) ölçeklendirmeyeceği bir sorunu var. Bundan biraz daha karmaşık. CoreText aslında matris uygulamasından sonra dikey boyutu kaplıyor gibi görünüyor, bu da emojiyi 45 derecelik açılarda çizememeyle ilgili gibi görünüyor. Her durumda, emojinizin büyük gösterilmesini istiyorsanız, büyük bir sürüm elde etmek için yazı tipinin bir kopyasını almanız gerekir.
Bu nedenle, kopyalarını oluşturmak için CTFont Chromium, aynı temel yazı tipi verilerinin kullanılmasını sağlarken dahili olarak farklı boyutlardaki nesneleri çekti. CGFont Kapalı CTFontardından yeni bir CTFont dan CGFont (CGFont nesneler boyuttan bağımsızdır, sihirli anahtarlama CoreText seviye). Bu, 10.154’e kadar iyi çalıştı. 10.15’te bu gidiş-dönüş çok fazla bilgi kaybederek ağırlık sorunuyla sonuçlandı. Flutter ağırlık sorununu fark etti ve yenisini oluşturmak için yeniden boyutlandırma için alternatif bir düzeltme yapıldı. CTFont doğrudan orijinalinden CTFont eski ama belgelenmemiş bir özniteliği kullanarak doğrudan optik boyutu kontrol ederken CoreText. Bu, 10.11’de her şeyin çalışmasını sağlar ve diğer sorunları giderir (optik boyutu açıkça varsayılan değere ayarlamak gibi).
Ancak, bu daha fazlasını korur CoreText Yazı tipinde ‘sihir’. Bunlardan biri, glif ilerlemelerini sadece bir şekilde değiştirmekten başka bir şekilde değiştirmesi gibi görünüyor. trak tablo (Chromium’un zaten başka bir belgelenmemiş öznitelik aracılığıyla bastırmaya çalıştığı uygulama).
CGFont bu ‘sihrin’ hiçbirini yapmaz, bu yüzden belki Chromium CGFont Kapalı CTFont ve sadece avans almak için mi kullanacaksınız? Ne yazık ki bu işe yaramaz çünkü CoreText yazı tipleriyle başka şekillerde de uğraştığı bilinmektedir. Örneğin, küçük emojiyi gerçekte istediğinizden biraz daha büyük yapar (boyutlarını biraz büyütür). CGFont bunu bilmiyor, bu yüzden tek bir boyutta ölçeceğiniz için sbix tabanlı emojiniz birbirine çok yakın olur. CoreText onları bir miktar daha büyütürdü. Chromium bunu istiyor CTFont ilerler, ancak onları izlemeden ve tercihen başka herhangi bir dalga geçmeden ister.
Boşluk sorununun düzeltilmesi, birbiriyle bağlantılı bir dizi Blink ve Skia düzeltmesi gerektirdiğinden, Chromium mühendisleri sorunu çözmek için “geri dönüş” yapamadılar. Chromium mühendisleri ayrıca Skia’da yazı tipiyle ilgili bir kod yolunu değiştirmek için farklı bir yapı bayrağı kullanmayı denedi; bu, kalın yazı tipleri sorununu düzeltti, ancak boşluk sorununu geriletti.
Çözüm #
Sonunda, elbette Chromium her iki şeyi de düzeltmek istedi. Chromium, yatay ölçüleri doğrudan sistem yazı tipinin yazı tipi tablolarındaki ikili verilerden almak için artık HarfBuzz yerleşik yazı tipi OpenType yazı tipi ölçüleri işlevlerini kullanmaya başvuruyor. Bunu kullanarak, Chromium yan adım atıyor CoreText ve Skia, yazı tipinde bir trak tablo (emoji yazı tipi olduğu durumlar hariç).
bu arada hala var Skia Sayı #10123 bunu tamamen Skia’da düzeltmeyi izlemek ve oradan geçen geçerli düzeltme yerine sistem yazı tipi ölçümlerini oradan almak için Skia’yı kullanmaya geri dönmek HarfBuzz.