Wszystko sprowadza się do mechanizmu ASI: http://inimino.org/~inimino/blog/javascript_semicolons
]]>>Ja nie narzekam.
Ale Ty != user. A dużo osób nie ma LTE, nie jest w zasięgu LTE lub ma pecha i pochylona sosna (autentyk!) blokuje sygnał.
>Do innych: Nie mówcie tego na rozmowie kwalifikacyjnej, ludzie kupują oczami.
Szkoda, że uwaliłeś kontekst wypowiedzi, który zmienia cały sens tego zdania. No i słowo „niepotrzebne” jest chyba wystarczająco dobitne. Poza tym zawsze mi się wydawało, że „efekciarstwo” jest jednoznacznie pejoratywnym określeniem… Ah, i nie narzekam na zarobki.
>To już przegięcie. Może jeszcze dyskryminujemy osoby niepełnosprawne dodawaniem zdjęć na stronie, bo to niepotrzebne efekty?
Jak nie używasz [alt], to tak – dyskryminujesz. Znów mylisz dobry design z nieużywalnym i niedostępnym efekciarstwem. To przecież całkowicie 2 różne rzeczy.
>Da Vinci – ten do dopiero dykryminował „wykluczonych społecznie”.
Nie, bo zajmował się też medycyną. Zresztą głupio byłoby gdyby dyskryminował, skoro sam był po części wykluczony społecznie.
>Poza tym założenie, że niewidomi są wykluczeni… kilku mogłoby się obrazić.
To akurat była ironia (myślałem, że rozpoznasz; wszak tak chętnie używasz jej do merytorycznej dyskusji ze mną). No i czemu założenie, że niepełnosprawni to tylko niewidomi? A np osoby z trudnościami motorycznymi, które nie bardzo są w stanie używać myszki?
>A rollover… nie no zajebisty.
Faktycznie… bo obrócenie avka to nie jest rodzaj rollovera ;)
> Co do LTE
Ja nie narzekam.
> Tak, niepotrzebne efekciarstwo jest bolączką Sieci.
Do innych: Nie mówcie tego na rozmowie kwalifikacyjnej, ludzie kupują oczami + taka jest rola designu.
> No bo po co pamiętać o wykluczonych społecznie?
To już przegięcie. Może jeszcze dyskryminujemy osoby niepełnosprawne dodawaniem zdjęć na stronie, bo to niepotrzebne efekty? Da Vinci – ten do dopiero dykryminował „wykluczonych społecznie”. Poza tym założenie, że niewidomi są wykluczeni… kilku mogłoby się obrazić.
> Co do braku efektów na mojej stronie – ewidentnie nie próbowałeś nigdzie nawigować ani nie najechałeś myszką na logo?
A rollover… nie no zajebisty.
>Taa…
A do czego to używasz? Do wykrycia touch eventu i zrobienia animacji przy scrollu. W najgorszym przypadku masz 20 linijek.
>Przecież LTE to pieśń przyszłości, a czekaj, nie – już jest w tanich smartfonach. No to jednak nie.
Całkowicie niepotrzebna ta przesadzona ironia. Co do LTE – polecam poużywać choć trochę mobilnego Internetu. Wówczas pieść przyszłości będzie najlepszym określeniem tego… „fenomenu”.
Tak, niepotrzebne efekciarstwo jest bolączką Sieci. NIKT lub prawie nikt nie pamięta dzisiaj o dostępności. No bo po co pamiętać o wykluczonych społecznie?
Co do braku efektów na mojej stronie – ewidentnie nie próbowałeś nigdzie nawigować ani nie najechałeś myszką na logo ;)
]]>>No to jednak nie jak na przykładzie…
Jak na przykładzie. Po prostu wadliwe rozwiązanie zostałoby zastąpione innym, dającym identyczny efekt. A przecież o efekt wizualny chodzi, prawda? ;)
>Tu popłynąłeś. Każdy klient marzy by jego witryna poleciała na GitHub. To takie oczywiste!
Rozumiem, że tylko Twoi klienci mają duże projekty i nie da się pokazać nic sensownego na ogólnie dostępnych zasobach? Pierwsze z brzegu – Yahoo.com. Doskonały przykład do omówienia wszelkiej maści problemów związanych z BEM. Całość można ładnie zakończyć prezentacją niezależnego modułu (i nie – nie chodzi mi o takie bio; chodzi mi o prosty przykład BEM). Ba, można było podejść do tematu mniej sztampowo i omówić BEM jako *architekturę aplikacji* a nie konwencję nazewniczą w CSS. Poza tym – firma webdeveloperska raczej może takie rzeczy pokazać na swojej stronie firmowej. Przynajmniej takie odnoszę wrażenie.
I odnośnik z http://www.awwwards.com – to już kwestia większej pracy i priorytetów
> wszystko działało tak, jak na przykładzie
> Prawdę powiedziawszy nawet nie widzę tutaj potrzeby zastosowania SVG
No to jednak nie jak na przykładzie…
> pokaż duży projekt a nie maciupki element
Tu popłynąłeś. Każdy klient marzy by jego witryna poleciała na GitHub. To takie oczywiste!
>Zostało… sprawdzaj uważniej. (_vars.scss)
To coś chyba nie bardzo to działa w tym inuicie… np grid jest false a w CSS i tak jest
>Wydajność CSS nad wydajność beckendu? Zostawię to bez komentarza.
Tak, z prostej przyczyny: backendu user nie widzi. Jeśli strona ma się wczytywać szybko, to CSS powinien zostać zoptymalizowany. Łatwiej jest stworzyć całkowicie nieoptymalny CSS niźli całkowicie nieoptymalny backend. Jak wsadzisz cały Symfony do routingu, to nie zabijesz serwa. Jak wsadzisz wielki framework CSS dla prostego elementu, to możesz zwiesić przeglądarkę (download pliki → rendering; wszystko blokujące!).
>To nie jest demo inuita, była nim prezentacja, nie wiem jak Ci to klarowniej przekazać.
No to skoro to *nie* jest demo inuita, to po co on tutaj jest, skoro *nie* pasuje? Poza tym – prezentacja prezentuje to demo… ale równocześnie nie jest to demo prezentacji?
>Nie widziałem na twojej stronie, nie wiem,… jakichkolwiek efektów?
Ilość efektów decyduje o efektywności CSS? Jeśli miałbym zakodować tak samo każdy element na swojej stronie, jak to proste bio, to miałbym CSS o długości zasobów Biblioteki Kongresu…
>Do policzenia stroke-dasharray? Ciekawe, ciekawe.
Prawdę powiedziawszy nawet nie widzę tutaj potrzeby zastosowania SVG, skoro to samo można osiągnąć po lekkiej zabawie z CSS (dam sę rękę uciąć, że border gradientowy + animacja sprawę by rozwiązało)…
>To jest przykład użycia elementu w dużym projekcie, tak samo jak inuit.
Tytuł prezentacji: „Dobre praktyki CSS, BEM i OOCSS na przykładzie inuit.css”. Ani razu nie jest wspomniany „duży projekt”. A jeśli chcesz pokazać użycie elementu w dużym projekcie, to… pokaż duży projekt a nie maciupki element.
> Dlaczego zatem w demo nie zostało to zastosowane?
Zostało… sprawdzaj uważniej. (_vars.scss)
> Dlaczego zatem w przypadku CSS – gdzie ta wydajność ma o wiele większe znaczenie!
Wydajność CSS nad wydajność beckendu? Zostawię to bez komentarza.
> Dalej – sam przyznajesz, że inuit *nie* jest tutaj potrzebny a równocześnie twierdzisz uparcie, że jest to demo inuita…
To nie jest demo inuita, była nim prezentacja, nie wiem jak Ci to klarowniej przekazać.
> Cała moja strona domowa zawiera ok. 10 razy mniej kodu CSS niźli Twoje demo.
Nie widziałem na twojej stronie, nie wiem,… jakichkolwiek efektów? (https://comandeer.pl/)
> dobrze napisane animacje w CSS
Do policzenia stroke-dasharray? Ciekawe, ciekawe.
> Zarówno jQuery, jak i wow.js można było zastąpić kilkoma prostymi linijkami w JS.
Taa…
To jest przykład użycia elementu w dużym projekcie, tak samo jak inuit, nie wizytówce. Jak chcesz pokazać przekład routingu w dużych projektach to… nie używasz Silexa, bo to nie jest narzędzie do tego typu rzeczy, a właśnie Symfony. „Minimalny” komponent CSS będzie niedługo.
]]>>Niektórzy spojrzeli na 10k linii i złapali się za głowę. Po samym wywaleniu komentarzy kod zmalał (liczę znaki – nie widzę sensu liczenia linii) o ponad 61%!
Zacznijmy od tego, że na produkcję komentarze *nie mają prawa* się dostać. Komentarze są tylko i wyłącznie dla developera i dla niego zostać powinny. Tym bardziej, że SASS jest w stanie minifikować pliki w locie, więc nie rozumiem czemu dostajemy w pełni czytelny plik CSS. Co do niewidzenia sensu liczenia linii – cóż, jakkolwiek by nie liczyć, to 10k to zdecydowanie za dużo jak na tak prosty element. Zarówno jQuery, jak i wow.js można było zastąpić kilkoma prostymi linijkami w JS. Cały narzut w CSS też można było rozwiązać lepiej, o czym będzie niżej.
>Pamiętajmy, ze inuit.css (już zawierający normalize.css) jest w tym pliku.
Na meecie AFAIR mówiłeś, że inuit.css zawiera możliwość warunkowego wczytywania poszczególnych modułów. Dlaczego zatem w demo nie zostało to zastosowane? To jest dokładnie to, o czym mówiłem: technika „wyciągania mixinów”. No i nie oszukujmy się – dla tego elementu z całego inuita potrzebny jest de facto tylko normalize.css. Czy jeśli potrzebujesz routera w PHP, to wczytujesz całe Symfony? Nie. Dlaczego zatem w przypadku CSS – gdzie ta wydajność ma o wiele większe znaczenie! – wczytujesz całą stajnię dla jednego konia?
>Dla tech wszystkich, którzy nie znają inuita (a wypadałoby) – inuit nie dostarcza designu i dla tego jednego elementu nie jest wgl potrzebny, a czemu jest więc w repo? To już zostało powiedziane
Artykuły na portalach, takich jak WebRoad.pl, mają chyba właśnie za zadanie pokazywać tym, którzy czegoś nie znają, dlaczego to coś jest dobre. Zatem zarzut, że ktoś nie zna inuita w tym wypadku brzmi śmiesznie. Co więcej, ci, którzy komentowali, wiedzą doskonale czym jest inuit.css, więc nie wiem właściwie w kogo celujesz tym zarzutem? Dalej – sam przyznajesz, że inuit *nie* jest tutaj potrzebny a równocześnie twierdzisz uparcie, że jest to demo inuita… Zawsze mi się wydawało, że jeśli prezentuję jakieś rozwiązanie, to od jak najlepszej strony i w tym, w czym jest naprawdę dobre. inuit.css nie nadaje się do prostych elementów – on potrzebuje czegoś bardziej zaawansowanego. To tak jakbym prezentował Web Sockets na przykładzie uploadu pliku na serwer – da się, ale to nie to. To, że nazwiesz coś „demo czegoś tam”, nie oznacza, że to demo nie może być równocześnie skrajnie przeinżynierowanym rozwiązaniem, nie pokazującym w pełni możliwości prezentowanego narzędzia (starczy wspomnieć dema „HTML 5” w wykonaniu Apple). Warstwy abstrakcji, takie jak inuit.css, są genialne, ale ta abstrakcja musi mieć co nadbudować. Tutaj nie ma, bo jesteśmy zostawieni z super prostym elementem, do którego ostylowania można z powodzeniem użyć zwykłej kaskady w CSS i nie powinno to sprawić większych trudności. Cała moja strona domowa zawiera ok. 10 razy mniej kodu CSS niźli Twoje demo. Jakkolwiek by nie patrzeć, nawet tak prosta strona internetowa jest bardziej skomplikowana niźli prosty element bio, który… powinien być prosty. Ten nie jest. Czemu? Bo wykorzystuje niepotrzebne warstwy abstrakcji i potrzebuje wielkiej ilości JS (a starczyłyby dobrze napisane animacje w CSS i *jeden* event listener w JS, żeby wszystko działało tak, jak na przykładzie) – więcej niźli np mój popover do obrazków. Przerost formy nad treścią. IMO postawiłeś na efektowność a nie efektywność rozwiązania. I to jest największa bolączka współczesnej Sieci.
BEM i niezależne komponenty – jak najbardziej, genialna rzecz. Ale żeby pomalować pokój nie trzeba w tym celu zachlapać całego mieszkania.
]]>>”Jeżeli chodzi o ilość CSS, to trzeba pamiętać, że było to demo do prezentacji m. in. o inuit.css” – to chyba zrozumiałe zdanie.
Jak najbardziej i dlatego się do niego odniosłem ;) „Gdybym użył tutaj inuita, użyłbym go tak, jak kiedyś ktoś użył Bootstrapa: wziął same mixiny” – miałbyś w prezentacji dodatkowo plus za pokazanie bardzo fajnej optymalizacji.
Nie bądź na mnie zły, ja po prostu jestem skrajnym, upierdliwym purystą. Jeśli sądzę, że można w jakikolwiek sposób jakieś rozwiązanie poprawić, to to piszę ;)
]]>„Jeżeli chodzi o ilość CSS, to trzeba pamiętać, że było to demo do prezentacji m. in. o inuit.css” – to chyba zrozumiałe zdanie. Po ewentualnej kolejnej prezentacji specjalnie dodam jeszcze źródło zminimalizowanej wersji po kompresji, tak dla spokoju.
]]>Nie lepiej pokazać, że umie się coś zrobić od podstaw zamiast prezentować podręcznikowe użycie armaty na muchę? To problem większości dzisiejszej sieci. Ludzie, którzy dostali do rąk kilka (wygodnych bądź co bądź) kolosów, pod płaszczykiem „elastyczności”, zapomnieli o skalowalności, umiarze i nie potrafią chyba już nic napisać bez użycia 3 frameworków.
Kwestia dostosowania rozwiązania do potrzeb.
]]>Jeżeli dobrze rozumiem, to pokazałeś tutaj właśnie diva z informacją o autorze, jednym akapitem tekstu i obracającym się obrazkiem. Do wykonania potrawy potrzebowałeś kostki masł.. tfu, ponad 3 tysięcy linijek CSS-a, ponad dziesięciu tysięcy linijek javascriptu i około 6 zewnętrznych bibliotek. Fajnie :)
Co się dzieje z tym światem…
]]>>Uszanuj podejście innych to tak miękkich spraw jak konwencja nazewnicza, bo jest to irytujące.
Z tym, że ja tego nie rozpatruję na poziomie samej konwencji nazewniczej, bo tutaj po prostu problemu nie ma. Raczej chodziło mi o mechanizm, który tak naprawdę leży pod tym i opiera się na wątłym założeniu, że dev czegoś nie robi. BTW z PSR używam tylko PSR-0 ;)
>Ja tego nauczyłem się z artykułów Harrego Robertsa (developera roku 2014 wg. magazynu .net), ale co on tam może wiedzieć…
Szanuję go jako twórcę inuita i wielu dobrych rzeczy odnośnie CSS-a, ale IMO w tym miejscu po prostu się pomylił. Ale co ja tam mogę wiedzieć…
>Tło nie rozepchnie kontenera + border-bottom
Hm, to może ::before? Powinno zadziałać bez problemu.
>IMO fatalnie, I(Harry Roberts)O ssie
Jeśli rozpatrywałbym to tylko w kontekście CSS, to faktycznie – być może jest to ciut niespójne. Natomiast jeśli to rozpatrujemy na poziomie HTML, JS i dopiero później CSS, to tutaj sprawa nie jest już tak oczywista. Poza tym w tym artykule Roberts równie niepochlebnie wyraża się o underscore, zatem .blok__elem również podpada pod niespójność ;)
>Zmianę stanu po najechaniu, a kliknięciu nazywasz błędem?
W wypadku tego przykładu można to nazwać jedynie niedogodnością. Niemniej spotkałem się już ze stronami, które nadpisywały w takim wypadku obsługę myszki przez touch i po sprawie. IMO tutaj działałaby dobrze technika, jaką zastosował Mathias Bynens przy obsłudze zdarzenia input przy pomocy keyup: http://mathiasbynens.be/notes/oninput oczywiście ideałem byłyby Pointer Events, ale wciąż to tylko IE…
Uszanuj podejście innych to tak miękkich spraw jak konwencja nazewnicza, bo jest to irytujące. Dyskusja na poziomie „wy używacie PSR-1, jesteście słabi, bo my używamy PSR-2” jest bezsensowna i szkoda na to czasu, na pewno mojego.
> nie ma potrzeby bowiem, żeby dodawać przy BEM selektory typu .js-* o czym już mówiłem
A ja się z tym nie zgodziłem i wyjaśniłem dlaczego.
> .blockName-elem–modifier
IMO fatalne.
> BTW jQuery 2.1 i wykrywanie IE Dodatkowo mój Chrome dla desktopów zawsze przedstawia się jako touch
device i w tym momencie uwierzenie Modernizrowi powoduje błąd w
działaniu strony.
A mój, nie. Błąd? Zmianę stanu po najechaniu, a kliknięciu nazywasz błędem?
> Jeśli się nie obrazisz, to jutro, gdy będę mieć czas, forknę Twój przykład
Po to właśnie jest na GitHub
Poza tym mam wrażenie, że kod – nawet mimo użycia BEM – jest przekombinowany. No i na avku zapomniałeś o odpowiedniej klasie ;) Wydaje mi się również, że byłoby lepiej zostawić tutaj pusty [alt] (duplikuje informacje z nagłówka, który jest tuż poniżej).
IMO .bio__bg js-equal-bio łamie zasady BEM i trójpodziału – nie ma potrzeby bowiem, żeby dodawać przy BEM selektory typu .js-* o czym już mówiłem (poza tym konwencja nazewnicza: .block__elem vs .js-elem – czemu taka dychotomia?) i nie widzę też realnej korzyści z zastosowania stylu inline. Ba, czemu to nie jest po prostu odpowiednie tło dla odpowiedniego elementu, tylko pusty div?
Dalej lecą same puste linki – i nie, ani svg, ani puste tagi i nie stanowią jakiejkolwiek treści. Polecam sobie to przepuścić przez jakiś czytnik ekranowy, który wdzięcznie ominie wszystkie linki (stąd moja nienawiść do czcionek ikonkowych, których de facto nikt nie używa dobrze).
Przykład dla BEM o tyle nietrafiony, że w przypadku stosowania klasycznego OOCSS kod byłby jakieś 5 razy krótszy (zarówno jeśli chodzi o HTML, jak i CSS). Nie bardzo widać tutaj korzyści z BEM – widać raczej jego narzut ;)
Osobiście stosuję też inną konwencję nazewniczą dla BEM. Zamiast .block-name__elem–modifier używam .blockName-elem–modifier. IMO o wiele bardziej czytelne ;)
BTW jQuery 2.1 i wykrywanie IE < 9 – po co? ;) Dodatkowo mój Chrome dla desktopów zawsze przedstawia się jako touch device i w tym momencie uwierzenie Modernizrowi powoduje błąd w działaniu strony.
Jeśli się nie obrazisz, to jutro, gdy będę mieć czas, forknę Twój przykład i zademonstruję jak ja to widzę ;)
]]>