list_109

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде ( сортировка, текущая страница в блоге, строка поиска и т.п. ).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта ( логины, пароли, номера кредиток, сообщения и т.п. ).

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

Вопрос: какой же все же способ подключения svg наиболее оптимальный, удобный, а главное качественный?

Оптимального не существует, все зависит от конкретной задачи. Для спрайтов и иконок я предпочитаю инлайновый svg - да, это увеличит html на десяток килобайт, но не критично, gzip наше все. Зато это дает огромную гибкость в управлении иконками и их стилизации. Забейте на громоздкий html - сейчас ситуация такова, что в любом случае приходится чем-то жертвовать, идеальных технологий нет. Поэтому нужно выбирать - красивый html или гибкость в управлении. Используя же систему сборки + шаблонизатор вроде pug, вы вообще с html не будете иметь дела.

Для отдельных изображений сподручнее применять отдельные же svg-файлы. Для простых иконок, с которыми априори не нужно никаких манипуляций, можно использовать фоновый svg.

Как вариант, можно захардкодить стили (анимацию там, эффекты) прямо в svg - это нормально, ведь адаптивность для svg только так и можно сделать. Тогда вы сможете сохранить нехилую долю возможностей вкупе с изящной реализацией, подключая svg к странице посредством, например, fragment identifiers.

Генерировать svg в font - это костыль. Нормально, если шрифт генерируется в формат svg, но если спрайт генерируется в font, то это уже извращения. Кроме того, браузеры по-разному рендерят решения на основе данного подхода, что снижает качество продукта.

Я за 2й способ. Используя тег use вставляем id символа, а перед этим вставляем весь спрайт на страницу. Этого способа достаточно, что бы через css спокойно менять размеры, заливку. Чаще всего такой способ и нужен. Просто используя конструкции серверного языка, вставить содержимое на страницу. Я это делаю обычно перед тегом </body>

Можно каждую иконку вставлять svg кодом, как это делает github. Скорей всего на сервер у них есть какая-то функция, которая просто вставляет содержимое указанной иконки. На php можно просто использовать функцию include();

Можно просто собрать весь спрайт в 1 иконку и так же через тег use вставлять их на страницу, указываю путь к id символа:
<use xlink:href="/app/img/icons.svg#ico"></use>

Вставлять фоном можно, но я не рекомендую, т.к. теряется возможность изменять свойства через css. Про размытие слышу 1 раз.

Все из способов верные, с точки зрения спецификации. Но с последним способом у меня были проблемы. Иногда иконка не отображалась, в IE вообще так не выводятся, но это его не доработка.

Вот видосик, для большего понимания https://www.youtube.com/watch?v=TNX0-JLdM_U

Все довольно просто:

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

модификатор позволит добавить какие-то особенности блоку или элементу, для модификатора блока в стили можно писать все (кроме отступов и позиционирования*), для модификатора элемента можно все.

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

*position, display, float, margin

Почему все молчат о том, что второй вариант нарушает синтаксис CSS и не будет работать в принципе?!

Автор не упоминает препроцессоры, в тегах тоже нет. Значит речь идёт о нативном css, в котором только первый вариант и возможен.

НО, даже в первом варианте я категорически не рекомендую писать так, как вы написали. Гораздо лучше и удобнее будет так:

/*== Какой-то блок на странице */
.class-1 {
  /* стили для экранов 767px и менее */
}
@media (max-width: 767px) {
  .class-1 {
    /* стили для экранов 767px и менее */
  }
}

/*== Какой-то другой блок на странице */
.class-2 {
  /* стили для экранов 767px и менее */
}
@media (max-width: 767px) {
  .class-2 {
    /* стили для экранов 767px и менее */
  }
}

/*== И так далее… */
…

Код должен быть структурирован. Стили, описывающие отдельный селектор, всегда должны быть все вместе и рядом.

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

Повторю ещё раз: главное — структурированность кода! Пишете один раз, читаете и дорабатываете — сотни. Облегчайте себе будущие чтение и модификацию кода, который пишете.

Если предполагается, что никто после вас не будет редактировать выходной CSS, и весь проект будет собираться сборщиком, то второй вариант удобнее, т.к. получается удобный компонентный подход.
Допустим, есть компонент "кнопка", и для него отдельный файл /blocks/button.scss, очень удобно писать стили для этой кнопки только в этом файле. И если соблюдать БЭМ, если создавать переменные, то позже, этот компонент (блок) можно будет использовать в других проектах, без дополнительного редактирования. Скопировал файл, поменял переменные (для оформления, цвет, отступы, размеры, шрифт и.т.д.), подключил и готово.
Но одно замечание, лучше сразу определите миксины (или переменные) для этих медиа запросов, чтобы не было сотни разных медиазапросов аля 300px, 320px, 400px и.т.д. Можно позаимствовать из Bootstrap 4

Первого варианта придерживаюсь при написании стилей на чистом css и без сборщиков, т.к. легче писать последовательно для разных устройств. Но такое случается редко, только если поддерживать старый проект.

Подключать отдельно JQuery есть смысле если подключать его с CDN google, ибо там ответ будет скорее всего быстрее чем на вашем хостинге и намного более вероятнее что этот JQ файл уже есть в кэше у пользователя. Ну и в идеале если не подключилось то загружать его с локального хранилища. Это будет полезно при разработке если нет доступа к интернету или типа того.

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="/assets/js/vendor/jquery.min.js"><\/script>')</script>

Пример взят с bootstrap.

Сначала были Промисы и девелопер понял что это хорошо. Но девелопер задумался, а можно ли перестать писать then().then()... Но async\await еще не было, тогда девелопер взял функцию генератор смешал с промисом и родилось - co Это выглядело немного страшненько (имхо), но хайп был, который наплодил много статей почему это спасение - порой слог был такой уверенный, что вводил в заблуждение. А потом появились async\await - которые промисы, но без then().then().

Промисы это промисы, их надо понять в любом случае. Зная промисы, async\await понимается быстро и полностью.
Генераторы (то что вы имеете в виду) это самописный сахар для реализации async\await подобного поведения до того как появился async\await. Т.е. это не реализация языка, а просто код обертка.
Async\await - это уже реализация языка, которая основана на промисах.