Comments 93
вариантов создания кнопок много, только я вот не понял, кому вообще в голову пришла идея создавать кнопки на стороне сервера?
Создателям самых популярных фреймворков видимо:-)
Zend Framework: framework.zend.com/manual/ru/zend.form.html
Ruby On Rails: guides.rubyonrails.org/form_helpers.html
Django: docs.djangoproject.com/en/dev/topics/forms/
Zend Framework: framework.zend.com/manual/ru/zend.form.html
Ruby On Rails: guides.rubyonrails.org/form_helpers.html
Django: docs.djangoproject.com/en/dev/topics/forms/
не, это-то я знаю, я имею в виду конкретно эту фирму. При условии использования фреймворков еще это можно себе представить, хотя я лично считаю это полным бредом, а вот если движок сайта не предусматривает фреймворков, я бы на месте «пехапистов» тоже возмутился. Это кроме того, что на деле при большом количестве графики на странице, отдача графики скриптами — большое зло, которое сильно увеличивает нагрузку на сервер.
Где в django кнопки на сервере создаются? Инпуты — на сервере можно генерировать, а кнопки надо вставлять вручную.
Кнопки можно вставлять с помощью html-хелперов. В этом случае они собираются по частям где-то в дебрях серверных скриптов. Когда кнопка состоит из множества элементов, код её сборки похож на кашу.
*[class*=neobtn] {Так уже не модно?
.neobtn {В таком случае .neobtn-thick не унаследует свойств .neobtn
Было бы, наверное, правильнее
<button class="neobtn neobtn-thick">Текст кнопки</button>
скорее даже так
селекторы будут проще и поиск по ним гораздо быстрее
в варианте автора… мне кажется это жесть
<button class="neobtn thick">Текст кнопки</button>
селекторы будут проще и поиск по ним гораздо быстрее
в варианте автора… мне кажется это жесть
Ну это уже зависит это самой систематизации всего приложения.
В некоторых случаях, neobtn-thick будет лучше, т.к. встретив это в css сразу понятно к чему относится и что от него зависит.
В некоторых случаях, neobtn-thick будет лучше, т.к. встретив это в css сразу понятно к чему относится и что от него зависит.
согласен, но комментарий был про то, что селекторы типа
*[class*=neobtn-thick] гораздо медленнее чем .neobtn {} и использовать их повсеместно мне кажется неправильно.
Всё можно сделать обычными классами.А для удобной разработки css можно использовать, например less(но на боевом использовать скомпилированный вариант конечно же)
*[class*=neobtn-thick] гораздо медленнее чем .neobtn {} и использовать их повсеместно мне кажется неправильно.
Всё можно сделать обычными классами.А для удобной разработки css можно использовать, например less(но на боевом использовать скомпилированный вариант конечно же)
Гораздо медленнее — это сколько?
Настолько, что ваш крупный сайт со сложным dom-деревом зависнит наглухо в каком-нибудь ie7(про 6-ой можно и не упоминать)
Селектор *[class*=neobtn-thick] означает пройтись по всем элементам и найти среди них те, у которых есть атрибут class, в котором *внимание* содержится значение neobtn-thick. Сами думайте на сколько он медленный
Селектор *[class*=neobtn-thick] означает пройтись по всем элементам и найти среди них те, у которых есть атрибут class, в котором *внимание* содержится значение neobtn-thick. Сами думайте на сколько он медленный
>про 6-ой можно и не упоминать
Почитайте топик сперва. Не позорьтесь.
За полгода использования метода никто не лёг.
Запись .neobtn-thick означает то же самое.
Почитайте топик сперва. Не позорьтесь.
За полгода использования метода никто не лёг.
Запись .neobtn-thick означает то же самое.
Браузер не вуду, для него *[class*=neobtn-thick] и .neobtn-thick сов-но разные вещи. Если вы этого не понимаете очень жаль. Не один я пытаюсь донести эту мысль. Что можно сказать, читайте больше умных книг… например Реактивные веб-сайты
В свою очередь, я пытаюсь донести простой факт, что метод разработан не вчера, а полгода назад и совершенно нормально работает на вполне развитом проекте. А у вас кроме книжных данных и сказать то нечего.
К моему сожалению, в книге нет ничего о способах и условиях, в которых производился замер скорости. Единственно ссылки на Виталия Харисова. При всём уважении, но я не вижу в ней ничего умного о CSS-селекторах.
Дело, по-моему, даже не в том, что медленнее. Это семантически неправильно — понимать имя класса как строку, у которой есть подстроки; его следует понимать как неделимую сущность.
Это тоже… найдётся же умник, который напишет *[class*=a] подразумевая … и всё… счастливой отладки....:)
Скорость тут не имеет значения, пока проект небольшой… когда он разрастётся… это станет ощутимо… и тогда начнутся реальные проблемы… всё переписывать. Поэтому системные вещи нужно очень осторожно разрабатывать.
Скорость тут не имеет значения, пока проект небольшой… когда он разрастётся… это станет ощутимо… и тогда начнутся реальные проблемы… всё переписывать. Поэтому системные вещи нужно очень осторожно разрабатывать.
Кстати, подумалось — а что плохого в составных именах классов? Даже безотносительно этих кнопок, вообще.
Например, классы «homo-erectus» и «homo-sapiens». Кто запрещает выделить общую (и по написанию, и логически, и семантически) часть «homo»?
Я не говорю, что такой подход может быть повсеместной практикой, но в определенных случаях — почему нет?
Например, классы «homo-erectus» и «homo-sapiens». Кто запрещает выделить общую (и по написанию, и логически, и семантически) часть «homo»?
Я не говорю, что такой подход может быть повсеместной практикой, но в определенных случаях — почему нет?
Плохого в них то, что CSS не позволяет обращаться к составляющим. Селектор
E[attr*="value"], к сожалению, обращается к фрагменту строки, безотносительно того, является ли он цельной составляющей или нет. Старый селектор E[attr|="value"] как раз способен анализировать атрибут с учётом разделителей, но — увы! — не понимает мультиклассовый атрибут, анализируя его значение как одно, а не как несколько. Поэтому он хорошо работает для атрибута идентификатора id, а в случае классов так же ненадёжен, как его коллега из CSS3.Редизайн, в той или иной степени, не возможен без перевёрстки. Если это редизайн всего проекта — значит всё равно всё менять. Если надо поменять только кнопку — достаточно просто найти всего один класс (тот что надо поменять) поиском по проекту и заменить его.
На деле дизайнер сразу продумывает внешний вид кнопок, который очень редко меняется в рамках текущего макета.
На деле дизайнер сразу продумывает внешний вид кнопок, который очень редко меняется в рамках текущего макета.
Так было бы длиннее и, на первый взгляд, понятнее.
Приведённый выше способ не менее правильный.
Приведённый выше способ не менее правильный.
Было бы, наверное, правильнее
Текст кнопки
Текст кнопки
Мне осталась непонятной одна идея.
Почему нужно было пользоваться таким сложным селектором, когда можно было общие стили вынести в .neobtn, а стилизовать, добавляя второй класс (class='neobtn thick'). Если боялись коллизий можно было добавить короткий префикс к стилеобразующим классам ('neobtn nbn-thick'). Просто имхо, на большом DOM-дереве такие селекторы, хоть и незначительно, но увеличат время парсинга страницы (а на слабых мобилках возможно и значительно). Да и из JS работать будет удобнее (например, если на время ajax-загрузки захочется дизейблить все кнопки на странице).
В остальном — глубокий респект, В IE7 выглядит прекрасно и не создает каши в шаблонах. Единственное что я бы лично оставил хоть какую-то gracefull degradation для IE6. Хотя бы серый прямоугольник и картинку)
Почему нужно было пользоваться таким сложным селектором, когда можно было общие стили вынести в .neobtn, а стилизовать, добавляя второй класс (class='neobtn thick'). Если боялись коллизий можно было добавить короткий префикс к стилеобразующим классам ('neobtn nbn-thick'). Просто имхо, на большом DOM-дереве такие селекторы, хоть и незначительно, но увеличат время парсинга страницы (а на слабых мобилках возможно и значительно). Да и из JS работать будет удобнее (например, если на время ajax-загрузки захочется дизейблить все кнопки на странице).
В остальном — глубокий респект, В IE7 выглядит прекрасно и не создает каши в шаблонах. Единственное что я бы лично оставил хоть какую-то gracefull degradation для IE6. Хотя бы серый прямоугольник и картинку)
Поясняю.
Один класс, пусть и длинный, выглядит проще, чем много коротких. Сервер-сайд программистам так проще скопировать и вставить.
Один класс, пусть и длинный, выглядит проще, чем много коротких. Сервер-сайд программистам так проще скопировать и вставить.
Эммм… Во-первых, при чем здесь сервер-сайт программисты? Во-вторых, один класс выглядит проще чем много коротких только на стороне html (где у вас одна строчка), а на стороне css например можно потеряться и не найти объявление общих свойств, если искать по ".neobtn" (если например новый клиент-сайд программер будет разбираться в вашем коде). В общем я клоню к тому, что увеличение нагрузки на парсер и усложнение селекторов кажется мне важнее чем «сложность» нескольких классов. К тому же, если thick не будет больше нигде использоваться отдельно — «neobtn-thick» выглядит менее естественно, чем «neobtn thick»)
Не обязательно же ради того, что бы просто добавить кнопку звать верстальщика.
Опять же, один класс как бы намекает на связанность слов в его имени. Сразу ясно, что «neobtn-thick-start» — это что-то одно, а «neobtn neobtn-thick neobtn-thick-start» или если ещё упростить «neobtn thick start» — просто три класса.
На стороне CSS, как говорит мне мой полугодовалый опыт, нет никаких проблем с поиском нужной строки. Более того, однажды написанные, они как правило не меняются. Разве что незначительно.
Нагрузка на парсер совершенно незначительна для проектов с количеством подобных элементов не более десятка-другого на страницу. Этого вполне хватает для среднестатистического проекта. В иных случаях конечно надо искать другие варианты.
Опять же, один класс как бы намекает на связанность слов в его имени. Сразу ясно, что «neobtn-thick-start» — это что-то одно, а «neobtn neobtn-thick neobtn-thick-start» или если ещё упростить «neobtn thick start» — просто три класса.
На стороне CSS, как говорит мне мой полугодовалый опыт, нет никаких проблем с поиском нужной строки. Более того, однажды написанные, они как правило не меняются. Разве что незначительно.
Нагрузка на парсер совершенно незначительна для проектов с количеством подобных элементов не более десятка-другого на страницу. Этого вполне хватает для среднестатистического проекта. В иных случаях конечно надо искать другие варианты.
Интересный вариант. но зачем придумывать колесо?
А всё-таки, для кнопок ведь специальные тэги есть.
Расскажите об этом нашему дизайнеру.
Почему ваш дизайнер лезет в html?
Как правило, дизайнер, и не только наш, никуда не лезет. Он просто выдаёт шаблон со словами: «Что бы так и было».
Все же просто! Идете с шаблоном к директору и говорите, что такие элементы будете делать один (два три вариант зависит от студии и квалификации) день, может стоит упростить дизайн этого элемента. Дизайнер получает ЦУ от руководства, и делает как правильно. Profit!
И хороший дизайн после упрощений превращается в страшно убожество. Дальше по цепочке программисты тоже упрощают и он в итоге еще и криво работает.
Покажите пожалуйста скрин красивого макета с такой кнопкой?
Хороший дизайн не нуждается в упрощениях.
1. Отдать шаблон директору
2. ?
3. PROFIT!
2. ?
3. PROFIT!
Дело, как мне кажется, тут не в html. Просто подавляющее большинство дизайнеров не удовлетворяются стандартными страшными серыми кнопками. И все эти их выкрутасы с красивыми инпутами превращаются в батхерт для верстальщиков и чаще всего в кучу ненужного html кода. Что в свою очередь вызывает батхерт у программистов. А решение которое предлагает автор перетаскивает 90% кода в css который лежит себе в директории с прочей статикой и никого не трогает. Профит очевиден.
Обёртку можно делать из чего угодно. Метод это позволяет.
Классы как вам удобно, так и называйте.
По поводу ".neobtn" — читайте выше.
И не переживайте так за скорость отрисовки. Экономия на удалении одной «звёздочки» в данном случае — экономия на спичках.
Остальные ваши замечания — только ваше личное дело.
Классы как вам удобно, так и называйте.
По поводу ".neobtn" — читайте выше.
И не переживайте так за скорость отрисовки. Экономия на удалении одной «звёздочки» в данном случае — экономия на спичках.
Остальные ваши замечания — только ваше личное дело.
И не переживайте так за скорость отрисовки. Экономия на удалении одной «звёздочки» в данном случае — экономия на спичках.
В статье речь идёт о системе составления классов, то есть все эти спички в итоге выльются вполне ощутимые тормоза. А если css не разделён по разделам? о-ооО-О:)
За верстку кнопки первоначальным вариантом я бы расстреливал.
Зачем столько тегов? Что за злой гений это верстал?
Фиксированная ширина кнопка один элемент.
Резиновая кнопка 3 элемента.
Зачем столько тегов? Что за злой гений это верстал?
Фиксированная ширина кнопка один элемент.
Резиновая кнопка 3 элемента.
Меня пугает количество закладок к статье, хватит плодить бездарную вёрстку, прислушайтесь к SilentImp.
Я бы такую кнопки делал в 1 на css3 с мягкой деградацией, максимум в 2 тега, для большей совместимости.
Я бы такую кнопки делал в 1 на css3 с мягкой деградацией, максимум в 2 тега, для большей совместимости.
Ужасный код. Мало того, что высота задана жестко, еще и кнопка сделана дивом вместо инпута/баттона. Вы кстати еще user-select забыли отменить. Селекторы вида *[что-то там] — вообще какой-то ужас.
По моему мнению, края кнопки (:before, :after) лучше позиционировать абсолютно — не будет проблем с очисткой после float.
Не поддерживать ИЕ6 на крупном проекте — нехорошо.
Примеры старого кода еще веселее — 4 вида тегов и css-класы с дефисами, подчеркиваниями. Разве что камелкейса не хватает.
Почему-то не приведен код для изменения вида кнопки в состояниях :hover и :active. Это нормально?
А чтоб у коллег-пехапистов не было возмущений, посоветуйте им организовать свой код и добавить систему виджетов, чтобы шаблон кнопки задавался где-то отдельно.
По моему мнению, края кнопки (:before, :after) лучше позиционировать абсолютно — не будет проблем с очисткой после float.
Не поддерживать ИЕ6 на крупном проекте — нехорошо.
Примеры старого кода еще веселее — 4 вида тегов и css-класы с дефисами, подчеркиваниями. Разве что камелкейса не хватает.
Почему-то не приведен код для изменения вида кнопки в состояниях :hover и :active. Это нормально?
А чтоб у коллег-пехапистов не было возмущений, посоветуйте им организовать свой код и добавить систему виджетов, чтобы шаблон кнопки задавался где-то отдельно.
После прочтения таких вот ответов на совершенно оправданную критику я понимаю почему на рынке существует такое большое количество разочарованных заказчиков. А все из-за того что «проффесионалы»(© Янукович) совершенно не хотят думать о будущем выполненного ими проекта и не закладывают устойчивый фундамент для его дальнейшего развития.
Вся критика в адрес автора статьи полностью обоснована (по моему мнению). Доводы про «спички» тоже смешны так как можно один раз выработать правильные принципы в работе и на спичках экономить больше не придется НИКОГДА!..
Было уже много исследований по поводу скорости рендеринга и загрузки сайтов, почему бы на их основе не разработать что то подходящее для ваших задач. Что бы использование не отнимало много времени. И это в последствии это принесет реальный профит! Как пример можно привести тот же «БЭМ».
Живите сегодняшним днем, но не забывайте о том что может наступить завтра:)
Вся критика в адрес автора статьи полностью обоснована (по моему мнению). Доводы про «спички» тоже смешны так как можно один раз выработать правильные принципы в работе и на спичках экономить больше не придется НИКОГДА!..
Было уже много исследований по поводу скорости рендеринга и загрузки сайтов, почему бы на их основе не разработать что то подходящее для ваших задач. Что бы использование не отнимало много времени. И это в последствии это принесет реальный профит! Как пример можно привести тот же «БЭМ».
Живите сегодняшним днем, но не забывайте о том что может наступить завтра:)
Коллеги, у меня складывается смутное ощущение, что не все из вас до конца понимают механизм работы селектора «звёздочка».
Согласно данным w3.org запись вида "*.warning" полностью эквивалентна ".warning", а запись «div.warning» означает ровно то же, что и «div[class~=warning]» иначе говоря, ".warning" есть то же самое, что и "[class~=warning]".
Как совершенно правильно было сказано, поиск элементов в DOM идёт слева на право. Это значит, что запись вида ".warning" указывает выбрать ВСЕ элементы у которых имеется атрибут class с именем «warning». Заметим так же, что запись подобного рода абсолютно всех устраивает.
Очевидно, что запись "*.warning" делает абсолютно то же самое — выбирает ВСЕ элементы у которых есть атрибут class с именем «warning».
Теперь анализаруем всё прочитанное и приходим к выводу, что запись вида *[class~=warning] аналогична записи ".warning".
Единственное отличие моего примера в том, что значение атрибута ищется как подстрока в имени класса.
Практические замеры подтверждают сказанное — 1000 кнопок прорисовываются в ИЕ7 за 800 мс, что в среднем сопоставимо со скоростью прорисовки в этом же браузере но при использовании идентификаторов класса.
Согласно данным w3.org запись вида "*.warning" полностью эквивалентна ".warning", а запись «div.warning» означает ровно то же, что и «div[class~=warning]» иначе говоря, ".warning" есть то же самое, что и "[class~=warning]".
Как совершенно правильно было сказано, поиск элементов в DOM идёт слева на право. Это значит, что запись вида ".warning" указывает выбрать ВСЕ элементы у которых имеется атрибут class с именем «warning». Заметим так же, что запись подобного рода абсолютно всех устраивает.
Очевидно, что запись "*.warning" делает абсолютно то же самое — выбирает ВСЕ элементы у которых есть атрибут class с именем «warning».
Теперь анализаруем всё прочитанное и приходим к выводу, что запись вида *[class~=warning] аналогична записи ".warning".
Единственное отличие моего примера в том, что значение атрибута ищется как подстрока в имени класса.
Практические замеры подтверждают сказанное — 1000 кнопок прорисовываются в ИЕ7 за 800 мс, что в среднем сопоставимо со скоростью прорисовки в этом же браузере но при использовании идентификаторов класса.
использование псевдоэлементов — плохая практика. визуально они есть, но в доме их нет. как следствие нельзя через инспектор посмотреть какие именно стили к ним применились, какая у них реальная ширина, высота, отступы, об их существовании можно догадаться только лишь из исходников или визуально. короче, при отладке от них только геморрой. чистота хтмл — это конечно хорошо, и надо стараться минимизировать число дополнительных элементов, но не стоит впадать в крайности. в век шаблонизаторов совершенно не важно будет ли 1 элемент и 2 дополнительных или же 1 элемента и 2 псевдоэлемента. браузеру монописуально. в шаблонах — одинаковые вызовы подшаблонов.
касательно селекторов — ты играешь с огнём. лучше писать что-то типа class=" b-mybutton m-green " а потом в цсс: .b-mybutton {} .b-mybutton.m-green {}
касательно селекторов — ты играешь с огнём. лучше писать что-то типа class=" b-mybutton m-green " а потом в цсс: .b-mybutton {} .b-mybutton.m-green {}
Еще бы приделать фокус и ховер-эффекты.
Нет ни единой причины использовать для кнопки div, если есть элемент button, который обладает дополнительными возможностями в браузерах — дефолтное оформление, возможность получать фокус и нажиматься безо всяких tabindex и JS, доступность не только для зрячих с мышкой.
Я бы очень рекомендовал вам исправить код статьи, чтобы не смущать и не провоцировать разработчиков писать такой ужасный и недоступный HTML-код. Иначе можно скатиться до кода, который пишет Google:
twitter.com/miripiruni/status/123316502760919040
Чувак из Гугла рассказал как надо делать чекбоксы:
Я бы очень рекомендовал вам исправить код статьи, чтобы не смущать и не провоцировать разработчиков писать такой ужасный и недоступный HTML-код. Иначе можно скатиться до кода, который пишет Google:
twitter.com/miripiruni/status/123316502760919040
Чувак из Гугла рассказал как надо делать чекбоксы:
<div role="checkbox" aria-checked="true">Вот в том и прелесть метода.
>что позволяет делать кнопку из любого тега
С небольшими доработками этим методом можно декорировать всё.
Я обновил свой пример: test.marow.net/button/demo/
>что позволяет делать кнопку из любого тега
С небольшими доработками этим методом можно декорировать всё.
Я обновил свой пример: test.marow.net/button/demo/
Sign up to leave a comment.
Метод html-верстки кнопок с применением псевдоэлементов