Frontend Thursday vol. 57

1. Chrome przestanie wspierać wtyczki oparte o Manifest V2

Zacznijmy od krótkiego wstępu dla wszystkich, którzy nigdy nie byli zaangażowani w rozwój wtyczek do przeglądarek. Manifest V2 to w sporym uproszczeniu zbiór API do tworzenia wtyczek dla Chrome. Ze względu na problemy z bezpieczeństwem rozwiązania Google zdecydował się porzucić ten format i zaimplementował ponad rok temu Manifest V3.

W minionym tygodniu gigant z Mountain View ogłosił, że w styczniu 2022 zablokuje możliwość dodawania do Chrome Web Store wtyczek opartych o Manifest V2, a od stycznia 2023 Chrome całkowicie usunie ich wsparcie. Temat wsparcia Manifest V2 już od dawna jest tematem sporów między twórcami wtyczek a Google. Ci pierwsi twierdzą, że Manifest V3 jest niekompletny i zbugowany, natomiast ci drudzy usilnie powołują się na argument poprawy bezpieczeństwa użytkownika. Są nawet tacy (na was patrzę uBlock), którzy zarzucają Googlowi celowy atak na blokery reklam w celu optymalizacji przychodów.

W zaistniałym sporze wyjątkowo rzadko wspomina się, że Manifest V3 wspierany jest również przez Firefoxa i Safari, a za jego rozwój obecnie odpowiedzialna jest grupa W3C WebExtensions Community Group, a nie sam Google. Brak niektórych API może być więc pokłosiem nie złej woli którejś ze stron, a poszukiwań wspólnego mianownika, na którego zgodzą się wszyscy zainteresowani Standaryzacja potrafi być bolesna, ale czasem warto zacisnąć trochę zęby.

Źródła:

https://www.theregister.com/2021/09/27/google_chrome_manifest_v2_extensions/

2. Czy składnia when-else trafi do standardu CSS ?

Lubicie składnię media-queries? Ja też nie 😉. Za każdym razem, kiedy patrzę na style zależne od wielkości ekranu muszę poświęcić chwilę na zrozumienie, co się właściwie dzieje. Na ten problem mają odpowiadać zaproponowane przez CSS Working Group @when i @else. Składnia jest znacznie czytelniejsza od obecnego rozwiązania, ale zanim trafi do przeglądarek czeka ją jeszcze niestety długa droga.

@when media(width >= 400px) and media(pointer: fine) and supports(display: flex) {
  /* A */
} @else supports(caret-color: pink) and supports(background: double-rainbow()) {
  /* B */
} @else {
  /* C */
}

W ramach prac nad draftem wszczęła się również ciekawa dyskusja dotycząca projektowania nowych funkcjonalności dla weba. Dla większości programistów domyślną składnią jest if-else, a nie when-else. Niestety nie zdecydowano się na pierwszy wariant ze względu na istnienie operatora @if w Sass, który jest obecnie najpopularniejszym prepocesorem cssów. Internet podzielił się na dwa obozy: tych którzy uważają, że nowe funkcje powinny dobrze integrować się z istniejącym ekosystemem i tych którzy uważają, że zależności stron trzecich nie powinny wpływać na podejmowane decyzje.

Źródła:

https://css-tricks.com/proposal-for-css-when/
https://github.com/w3ctag/design-principles/issues/335
https://tabatkins.github.io/specs/css-when-else/

3. Flexbox wspiera gap property

Prawdopodobnie kojarzycie property gap z CSS Grid Layout, ale czy wiecie, że ostatnimi czasy, trochę po cichu zostało dodane wsparcie dla gap w Flexbox? Co prawda taki sam efekt można było do tej pory osiągnąć odpowiednio manipulując marginesami i paddingiem, ale nowa składnia znacznie poprawia czytelność.

.container {
  display: flex;
  flex-direction: column;
  gap: 10px;
}

Jeśli chcecie zagłębić się w temat, to css-tricks przygotował świetny artykuł zagłębiający się, w to jak działa gap w Flexbox i Grid Layout i dlaczego jest lepszy od konfiguracji marginesów.

Źródła:

https://css-tricks.com/minding-the-gap/

Bonus: Jak powstał Quake w 13kB JavaScript

Jeśli wydaje wam się, że już gdzieś widzieliście Quake w 13kB JavaScript, to przeczucie Was nie myli. Ta kreatywna implementacja Quake pojawiła się już w naszym zeszłotygodniowym przeglądzie, ale twórca gry opublikował blogpost dokładnie tłumaczący, jak udało mu się osiągnąć tak małą paczkę. Jeśli tęsknicie za niskopoziomowym kodem, albo po prostu lubicie hardcorowe optymalizacje, to będzie dla Was idealny artykuł do popołudniowej kawy.