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

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

  • Разрабатываем игру на Svelte 3
    0
    имеете в виду, что 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 и получил их чище и меньше, без лишних обёрток, атрибутов и мишуры.

  • Разрабатываем игру на Svelte 3
    +1
    учитывая, что в таких играх нужна очень быстрая реакция

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

  • Разрабатываем игру на Svelte 3
    +1

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


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

  • Изучаем принцип работы единиц измерения em на примере задачи «Верстка гибкого прелоадера»
    +1

    Не хватает ссылки на CodePen с живым кодом.

  • Организация поиска по веб-странице на JavaScript (без jQuery)
    +2

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


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

  • Изучаем принцип работы процентов для свойства padding-top на примере задачи «Верстка плейсхолдера для изображений»
    0

    Picture — управляющая конструкция вокруг img, а img прекрасно умеет object-fit и object-position. Другой вопрос, что вы их не умеете :)

  • Изучаем принцип работы процентов для свойства padding-top на примере задачи «Верстка плейсхолдера для изображений»
    0
    контентные изображения не надо фоном делать

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

  • Изучаем принцип работы процентов для свойства padding-top на примере задачи «Верстка плейсхолдера для изображений»
    +1

    Новичкам конечно будет полезно узнать про этот трюк, но причина обозначена неудачно. Беда в том, что если картинка не 16:9, то от прыжков мы всё равно никуда не денемся. Только если договоримся прописывать размеры в атрибутах на сервере.

  • Фронтенд-2018: итоги года
    +4

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

  • 10 смертных грехов спикера
    +1

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

  • 10 смертных грехов спикера
    0

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

  • 10 смертных грехов спикера
    +3
    Грех четвертый: циклический доклад

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


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


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

  • 10 смертных грехов спикера
    +1
    Грех десятый: высокомерие

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

  • Меню для меню, гриды или Бутстрап, целесообразность удобства
    0

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


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

  • Меню для меню, гриды или Бутстрап, целесообразность удобства
    0

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

  • Меню для меню, гриды или Бутстрап, целесообразность удобства
    0

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

  • Меню для меню, гриды или Бутстрап, целесообразность удобства
    +1

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

  • Доступность интерфейсов. Лекция Яндекса
    0

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


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

  • BEM'a не должно существовать
    +15

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


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


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


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


  • Кастомный подход для нормализации и сброса стилей (custom-reset.css)
    –1

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

  • 5 приемов работы с CSS, о которых вам следует знать
    +7

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

  • Исследование Ivy — нового компилятора Angular
    0

    Шакид, всё же.

  • Веб-компоненты. Часть 3: html шаблоны и импорты
    +4

    HTML-импорты считаются тупиковой веткой: они, например, уже есть за флагом в Firefox, но включать их не планируют. Не удивлюсь, если их выпилят и из Chrome. Альтернатива — ES-импорты.

  • Реактивный фронтенд. История о том, как мы снова всё переписали
    0

    Предвосхищая «ой, ну подумаешь» и оставляя в стороне то, что код не выделить и не скопировать, да и индексации ноль, я просто оставлю одну картинку. Зашёл почитать статью на мобилке:


  • Реактивный фронтенд. История о том, как мы снова всё переписали
    +4

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


    Попробуйте может объяснить, я даже готов понять.

  • Приглашаем на Front-end MeetUp в Райффайзенбанк UPD: Трансляция митапа
    +3

    В тексте поста нет слова «Москва». Добавьте его, пожалуйста, в заголовок. «Ну а где ещё?» — это синдром дефолт-сити.

  • Полезное дизайнеру и разработчику. Свежие утилиты и инструменты для ускорения работы. Выпуск № 10
    +1

    Спасибо за дайджест. Только у меня личная просьба: можно без & в заголовке? Это я магазину Шубы & Меха могу простить, они не ведают, что творят, но тут вроде дизайнеры, люди не чуждые здравому смыслу.

  • Начинающему веб-мастеру: делаем одностраничник на Bootstrap 4 за полчаса
    +2

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

  • Начинающему веб-мастеру: делаем одностраничник на Bootstrap 4 за полчаса
    +11

    Такое ощущение, что я попал в 2003 год: комментаторы кивают головами «хорошая, хорошая статья, ну… разве что недостатки мелкие есть». Да вы с ума сошли все: <font color="#3AC1EF"> и сингл-пейдж на jQuery, серьёзно?


    Опять вы переводите всякий мусор, не понимая, что делаете. Здесь очень много вредных советов для новичков. HTML, CSS, JS — весь код кричит «я с позавчерашнего дня во фронтенде, но вот вам статья».

  • Сортировка списков на CSS
    +2

    Только не надо делать вид, что это рабочее решение. Оно недоступно с клавиатуры, для скринридеров и не выглядит проще. В чём, собственно, профит решений на чистом CSS? В том, что вам не нужно писать JS? На любом сайте уже куча JS.


    Давайте сделаем правильный выбор между плохой сортировкой на CSS и хорошей на JS.

  • Html страница глазами разработчика приложений. Часть 1: «Подготовка»
    +1

    Ну давайте разбираться. То, что я приведу ниже — это не повод поспорить (оправдаться) по каждому пункту, это общепринятые практики в современной вёрстке. Я её практикую сам и учу в рамках HTML Academy — это мой ответ на вопрос «а где научиться?»


    1. Опасные селекторы: #main может встречаться только один раз на странице, а значит никакой универсальности и сделать второй элемент с такими же стилями не получится. Плюс селектор по #id специфичнее, а значит его будет сложно перебить. Напротив, header может встречаться несколько раз на странице, а вы к нему обращаетесь глобально, мол, вообще все header на странице. Селектор .scroll-nav li a слишком зависит от структуры HTML, которая может и будет меняться.


    #main { … }
    header { … }
    .scroll-nav li a { … }

    Один из признаков того, что у вас проблемы с селекторами — это !important, который сам по себе является антипаттерном.


    .lang-first-init {
        display: none !important;
    }

    Вывод: сегодня подавляющее большинство разработчики пишут селекторы вида .main и .header, это самое гибкое и удачное решение. Познакомьтесь с подходом БЭМ — это хорошая система именования классов и описания интерфейсов, которая сегодня мейнстрим в разработке интерфейсов.


    2. Синтаксические ошибки: Это не CSS-комментарии (они выглядят так: /* … */) и такой код ломает следующий за ним селектор, то есть все стили для header не применятся.


    <---------------header--------------->
    header { … }

    Да, это «всего лишь пример в статье», но это показывает небрежность. Скопированный отсюда код сломается.


    3. Префиксы: В одном месте вы пишете очень подробную батарею префиксов для свойства transition, а в другом не пишете для animation и @keframes, притом, что кроссбраузерность у transition на поколение-два браузеров лучше, чем у animation.


    .transition{
        -webkit-transition: all 500ms linear;
        -moz-transition: all 500ms linear;
        -o-transition: all 500ms linear;
        -ms-transition: all 500ms linear;
        transition: all 500ms linear;
    }
    @keyframes hideBlock {
        …
    }

    Уже года три верстальшики не пишут префиксы для браузерных свойств руками. Для этого используется Автопрефиксер, которому вы, при желании, можете скормить список браузеров, которые вы хотите поддерживать. Код с префиксами слишком раздувается, а их наличие — признак устаревшего кода и отсутствия шага сборки (оптимизации) этого кода.


    4. Технологии вёрстки: Вы используете только флоаты float: left, которые хоть и продолжают работать во всех браузерах, но уже пару-тройку лет как уступили место флексам display: flex. Флексы гораздо удобнее: их не нужно клиарить, вертикальное выравнивание и колонки одинаковой высоты в них — ерундовое дело.


    <div class="clearfix"></div>

    Когда в коде есть .clearfix, то этот код с душком: либо устарел код, либо навыки автора.


    5. Лишние атрибуты: У вас вроде есть и <nav>, и <header>, и даже пара заголовков <h3> — за что вам отдельное спасибо. Но есть места, где мусорные (ненужные) атрибуты показывают небрежность.


    <link rel="stylesheet" type="text/css" href="css/style.css" media="all">
    <link rel="stylesheet" href="css/style.css">
    …
    <script type="text/javascript" src="scripts/jquery.min.js"></script>
    <script src="scripts/jquery.min.js"></script>
  • Html страница глазами разработчика приложений. Часть 1: «Подготовка»
    +3

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


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


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


    Может быть когда вы перейдёте к части про Vue.js, я буду ошеломлён и повержен. Но сейчас это урок плохой вёрстки.

  • Пандус для сайта
    +2
    1. display: none скрывает блок от всех, включая скринридеры
    2. Разбавьте ваш суп из дивов ориентирами: header, footer, main, nav и заголовками секций
    3. SVG-иконки лучше прятать, там может случайно оказаться <title> или какой-то текст

    Посмотрите доклад «Людоедский интерфейс» и почитайте сайт «Веблайнд».

  • Цена JavaScript
    +1

    Больше недели назад перевели на Веб-стандартах, вы следите. В дайджесте на Хабре тоже упоминали перевод.

  • Кому нужны флексы
    +1

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

  • Какие нужны фавиконки
    0

    SVG-иконки пока плохо поддерживаются. Без парочки PNG и тач-иконки не обойтись.

  • О чем всегда стоит помнить при локализации веб-сайта, чтобы потом не было стыдно
    +6

    Вы очень настойчиво пишете «ориентация письменности» вместо «направление письма» и об это всё время спотыкаешься. Это такой термин или вы неудачно перевели? Или ещё: «по стандартным скриптам глоссария Юникода» — в это месте я сломался. Вы про Unicode scripts? Так это письменности, а не скрипты.

  • Основные ошибки accessibility при разработке сайта
    +1

    Пост о том, что 2 из 10 верстальщиков знают об этом, а применяют — 0,5 из 10.

  • Как сделать Progressive Web Apps: руководство новичка
    0

    Это не «пользователь uve», это Уве Тульсиани (Uve Tulsiani) из команды Samsung Internet.