не должен и в "базовом стандарте"в3ц - не стандарт, а рекомендация, а строковые параметры отделяются кавычками по стандарту (большинства) языков (и языков разметки в том числе). Другое дело что возникает чехарда с кавычками, когда сам параметр уже в кавычках (по сути уже строка), как в случае инлайнового стиля, и приходится либо не писать кавычки, либо использовать одинарные и двойные для разделения. В том числе для предотвращения разночтений между заковыченным текстом и продолжением строки. А в случае локальных виндовых адресов или нестандартных путей без этого вообще работать не будет. То есть все это расписывать, упоминать что стили в свое время не имели обязательного отделения кавычками в инлайновом описании в половине браузеров и тд пожалуй длинновато. Короче написать "нужны кавычки".
Поэтому ваше утверждение "урл должен быть в кавычках" не должно быть категоричным.Тут да, высказывание звучит как утверждение, хотя на самом деле рекомендация. И кстати в формате представленным ТС вполне может не работать без кавычек, так как русские символы, пробелы и разный регистр в урл без кавычек вообще не понятно как будет работать в такой солянке.
тут же задана высотамаксимальная высота, а минимальная или базовая не задана, по умолчанию она нулевая.
background - это сокращенное свойство, которое включает в себя и background-image.ага, а теперь пройдите по ссылке и посмотрите что же рекомендует в данном случае мдн. Вообще - да, кавычки опциональны, но в базовом стандарте они были, и в доках везде по прежнему они есть. Лучше поставить, так и семантически отделяется строковое значение, и с базовым определением совпадает.
//Убираем Notice, а все остальные ошибки выводимТак делать не нужно, выводить нужно ВСЕ о чем предупреждает интерпретатор, выключить ошибки можно только на продакшне, когда проект завершен и оттестирован.
я хочу точно знать определение.Зачем? Это же не школьный учебник математики, в котором кстати от издания к изданию тоже есть разница в определениях, а вполне себе гибкое понятие, кроме всего прочего немного различающееся в языковых реализациях. Ну и если уж на то пошло - нюансы перевода и интерпретация цитирующих (дабы не выглядеть плагиатором и показать себя умнее прочих). Так что - что в лоб, что по лбу, все едино.
Способ проще: Читать доки мускуля и SQL в целом, научиться делать join, group by, count, ну или заплатить нормальному специалисту за 1-2 запроса, чтобы сделали нормально, если сами не сможете.
На будущее - если у вас запросы в цикле - 99% что вы делаете плохой код. Единственный вариант когда это приемлемо - внесение больших массивов данных, но никак не чтение!