Действительно ли необходимо указывать значение url ()?


235

Что из следующего я должен использовать в своих таблицах стилей?

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

Что W3C указывает как правильный путь ?


Ответы:


243

W3C говорит, что цитаты не являются обязательными, все три ваших способа являются законными.

Открывающая и закрывающая цитата просто должна быть одного и того же символа.

Если в вашем URL есть специальные символы, вы должны использовать кавычки или экранировать символы (см. Ниже).

Синтаксис и основные типы данных

Формат значения URI: «url (», за которым следует необязательный пробел, за которым следует необязательный символ одинарной кавычки (') или двойной кавычки ("), за которым следует сам URI, за которым следует необязательная одинарная кавычка (') или двойная кавычка ("), за которым следует необязательный пробел, за которым следует") ". Два символа кавычки должны быть одинаковыми.

Экранирование специальных символов:

Некоторые символы, появляющиеся в URI без кавычек, такие как круглые скобки, символы пробела, одинарные кавычки (') и двойные кавычки ("), должны быть экранированы с помощью обратной косой черты, чтобы полученное значение URI было токеном URI:' \ (', '\)'.


9
Некоторые старые браузеры могут иметь проблемы с указанными URL, а именно IE Mac.
mveerman

5
В дополнение к тому, что сказал bic72, некоторые старые браузеры также делают двойные запросы, когда сталкиваются с цитируемыми URL-адресами в CSS, сначала они запрашивают «myfile.png», а затем myfile.png - поэтому я и избегаю их использовать.
Пеббл

Похоже, что спецификация, на которую вы ссылаетесь, была переписана с тех пор, как вы опубликовали вторую цитату. Теперь запятые не требуют экранирования.
Бен

@pebbl - Вы правы, и в старых браузерах установлена ​​новейшая версия Chrome для Mac.
Дэниэл Бердсли

7
Последний проект редактора CSS 3 (май 2015 г.), по-видимому, больше не допускает кавычки: dev.w3.org/csswg/css-syntax (проверьте url-tokenсхему железной дороги), тогда как текущая рекомендация кандидата (февраль 2014 г.) делает это: w3.org/TR / css-syntax-3 Полагаю, они хотят продвигать использование escape-последовательности вместо кавычек
Саймон Мурье

34

Лучше использовать кавычки, потому что это рекомендовано по новейшему стандарту и меньше случаев.

Согласно новейшей редакции проекта CSS-значений и модулей уровня 3 (18 декабря 2015 г.)

URL - это указатель на ресурс и функциональная нотация, обозначаемая <url>. Синтаксис <url>:
<url> = url( <string> <url-modifier>* )

Версия без кавычек поддерживается только по старым причинам и требует специальных правил синтаксического анализа (для escape-последовательностей и т. Д.), Поэтому она громоздка и не поддерживает модификаторы url.

Это означает, что url(...)синтаксис должен быть функциональной нотацией, которая принимает строку и модификатор url в качестве параметров. Использование кавычки (которая создает строковый токен) будет более совместимым со стандартом и будет представлять меньшую сложность.

Комментарий @ SimonMourier в верхнем ответе неверен, потому что он искал неправильную спецификацию. url-tokenТип вводятся только для правил наследия специального разбора, так вот почему он не имеет ничего общего с кавычками.


«Версия без кавычек поддерживается только по устаревшим причинам [..]» Источник?
Семмел

5
drafts.csswg.org/css-values-3/#ref-for-url-value-7 «Примечание. Специальные правила синтаксического анализа для устаревшего синтаксиса <url> без кавычек означают, что…»
sodatea

Я прочитал это, но, должно быть, пропустил эту часть - спасибо! В любом случае - очень ценный совет. Имхо это должен быть принятый ответ!
Семмел

Версия ссылочного документа 2020 года, по-видимому, больше не упоминает, что «версия без кавычек поддерживается только по устаревшим причинам».
Джахмик

11

Вот что говорит спецификация W3 CSS 2.1:

Формат значения URI: «url (», за которым следует необязательный пробел, за которым следует необязательный символ одинарной кавычки (') или двойной кавычки ("), за которым следует сам URI, за которым следует необязательная одинарная кавычка (') или двойная кавычка ("), за которым следует необязательный пробел, за которым следует") ". Два символа кавычки должны быть одинаковыми.

Источник: http://www.w3.org/TR/CSS21/syndata.html#uri

Таким образом, все 3 предложенных вами примера верны, но я бы выбрал первый, потому что вы используете меньше символов, и, следовательно, полученный CSS-файл будет меньше, что приведет к меньшему использованию полосы пропускания.

Может показаться, что это не важно, но веб-сайты с большим трафиком предпочитают экономить трафик и больше, чем CSS-файлы, и ссылки на них в них имеет смысл выбрать вариант, который делает файл меньше ... Даже потому, что нет никаких преимуществ не делая этого .

Примечание: вам может потребоваться экранировать символы, если URL содержат круглые скобки, запятые, пробельные символы, одинарные или двойные кавычки. Это может сделать URL длиннее, чем просто использование кавычек (которые требуют меньше экранирования). Следовательно, вы можете использовать Css-файл с URL-адресами без кавычек, только если накладные расходы на экранирование не делают URL-адрес более длинным, чем просто использование кавычек (что очень редко).

Однако я не ожидал бы, что какой-либо человек даже рассмотрит эти крайние случаи ... Оптимизатор Css справится с этим за вас ... (но вам обязательно нужно знать обо всем этом, если вы на самом деле пишете оптимизатор css: P)


5
Не знаю, почему за это проголосовали; для сайта с высоким трафиком подобные идеи имеют большое значение в течение года.
Джойси Майк

7
Я действительно сомневаюсь в этом. Сколько URL есть на CSS? Не слишком. И вы просто сэкономили два байта (в ASCII или UTF-8) в каждом. Кроме того, вы можете увеличить URL-адрес, потому что вам может понадобиться использовать обратную косую черту. Есть намного лучшие способы уменьшить размер сети ...
kralyk

1
Очевидно, это не особо помогает, но Андреа и Джойси все еще правы. В качестве крайнего примера, Google нужно только удалить один байт со своей домашней страницы, чтобы сэкономить немного пропускной способности;)
Pebbl

2
@kralyk ... Следовательно, лучше всего не использовать кавычки, когда они не нужны ... Поэтому лучше использовать кавычки, когда у вас есть URL-адрес, содержащий более двух скобок, запятые, символы пробела, одинарные или двойные кавычки , Что, однако, я никогда не встречал в Css-файле ... И я уверен, что никогда не буду :) (обновил ответ)
Андреа Зилио

18
Программисты, которые занимаются оптимизацией отдельных символов из своих исходных кодов, полностью упускают возможности - они вряд ли когда-либо вообще что-то оптимизируют. В любом случае, я всегда использую двойные кавычки. Я человек последовательности.
ChaseMoskal

6

Три способа являются законными в соответствии с W3C. Если у вас есть специальные символы в имени (как пробел), вы должны использовать второй или третий.


3

Пример 2 или 3 являются лучшими:

От W3C: формат значения URI: «url (», за которым следует необязательный пробел, за которым следует необязательный символ одинарной кавычки (') или двойной кавычки ("), за которым следует сам URI, за которым следует необязательная одинарная кавычка (') или символ двойной кавычки ("), за которым следует необязательный пробел, после которого следует ')'. Два символа кавычки должны быть одинаковыми.

Примечание из того же объяснения, Пример 1 является приемлемым, если соответствующие символы экранированы.


1

Я имел:

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

Мне потребовалось некоторое время, чтобы понять, что закрытое в скобках имя файла нарушает правило.

Так что это не обязательно, но даже если цитирование не очень хорошо понимается старыми браузерами, это может избавить вас от головной боли на довольно сложных динамически генерируемых страницах.


0

Согласно Google CSS Coding Style

Не используйте кавычки в значениях URI (url ()).

Исключение: если вам нужно использовать правило @charset, используйте двойные кавычки - одинарные кавычки недопустимы.


2
@ DávidHorváth: Я не говорю, что вы не правы, но какие плохие соглашения вы имеете в виду?
Сэм Даттон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.