Сергей delphinpro

const transformClass = document.querySelector(".info-speaker__link-wrap");
const introLink = document.querySelector(".info-speaker__link");

introLink?.addEventListener("mouseenter", (e) => {
    transformClass.classList.add("info-speaker__link-wrap-trans");
});

introLink?.addEventListener("mouseout", (e) => {
    transformClass.classList.remove("info-speaker__link-wrap-trans");
});

https://developer.mozilla.org/ru/docs/Web/JavaScri...
Оператор ?. заменяет проверку того что объект существует.

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

В одном проекте можно, в другом нельзя; одному программисту можно, другому нельзя. Если человек хочет развиваться, вы его не остановите. Если не хочет - не заставите. Проект может помогать или мешать, но сам по себе определяющим фактором почти не является. Собственно, вы сами это подтверждаете своим bio:

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

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

работодателю вообще плевать на это. и на ваше портфолио тож.

Я так понял они нужны для того чтобы сделать фронтенд части в бэкенде.

Вы неправильно поняли. Шаблонизаторы всего лишь упрощают логику генерации html бэкендом, но не имеют прямого отношения к фронтенду и вообще никакого к динамическим интерфейсам.

Во-первых, за удаление методом GET тебя ждёт спец. котёл в аду.

Во-вторых, читай документацию ларавел, про мидлвари и политики.

В-третьих, изучай основы HTTP, чтобы знать, как сделать

Например, чтобы в ссылке не было видно ID группы, а само ID отправлялось другим способом, не через URL, и чтобы запросы вида www.site.ru/group/delete/2 не работали.

Спецификаций CSS занимается рабочая группа в составе W3C. Там же есть и информация о том, как принять участие / предложить свою идею.

К примеру вы можете создать issue в репозитории рабочей группы.

Однако вам стоит понимать, что работа над спецификацией уровня CSS Grid - это многолетний труд сотен людей для того, чтобы довести её до реального использования. Если вы предполагаете что за всё это время никто из них не додумался до этой идеи - то вам стоит подумать ещё раз.

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

За примерами далеко ходить не нужно: parent selector - мечта уже нескольких поколений разработчиков и тема постоянных вопросов. Однако его нет в спецификации (хотя он был в первых драфтах CSS 3 насколько я помню) и скорее всего не будет. Причину, если интересно, попробуйте поискать сами.

Или, к примеру, такое очевидное, казалось бы, опущение как отсутствие аналога :hover для "stuck" состояния элемента с position: sticky. Ведь его явно не хватает почти любому кто использовал этот стиль. Однако его не будет, о причинах (логичных, но далеко неочевидных) можно почитать в соответствующем issue.

Конечно, если вы внимательно и детально изучите все спецификации и проработаете и напишете своё предложение - оно, вероятно, будет рассмотрено. Но более вероятна ситуация что где-то здесь вы найдёте аналогичную или близкую идею.

Они называются badges.
Брать отсюда: https://shields.io/

Теги - это все же про HTML, а не про CSS.

А со всем, что есть в CSS, можно познакомиться на сайте W3C. Они заботливо делают странички с состоянием CSS на текущий год, где есть перечисление всего со ссылками на стандарты, где можно более подробно обо всем почитать. Но это такой источник информации для теоретиков, если хотите погрузиться действительно глубоко. На сайте MDN есть почти то же самое, но в формате, более ориентированном на практику, чем на теорию.

Отвечу всё же на заданный вопрос:

Откуда это берется вообще? /*!40001 SQL_NO_CACHE */ и как это убрать?

Это - комментарий с фрагментом запроса, специфичным для MySQL.

Помещается в тело запроса (в т.ч. в дамп) для того, чтобы запрос, использующий какую-либо специфичную для MySQL конструкцию, мог быть выполнен в другом SQL-диалекте без внесения изменений в текст запроса. Т.е. MySQL обрабатывает содержимое такого комментария так, словно этот фрагмент не закомментирован, тогда как другие СУБД проигнорируют этот фрагмент как комментарий.

Опциональное пятизначное число указывает минимальную версию MySQL, начиная с которой содержимое комментария должно обрабатываться (в показанном фрагменте - это версия 4.00.01), на более младшей версии комментарий останется комментарием. При его отсутствии (используется только /*!) - код из комментария обрабатывается любой версией.

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

Если это JSON'ы локальные, то держать их в базе данных.
Если они берутся с удалённого сервера, то кэшировать их в БД, периодически загружая их туда отдельным скриптом.

Смотря что за эффекты, зачем они нужны, какое пользователь ожидает поведение и какие есть другие стили. Иными словами - никакого "правильного" способа нет.
Если же вертеть в вакууме сферического коня, то логичнее всего обычно "анимировать" ссылку.

Раздел "матрицы" в математике, наверное, будет ближайшим, для понимания текста.

А вообще тут базовое понимание текста, к математике не особо относящееся.

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

Таким образом, при входном параметре size = 3, нужно построить таблицу 3х3.

Как пофиксить баг с панелью задач?

1. Установи винду отсюда: https://www.microsoft.com/en-us/software-download/...
2. Отключи ненужное самостоятельно и осознано (возможность включить обратно сохранится)
3. Опыт

P.S.
Пытаться восстанавливать не смысла, ты запорол себе систему, либо она уже была запорота уже в установщике. Точек восстановления у тебя только одна, это свежая установка винды.

li:not(:first-child, :last-child)

или

li:not(:first-child):not(:last-child)

или

li {
  /* тут стили для всех элементов */
}
li:first-child,
li:last-child {
  /* здесь сбрасываете стили, установленные выше */
}

https://jsfiddle.net/6zxdwear/

Что в переменной input?
Причём тут .push() и обращаться через input['agreements']?
Вы знаете что у Вас в коде происходит push сразу двух элементов? Один строка, второй массив.
И главный вопрос: сложить? Сложить что с чем?

По видимому, Вам надо что-то вроде этого:

var input = {
 agreements: [$('#single_product .display-block .btn').attr('data-agreements')]
}

А если переменная inputуже инициализирована, то

input.agreements = [$('#single_product .display-block .btn').attr('data-agreements')]

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

Больше никак

command line interface уже давно выработал очень простой стандарт.

Есть команда (внутренняя команда оболочки или внешняя утилита, вроде nodejs)
Есть аргументы к команде
Аргументы логически делятся на опции и параметры.

Опции обычно начинаются с дефиса или двух (в POSIX стандарте один дефис для коротких опций, вроде -h, -e, два дефиса для длинных опций, вроде --help, --environment)
Некоторые опции могут требовать параметр (--environment prod), некоторые нет.

Параметры - это сами данные - названия файлов, устройств, другие данные в виде текста

По стандарту POSIX короткие опции, которые не требуют дополнительного параметра, могут объединяться под одним дефисом ( пример: rm -rf )

Список конкретных опций и параметров у каждой утилиты свой. Не все утилиты строго следуют POSIX, поэтому могут быть варианты. Для этого читай документацию конкретной утилиты.
Таким образом твой вопрос относится не к nodejs, а к общим стандартам работы в командной строке.

Ну и еще в CLI есть перенаправления, это отдельная лекция.

<div id="test" data-color="#ff0000" data-test="test">
  div
</div>

const div = document.querySelector('#test');

console.log(div.dataset); // DOMStringMap {color: '#ff0000', test: 'test'}