Noder SS

В зависимости от требования к скорости доставки изменений для всех пользователей, то эту задачу можно решить разными способами.
1. Низкие требования к скорости оповещения - "когда пользователь решит сам обновить или перейти на другую страницу, тогда и выведем новое состояние (новый статус, новое сообщение)".
Классическая форма взаимодействия браузера с сервером.
Один пользователь набирает сообщение в обычной форме (без ajax). Отправляют его на сервер. Сервер сохраняет его в любой форме. Когда другие пользователи запрашивают у сервера страницу с сообщением или статусом, то они получают новое состояние, если сами сделали какое-то действие, связанное с переходом на другую страницу.
Так работают старые веб почтовики и форумы 2000-х годов.
2. Средние требования к скорости оповещения - "пользователь не должен предпринимать никаких действий, чтобы он получил новое состояние, но получать состояние можно раз в несколько минут и более".
Один пользователь набирает сообщение, отправляет на сервер. А другие пользователи запрашивают новое состояние страницы у сервера по технологии ajax. Проблема в том, что инициатором получения изменений от первого пользователя являются клиентская часть приложения пользователей, которые ждут изменений на сервере, а не приложение сервера. Поэтому когда первый пользователь отправит сообщение, то другие пользователи получат его не сразу, а когда наступит следующий период опроса сервера.
Это требование подходит для интернет магазинов, чтобы отслеживать статус заказа, новые почтовики.
3. Высокие требования к скорости оповещения - "пользователь должен незамедлительно получать изменения от сервера, как только другой пользователь сделает действие".
Вот тут уже на стороне ожидающих пользователей работает технология websocket. Клиентская часть этих пользователей создает соединение с сервером и ждет от него отклика, когда другой пользователь напишет сообщение. Постоянные опросы состояния, как в случае 2 таким пользователям проводить не нужно.
Но для websocket есть ограничения, что не каждый веб сервер для него годится. Например, с PHP его сложнее подружить, чем с NodeJS. Вся проблема в том, что PHP не приспособлен для обработки множества запросов на одно соединение, в NodeJS и других средах, где такая концепция заложена изначально, проблем не будет с реализацией.
С такими требованиями работают современные чаты в любых мессенджерах.

Как сделать анимацию не подскажу, но как сделать кнопку в скошенном состояние то Сайт, надеюсь я чес-то помог

Это называется sticky menu. Можете использовать какой нибудь плагин для этого. Если хотите научится самим делать этого вот пример где это описано.

.btn-item-main2 { 
    transform: skew(23deg)       
}

Преобразование не является наследуемым свойством.
Но согласно спецификации, преобразование создаёт новое "пространство координат" для своих дочерних элементов, это то, что происходит в вашем примере. Значение свойства преобразования равно none, но это не означает, что на него не влияет преобразование родительского элемента.
www.w3.org/TR/css-transforms-1/#transform-rendering

Например:

.button {
    background: #63319f;
    padding: 10px 45px;
    color: #fff;
    clip-path: polygon(85% 0, 100% 50%, 85% 100%, 15% 100%, 0% 50%, 15% 0);
}

атрибут name есть у тега select.

htmlbook.ru/css/selection?

// «функция(не важно, сколько раз)»
const readBook = () => console.log('A B C');

// кнопка, которую много раз
const btnRead = document.getElementById('btn-read-book');
btnRead.addEventListener('click', readBook);

// другая кнопка, которая всё.
document.getElementById('btn-lights-out')
  .addEventListener(
    'click',
    () => btnRead.removeEventListener('click', readBook)
  );

Так имеете ввиду?