Al

Градиенты нельзя анимировать в рамках CSS "в лоб". Но можно сделать несколько элементов с разными градиентами друг над другом и менять им прозрачность:

Вот список свойств, которые можно анимировать, и background-image среди них нет. Т.е. оно меняется, конечно, но плавности не ждите.

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

Вы считаете себя программистом, и до сих пор не знаете что в Windows crlf а в Linux lf?

Настройка в git существует изначально.
Проблема переноса строк существует с тех пор, когда появился DOS и Windows со своей кодировкой. И чтобы сейчас не изобретали, эта проблема будет оставаться. Точнее не проблема, если есть конфиг.
В общем ваше нытье удивляет.

gmx.com

.polygon {
    clip-path: polygon(5px 0,100% 0,100% calc(100% - 5px), calc(100% - 5px) 100%,0 100%,0 5px);
}

не особо понятно что ты хочешь, но если это то о чем я думаю то тебе поможет bennettfeely.com/clippy

Нет правильной причины не оборачивать строки в кавычки. По гайдлайнам CSS/SCSS - все строки оборачиваются в одинарные кавычки(их проще набрать на клавиатуре, чем двойные), для лучшей читаемости кода(подсветка кода срабатывает на содержимое кавычек) и для того, чтобы синтаксический анализатор не полыхнул пламенем при виде строки без кавычек.

Комментарий Евгений Петров не соответствует действительности - CSS не требует, чтобы строки были помещены в кавычки, даже те, что содержат пробелы. Строка в кавычках является точным соответствием её двойника без кавычек. Просто в предложенном примере с data:uri в строке имеются другие кавычки и интерпретатор банально сходит с ума, такие символы нужно экранировать.

Зависит от того, что наниматель вкладывает в "слежение". Может понадобиться:

1. Уверенное знание Linux и, соответственно, умение работать в консоли.
   
2. Знание SQL и используемой СУБД.
   
3. Понимание общих принципов работы сетей в целом и Web в частности.
   
4. Знание языка программирования, на котором написан сайт.
   
5. Знание фреймворка, на котором написан сайт.
   

В такой постановке изучить понадобится с десяток учебников.

Но если задача ограничивается только "обновлять цены/дополнять разделы/etc", то нужно на пользовательском уровне знать используемую CMS. С этим справляются и анекдотично блондинистые девочки-маркетологи.

Завтра мне нужно будет "следить" За сервером. Что мне понадобится изучить и какие учебники можете посоветовать?

Если от этого "поезда" не убежать, то советую перед каждым действием - 5 раз гуглить, 10 раз перечитать информацию, если есть возможность не править код в наглую в "мастере" и на боевом сервере(накатить на dev и оттестировать"), как можно чаще задавать себе вопрос "а не делаю ли я что-то, что может привести к факапу и увольнению за нецелесообразность".

1) Вы не помогаете ни себе в будущем, ни будущему разработчику читать код сайта. Так как всё - див, то не понятно на первый взгляд, функциональный он или же просто обёртка. Хотя див по своей задумке должен быть обёрткой и только обёрткой.
2) Вы не помогаете людям, пользующимся интерфейсом не только мышкой, не только глазами. Семантические теги помогают строить дерево доступности, которое помогает быстрее навигироваться по странице и понимать что на ней вообще есть.
3) Вы не помогаете поисковым системам понять, что на сайте за контент. Поисковые системы любят семантику. Любят семантические сайты. Поэтому если всё хорошо размечено, то в поисковой выдаче сайт будет выше, а так же может быть более качественный и информативный сниппет ответа на запрос пользователя, а это положительно сказывается на пользовательском опыте и конверсии для сайта.
4) Если Вы даже кнопки и ссылки верстаете дивами, то гореть вам синим пламенем Вы теряете нативное поведение этих элементов, которое Вам придётся эмитировать. Причём полностью повторить его, скорее всего и не удастся. Например: если вместо ссылки Вы делаете div c событием onClick, в обработчике клика указываете что нужно перейти на такую-то страницу, то переход будет осуществляться СТРОГО по событию клика. На этом диве Вы не сможете нажать колёсиком, как на ссылке, чтобы открыть её в новой вкладке. На этом диве, если нажать правой кнопкой мыши, в контекстном меню НЕ будет кнопки "Открыть в новой вкладке". На этом диве Вы НЕ сможете использовать CSS селекторы :active, :visited и тд. Если это див будет, каким-то чудом, в фокусе, Вы НЕ сможете нажатием на пробел "перейти по ссылке" и это только то, что касается ссылок, и то не всё.

В чём минус вёрстки только дивами? Проще ответить на вопрос: в чём достоинство? Ответ: ни в чём.

P.s. Да, можно достичь почти всего вышесказанного только дивами, но для этого нужно грамотно и весьма геморно пользоваться aria-* и role атрибутами, а так же городить кучу лишнего js`а.

годится вполне, для введения,
потом практика и узкоспециализированные

Орейли в целом высокий уровень, не индусы с ПактПаба