Ответы пользователя по тегу Sass
  • Когда лучше использовать примеси, а когда общие классы?

    @Flying
    Общие CSS классы можно использовать если вы контролируете установку этих CSS классов, ведь это делается в HTML. Естественно в этом случае объём результирующего CSS кода будет меньше, но в сложных случаях логика расстановки CSS классов может быть не самой тривиальное.

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

    Также не стоит забывать о ещё одном способе горизонтального расширения - placeholder'ах. Их использование позволяет сэкономить на объёме CSS кода за счёт исключения дублирования, но может иметь не самые очевидные последствия без понимания того что именно стоит за этой абстракцией.
    Ответ написан
  • SASS placeholder может быть в любом месте кода?

    @Flying
    Вложен внутри селектора - да, может, но внешние по отношению к нему селекторы будут добавляться ко всем селекторам, использующим placeholder.
    Вложен внутри mixin'а - да, может.
    Вложен внутри @media запроса - да, может, но @media запрос будет также применяться. Также такой placeholder не может быть использован внутри другого @media - это приведёт к ошибке.

    Ответы на все эти вопросы довольно очевидны если помнить что placeholder - это по сути просто CSS селектор с возможностью дописывания к нему новых селекторов через запятую.

    Поиграться можно здесь.
    Ответ написан
  • Что за Sass в Foundation CSS?

    @Flying
    С языком Sass лучше всего знакомиться на его официальном сайте, там есть подробная документация.
    Ответ написан
  • Node SASS vs Dart SASS. Какой производительнее при каких условиях?

    @Flying
    1. dart-sass - reference implementation языка т.е. является образцом того как должен работать язык. node-sass binding libsass (реализации спецификации языка на C++) к node.js.

      dart-sass содержит в себе все последние фичи языка, к примеру там уже есть поддержка sass modules, libsass отстаёт, а node-sass отстаёт от libsass. За пруфами - сюда и сюда
    2. libsass производительнее, местами - существенно. К примеру в моих тестах интенсивная работа с sass maps в libsass примерно в 10 раз быстрее чем в dart sass. Насчёт микросекунд - у меня есть проекты которые по 15-20 секунд компилируют только стили на node-sass, на dart-sass всё намного медленнее
    3. Приведённые ссылки - сравнение тёплого с мягким. Есть реализации языков, а есть плагины для их подключения к различным сборщикам. sass - сама реализация языка, gulp-sass - binding для Gulp, sass-loader - binding для Webpack
    Ответ написан
  • Как в sass можно именовать и переиспользовать группу селекторов с их правилами?

    @Flying
    То что показано у вас на screenshot'е делается через placeholder'ы. Однако судя по имени вашего mixin'а - это не финальный код и вы планируете добавить туда @media выражение. В этом случае placeholder уже не сработает, вы получите ошибку. Такой вариант реализуется уже через mixin'ы.

    Aside note: не вставляйте код скриншотом
    Ответ написан
  • Как организовать mixin по айдишникам?

    @Flying
    Ваша задача по сути сводится к динамическому обращению к переменным. Sass так не умеет. Для реализации вам необходимо сменить структуру данных и использовать maps.

    Т.е. ваш код мог бы выглядеть как-то так:

    $vars: (
      1 : #333,
      5 : #111,
      100 : #222,
    );
    
    @mixin div-color($id) {
      @if (map-has-key($vars, $id)) {
        color: map-get($vars, $id);
      }
    }

    Посмотреть в действии можно на Sassmeister.
    Ответ написан
  • Review верстки: ошибки и замечания???

    @Flying
    Макет весьма простой для портфолио как по мне. Также отсутствие макетов мешает понять насколько полученный результат им соответствует. Если в качестве источника вы брали именно указанную HTML страницу - то отличия от неё слишком очевидны чтобы это комментировать. Тем не менее хочу сказать что результат лучше многого из того что постят здесь с просьбами оценить.

    Однозначные плюсы:
    • Внимание к деталям, к примеру то что вы позаботились сделать шрифт только с нужными вам иконками вместо того чтобы пихать всё подряд


    На что стоит обратить внимание:

    По самому проекту:
    • Не следует хранить генерируемые файлы (тот же CSS) в системе контроля версий т.к. это приводит к ненужным локальным модификациям. Понятно что в данном случае вы хотели показывать его через GitHub Pages, поэтому в данном случае это нормально, но вообще при разработке - нет, эти файлы должны быть указаны в .gitignore
    • Использование символа & в имени файла - сомнительная затея. В целом ничего страшного, но он может иметь специальное значение
    • Подключение шрифта через @import - плохая идея т.к. он будет загружаться после того как будет загружена и разобрана таблица стилей т.е. вы оставляете пользователя с неправильными шрифтами дольше чем нужно.
    • Не оставляйте неиспользуемый код в проекте, это усложняет его поддержку, особенно когда вы работаете в команде
    • Продолжайте изучать английский, учите написание слов


    По CSS:
    • Не мучайте себя, познакомьтесь с flexbox. В современном вебе вёрстка на float'ах выглядит архаичной, сложнее поддерживается и требует от вас использования ненужных хаков.
    • Старайтесь не экономить на CSS классах и использовать их для применения стилей вместо элементов. Это позволит вашему коду быть гибче и отвяжет его от деталей HTML
    • Из-за неиспользования float'ов структура layout'а для teaser черезчур переусложнена, можно сделать намного проще
    • Вы слишком полагаетесь на то что реальный контент будет точно соответствовать вашему демо-контенту, а на практике это обычно не так. К примеру:
      • попробуйте в .post section добавить не один параграф, а два
      • попробуйте использовать "Константин Константинопольский" в качестве имени автора в .post-meta-author


    • У вас явно прослеживается неумение думать об элементах макета как об иерархической структуре, вы рассматриваете её как плоскую общность элементов. К примеру возьмите .post: Этот элемент обладает очень простой структурой - общим внутренним отступом из которого иногда "вылезают" элементы (к примеру картинка на мелких экранах), но у вас это какие-то кусочки отступов, применённые к разным внутренним элементам, причём иногда даже не к непосредственным потомкам, часть отступов - margin, а часть - padding, в общем полный бардак. Это делает макет весьма хрупким и сложным в поддержке. Вам стоит немного углубиться в теорию и выстроить у себя внутри понимание того как именно взаимодействуют элементы между собой
    • В мобильном меню кликабельная часть ссылки - только её текст, лучше чтобы это было всё пространство элемента меню.


    По HTML
    • Не надо так с lang, установите корректно
    • Где ваш some.php?
    • Старайтесь не увлекаться одинаковым контентом у повторяющихся элементов, тем самым вы лишаете себя возможности проверить поведение макета с реальным контентом.
    • Вроде незаметно, но это ломает выравнивание элементов на странице. Видите суслика? :)


    По JavaScript:
    • Использование let в JavaScript коде приводит к ошибкам в MSIE, если вы вдруг собираетесь его поддерживать
    • Хранить у себя внешние зависимости, которые вы к тому же устанавливаете - плохая идея, забирайте код из node_modules при сборке проекта
    • Код ваших скриптов лучше оборачивать в самозапускающуюся функцию
      (function(window, document) { ... })(window, document);
      чтобы скрыть его из глобального пространства имён - это позволит избегать конфликтов с другим кодом который может быть загружен
    • На маленьких экранах введённый в форму текст пропадает при закрытии, возможно это как-то связано с клонированием формы
    Ответ написан
  • Что из препроцессоров вы используете?

    @Flying
    Использую по возможности всё что есть в Sass и хотелось бы видеть в нём больше. Активно использую и переменные и миксины и функции и placeholder'ы и list'ы и map'ы и т.п. Многие практические задачи намного легче решаются через препроцессор, те же CSS variables ни разу не замена.

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

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

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

    @Flying
    В SCSS это легко решается через @extends:
    %subsclasses-color {
      .sub1, .sub2, .sub3 {
        color:red;
      }
    }
    .main1 {
      @extends %subclasses-color;
    }
    .another-main {
      @extends %subclasses-color;
    }
    Ответ написан
  • Как переопределить параметр mixin, не трогая исходники?

    @Flying
    Вы можете передавать её как именованный аргумент при вызове, т.е.
    @include button-variant($active-background: white, $active-border: lightgrey);
    Ответ написан
  • Что не так при обращении к элементу так?

    @Flying
    Причина вашей проблемы в непонимании того как работает псевдо-класс :first-of-type. На Stack Overflow есть пара очень хороших объяснений этого, стоит ознакомиться (раз, два).

    Ключевым моментом для понимания должен стать тот факт что в контексте HTML понятие "element type" эквивалентно имени тега. Таким образом ваше ожидание что .services-block:first-of-type означает "первый элемент с классом services-block" ложно и это приводит к неработающему селектору. В реальности этот селектор читается как "любой подэлемент текущего элемента, имеющий класс services-block и при этом являющийся первым элементом с таким именем тега среди всех имеющихся". Слегка контр-интуитивно, да, но уж как есть.

    Вашу задачу можно решить если вы вспомните что div - не единственный элемент в HTML и начнёте использовать также и другие элементы. В вашем примере для div.basic-title и div.services-block_title явно лучше подходят какие-то из элементов заголовка, а структура из div.services-block_item и подэлементов - это явно dl/dt/dtt

    Простая замена заголовка на какой-либо Hx элемент позволит использовать селектор
    .container > div.services-container:first-of-type > .services-block:first-child
    .

    Также можно ничего не менять, тогда селектор получится несколько более жёстким:
    .container > .basic-title + .services-container > .services-block:first-child
    Ответ написан
  • Как перестроить миксин?

    @Flying
    В целом всё очень просто:
    @each $query in $queries {
        @media (max-width: #{$query}) {
            @for $i from 1 through 6 {
                h#{$i} {
                  font-size: nth($sizes, $i);
                }
            }
        }
    }

    Однако лучше хранить размеры в map'е, это позволит упростить код:
    $sizes: (
      h6: $fzh6, 
      h5: $fzh5, 
      h4: $fzh4, 
      h3: $fzh3, 
      h2: $fzh2, 
      h1: $fzh1
    );
    
    @each $query in $queries {
        @media (max-width: #{$query}) {
            @each $tag, $size in $sizes {
                #{$tag} {
                  font-size: $size;
                }
            }
        }
    }
    Ответ написан
  • Как в SCSS сделать увеличенное значение?

    @Flying
    На самом деле ваш пример почти корректен, только чуть доработать:
    @mixin last-childs {
        @for $i from 7 through 1 {
            &:nth-last-child(#{$i}) {
               margin-left: 40px - 5px * ($i - 1);
            }
        }
    }
    Ответ написан
  • SASS. Компиляция. От чего зависит результат?

    @Flying
    У вас placeholder %gallery__man-flex определён внутри .gallery, таким образом все места где будет использоваться этот placeholder будут наследовать контекст его определения.

    В остальных случаях запись вида &__man означает "расширение текущего селектора", поэтому очевидно добавления контекстного селектора не происходит. Если он нужен - то стоит использовать & &__man
    Ответ написан
  • Почему не подключаются стили и иконки к сайту?

    @Flying
    Они подключаются, просто у вас стили в репозитории пустые, сами посмотрите. С SVG картинками ситуация чуть другая, такого файла просто нет в репозитории.

    В общем проверяйте что вы туда залили
    Ответ написан
  • Не могу подключить иконочные шрифты?

    @Flying
    .ai - это формат Adobe Illustrator, он явно не является шрифтом. Просто используйте реальные веб-шрифты (расширение должно быть .woff2 или .woff).

    Если у вас есть только desktop версия шрифта (к примеру с расширением .ttf или .otf) - то веб-версию можно получить используя FontSquirrel generator.
    Ответ написан
  • Для чего предназначена данная примесь?

    @Flying
    Этот код проверяет что элементы в $map расставлены в порядке возрастания значений
    Ответ написан
  • Как компилируются пути из scss в css?

    @Flying
    Sass ничего не знает про ваши пути до картинок, указание корректных путей - ваша задача. Пути должны указываться относительно CSS файла, а не SCSS т.к., очевидно, они будут использоваться только когда CSS файл будет загружен в браузер.

    По поводу "локально запускается": проверьте что ваши пути в итоге не уходят выше document root сайта т.к. если это так - то они, очевидно, недоступны извне.
    Ответ написан