Pewnego dnia, na pewnym forum webmasterskim pewien użytkownik w shoutboksie (chacie?) pochwalił się swoją stroną internetową naxiu.pl, twierdząc równocześnie, że strona jest na tyle prosta, że przecież nie da się w niej znaleźć dużej liczby błędów. Cóż – mylił się.
- Zacznijmy od walidacji. Jest dobrze, ale może być lepiej – zwłaszcza, że obydwa błędy można łatwo poprawić.
- Natomiast już PageSpeed Insights nie jest zadowolone. Jednak i to da się łatwo naprawić.
- I jeszcze jedna rzecz na pierwszy rzut oka: na stronie jest aż jeden link, ale nie posiada odpowiedniego
outline. W tym wypadku oznacza to tyle, że domyślne style takiego obramowania w Chrome są niewidoczne. - Strona co prawda określa język treści, ale robi to błędnie. Twierdzi, że wszystko jest po polsku, podczas gdy jest po angielsku.
- 4 arkusze stylów – o 3 za dużo. Dodatkowo 3 dotyczą czcionek doczytywanych z zewnętrznych serwisów. Tego typu arkusze najlepiej doczytywać asynchronicznie i dodatkowo ładnie obsługiwać wczytywanie czcionek. Warto też zauważyć, że arkusze z Google Fonts API można łączyć i wczytywać kilka czcionek równocześnie. A z Font Awesome wybrać te ikonki, które są nam potrzebne. Ba, można je przekonwertować na Data URI i wsadzić bezpośrednio do naszego arkusza stylów.
- Autor strony nie ma pojęcia czym są pseudoelementy. Aż 3 elementy (de facto ustalające wygląd całej strony, zatem mające czysto prezentacyjne przeznaczenie) –
.overlay, .overlay2, .arrow– doskonale nadają się na pseudoelementy::before, ::after. - Hierarchia nagłówków jest nieprawidłowa. Obecnie strona przedstawia się jako
Hello, nice to meet you!
. Tak naprawdę nie traktowałbym tego w ogóle jako nagłówek, a za jedyny (i zarazem główny) nagłówek potraktowałbym obecneh2. -
<p>Polish webdeveloper & webdesigner</p>Warto pamiętać, że ampersand należy zapisywać jako encję
&. Co prawda tutaj nie powinno to spowodować problemów, ale już XML by nie popuścił. -
.socialsdoskonale nadają się na sekcjęaddress, gdyż są to dane kontaktowe autora. Dodatkowo konwencja ikonka – adres obok przypomina listę definicji. Ikonka przedstawiająca nazwę danej metody kontaktu to elementdt, natomiast szczegółowe informacje o niej todd.Trzeba także zwrócić uwagę, że obecnie lista metod kontaktu jest nieprzyjazna dla osób niepełnosprawnych – oni dostaną jedynie pusty link (podlinkowana ikonka FB, która nie niesie żadnych treści – bo to pusty element) i należałoby to zmienić. Proponuję dodać obok ikonki element z czymś typu
.visuallyhiddenlub w ostateczności dołożyć[aria-label]do pustegoi. Warto też dodać zwykły[title], bo nie każdy rozpoznaje FB po ikonce.Inną sprawą jest sposób, w jaki jest to podlinkowane. Uważam, że podlinkować należy całość (ikonkę + tekst). Osobiście próbowałem klikać zarówno to, co jest po ikonce FB, jak i po ikonce maila, ale nic się nie działo. Klikalna ikonka jest średnio intuicyjna – osobiście dla mnie jedynie informuje do czego prowadzi link obok niej. Mail za to jest w ogóle nieklikalny. No i ten slash na początku – po co? Wprowadza w błąd – zwłaszcza tych, którzy będą kopiować maila.
A, nie zapominajmy o
[target]!Ostatecznie wyszłoby coś takiego:
<address> <dl> <dt> <a href="http://www.facebook.com/naxiuweb" title="Profil na FB"> <i class="fa fa-facebook"></i> <span class="visuallyhidden">Profil na FB</span> </a> </dt> <dd> <a href="http://www.facebook.com/naxiuweb" title="Profil na FB">naxiuweb</a> </dd> <dt> <a href="mailto:naxweb7@gmail.com" title="E-mail"> <i class="fa fa-at"></i> <span class="visuallyhidden">E-mail</span> </a> </dt> <dd> <a href="mailto:naxweb7@gmail.com" title="E-mail">naxweb7@gmail.com</a> </dd> </dl> </address> - Teraz może coś o CSS. Nie widzę ani resetu, ani normalizacji. Przy tak małych projektach nie ma to co prawda jakiegoś większego znaczenia, ale warto pamiętać o tych technikach.
-
font-family:'Roboto';Lepiej zawsze podawać czcionki fallbackowe – inaczej fallback będzie do najbardziej domyślnej… czyli koszmarnego Times New Roman.
- Tak se myślę czy
.overlay, .overlay2nie można by się od razu pozbyć używając tła gradientowego nabody. -
.arrow { background:url('img/arrow.png');Co to za obrazek? Półprzezroczysty prostokąt. Ktoś nie słyszał o CSS triangles.
To by było na tyle… Strona mini, ale krytyka taka mini znowu nie wyszła.
Zabawne jest to, że tekst artykułu krytykującego jest dłuższy od samego kodu strony wziętej pod lupę. Jak widać, twórca tej mini-wizytówki nieźle się przejechał na swojej pysze. Swoją drogą, smutne jest to, że tak niewiele osób dba o poprawność kodu, uważając się przy tym za webdeveloperów.
Pisząc ten komentarz, tabuję po polach, a kursor niewdzięcznie ustawia się nie w tym polu co powinien 🙁
https://instagram.com/p/6jpYhemGPr/ yyyyyyyyyyyyy no takie błędy… i niby czczłowiek ma się z tego uczyć.
Rzeknę tak: szkoda, że nie pokazałeś kodu. Jeśli outline jest usuwany dla a:active (na co wskazywałoby „clicked links”) jest to całkowicie dozwolone – to oznacza, że user i tak kliknął go myszką. Niebezpieczne jest usuwanie outline dla :focus
Panie hipokrytyk,
zanim zaczniesz pan coś krytykować, to spójrz na siebie. Strona ładuje kilkanaście plików JS i CSS, których nie widać praktycznie na stronie. Do tego używasz najbardziej zaśmiecającego internet systemu CMS. Na koniec w szablonie zostawione są komentarze developera szablonu oraz wtyczek.
Natomiast strona „autora projektu” to już w ogóle istny odjazd – do poprzedniego dziesięciolecia.
Skoro zauważyłeś, że nie jestem autorem projektu i co więcej to nie jest jego strona domowa, to skąd założenie, że ta strona jest moja? 😉 Zapraszam na https://www.comandeer.pl do krytyki kodu – czekam na to od dobrych 3 lat i nikt się nie kwapi… Co do stanu strony WK już kiedyś mówiłem: to tylko medium przekazu, które nie zawsze jest doskonałe. Na chwilę obecną nie mamy po prostu czasu, żeby przenieśc WK na coś lepszego niż WP. Ale jak lubisz czekać i wierzysz ludziom, to zapraszamy za pewien czas, gdy przejdziemy na Jekylla lub podobne rozwiązanie 😉
Nie sądziłem, że zatwierdzisz ten komentarz. Dzięki. Wracając do tematu:
Skomplikowanie tej strony nie jest duże, więc spokojnie można pokusić się o własny system CMS lub użycie jednego ze znacznie lżejszych gotowców. Sam szablon też można spokojnie przyciąć o połowę.
Jak już chcesz, to chętnie skomentuję też Twoją stronę:
– klepanie itemscope i innych fanaberii strict, które niczego nie zmieniają
– używanie ładowanych fontów (Myriad)
– używanie protezy html5.js dla starych IE*
– używanie komentarzy warunkowych dla IE*
– debug w konsoli przeglądarki
– używanie CSS z przedrostkami przeglądarki
– gradient użyty w tle zajmuje mniej bajtów jako grafika
– liczne nbsp
– niekonsekwencja wstawiania linków (raz dajesz z protokołem, raz bez; raz ze slashem, raz bez)
– mały margines boczny w ramce na stronie kontakt
* – zamiast tego dałbym bezczelnie komunikat w die() po UA
I konsekwetnie piętnował starsze wersje innych przeglądarek – np Operę 12.xx
Oczywiście to moje subiektywne zdanie i nie muszą one być zgodne z Twoim podejściem. Ogólnie reszta ok.
No i jeszcze Google PageSpeed ma 2 uwagi. Jedna to juz hipokryzja z ich strony, ale drugą można poprawić.
Wyglądu nie zmieniam, bo nie 😉
Co do debugu w konsoli: jutro postaram się to ogarnąć. Dla IE skrypty w sumie też mogę wywalić.
Co do CSS: AFAIR są jedynie potrzebne prefiksy, ale jeszcze to przejrzę.
Ładowane fonty są do bólu zoptymalizowane jeśli o to Ci chodzi (polecam poczytać o FOIT u Filament Group). Jeśli natomiast nie lubisz fontów bo tak – no to cóż 😉
Schema.org i mikroformaty są bardzo fajną wartością dodaną dla parserów i wyszukiwarek – IMO mogą zmienić bardzo dużo.
Nbsp jest liczne, ale używane całkowicie poprawne – do pozbywania się sierot itd.
Jeśli chodzi o linki: tutaj muszę ogarnąć, żeby de facto wszędzie było https. Różnice są, bo OpenGraph nie akceptuje relatywnego protokołu AFAIR.
Co do PageSpeed: ta druga uwaga jest błędem narzędzia 😉 zauważ, że ten link to widoczny tylko przy focusie link „skip to content”
I jeszcze jedno – biały tekst na szarym tle to tragedia. I text shadow tego nie ratuje.
No właśnie o te prefiksy chodzi. Developerzy używający stylów z prefixami pod przeglądarki powodują, że popularne staje się rozwiązanie konkretnego producenta przeglądarki zamiast standardów W3C.
Cały kod gradienta ma ponad 1600 bajtów – zarówno JPG jak i PNG uda się upchnąć poniżej tej wartości.
Ładowanie czcionek ma sens, gdy strona jest dużym portalem lub gdy czcionka jest bardzo wymyślna, unikalna czy też firmowa (wiele firm posiada „swoje” czcionki). Tutaj ładujesz font (dla przeciętnego śmiertelnika nie różniący się niczym od stanardowych) dla kilkunastu słów na krzyż.
Dla jakich parserów i wyszukiwarek? Google i Bing istnieją już tak długo, że radza sobie z błędami w składni, więc na idealnie zakodowanej stronie (zgodnie z W3C) dodatkowe wytyczne nie są im do szczęścia potrzebne. W3C jasno określa standard HTML5 i nie widzę sensu linkować dodatkowych schematów do tego. Jedyne parsery jakim można iść na rękę to te dla osób niewidomych.
Tylko czasami nbsp występuje w miejscu, gdzie złamanie linii nie ma prawa się wydarzyć. Swoją drogą, że takie usuwanie sierot to dla mnie nazizm językowy.
Używanie „//” jest złe u samych podstaw i powinno zostać zakazane. Albo określamy ścieżkę relatywną, albo pełen adres wraz z protokołem.
Przy 3 pozycjach menu „skip to content” nie ma większego sensu. Do tego jest umieszczone w złym miejscu – wyrównanie do prawej krawędzi powinno być lepszą opcją.
Nie ma czegoś takiego jak line-height:auto – sam to u siebie ostatnio poprawiałem.
Popadasz w zbytni puryzm IMO jeśli chodzi o prefiksy. Część potrzebnych rzeczy nie jest standardem W3C i raczej nie będzie, a pozwala np wycisnąć więcej z Blinka. Puryzm dla samego puryzmu nie ma sensu i czasami warto zastosować coś, co nie jest standardem, a po prostu dziala. Jeśli natomiast dana rzecz ma wersję standardową, to wówczas odpowiednia kolejność własności z prefiksami i bez nich zapewnia standardową obsługę na wszystkich kompatybilnych przeglądarkach.
Co do gradientu: zostawię na razie jak jest.
Ładowanie czcionek to głównie eksperyment odnośnie FOIT i jego unikania. Stąd kwestia tego czy czcionka ma sens, czy nie nigdy nie była dla mnie istotna.
HTML5 niesie bardzo mało informacji semantycznych tak naprawdę. Np jak wyrazisz w HTML5, że dany fragment dotyczy osoby i opisuje jej miejece zamieszkania itd? I właśnie tutaj na wcenę wkraczają mikrodane i mikroformaty. Te dane są wykorzystywane później choćby do tworzenia vcardu danej osoby czy dokładniejszego wyświetlania danych w wyszukiwarce. AT z tego de fscto nie korzysta.
A nazywaj se to jak chcesz 😉 niemniej nie zaprzeczysz, że takie jest dedykowane przeznaczenie twardej spacji.
I co dokładnie jest złego w używaniu // na stronie z HTTPS skoro zostanie to przekształcone na HTTPS? A zawwze to te 3 bajty mniej 😉 problem z // jest taki, że przy serwowaniu przez HTTP zamieni nam na „zły” protokół. Przy HTTPS ten problem jest zdecydowanie mniej poważny
Równie dobrze można powiedzieć, że nie ma sensu przy ARIA landmarks. Ale jest, gdyż akurat moja domowa służy mi do eksperymentów. Co do wyrównania do prawej – IMO źle to wygląda, stąd przeniosłem to na lewo.
Fakt, trza poprawić na normal
Stosowanie czegoś, co nie jest standardem, już przerabialiśmy 2 razy. Raz przy marquee, drugi raz przy wchodzeniu CSS3, gdzie trzeba było prefiksy dla każdego silnika, tysiąc if-ów dla IE + protezy i hacki css.
Wiadomo, że czasem klient się uprze i nic nie zrobisz, ale generalnie powinno się trzymać standardów i jak coś nie działa na jakieś przeglądarce, to nie działa i juz – trzeba wymusić na użytkowniku zmianę przeglądarki na nową lub inną, wymusić na producentach przeglądarek trzymanie się standardów.
Dostosowywanie się to zabytków czy też konkretnej przeglądarki jest złe.
Nie chcę być złym prorokiem, ale to co zrobił kiedyś IE, może powtórzyć webkit – stworzy jedyną słuszną przeglądarkę, która jest na bakier ze standardami i robi wszystko po swojemu. Powstanie tony CSS z funckjami „-webkit”, których nie będzie w innych silnikach, trzeba będzie je sztukować przy pomocy JS, a potem płacz i zgrzytanie zębów.