Dlaczego W3C zaleca używanie zapisu flex, zamiast każdej składowej właściwości osobno?

pytanie zadane 16 września 2019 w HTML i CSS przez startCoding Obywatel (1,210 p.)

Przeglądając dokumentację odnośnie Flexboxa znalazłem zalecenie aby korzystać z właściwości skrótowej flex, zamiast zapisywać osobno właściwości składowe.

W dokumentacji czytamy:

Authors are encouraged to control flexibility using the flex shorthand rather than with its longhand properties directly, as the shorthand correctly resets any unspecified components to accommodate common uses.

[Developerzy są zachęcani do kontrolowania elastyczności za pomocą zapisu skrótowego flex, zamiast poszczególnych właściwości składowych, ponieważ właściwość skrótowa flex poprawnie resetuje jakiekolwiek nieokreślone komponenty w celu dostosowania do typowych zastosowań.]

Ta uwaga jest powtórzona wszędzie w dokumentacji dla flex-grow, flex-shrink czy flex-basis.

Nie bardzo rozumiem w ogóle co ma oznaczać to wyjaśnienie w dokumentacji i dlaczego dla moich elementów w flex containerze nie powinienem po prostu określić flex-basis czy flex-grow...
Bardzo proszę o łopatologiczne wyjaśnienie i jeśli to możliwe zobrazowanie problematyki na przykładzie/ach.

Pozdrawiam serdecznie.

2 odpowiedzi

odpowiedź 16 września 2019 przez Comandeer Guru (601,550 p.)
wybrane 16 września 2019 przez startCoding

Najlepsza

Dokładniej jest to opisane przy samej własności flex:

Note: The initial values of flex-grow and flex-basis are different from their defaults when omitted in the flex shorthand. This is so that the flex shorthand can better accommodate the most common cases.

Innymi słowy: flex: 1 generuje inny wynik niż po prostu ustawienie flex-grow: 1. W tym pierwszym przypadku uzyskamy element o takich właściwościach:

flex-grow: 1;
flex-shrink: 1;
flex-basis: 0;

W drugim przypadku uzyskamy:

flex-grow: 1;
flex-shrink: 1;
flex-basis: auto;

IMO łatwiej jest ustawić jedną własność niźli pamiętać o konieczności ustawiania wszystkich trzech. Chociaż z drugiej strony to trochę błąd w standardzie, że skrótowy zapis odbiega od nieskrótowego. Ale teraz to już po ptokach i trzeba będzie z tym żyć.

komentarz 16 września 2019 przez startCoding Obywatel (1,210 p.)

No to przeoczyłem! Ja myślałem, że jeżeli zapisuję flex: 1; to pozostałe właściwości składowe (flex-shrink i flex-basis) są ustawiane na wartości domyślne, czyli kolejno 1 i auto.

Jeżeli zapis flex powoduje przy niepodaniu wartości dla flex-basis ustawienie wartości 0, to jaki jest sens korzystania z tego skrótu, kiedy niemal zawsze trzeba podawać w ramach tej właściwości wartość dla flex-basis? W praktyce niemal nigdy nie chcemy aby flex-basis miał wartość 0, a jak rozumiem ideą shorthandów jest danie developerowi komfortowego wyboru aby wykorzystać wszystkie, lub część możliwych składowych właściwości.

A to wytłumaczenie w postaci:

This is so that the flex shorthand can better accommodate the most common cases.

Nadal jest dla mnie całkowicie niezrozumiałe.

Jeszcze aby się upewnić, że całkiem nie zgłupiałem - flex-basis rozumiałem następująco: domyślna wartość to auto - gdzie dla auto flex item albo przyjmuje określony wymiar względem main axis (width lub height), lub jeśli to też nie zostało określone to przyjmuje wymiar contentu. Jeżeli jest jakakolwiek inna wartość niż auto np. 0 to ta wartość zawsze nadpisze height czy width. Dobrze to rozumiem?

komentarz 16 września 2019 przez Comandeer Guru (601,550 p.)

Jeszcze aby się upewnić, że całkiem nie zgłupiałem - flex-basis rozumiałem następująco: domyślna wartość to auto - gdzie dla auto flex item albo przyjmuje określony wymiar względem main axis (width lub height), lub jeśli to też nie zostało określone to przyjmuje wymiar contentu. Jeżeli jest jakakolwiek inna wartość niż auto np. 0 to ta wartość zawsze nadpisze height czy width. Dobrze to rozumiem?

Wygląda na to, ze tak.

A to wytłumaczenie w postaci:

This is so that the flex shorthand can better accommodate the most common cases.

Nadal jest dla mnie całkowicie niezrozumiałe.

Najwidoczniej autorzy specyfikacji uznali, że ustawienie flex-basis na 0 jest bardziej intuicyjne. Pewnie gdzieś w issues na GH jest zakopana dyskusja na ten temat, ale to już mocno archeologiczna zabawa.

komentarz 16 września 2019 przez startCoding Obywatel (1,210 p.)

Dla wszystkich znajomych backendowców którzy mówią, że CSS jest nielogiczny, chciałem (i nadal chcę) mówić "Nie, po prostu nie przestudiowałeś dokumentacji i dlatego nie rozumiesz".

Niestety, im dalej w las poznając więcej szczegółów tego języka to tym bardziej tracę wiarę, że mogę takie zdanie powiedzieć.

No nic, pozostaje zaakceptować, że jak korzystam z shorthanda to właściwości składowe nie przyjmują wartości domyślnych (a przynajmniej nie flex-basis)...

odpowiedź 16 września 2019 przez Majonez.exe Gaduła (3,490 p.)

W3C gada czasami głupoty, używa starej specyfikacji itp.

komentarz 16 września 2019 przez Comandeer Guru (601,550 p.)

W3C ustala specyfikację, więc nie może używać starej wersji… Jest tylko różnica pomiędzy wersją opublikowaną jako raport techniczny (Working Draft), a wersją rozwojową (Editor'e Draft). Jednak obydwie specyfikacje są tworzone przez W3C, a dokładnie – CSS Working Group.

komentarz 16 września 2019 przez startCoding Obywatel (1,210 p.)

To kto według Ciebie określa standardy sieciowe, szczególnie, że W3C działa od dobrych paru miesięcy wspólnie z WHATWG?

P.S. To nie jest odpowiedź do Comandeer'a, tylko pytanie retoryczne do MAJO.

komentarz 17 września 2019 przez Majonez.exe Gaduła (3,490 p.)

Wiem, teraz w sumie ja powiedziałem głupotę, oni ustalają standardy sieciowe, czasami jednak walną głupotę gdzieś w "przykładzie" np. złe zastosują coś itp. Przynajmniej ja takie coś widziałem.

1	komentarz 17 września 2019 przez Comandeer Guru (601,550 p.) I oczywiście zgłosiłeś odpowiedni issue na GH, żeby mogli to poprawić i żeby nikt nie powielił tego błędu? ;)