Czy naprawdę warto podać wartość url ()?


235

Którego z poniższych należy użyć w moich arkuszach stylów?

/* Example #1: */ background-image: url(image.png);
/* Example #2: */ background-image: url("image.png");
/* Example #3: */ background-image: url('image.png');

Co W3C określa jako prawidłowy sposób ?


Odpowiedzi:


243

W3C mówi, że oferty są opcjonalne, wszystkie trzy sposoby są legalne.

Cytat otwierający i zamykający musi być tylko tym samym znakiem.

Jeśli w adresie URL znajdują się znaki specjalne, należy użyć cudzysłowów lub znaków specjalnych (patrz poniżej).

Składnia i podstawowe typy danych

Format wartości identyfikatora URI to „url (”, po którym następuje opcjonalna biała spacja, a następnie opcjonalny pojedynczy cudzysłów („) lub znak podwójnego cudzysłowu (”), a następnie sam identyfikator URI, a następnie opcjonalny pojedynczy cudzysłów (”) lub podwójny cudzysłów („), po którym następuje opcjonalna biała spacja, po której następuje„) ”. Dwa znaki cudzysłowu muszą być takie same.

Uciekające znaki specjalne:

Niektóre znaki występujące w niecytowanym URI, takie jak nawiasy, białe znaki, pojedyncze cudzysłowy (') i podwójne cudzysłowy ("), muszą być poprzedzone odwrotnym ukośnikiem, aby wynikowa wartość URI była tokenem URI:' \ (', „\)”.


9
Niektóre starsze przeglądarki mogą mieć problemy z cytowanymi adresami URL, a mianowicie IE Mac.
mveerman

5
W uzupełnieniu tego, co powiedział bic72, niektóre starsze przeglądarki również wysyłają podwójne żądania, gdy są konfrontowane z cytowanymi adresami URL w CSS, najpierw żądają „myfile.png”, a następnie myfile.png - stąd powód, dla którego ich nie używam.
Pebbl

FWIW wydaje się, że specyfikacja, do której linkujesz, została przepisana od czasu opublikowania drugiego cytatu. Teraz przecinki nie wymagają ucieczki.
Ben

@pebbl - Masz rację, a starsze przeglądarki zawierają najnowszą wersję Chrome na Maca.
Daniel Beardsley,

7
Najnowszy projekt redakcji CSS 3 (maj 2015 r.) Nie wydaje się już pozwalać na cytowanie: dev.w3.org/csswg/css-syntax (sprawdź url-tokenschemat kolei), podczas gdy aktualne rekomendacje kandydatów (luty 2014 r.): W3.org/TR / css-syntax-3 Przypuszczam, że chcą promować stosowanie sekwencji specjalnej zamiast cudzysłowów
Simon Mourier

34

Lepsze wykorzystanie cytatów, ponieważ jest zalecane przez najnowszy standard i jest mniej przypadków brzegowych.

Według najnowszego szkicu wartości i modułów CSS poziomu 3 (18 grudnia 2015 r.)

Adres URL jest wskaźnikiem do zasobu i jest oznaczeniem funkcjonalnym oznaczonym przez <url>. Składnia a <url>to:
<url> = url( <string> <url-modifier>* )

Niecytowana wersja jest obsługiwana tylko z wcześniejszych powodów i wymaga specjalnych reguł analizy (dla sekwencji specjalnych itp.), Dlatego jest nieporęczna i nie obsługuje modyfikatorów URL.

Oznacza to, że url(...)składnia ma być notacją funkcjonalną, która przyjmuje parametry i modyfikator adresu URL jako parametry. Użyj notacji cytatowej (która tworzy token łańcuchowy) byłby bardziej zgodny ze standardami i wprowadziłby mniej złożoności.

@ Komentarz SimonMouriera w górnej odpowiedzi jest błędny, ponieważ szukał złej specyfikacji. Ten url-tokentyp został wprowadzony tylko dla starszych specjalnych reguł analizy, dlatego nie ma on nic wspólnego z cudzysłowami.


„Wersja bez cudzysłowu jest obsługiwana tylko ze starszych powodów [..]” Źródło?
Semmel

5
drafts.csswg.org/css-values-3/#ref-for-url-value-7 „Uwaga: Specjalne reguły analizy dla starszej składni <url> bez cudzysłowu oznaczają, że…”
sodatea

Przeczytałem to, ale chyba przegapiłem tę część - dzięki! Tak czy inaczej - bardzo cenna rada. Imho to powinna być zaakceptowana odpowiedź!
Semmel

Wydaje się, że w wersji 2020 wspomnianego dokumentu nie ma już mowy o „wersji bez cudzysłowu jest obsługiwana tylko ze względu na starsze wersje”.
Jahmic

11

Oto, co mówi specyfikacja W3 CSS 2.1:

Format wartości identyfikatora URI to „url (”, po którym następuje opcjonalna biała spacja, a następnie opcjonalny pojedynczy cudzysłów („) lub znak podwójnego cudzysłowu (”), a następnie sam identyfikator URI, a następnie opcjonalny pojedynczy cudzysłów (”) lub podwójny cudzysłów („), po którym następuje opcjonalna biała spacja, po której następuje„) ”. Dwa znaki cudzysłowu muszą być takie same.

Źródło: http://www.w3.org/TR/CSS21/syndata.html#uri

Tak więc wszystkie 3 zaproponowane przez Ciebie przykłady są poprawne, ale ten, który wybrałbym, jest pierwszy, ponieważ używasz mniej znaków, a zatem wynikowy plik CSS będzie mniejszy, co spowoduje mniejsze użycie przepustowości.

Może się wydawać, że to nie jest ważne, ale witryny o dużym natężeniu ruchu wolą oszczędzać przepustowość i wiele plików css, a odwołania do adresów URL w nich mają sens, aby wybrać opcję, która zmniejsza plik ... Nawet jeśli nie ma żadnej przewagi nie robiąc tego .

Uwaga: być może trzeba będzie unikać znaków, jeśli adresy URL zawierają nawiasy, przecinki, białe znaki, pojedyncze cudzysłowy lub podwójne cudzysłowy. Może to spowodować, że adres URL będzie dłuższy niż tylko użycie cudzysłowów (które wymagają mniejszej liczby znaków ucieczki). Dlatego możesz chcieć podać plik Css z adresami URL bez cudzysłowów tylko wtedy, gdy narzut związany z ucieczką nie powoduje, że adres URL jest dłuższy niż tylko użycie cudzysłowów (co jest bardzo rzadkie).

Jednak nie spodziewałbym się, że jakikolwiek człowiek weźmie pod uwagę te przypadki krawędzi ... Optymalizator CSS poradziłby sobie z tym za Ciebie ... (ale na pewno musisz wiedzieć o tym wszystkim, jeśli faktycznie piszesz optymalizator CSS: P)


5
Nie wiem, dlaczego to zostało odrzucone; w przypadku witryn o dużym natężeniu ruchu takie pomysły mają duże znaczenie w ciągu roku.
Joisey Mike,

7
↑ Naprawdę w to wątpię. Ile jest adresów URL na css? Nie za dużo. I właśnie oszczędziłeś DWIE bajty (w ascii lub utf-8) w każdym. Ponadto możesz wydłużyć adres URL, ponieważ może być konieczne użycie odwrotnych ukośników. Są znacznie lepsze sposoby na zmniejszenie rozmiaru sieci ...
kralyk

1
Oczywiście nie jest to duża oszczędność, ale Andrea i Joisey nadal mają rację. Jako skrajny przykład Google musi usunąć tylko jeden bajt ze swojej strony głównej, aby zaoszczędzić sporo przepustowości;)
Pebbl

2
@kralyk ... Dlatego najlepiej nie używać cudzysłowów, gdy nie są potrzebne ... Lepiej więc używać cudzysłowów, gdy masz adres URL z więcej niż dwoma nawiasami, przecinki, białe znaki, pojedyncze cudzysłowy lub podwójne cudzysłowy . Którego jednak nigdy nie spotkałem w pliku CSS ... I jestem prawie pewien, że nigdy tego nie zrobię :) (zaktualizowałem odpowiedź)
Andrea Zilio

18
Programiści, którzy zajmują się optymalizacją poszczególnych znaków z kodów źródłowych, całkowicie tęsknią za łodzią - prawie nigdy niczego nie zoptymalizują. W każdym razie zawsze używam podwójnych cudzysłowów. Jestem mężczyzną konsekwentnym.
ChaseMoskal

6

Według W3C trzy sposoby są legalne. Jeśli masz w nazwie znaki specjalne (jako spację), powinieneś użyć drugiego lub trzeciego.


3

Przykłady 2 lub 3 są najlepsze:

From W3C: Format wartości URI to „url (”, po którym następuje opcjonalna biała spacja, po której opcjonalny znak pojedynczego cudzysłowu („) lub podwójny cudzysłów (”), po czym sam URI, a następnie opcjonalny pojedynczy cudzysłów (”) lub znak podwójnego cudzysłowu („), po którym następuje opcjonalna biała spacja, po której następuje„) ”. Dwa znaki cudzysłowu muszą być takie same.

Uwaga z tego samego objaśnienia: Przykład 1 jest dopuszczalny, jeśli odpowiednie znaki zostaną pominięte.


1

Miałem:

a.pic{
    background-image: url(images/img (1).jpg);
}

Trochę zajęło mi zrozumienie, że nawias klamrowy nazwy pliku łamie regułę.

Nie jest to zatem obowiązkowe, ale nawet jeśli cytowanie nie jest tak dobrze rozumiane przez starsze przeglądarki, może zaoszczędzić ci bólu głowy na dość złożonych dynamicznie generowanych stronach.


0

Zgodnie ze stylem kodowania Google CSS

Nie używaj cudzysłowów w wartościach URI (url ()).

Wyjątek: jeśli potrzebujesz użyć reguły @charset, użyj podwójnych cudzysłowów - pojedyncze cudzysłowy nie są dozwolone.


2
@ DávidHorváth: Nie mówię, że się mylisz, ale jakie złe konwencje masz na myśli?
Sam Dutton,
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.