Wielki błąd w zapytaniu o media CSS
Opublikowany: 2017-05-15Czy kiedykolwiek czułeś się dziwnie, gdy wszyscy wokół ciebie robią coś, co zwykle uważasz za złe [lub przynajmniej niezupełnie idealne], ale wydaje się, że nikt nie chce nic powiedzieć z tego czy innego powodu? To bardzo dziwne uczucie widzieć, jak wszyscy robią najlepsze wrażenie nieszczęsnego obserwatora. Przypomina mi to starą bajkę „Nowe szaty cesarza”.
Zawsze czułem się w ten sposób w przypadku zapytań o media CSS. Dlaczego wszyscy tak po prostu akceptują technologię, która wydaje się nie wykonywać swojej pracy? Dlaczego jako społeczność nie zebraliśmy się razem i nie ulepszyliśmy jej w rzeczywisty i znaczący sposób? Dlaczego nie wymyśliliśmy czegoś lepszego?
Obecnie zapytania o media CSS są po prostu podstawą funkcjonalnego projektowania stron internetowych. Ale nigdy nie został zaprojektowany do tego, do czego wszyscy go dzisiaj używają, a dowodem na to jest praktyka. Nadal często natykam się na strony internetowe, gdy korzystam z tabletu, który na pierwszy rzut oka wydaje się dobrze zaprojektowany, ale po prostu wygląda i czuje się niepewnie, gdy przetestujesz je.
Jest coś fundamentalnie złego w tym podejściu do responsywnego projektowania stron internetowych, którym po prostu jeszcze nie zajęliśmy się właściwie, i chciałbym być jednym z niewielu głosów, które wezwały cesarza za jego nagość w tym przypadku. Jednak na szczęście w dzisiejszych czasach cieszę się, że prawdopodobieństwo spalenia na stosie jest prawie zerowe za posiadanie tego alternatywnego punktu widzenia.
Co jest nie tak z zapytaniami o media CSS?
Zapytania o media CSS zostały zaprojektowane do czegoś, ale to nie jest responsywne projektowanie stron internetowych. Opierając się na moim doświadczeniu, oto siedem (7) dużych problemów, które napotkałem, próbując użyć ich do pracy ze stronami internetowymi:
1. Nie intuicyjne:
„Zapytania o media CSS są intuicyjne”, powiedział żaden projektant stron internetowych. Sposób, w jaki definiujesz zapytanie o media, jest dość prosty, ale nie zawsze jest do końca jasne, jak to będzie wyglądać w prawdziwych przeglądarkach, na prawdziwych urządzeniach i w niezliczonych scenariuszach.
@media only screen and (minimalna szerokość: 320px) i (maksymalna szerokość: 480px) {
/** Reguły CSS tutaj **/
}
Powyższy kod dotyczy widocznego obszaru, gdy ma on od 320 do 480 pikseli. Jednak nie jest to dokładnie ostateczne [lub intuicyjne], kiedy chcesz zrobić coś bardziej konkretnego, na przykład zastosować regułę stylu, gdy urządzenie jest tabletem w trybie poziomym. Nie jest niemożliwe, aby ustawić zapytanie medialne, aby to zrobić, ale zdecydowanie nie jest to intuicyjne – ani ostateczne.
2. Ograniczona warunkowość:
Zapytania o media CSS są dynamiczne i umożliwiają definiowanie instrukcji warunkowych w CSS. Na przykład, jeśli rzutnia znajduje się między tym a tamtym, zrób to drugie. Jednak ograniczasz się głównie do kwestii rzutni i istnieje wiele innych warunkowych scenariuszy, które miałyby sens w nowoczesnym projektowaniu stron internetowych.
Załóżmy, że tworzysz progresywną aplikację internetową. Są chwile, kiedy przydałoby się inaczej stylizować niektóre elementy interfejsu użytkownika w zależności od systemu operacyjnego. Na przykład w przypadku urządzeń z systemem iOS zwykle znajduje się pasek kart na dole, podczas gdy w przypadku Androida jest odwrotnie. A więc, jak dokładnie ma to działać z zapytaniami o media CSS?
Nie możesz, ponieważ CSS media kwerendy nie są zbudowane z żadną funkcją, która by Ci na to pozwoliła. Poza tym zdarza się, że istnieje wiele innych dostosowań, które być może trzeba będzie wprowadzić za pomocą CSS, ale zapytania o media nie są opcją, gdy potrzebujesz różnych stopni prostych do zaawansowanych warunkowości.
3. Nie rozszerzalny natywnie:
Zapytania o media CSS to funkcja wypiekana w przeglądarce. Oznacza to, że nie jest natywnie rozszerzalny. Innymi słowy, nie można dodawać dodatkowych i ulepszonych możliwości do zapytań o media CSS natywnie za pośrednictwem interfejsu CSS.
Nawet jeśli nowe funkcje zapytań o media CSS zostaną zatwierdzone przez [długo cierpliwy] proces standardów internetowych, nadal potrzeba czasu, zanim te funkcje staną się dostępne ze względu na wszechobecność. Ponadto nie każda dodana funkcja może być dla Ciebie przydatna, więc musisz znaleźć inny sposób rozwiązania konkretnego wyzwania, jeśli nie otrzymasz tego, czego chcesz.
Oczywiście istnieje sposób na rozszerzenie CSS, ale musisz naprawdę dobrze znać JavaScript, a nie jest to proces praktyczny dla większości projektantów stron internetowych.
4. Nie nadaje się do modernizacji:
Niektórym może trudno w to uwierzyć, ale zanim pojawiły się urządzenia mobilne, istniało wiele stron internetowych i żadna z nich nie była przyjazna dla urządzeń mobilnych. W rezultacie te witryny z ery komputerów stacjonarnych musiały zostać uaktualnione.
Niestety zapytania o media CSS nie są zbyt dobrą opcją do tego zadania. Ponieważ te witryny zostały zbudowane, zanim urządzenia mobilne stały się odpowiednie, wiele z nich ma elementy projektu, które nie nadają się do projektowania witryn responsywnych, np. paski boczne, układy oparte na tabelach, zawartość z zakładkami itp. Ponadto znaczna część tych witryn jest zbudowany w oparciu o system zarządzania treścią (CMS), taki jak WordPress, Drupal, Magento itp., a skuteczna integracja zapytań o media CSS [front-end] z zaplecza jest niezwykle trudna lub prawie niemożliwa do skoordynowania.
Musiałem zmodernizować strony internetowe obsługiwane przez Magento Enterprise, WordPress i takie, które używały niestandardowego CMS opartego na Coldfusion, a wszystkie projekty byłyby wręcz niemożliwe przy użyciu zapytań o media CSS [co próbowali wszyscy moi klienci przed skorzystaniem z naszej alternatywy zbliżać się].
5. Niewydajny kod:
Korzystanie z zapytań o media CSS, aby strona internetowa była responsywna, wymaga mnożenia kodu na znaczną skalę. Ze względu na sposób, w jaki te dyrektywy działają [z punktami przerwania], musisz zdefiniować indywidualne reguły stylu w każdym bloku zapytania o media.
sekcja {szerokość: 960px;}
/* Portret */
@media only screen and (min-device-width: 320px) and (max-device-width: 480px) and (-webkit-min-device-pixel-ratio: 2) and (orientacja: portret) {
sekcja {szerokość: 100%}
}
/* Krajobraz */
@media only screen and (min-device-width: 320px) and (max-device-width: 480px) and (-webkit-min-device-pixel-ratio: 2) and (orientacja: pozioma) {
sekcja {szerokość: 100%;}
} Podczas pisania powyższego kodu moim pierwotnym zamiarem było sprawienie, aby elementy <section> na mojej stronie były płynne [szerokość 100%] na wszystkich urządzeniach mobilnych. Ponieważ jednak nie mam natywnej możliwości wykrywania urządzeń, muszę iść na kompromis i zdefiniować regułę stylu w każdym bloku zapytań o media CSS zorientowanym na urządzenia mobilne, aby upewnić się, że nowa właściwość będzie miała zastosowanie we wszystkich odpowiednich scenariuszach.
Oznacza to, że sprawność funkcjonalna kaskady arkuszy stylów i dobre zasady rozwoju „ Do-not-repeat-Yourself ” muszą zejść na dalszy plan.
6. Zwiększa złożoność przepływu pracy:
Zapytania o media CSS obsługują tylko bardzo specyficzny aspekt responsywnego projektowania stron internetowych, który prawie całkowicie koncentruje się na zmianie rozmiaru układu. Ergo, aby zrobić coś więcej, musisz polegać na JavaScript, aby nadrobić różnicę. Wprowadza to dodatkowe wymagania edukacyjne dotyczące kodu i narzędzi.
Ponadto nieokreślony sposób, w jaki [media kwerendy] obsługuje punkty przerwania, oznacza, że musisz poświęcić więcej czasu [i pieniędzy] na testowanie swoich stron internetowych na wielu urządzeniach wirtualnych i/lub fizycznych, aby upewnić się, że wszystko działa zgodnie z pierwotnym zamierzeniem . I musisz wszystko ponownie przetestować, gdy wprowadzisz jakiekolwiek znaczące zmiany w swoim układzie.
Dzięki prostemu i celowemu działaniu, jakim jest użycie zapytań o media CSS, znacznie zwiększasz liczbę kroków wymaganych do zbudowania nowoczesnej strony internetowej.
7. Pogarsza wydajność:
Ze względu na sposób, w jaki działają zapytania o media CSS, będziesz potrzebować znacznie więcej kodu CSS niż w innym przypadku, aby Twoja witryna była responsywna/przyjazna dla urządzeń mobilnych. Według danych HTTPArchive.org rozmiary plików CSS wzrosły o 114% w ciągu ostatnich pięciu lat. W tym samym okresie wzrost rozmiarów plików HTML osiągnął około 53%.
Ta szczególna sytuacja ma wpływ na wydajność Twojej witryny, ponieważ po zaimplementowaniu zapytań o media CSS [w kontekście responsywnego projektowania stron internetowych] z pewnością będzie wolniejsza niż kiedykolwiek wcześniej, szczególnie w przypadku urządzeń mobilnych korzystających z mniej niż idealnych mobilnych sieci szerokopasmowych.
Poza kwestią zwiększonych rozmiarów plików, w zapytaniach o media CSS nie ma żadnego wewnętrznego mechanizmu, który faktycznie poprawiałby wydajność Twojej strony internetowej. W tym celu będziesz musiał wykorzystać zaawansowane techniki JavaScript, aby włączyć te ulepszenia.
Dlaczego nadal tego używamy?
Gdybym spytał, jaki procent witryn używa zapytań o media CSS, jaka byłaby Twoja odpowiedź? Biorąc pod uwagę cały stres, jaki projektanci stron internetowych musieli znosić przez lata, można by pomyśleć, że prawdopodobnie już pokonaliśmy garb adopcyjny, ale bardzo się mylisz.
Odsetek witryn korzystających z zapytań o media CSS w całej sieci wynosi około 0,2%. Dla porównania, odsetek witryn korzystających z jQuery wynosi 18%. Oznacza to, że 90 razy częściej trafisz na stronę internetową obsługiwaną przez jQuery niż na stronę responsywną [nie licząc tych, które są obiema wersjami].
Dlaczego zestaw narzędzi oparty na podstawowej technologii [JavaScript], który niektórzy ludzie wydają się uważać za skomplikowany i zbyteczny, miałby tak daleko wyprzedzać ten, który wydaje się mniej złożony [CSS] i ma rozwiązać prawdopodobnie ważniejszy problem [przyjazność dla urządzeń mobilnych] ? Oczywiście jest tu coś poważnie nie tak, co utrudnia adopcję i należy się tym zająć.
Zapytania o media CSS znalazły drogę do przeglądarek internetowych, aby poradzić sobie z konkretnym wyzwaniem, ale następnie zostały opracowane tak, aby dźwigać na swoich barkach cały ciężar responsywnego projektowania stron internetowych. To trochę jak ćwiczenie do recitalu trzeciej klasy na flecie prostym, po czym w magiczny sposób zostaje się przeniesionym do Royal Albert Hall, by zagrać solo na puzonie Mesjasza Haendla; Nie fair!
Biorąc pod uwagę wszystkie wyzwania współczesnego projektowania stron internetowych, niezwykle zaskakujące jest to, że wciąż zajmujemy się tą branżą zapytań o media. To za mało, by poradzić sobie z niektórymi ważnymi problemami ze spuścizną, oprócz kilku nowych w nowych dziedzinach, takich jak progresywne projektowanie aplikacji internetowych. W związku z tym myślę, że nadszedł czas, abyśmy wymyślili alternatywę. Ale co by to było dokładnie?
Jakie jest rozwiązanie?
Rozwiązanie tego wszystkiego jest naprawdę bardzo proste: JavaScript. Teraz, zanim podniesiesz te widły, daj mi szansę wyjaśnić.
JavaScript jest jedynym składnikiem trójcy HTML5, w którym rozszerzalność nie jest brzydkim słowem. Nie możesz rozszerzyć znaczników HTML przy użyciu większej ilości kodu HTML, a na pewno nie możesz rozszerzyć CSS natywnie za pomocą CSS. Możesz jednak rozszerzyć JavaScript natywnie za pomocą JavaScript, a nawet zrobić to samo dla CSS.
Manipulowanie CSS za pomocą JavaScript jest szeroko omawiane w programie W3C Web Standards Curriculum. Interfejs DOM document.stylesheets umożliwia nam dostęp do arkuszy stylów zastosowanych do strony internetowej, w tym do wszystkich zewnętrznych arkuszy stylów, do których odwołuje się tag <link> w HTML. Nie jest to łatwe, ale możliwe.
Powinienem więc rozwinąć początkową odpowiedź: to nie jest po prostu JavaScript, to CSS wspomagany JavaScriptem . JavaScript to niesamowita platforma z funkcjonalnością, w którą nie uwierzysz, ale CSS to miejsce, w którym pracuje większość projektantów stron internetowych. Gdybyśmy mogli w jakiś sposób stworzyć jakiś funkcjonalny most między tymi dwoma, w którym projektant stron internetowych mógłby napisać zestaw reguł CSS, aby wykorzystać funkcjonalność JavaScript, byłoby to w pewnym sensie rewolucją w projektowaniu stron internetowych.
Pokaż mi kod
Przez ostatnie dwa lata pracowałem nad nowym zestawem narzędzi CSS wspomaganym JavaScriptem o nazwie rKit. Cała idea polegała na zbudowaniu przyjaznego dla projektantów narzędzia, które nie tylko zastąpi zapytania o media CSS na potrzeby responsywnego projektowania stron internetowych, ale także zajmie się niektórymi znanymi [i nieznanymi] wyzwaniami, przed którymi stoją projektanci/deweloperzy stron internetowych podczas tworzenia nowoczesnych stron internetowych i aplikacji internetowych.
Ta koncepcja jest dużo, ale oto krótki fragment kodu CSS, który wyjaśni:
#my-element[rk="if @viewport.width między 320 a 480"]{kolor-tła: #0000ff;}
W rKit reguły CSS wyglądają jak zmodyfikowane selektory atrybut-wartość. Następnie możesz zdefiniować wyrażenie w sekcji wartości. Składnia tego wyrażenia ma być prosta i intuicyjna.
Uwaga : rk jest stałym identyfikatorem atrybutu.
Powyższy kod jest funkcjonalnym odpowiednikiem poniższego zapytania o media CSS:
@media only screen and (min-device-width: 320px) and (max-device-width: 480px) {
#mój-element {kolor-tła:#0000ff;}
}Jednak z rKit można zrobić o wiele więcej. Oto kolejny szybki przykład:
#mój-element[rk="if @self.width między 320 a 480"]{kolor-tła: #00ff00;} Zmieniając po prostu odwołanie do encji z @viewport na @self , zasadniczo skonfigurowaliśmy to, co jest powszechnie określane jako zapytanie elementowe. Teraz dzieje się tak, że gdy szerokość #my-element wynosi od 320 do 480 pikseli, zastosowana zostanie podana deklaracja [ background-color: #00ff00 ].
Możesz również użyć klas zamiast czystych deklaracji:
#my-element[rk="if @self.width między 320 a 480 then addClass(c_mobile_320)"]{}
.c_mobile_320 {kolor-tła: #00ff00;}To jednak tylko wierzchołek góry lodowej. Dzięki rKit możesz robić całkiem niesamowite rzeczy, takie jak zarządzanie zdarzeniami, obserwacja mutacji, zapytania ilościowe, routing, wiązanie danych [do 7-kierunkowe] i wiele innych fajnych rzeczy, a wszystko to przy użyciu czystego kodu CSS i bez pisania pojedyncza linia JavaScript.
rKit będzie darmowy i open-source po uruchomieniu. Będzie również oferować specjalny pakiet wydajności, który można zainstalować w sposób gwarantujący zerowe blokowanie renderowania, dzięki czemu strona internetowa ładuje się jak rakieta na szynach.
Poskładanie tego w całość zajęło trochę czasu, ale pojawi się niedługo [zdecydowanie przed Godotem] i naprawdę interesuje mnie, co projektanci stron internetowych [i programiści] są w stanie z tym zrobić.
Wniosek
Mam nadzieję, że nie odejdziesz od tego postu, myśląc, że niszczę zapytania o media CSS tylko dlatego. Nie jestem. To byłoby jak walnięcie w pomidora za wylądowanie w sałatce owocowej. Tak jak powiedziałem wcześniej, zapytania o media CSS nigdy nie były zaprojektowane do responsywnego projektowania stron internetowych. Został on dokooptowany ze względu na celowość i wszyscy popełniliśmy błąd, próbując go użyć do rozwiązania wszystkich problemów.
Niestety, my, jako społeczność internetowa, nigdy tak naprawdę nie udało nam się naprawić tego początkowego błędu poprzez znaczące ulepszenie go lub zaproponowanie lepszej alternatywy. Niestety, programy muszą być kontynuowane, strony internetowe muszą być budowane, a postęp musi dominować. Czas na zmianę.
rKit to tylko jedna opcja i jedna odpowiedź. Nie pierwszy i na pewno nie ostatni. Ale przynajmniej jest to właściwy krok we właściwym kierunku. Okazja do naprawienia niektórych problemów z przeszłości, a następnie iteracji, aby naprawić te w teraźniejszości i przyszłości. Ciekawie byłoby zobaczyć, jak pasuje do status quo.
Wszystko za to, że popełnienie błędu nie jest celem samym w sobie; powinno to być doświadczenie edukacyjne. Przy odrobinie szczęścia nauczymy się następnym razem używać właściwego narzędzia do właściwej pracy. To znaczy, tylko dlatego, że możesz jeździć rowerem po utwardzonej drodze, nie oznacza, że powinieneś go zabrać na Nurburgring. Przywieź Porsche!