Даже не смотря на то что с самого начала наткнулся на баг :)
Шаги для воспроизведения:
— открываем инспектор кода;
— переключаем его в вертикальный режим;
— пытаемся переключить обратно в горизонтальный режим или переключиться между вкладками…
Результат:
— Часть инспектора перекрывается блоком с адресной строкой, блокируя часть его функциональности.
кликаешь в карту на то место где ты находишься, в появившемся колауте кликаешь на ссылку «Поиск рядом», пишешь запрос «банкомат сбербанк», получаешь выдачу банкоматов сбера отсортированных по-расстоянию.
А как вы поступите если есть макет дизайна с кастомным скроллбаром и нет возможности оставить нативный, так как и дизайнер и заказчик настаивает на его реализации?
Я не думаю что ваши аргументы убедят одного и другого в обратном.
Макс, в целом всё достаточно интересно и актуально, но есть несколько спорных моментов. Да, ты сделал вроде бы более гибкий фреймворк, чем тот же бутстрап, и я надеюсь что этот инструмент найдёт свою аудиторию, но за счет того, что твой фреймворк более сложный и трудно модифицируемый, считаю что она будет достаточнго узкой.
Имею такое мнение, что ты никак не избавил верстальщика или фронтенд разработчика от разбирания по-кускам и переваривания фреймворка, ты его более усложнил. И могу сказать исходя из своего опыта – основная твоя идея с общими (одинаковыми) модификаторами чревата нудным последствием – рефакторингом.
Да, сейчас нам не надо помнить и искать длинных классов, но нам надо будет беспокоиться чтобы наличие модификатора не отразилось на элементах которые мы не хотим менять.
Например:
.-menu > .-group.-error- > input[type="button"]
Мне кажется этот подход достаточно избыточен и неудобен. Если мы захотим применить эти же стили для ссылки или для инпута другого типа нам придется, как минимум, дописывать через запятую строку селекторов. В том случае, когда у нас изменится расположение кнопки в дом дереве этот вариант не подходит, то есть тут нет ни капли универсальности. Здесь достаточно было бы иметь один уникальный класс у кнопки и разные состояния при наличии различных модификаторов. Тут тебе нет привязки к расположению в дом дереве (имею в виду внутри какого-либо блока), и стили можно применять практически к любому тегу.
Затем, поизучал maxmert.com/widgets#grid. Если посмотреть на html-код и стили для него, то у меня волосы на голове начинают подниматься – зачем так извращаться над обтеканием, если семантически правильно для таблиц использовать тег table? У нас тут на совсем подходе flexbox ну или на самый крайний случай всё это можно обыграть inline-block.
В одном из самых первых примеров кода этой статьи я заметил как минимум 3 “недочёта“:
1. Использование тега <a> без указание аттрибута href несемантично;
2. Не вижу смысла использовать тег <i> непоназначению, напомню что он придумывался для оформления текста, по-дефолту делает его курсивом;
3. Не смог найти смысла разделения, казалось бы, единой кнопки на две, причем одна из них никак не функционирует (см. пункт 1);
Всё это можно было бы обыграть более изящно и семантично:
<div class="-group">
<a class="-btn -thumbs-up-" href="http://www.url.com">I like it</a>
</div>
в этом случае первая строчка, то есть «Basic support» меня устроит, так как я буду брать строковое значение аттрибута и вставлять его в псевдоэлемент через свойство content
Даже не смотря на то что с самого начала наткнулся на баг :)
Шаги для воспроизведения:
— открываем инспектор кода;
— переключаем его в вертикальный режим;
— пытаемся переключить обратно в горизонтальный режим или переключиться между вкладками…
Результат:
— Часть инспектора перекрывается блоком с адресной строкой, блокируя часть его функциональности.
Я не думаю что ваши аргументы убедят одного и другого в обратном.
Имею такое мнение, что ты никак не избавил верстальщика или фронтенд разработчика от разбирания по-кускам и переваривания фреймворка, ты его более усложнил. И могу сказать исходя из своего опыта – основная твоя идея с общими (одинаковыми) модификаторами чревата нудным последствием – рефакторингом.
Да, сейчас нам не надо помнить и искать длинных классов, но нам надо будет беспокоиться чтобы наличие модификатора не отразилось на элементах которые мы не хотим менять.
Например:
Мне кажется этот подход достаточно избыточен и неудобен. Если мы захотим применить эти же стили для ссылки или для инпута другого типа нам придется, как минимум, дописывать через запятую строку селекторов. В том случае, когда у нас изменится расположение кнопки в дом дереве этот вариант не подходит, то есть тут нет ни капли универсальности. Здесь достаточно было бы иметь один уникальный класс у кнопки и разные состояния при наличии различных модификаторов. Тут тебе нет привязки к расположению в дом дереве (имею в виду внутри какого-либо блока), и стили можно применять практически к любому тегу.
Затем, поизучал maxmert.com/widgets#grid. Если посмотреть на html-код и стили для него, то у меня волосы на голове начинают подниматься – зачем так извращаться над обтеканием, если семантически правильно для таблиц использовать тег
table? У нас тут на совсем подходе flexbox ну или на самый крайний случай всё это можно обыгратьinline-block.Идем дальше.
В одном из самых первых примеров кода этой статьи я заметил как минимум 3 “недочёта“:
1. Использование тега
<a>без указание аттрибута href несемантично;2. Не вижу смысла использовать тег
<i>непоназначению, напомню что он придумывался для оформления текста, по-дефолту делает его курсивом;3. Не смог найти смысла разделения, казалось бы, единой кнопки на две, причем одна из них никак не функционирует (см. пункт 1);
Всё это можно было бы обыграть более изящно и семантично:
и в стилях оперировать:
Могу сделать вывод. Если бы я, в коем-то веке, для какого-нибудь из проектов взял за основу какой-нибудь фреймворк, я бы остановился на бутстрапе.
contentInternet Explorer 8.0+
Chrome 2.0+
Opera 9.0+
Safari 3.1+
Firefox 1.0+
Android 1.0+
iOS 1.0+
transform: rotate(360deg);