Pull to refresh
232
0
Вадим Макеев @pepelsbey

Фронтендер, влюблённый в веб, браузеры и подкасты

Send message

Вашим слайдером невозможно пользоваться с клавиатуры (дивы вместо кнопок), ваш код местами битый из-за типографских кавычек. Я всё больше боюсь за Хабр, после таких статей. Пожалуйста, не надо больше, ведь кто-нибудь и правда возьмёт этот код.

Непреодолимое ощущение, что я читаю Хабр 2006 года. Или что вы прятались в криокамере лет 10. Стиль написания кода, подход к анимации, терминология — всё это говорит о том, что вы очень сильно отстали от сообщества. Сейчас стили и скрипты пишут по-другому, не говорят CSS3 и не пишут префиксы в стилях. Почитайте статьи на CSS-Tricks, не надо пока ничего писать, а то я от испанского стыда умираю, глядя на это.

В статье были использованы материалы из статьи How React Hooks can replace React Router

Это называется перевод. Вольный, но перевод, с той же структурой, кодом и скриншотами. То есть это не вы автор, а Peter Ekene Eze. Давайте с уважением относиться к авторским текстам и не «рерайтить». У Хабра есть специальный тип статей для переводов.

имеете в виду, что rect прекрасно можно использовать с transform

Нет, гораздо больше. Сравните:


bullet-before.svg
<svg height="40px" viewBox="0 0 427 427.08344" width="40px">
  <path
    d="m341.652344 38.511719-37.839844 37.839843 46.960938 46.960938
    37.839843-37.839844c8.503907-8.527344 15-18.839844
    19.019531-30.191406l19.492188-55.28125-55.28125 19.492188c-11.351562
    4.019531-21.664062 10.515624-30.191406 19.019531zm0 0" />
  <path
    d="m258.65625 99.078125 69.390625 69.390625
    14.425781-33.65625-50.160156-50.160156zm0 0" />
  <path
    d="m.0429688 352.972656 28.2812502-28.285156 74.113281 74.113281-28.28125
    28.28125zm0 0" />
  <path
    d="m38.226562 314.789062 208.167969-208.171874 74.113281
    74.113281-208.171874 208.171875zm0 0" />
</svg>

bullet-after.svg
<svg viewBox="0 0 427 427.08"><path d="M341.65 38.51l-37.84 37.84 46.96 46.96 37.84-37.84c8.5-8.52 15-18.84 19.02-30.19L427.13 0l-55.29 19.5a81.08 81.08 0 0 0-30.19 19.01zm0 0M258.66 99.08l69.39 69.39 14.42-33.66-50.16-50.16zm0 0M.04 352.97l28.28-28.28 74.12 74.11-28.28 28.28zm0 0M38.23 314.79l208.16-208.17 74.12 74.11L112.34 388.9zm0 0"/></svg>

left-before.svg
<svg
  width="40px"
  height="40px"
  viewBox="0 0 292.359 292.359"
  transform="translate(-5 0)">
  <path
    d="M222.979,5.424C219.364,1.807,215.08,0,210.132,0c-4.949,0-9.233,1.807-12.848,5.424L69.378,133.331
    c-3.615,3.617-5.424,7.898-5.424,12.847c0,4.949,1.809,9.233,5.424,12.847l127.906,127.907c3.614,3.617,7.898,5.428,12.848,5.428
    c4.948,0,9.232-1.811,12.847-5.428c3.617-3.614,5.427-7.898,5.427-12.847V18.271C228.405,13.322,226.596,9.042,222.979,5.424z" />
</svg>

left-after.svg
<svg viewBox="0 0 292.36 292.36"><path d="M222.98 5.42A17.55 17.55 0 0 0 210.13 0c-4.95 0-9.23 1.8-12.85 5.42L69.38 133.33a17.56 17.56 0 0 0-5.43 12.85c0 4.95 1.81 9.23 5.43 12.84l127.9 127.91a17.56 17.56 0 0 0 12.85 5.43c4.95 0 9.23-1.81 12.85-5.43a17.55 17.55 0 0 0 5.43-12.84V18.27c0-4.95-1.81-9.23-5.43-12.85z"/></svg>

Ну и аналогично с right.svg. Я просто кинул файлы в SVGOMG и получил их чище и меньше, без лишних обёрток, атрибутов и мишуры.

учитывая, что в таких играх нужна очень быстрая реакция

Больше всего фронтенду любых интерфейсов нужно, чтобы мы не делали выводов о людях, о которых ничего не знаем. Я столько дичи слышал про то, что слепые и прочие «странные люди» не ходят в интернет, не смотрят Ютуб, не покупают в интернете. Нет, это не так. Делайте хорошо и доступно, а люди разберутся, как им это использовать.

Не срезайте углы, из-за вашей лени (оптимизации?) кто-то не сможет пользоваться интерфейсами.


А ещё, глядя на ваш SVG, видно, что вы в душе не понимаете, что там происходит. Разберитесь, там много лишнего очень красиво выровнено по строкам.

У вас беда с обработчиками событий, почему не повесить их динамически? Даже если вы вешаете их с помощью onclick, вы как будто бездумно скопировали их из другого примера со ссылками: javascript: … ; return false глупо писали в href ссылок 10 лет назад — чтобы кликалось, но не переходило по ссылке. Здесь кнопка и onclick, достаточно написать имя функции внутри. Ну и зачем это в форму оборачивать, у неё же нет экшена?


В общем, я бы вам рекомендовал сначала научиться писать JS, а потом писать статьи на Хабр. Вы делаете ошибки новичка: и выглядит грустно, и кто-то может поверить, что так надо писать.

Это красивая история «Чем занимались JS-библиотеки в 2018 году», а не обзор технологий фронтенда. Напомню, это HTML, CSS и JavaScript, а не React, Angular и Webpack.

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

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

Грех четвертый: циклический доклад

Вы бывали в театре, на концерте? Там люди снова и снова играют одно и то же, иногда сезон, иногда целую жизнь. Ездят по разным городам, радуют людей. Вы можете сказать: но доклады — это другое! И сведёте всё к пересказу документации. Доклад — больше, чем информация. Он не работает на видео, в пересказе, по слайдам. Очень важно быть живьём на сцене.


Я сам пишу доклад на один сезон (один до лета, другой после) и читаю его 3–5 раз в разных городах. Я стараюсь следить, чтобы видео и тексты не утекали слишком широко, пока сезон не закончится. И в каждом городе я вижу людей, которые внимательно слушают, радуются и задают вопросы. То есть доклад приносит пользу, даже если не меняется между выступлениями.


Тогда в чём проблема с повторами?

Грех десятый: высокомерие

Однако весь пост достаточно высокомерный: кругом «ящитаю» и реальные примеры докладов от хорошо знакомых спикеров. То есть все неправы, а вы молодец. Ну такое.

(дублирую с Ютуба для развития дискуссии)


Гуглоботу не нужно красиво, ему нужно чтобы разметка была нормальная. Да, есть некоторые нюансы, но вряд ли у вас либо гриды, либо сразу display: none. Ещё одна причина, чтобы начинать mobile-first, с одной длинной колонки, а потом улучшать гридами. IE11, старым Safari и Гуглоботу такое понравится. Мне кажется, что чаще всего гриды используют для глобальных раскладок. А контент уже лежит внутри каждой из частей. Тут нужно от практики идти (и там кажется нет проблем), а не ждать пока Гуглобот обновит свой Хромиум.

Это вообще не о том, хотя вы можете уловить пару общих мыслей.

Так уж вышло, надо справляться )

Спасибо, думаю так и сделаю в следующий раз.

Отличная лекция и плохая расшифровка :(


Самое плохое — слайды с текстом и кодом картинками. Это противоречит почти всему, чему учит лекция. Как так? Ну и убрать из текста контекст ШРИ, сделать его полноценным и независимым тоже несложно, но это скорее про редактирование.

Вы вроде даже приводите цитаты с bem.info, а там ведь по-русски всё написано. Но вы просто не читали. Там на все (да, вообще все) ваши претензии есть ответы.


Больше всего доставил запрет «всё блоками». Нет, правда, ржу. Вы не поняли, что блок — это не коробка, не кирпич, не что-то большое. Блок — это самостоятельная единица интерфейса. Есть блоки, у которых нел элементов и стилей 5 свойств. Это тоже блок.


Смешно, грустно, стыдно за вас. Что вот так вышли и показали себя миру, сказав гулопсть, поторопившись, не разобравшись.


Почитайте «Архитектуру CSS» Филипа Уолтона, вчитайтесь в bem.info, например в FAQ есть хорошие ответы. Ну и видео посмотрите, для вас же снимали:


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

Я понимаю, что вы привыкли. Но если вы правда писали это для новичков, то почему бы не дать примеры на CSS, а не на Sass? Вы даже не упоминаете это нигде и случайному человеку это кажется нормальным. Он копирует код, сохраняет и ничего не работает.

Information

Rating
Does not participate
Location
Berlin, Berlin, Германия
Date of birth
Registered
Activity

Specialization

Frontend Developer
Senior