Stretching his hand out to catch the stars, he forgets the flowers at his feet.
Контакты
Местоположение
Россия, Санкт-Петербург и область, Санкт-Петербург

Достижения

Все достижения (20)

Наибольший вклад в теги

Все теги (120)

Лучшие ответы пользователя

Все ответы (876)
  • Есть ли "правильность" верстки?

    sniggering_deus
    @sniggering_deus Куратор тега CSS
    I will live forever in the flame of your eyes.
    Смысл есть в именах классов, то есть если назвать класс:

    .brrrrrrr {.....}

    Или:

    .g6jdk4894 {.....}

    Будет вообще непонятно к чему относится данный класс.

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

    Блоки

    page — корневой элемент страницы
    header — шапка (страницы или элемента)
    footer — подвал (страницы или элемента)
    section — раздел контента (один из нескольких)
    body — основная часть (страницы или элемента)
    content — содержимое элемента
    sidebar — боковая колонка (страницы или элемента)
    aside — блок с дополнительной информацией
    widget — виджет, например, в боковой колонке

    Раскладка

    wrapper, wrap — обёртка, обычно внешняя
    inner — внутренняя обёртка
    container, holder, box — контейнер
    grid — раскладка (страницы или элемента) в виде сетки (обычно содержит в себе row и col)
    row — контейнер в виде строки
    col, column — контейнер в виде столбца

    Элементы управления

    button, btn — кнопка, например, для отправки формы
    control — элемент управления, например, стрелки «Вперёд/назад» в фотогалерее, кнопки управления слайдером
    dropdown — выпадающий список

    Текст

    title, subject, heading, headline, caption — заголовок
    subtitle — подзаголовок
    slogan — слоган
    lead, tagline — лид-абзац в тексте
    text — текстовый контент
    desc — описание, вариант текстового контента
    excerpt — отрывок текста, обычно используется перед ссылкой «Читать далее…»
    link — ссылка
    copyright, copy — копирайт

    и так далее...


    Источник: https://github.com/yoksel/common-words

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

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

    Нечто в стиле:

    .avatarka-polzovatelуa-izobrazenie {...}

    Подобное выглядит очень и очень ужасно.
    Ответ написан
  • Должен ли UX/UI дизайнер знать компоненты React/Vue?

    sniggering_deus
    @sniggering_deus
    I will live forever in the flame of your eyes.
    Должен ли UX/UI дизайнер знать компоненты таких фреймворков как React и Vue и в идеале подготавливать макет прямо на React, но без логики приложения?


    Нет, не должен.

    Ведь большинство современных веб интерфейсов создаются именно на этих фреймворках.


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

    Я слабо могу себе представить, что UX/UI дизайнер может только разбираться в графических программах (Adobe XD, Sketch, Illustrator) не зная можно ли вообще реализовать такой календарь на Vue для сайта или сделать модальный диалог таким вот, а не таким на React.


    Дизайнер не должен забивать себе голову подобными вещами. Это работа для разработчика.

    Конечно UX/UI дизайнер не должен знать Javascript на уровне Front-end разработчика, но наверное какие-то основы, работу с NPM, CSS/SASS препроцессоры он должен знать?


    По поводу CSS скажу так — его выучить не сложно, возможно пригодится. Всё остальное не так важно для дизайнера.

    Frontend-разработкой должен заниматься Frontend-Developer. Дизайнер же должен делать свою работу.

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

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

    Это реальная жизнь, а не компьютерная игра в которой ты можешь прокачать свой SkillLevel до 90 уровня будучи Магом, и потом возьмёшься подниматься до такого же уровня, превращаясь в Паладина. Жизнь человека быстротечна и имеет много нюансов и если бы человек был бессмертным творением, наверное он и не стремился бы к лучшему. Он бы наслаждался свободой и бесконечным временем и не пытался бы улучшить себя для дальнейшей жизни.

    Пытаясь гоняться за двумя зайцами сразу, вы всё равно однажды провалитесь в бездну отчаяния из которой выбраться сможете выбрав только одно направление. Frontend и Дизайн — это две разные вселенные, и в каждой из них есть огромное множество дочерних миров, которые в свою очередь имеют свои дочерние миры и так далее до бесконечности.

    Но это всё не значит что нужно выбрать одно и забыть о втором. Frontend-разработчику всегда нужно понимать основные принципы построения дизайна. Часто приходится допиливать какие-то мелочи самому, и эти "мелочи", должны быть на соответствующем уровне. Да и не только для этого. А дизайнеру тоже было бы неплохо знать основные принципы верстки. Я не говорю что нужно учить ЯП, уметь поднимать свой сервер, парсить данные и прочее. Достаточно просто понимать реальную структуру создания тех или иных компонентов/элементов.

    И если подумать, то всё зависит от того для чего вам это всё нужно? Если для бизнеса, тогда занимайтесь дизайном и не слишком сильно пытайтесь изучать фронтенд. А если для себя, тогда можно и попытаться, но абсолютной гарантии успеха тоже нет. Выбор остаётся за вами.

    И несмотря на всё вышесказанное быть Frontend-разработчиком и UI/UX - дизайнером, в одном лице, можно. Но как показывает практика, не совсем и нужно. Одно будет уничтожать другое в вашем подсознании, памяти, душе. И вы будете теряться в этом бесконечном цикле совершенства и погони за идеалом.
    Ответ написан
  • Как правильно начинать верстать адаптивный сайт?

    sniggering_deus
    @sniggering_deus
    I will live forever in the flame of your eyes.
    Нет единого решения данной задачи. Есть только опыт, время, скиллы, стремление решить задачу как можно лучше и менее затратно.

    Лично я верстаю сначала для Full и уже потом для Mobile, но, прежде всего я проверяю сразу все детали на адаптивность, т.е по разным "комнатам" разбрасываю карточки, меню, кнопочки и т.д и проверяю как они будут выглядеть на мобильниках. В переменных сразу указываю нужные параметры и возвращаюсь к верстке Full, зная что я могу верстать спокойно спускаясь вниз, и меня не будет ждать мучение на последних шагах.

    Достаточно добавить один класс с переменными, и на разных разрешениях менять внутренние параметры, вкладывая класс с содержимым в медиа запрос. Пример:

    Сначала объявляем переменные внутри родительского класса и задаём параметры по умолчанию:

    .main-styles {
      --main-bgcolor: #c0ff00;
      --block-width: 500px;
      --block-height: 500px;
    }


    Применяем переменные для какого-нибудь элемента, который является потомком блока с классом: main-styles, например так:

    .icon {
      width: var(--block-width);
      height: var(--block-height);
      background: var(--main-bgcolor);
      border-radius: 50%;
    }


    С помощью медиа запроса, мы можем поменять параметры в переменных, тем самым не создавая мусор в стилях, используя для изменения параметров всего лишь один класс:

    @media (max-width: 900px) {
      .main-styles {
        --main-bgcolor: #ff00e0;
        --block-width: 200px;
        --block-height: 200px;
      }
    }
    
    @media (max-width: 700px) {
      .main-styles {
        --main-bgcolor: green;
        --block-width: 150px;
        --block-height: 150px;
      }
    }
    
    @media (max-width: 500px) {
      .main-styles {
        --main-bgcolor: red;
        --block-width: 100px;
        --block-height: 100px;
      }
    }


    Самый обычный пример с использованием всего того что я описал в ответе:



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

    Итог:

    Устанавливаем изменяемые параметры в переменные, и затем на нужных брейкпоинтах меняем свойства этих параметров, через основной класс - который будет содержать важные переменные, т.е в нашем случае, этот класс имеет имя: main-styles.

    Пример достаточно простой, но я думаю вы уловили смысл. Вместо смены +50 свойств в разных классах, вы можете просто поменять значение переменных - одного класса, что намного упрощает разработку и очищает файл css от лишнего хлама.

    Сначала под разрешение мобильных устройств, а далее по возрастанию?


    С течением времени - экраны мобильных устройств увеличиваются и в итоге получается что к примеру блок с шириной в 300px который нормально отображался на устройстве с шириной экрана в 350px, будет выглядеть как-то не очень, когда наименьшая ширина устройства будет равна допустим 500 пикселям, а устройства с шириной в 350px забудутся и уже не будут актуальны. ИМХО.

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

    Дополнительно:

    1. Используйте препроцессоры или CSS переменные.
    2. Активно пользуйтесь и изучайте: Flexbox и CSS Grid.
    3. Не стесняйтесь использовать медиа запросы, но в меру, не слишком увлекайтесь.
    4. Пытайтесь оставлять свободное место/воздух. Зажатые элементы, выглядят не очень, хотя это мало кем учитывается.
    5. Используйте нормальные, понятные, и удобные имена для нейминга классов CSS.

    Удачи.
    Ответ написан
  • Как сделать такую полосу?

    sniggering_deus
    @sniggering_deus Куратор тега CSS
    I will live forever in the flame of your eyes.
    Ответ написан
  • Как реализовать такой элемент в CSS?

    sniggering_deus
    @sniggering_deus Куратор тега CSS
    I will live forever in the flame of your eyes.
    Вариант первый:



    Вариант второй:



    Вариант третий:



    Вариант четвёртый:



    Вариант пятый:



    Вариант шестой:



    Вариант седьмой:



    Вариант восьмой:



    Вариант девятый:



    Вариант десятый:



    Вариант одиннадцатый:



    Вариант двенадцатый:



    =================================================================================
    =================================================================================

    Моя коллекция меню навигаций и хлебных крошек: https://codepen.io/collection/njaGMk
    Оставляю ссылку тут. Коллекция будет обновляться.
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (14)