Jaki jest powód umieszczania prefiksów w nowych funkcjach CSS?


10

Czy istnieje uzasadniony powód, dla którego przeglądarki prefiksują nowe funkcje CSS, zamiast pozwolić webmasterom na użycie wersji bez prefiksu?

Na przykład przykładowy kod gradientu tła wygląda następująco:

#arbitrary-stops {
  /* fallback DIY*/

  /* Safari 4-5, Chrome 1-9 */
  background: -webkit-gradient(linear, left top, right top, from(#2F2727), color-stop(0.05, #1a82f7), color-stop(0.5, #2F2727), color-stop(0.95, #1a82f7), to(#2F2727));

  /* Safari 5.1+, Chrome 10+ */
  background: -webkit-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* Firefox 3.6+ */
  background: -moz-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* IE 10 */
  background: -ms-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* Opera 11.10+ */
  background: -o-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);
}

Po co zmusić webmasterów do czterokrotnego skopiowania i wklejenia tego samego kodu, aby uzyskać ten sam wynik?


Uwaga: jednym z często cytowanych powodów jest to, że style z prefiksem mają być tymczasowe, podczas gdy albo przeglądarka nie implementuje specyfikacji poprawnie, albo specyfikacja nie jest ostateczna .

IMO, ten powód to nonsens:

  • Jeśli silnik przeglądarki nie implementuje specyfikacji poprawnie, przeglądarka nie będzie zgodna, bez względu na to, czy nie zaimplementuje jej w formie bez prefiksu lub nie zaimplementuje jej w formie prefiksu.
  • Jeśli specyfikacja nie jest ostateczna, może mieć znaczenie, kiedy istniały wcześniejsze implementacje o tej samej nazwie. Na przykład, jeśli CSS2 miał linear-gradient, ale CSS3 miał zostać rozszerzony linear-gradiento dodatkowe funkcje, byłoby mądre tymczasowe przedrostek nowego, szkicu, implementacji poprzez -css3-<style>rozróżnienie między działającym CSS2 a eksperymentalnym CSS3. W praktyce CSS2 nie ma linear-gradientani innych nowości CSS3.

Zrozumiałbym również, gdyby różne przeglądarki miały różne formaty implementacji : na przykład powiedzmy, że wymagany jest Firefox, cień tekstu <weight-of-shadow distance-x distance-y color>, a Chrome wymagany <distance-x distance-y weight-of-shadow color>. Ale w rzeczywistości tak nie jest; przynajmniej wszystkie nowe funkcje CSS3, z których dotychczas korzystałem, miały ten sam format.


2
If the browser engine does not implement the spec correctly, the browser will not be compliant- Witamy w prawdziwym świecie. ™
Robert Harvey

Widziałem warianty zaokrąglonych granic między przeglądarkami - szczególnie, gdy próbowałem przypisać określony róg. W tym przypadku myślę, że implementacje specyficzne dla przeglądarki były dostępne przed napisaniem specyfikacji dla okrągłych ramek.
HorusKol,

Odpowiedzi:


9

Zgodnie z tą notatką W3C :

Aby uniknąć kolizji z przyszłymi funkcjami CSS, specyfikacja CSS2.1 zastrzega prefiksowaną składnię zastrzeżonych i eksperymentalnych rozszerzeń CSS.

Zanim specyfikacja osiągnie etap rekomendacji kandydata w procesie W3C, wszystkie implementacje funkcji CSS są uważane za eksperymentalne. Grupa robocza CSS zaleca, aby implementacje korzystały ze składni z prefiksem dostawcy dla takich funkcji, w tym w wersjach roboczych W3C. Pozwala to uniknąć niezgodności z przyszłymi zmianami w projekcie.


Możesz śledzić stan CSS tu i tutaj .


4

Zrozumiałbym również, gdyby różne przeglądarki miały różne formaty implementacji ... [b] ale w rzeczywistości tak nie jest; przynajmniej wszystkie nowe funkcje CSS3, z których dotychczas korzystałem, miały ten sam format.

To mówi mi, że nie grałeś w tę grę wystarczająco długo.

Problem polega na tym, że przeglądarki internetowe nigdy nie implementują nowych funkcji w ten sam sposób. Często zdarza się, że przeglądarka implementuje funkcje, które nie zostały znormalizowane, w wyniku czego wszystko działa inaczej w różnych przeglądarkach.

Co więcej, nowe funkcje są często błędne (unikamy wywoływania IE po nazwie), więc nawet jeśli składnia różnych elementów jest taka sama, wynik jest inny.

Powoduje to ból głowy dla programistów, którzy chcą korzystać z nowych funkcji. Po zakończeniu pisania arkusza stylów szybko zdają sobie sprawę, że renderuje się inaczej w różnych przeglądarkach z niewytłumaczalnych powodów.

Przed pojawieniem się prefiksów programiści byli zmuszeni polegać na wykrywalnych różnicach między przeglądarkami, często wykorzystując błędy w parserze CSS. Spowodowało to takie obrzydliwości jak ten:

padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;

Tego rodzaju ataki hakerskie były wynikiem próby dewelopera dostosowania arkusza stylów do każdej przeglądarki przy użyciu wszelkich dziwacznych metod, jakie mogli znaleźć.

Dzięki standaryzacji prefiksów umożliwia programistom korzystanie z funkcji, które nie są stabilne w różnych przeglądarkach. -moz-I -webkit-prefiksy zrobić to oczywiste, że autor stara się dostarczyć stylu, które powinny być stosowane tylko w niektórych przeglądarkach.

Gdy funkcje staną się stabilne, a przeglądarki zaczną działać tak samo, możesz usunąć prefiks i zadeklarować funkcję raz.

Myślę, że ważne jest, aby zdawać sobie sprawę, że przedrostki NIE oznaczają, że musisz deklarować style raz dla każdej przeglądarki. Prefiksy oznaczają, że muszą zadeklarować dodatkowe style za każdym razem, gdy okaże się, że przeglądarka internetowa nie jest zgodna ze standardem. Na przykład zamiast powyższego kodu powinieneś zacząć od:

 background: linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

Jeśli nagle zdasz sobie sprawę, że Microsoft nie jest w stanie poprawnie obliczyć gradientu liniowego, możesz dodać prefiks, aby rozwiązać problem w IE:

 /* Friggin IE */
 background: -ms-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);
 background: linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

Nagle Twoja strona wygląda tak samo w każdej przeglądarce, mimo że jedna z nich działała inaczej.

Przekonasz się, że zostało to omówione w bardzo wyczerpujący sposób w tym artykule na temat A List Apart .


2

Jeśli silnik przeglądarki nie implementuje specyfikacji poprawnie, przeglądarka nie będzie zgodna, bez względu na to, czy nie zaimplementuje jej w formie bez prefiksu lub nie zaimplementuje jej w formie prefiksu.

Różnica polega na tym, że przeglądarka nie złamie kompatybilność gdy nie stać zgodny. Jeśli zachowanie przeglądarki jest inne niż w specyfikacji, wówczas nie będą łamać starego kodu, gdy go zmieniają - ponieważ jest wymieniony pod nową nazwą.


Więc czy mówisz, że w przypadku, gdy nie jest on zgodny (lub staje się niezgodny), sprzedawca pozostawia go takim, jakim jest, i tworzy kolejną wersję z prefiksem, która jest zgodna? Myślałem, że wersje z prefiksem powinny zniknąć, gdy stały się zgodne / oficjalne?
Jacob Schoen,

@jschoen: To nigdy nie może się zdarzyć, ponieważ złamałbyś starszy kod, który zależy od tego.
DeadMG,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.