Cześć. Co z poniższych jest bardziej wydajne jeśli chcę ostylować przykładowy div?
<header>
<div></div>
</header>
header div {
background: red;
}
<header>
<div class="red"></div>
</header>
.red {
background: red;
}
Czy warto jest tworzyć klasę nawet pod 1 cssowy selektor?
Pozdrawiam
Ale co masz na myśli pisząc o wydajności? Bo tego za bardzo nie rozumiem.
Za to wiem, że trzymanie CSS w HTML jest kiepskim pomysłem. Dobrze, że chociaż masz to wydzielone i nie piszesz styli inline.
Poza tym zauważ, że w pierwszym przykładzie twój styl będzie zastosowany do wszystkich elementów typu DIV umieszczonych w HEADER a w drugim do wszystkich elementów z ustawioną klasą red, więc ciężko te dwa przykłady porównać, bo robią one coś innego.
Osobiście uważam, że im mniej nasadzimy w kodzie różnych klas i atrybutów, tym bardziej on jest czytelny.
Ale z drugiej strony szaleje obecnie metodyka BEM i tam się sadzi w każdym elemencie zylion różnych klas.
Jeśli chodzi tylko o dzieci head bez dalszych potomków, używaj:
header > div {...}
im mniej nasadzimy w kodzie różnych klas i atrybutów, tym bardziej on jest czytelny
Ja uważam zupełnie odwrotnie.
Kod podany w pierwszym przykładzie jest zaprzeczeniem rozdziału treści od prezentacji. I nie chodzi o to, że OP coś źle napisał, tylko ja totalnie nie popieram takiego podejścia (które jednakże jest przez wiele osób promowane). Zauważ, że tutaj masz ostylowany DIV ale tylko będący dzieckiem jakiegoś innego elementu. Jeśli będziesz chciała zamienić HEADER na coś innego (chociażby dodasz do headera jeszcze jednego DIV'a, który bedzie w sobie zawierać treść aktualnie zamieszczoną w HEADER) to duża część formatowania się rozjedzie. Poza tym tutaj musisz określać dla każdego elementu osobno. Powiedzmy, że chcesz mieć jakiś BORDER ustalony dla elementów DIV. Dając to w przypadku pierwszego kodu, to ostylujesz jedynie DIV wewnątrz HEADER. Jakbyś chciała zrobić analogicznie z innymi DIV, to musisz to powtórzyć - stworzyć kolejne, analogiczne do header div {... zapisy. A jak będziesz chciała to zmienić to jeszcze gorzej, bo potem masz zmianę w X miejscach, zamiast jednej klasy.
O wiele bardziej logiczne jest stworzenie klasy maRamkęFajną a potem dodanie jej do tych DIV, które chcesz w ten sposób ostylować.
No i nie zgadzam się, że stylowanie bazujące na układzie HTML (czyli de facto na strukturze strony) jest bardziej czytelne. Zobacz - patrząc na pierwszy przykład NIC NIE WIESZ bez zajrzenia w CSS. W drugim od razu widać, że ten div ma być czerwony. Oczywiście - nie wiemy, czy chodzi o czerwony tekst, tło, ramkę - ale już coś wiemy. Przy założeniu, że nazwy klas są opisowe, a nie cl-17xy, ale tutaj akurat mamy jasny sygnał, że z tym DIV ma się dziać coś czerwonego.
szaleje obecnie metodyka BEM
Tutaj się zgodzę, że to jest lekkie przegięcie.
cerrato napisał(a):
im mniej nasadzimy w kodzie różnych klas i atrybutów, tym bardziej on jest czytelny
Ja uważam zupełnie odwrotnie.
Kod podany w pierwszym przykładzie jest zaprzeczeniem rozdziału treści od prezentacji.
(...)
No i nie zgadzam się, że stylowanie bazujące na układzie HTML (czyli de facto na strukturze strony) jest bardziej czytelne. Zobacz - patrząc na pierwszy przykład NIC NIE WIESZ bez zajrzenia w CSS. W drugim od razu widać, że ten div ma być czerwony.
Ale właśnie na tym polega separacja treści od jej opisu, że w treści nie ma być żadnych informacji na temat wyglądu.
Jak to robiliśmy w 1999?
<div color="red">
po co wymyślono CSS? Po to, żeby móc zamiast tego pisać po prostu:
<div> ew <div class="nazwa-klasy-opisująca-funkcję-elementu">
jeśli zamiast tego mamy:
<div class="red">
to wracamy tak naprawdę do 1999 i szlag trafia wszelką elastyczność.
Co do klasy maRamkęFajną to w wielu wypadkach może to być dobre rozwiązanie. No chyba, że jesteś pewien, że chodzi o jakieś specyficzne, używane tylko w nagłówku elementy, które nie będą występować nigdzie indziej na stronie.
Różnica jest taka, że mamy dwie skrajności:
Dlatego takim rozsądnym kompromisem jest przydzielanie klas i stylowanie w oparciu o nie. Przez to mamy:
I nie zgadzam się, że stosowanie wynalazków w stylu header div span jest separacją treści od zawartości, bo jednak poszczególne znaczniki tez są częścią treści (aczkolwiek się nie wyświetlają). Przy czym zależy, co jest treścią - czy tylko to, co masz na ekranie, czy patrzymy szerzej - cały HTML. Dla mnie treść to jest druga opcja, nie można patrzeć na znaczniki w oderwaniu od reszty. Zresztą, nawet jak dasz xxxxxx <span> YYYYY </span> xxx to i tak masz pomieszanie treści i informacji o formatowaniu. Wprawdzie nie jest to napisane wprost, że ten SPAN ma się inaczej wyświetlać, ale i tak do tego się to sprowadza.
Ciekawą dyskusję o czytelności nawiązaliście, muszę przyznać. Pisząc "wydajność", miałem jednak na myśli szybkość ładowania się strony, czyli która opcja zajmie mniej bajtów, o ile w ogóle będzie jakaś różnica. Ciekawi mnie też wpływ na SEO, czy w ogóle jakikolwiek będzie. Kod CSS i HTML umieszczam zawsze w różnych plikach, tylko na przykładzie podałem to jednym ciągiem, klasa "red" to też tylko przykład.
na pierwszy rzut oka można odczytać, jakie style są przypisane do danego elementu
No, ale - powtórzę - tej informacji ma nie być w kodzie. Style powinny określać funkcję elementu i nic więcej.
Żeby to wyjaśnić, chciałam posłużyć się kolorem nagłówka niniejszego forum w trybie jasnym i ciemnym, ale zajrzałam tam i załamałam się:
<nav class="navbar navbar-expand-lg bg-light navbar-light">
<nav class="navbar navbar-expand-lg bg-dark navbar-dark">
Ze 20 lat temu też wpadłam na pomysł, żeby dynamicznie modyfikować wygląd strony, wykorzystując zmienne w PHP, ale później na szczęście dowiedziałam się, jak działa CSS (a w każdym razie, jak powinno) i pomysł swój uznałam wtedy za poroniony, skoro identyczny efekt można przecież uzyskać zmieniając jedynie podpięty arkusz styli. A dziś po zajrzeniu w kod 4p, cóż... świat stanął na głowie :p
kod odporny na zmiany struktury
Tu się częściowo zgodzę. Bazowanie w stylowaniu na hierarchiach obiektów posiada właśnie takie ograniczenie, niemniej nie ma rozwiązań pozbawionych ograniczeń. Gdzie nie spodziewam się powtórnego użycia elementu, bazuję na łańcuchu rodziców, gdzie wymagana jest powtarzalność, styluję w oparciu o nazwę tagu klasy czy nawet id elementu.
Drzewiec napisał(a):
Pisząc "wydajność", miałem jednak na myśli szybkość ładowania się strony,
header > div {...} zostanie szybciej przetworzone przez przeglądarkę niż header div {...}.
czyli która opcja zajmie mniej bajtów, o ile w ogóle będzie jakaś różnica.
Jak łatwo zauważyć, kod z mniejszą ilością klas zajmie mniej bajtów, ale różnica będzie w sumie kosmetyczna, zwłaszcza w świecie, gdzie co druga strona ładuje na dzień dobry kilka MB bibliotek JS i CSS.
Zaletą nie zamienainia kodu w gęstą zupę, jest w moim odczuciu większa czytelność.
Zaletą rozwiązań podobnych do BEM jest mniejsza upierdliwość wprowadzania kolejnych modyfikatorów do klas. Przykładowo:
class="zielone zielone_z_ramką zielone_z_ramką_i_szlaczkiem"
gdzie każda kolejna klasa na pewno nadpisze ustawienia wcześniejszej.
Bo jak masz zapis
.zbiornik > DIV > DIV {color:blue;}
.blad {color:red;}
i
<div class="zbiornik"><div><div class="blad">
To bardziej złożony selektor ma priorytet nad prostszym selektorem, o czym należy pamiętać i co trochę komplikuje pisanie arkusza styli.
Freja Draco napisał(a):
header > div {...}zostanie szybciej przetworzone przez przeglądarkę niżheader div {...}.
Dlaczego się tak dzieje? Bardzo mnie ciekawi ten temat. Wiesz może co bardziej obciąży przeglądarkę: selektor header > div, czy nadanie klasy na div znajdujący się w headerze i selektor .klasa?
Drzewiec napisał(a):
Freja Draco napisał(a):
header > div {...}zostanie szybciej przetworzone przez przeglądarkę niżheader div {...}.Dlaczego się tak dzieje? Bardzo mnie ciekawi ten temat.
Zapewne dlatego, że w przypadku:
header > div {...}
wystarczy sprawdzić rodzica właśnie badanego elementu, żeby wiedzieć, czy łapie się na powyższy selektor i to już cała robota.
W przypadku:
header div {...}
przeglądarka musi sprawdzić wszystkich przodków elementu, żeby mieć pewność, czy powyższy selektor do niego nie pasuje.
Wiesz może co bardziej obciąży przeglądarkę: selektor header > div, czy nadanie klasy na div znajdujący się w headerze i selektor .klasa?
Najmniej pracy przeglądarki zabiorą najprostsze selektory:
.klasa {...}
#id {...}
miałem jednak na myśli szybkość ładowania się strony
[...] która opcja zajmie mniej bajtów
[...] co bardziej obciąży przeglądarkę
Moim zdaniem w obecnych czasach nie ma to żadnego znaczenia. Ludzie mają łącza idące w dziesiątki czy setki Mbit, 4-rdzeniowe procesory po 3Ghz i 8GB RAM - więc zastanawianie się nad takimi rzeczami jest według mnie stratą czasu.
Drzewiec napisał(a):
Ciekawą dyskusję o czytelności nawiązaliście, muszę przyznać. Pisząc "wydajność", miałem jednak na myśli szybkość ładowania się strony, czyli która opcja zajmie mniej bajtów, o ile w ogóle będzie jakaś różnica. Ciekawi mnie też wpływ na SEO, czy w ogóle jakikolwiek będzie
Jest takie narzędzie Lighthouse, które jest w stanie ci zrobić audyt strony pod kątem wydajności, SEO, dostępności itp. https://developers.google.com/web/tools/lighthouse