Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
(id вообще оставим как и положено для JS).
id для js — плохая практика. Лучше воспользоваться классами (с префиксом, на которые не накладываем стили), либо data аттрибутами
Ваше решение — отлично бы подошло для сайтов — одно-двухстраничников.
1) Чем сложнее сайт, тем сложнее разобраться с такими стилями
2) Неоднородное поведение элементов. Иногда можно столкнуться со следующими идеями интерфейса — на страницах с какой-то объемной информацией header может «спускаться» за пользователем (быть фиксированным) на других страницах этого не надо (да, вырвиглазно, но присутствует)
3) «Шаблонность» (по отношению к header\body\footer) это проверенная годами возможность предоставить пользователю удобное понимание сайта. Было б непривычно, если бы каждый из сайтов был построен «как душеньке захотелось»
Если разобрать Вашу идею можно найти множество проблем данного кода (начиная от пометки выбранного пункта меню и т.д.)
Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
Много ли сайтов уровня usatoday.com Вы делали собственноручно?
По теме: сам я к CSS-фреймворкам отношусь не то что бы совсем негативно, но с достаточной долей опаски. Даже довольно сложный многостраничный интернет-магазин или интернет-журнал можно верстать без всякого фреймворка и вёрстка получится гораздо чище, очевиднее и с более предсказуемым поведением, нежели при использовании фреймворка. Особенно это помогает в ситуациях, когда по незнанию или случайности в доп. стилях цепляешь уже используемый фреймворком класс.
Второе, что особенно вымораживает: некоторые индивидуумы настолько уверены, что CSS поставляемые с фреймворками неизменны и изменять их «под себя» никто и никогда не будет, и пишут плагины (порой довольно большие) опирающиеся на «родные» стили фреймворка. В терминальной стадии те же индивинуумы уверены что все и всегда используют только одну, такую же как у них, цветовую схему этого фреймворка (например тема Default в jQuery UI).
И это не просто печально. Это по-настоящему бесит.
Сам я не против использования фреймворков в проектах. Они действительно ускоряют процесс разработки. Но любой инструмент нужно использовать в меру и с умом, а не лепить где надо и где не надо.
> вёрстка получится гораздо чище, очевиднее и с более предсказуемым поведением
Потому что верстали — Вы и именно Вам она кажется чище, очевиднее и с более предсказуемым поведением :-)
Если с такой версткой, будет разбираться верстальщик с «другими» мозгами, ему она такой — вряд ли покажется, проходили миллион раз.
А насчет индивидуумов — Вы абсолютно неправы.
Это правильное использование сторонней библиотеки — надо не изменять ожидаемое поведение, а писать glue-код и там переопределять поведение, если необходимо.
Это делается для того, чтобы:
— можно было обновляться без последствий
— иметь ожидаемое поведение используемой библиотеки (например, если в команду приходит новый парень, отлично знающий фреймворк, но из-за того, что Вы там что-то поменяли, парень косячит)
Потому что верстали — Вы и именно Вам она кажется чище, очевиднее и с более предсказуемым поведением :-)
Если с такой версткой, будет разбираться верстальщик с «другими» мозгами, ему она такой — вряд ли покажется, проходили миллион раз.
А насчет индивидуумов — Вы абсолютно неправы.
Это правильное использование сторонней библиотеки — надо не изменять ожидаемое поведение, а писать glue-код и там переопределять поведение, если необходимо.
Это делается для того, чтобы:
— можно было обновляться без последствий
— иметь ожидаемое поведение используемой библиотеки (например, если в команду приходит новый парень, отлично знающий фреймворк, но из-за того, что Вы там что-то поменяли, парень косячит)
Если с такой версткой, будет разбираться верстальщик с «другими» мозгами, ему она такой — вряд ли покажется, проходили миллион раз.
Если свёрстано по стандартам и с очевидными именами классов, правильным их применением — если этим мозги не совсем отморожены, то человек разберётся достаточно быстро.
Это правильное использование сторонней библиотеки — надо не изменять ожидаемое поведение, а писать glue-код и там переопределять поведение, если необходимо.
Не совсем понимаю что Вы имеете в виду под "glue-код".
Используя библиотеку/фреймворк при необходимости изменить поведение/стиль того или иного элемента я просто добавляю к нему свой класс
<div class="my-small-corners ui-corner-all ... ">
...
</div>и вношу изменения следующим побразом:
.my-small-corners.ui-corner-all {
border-radius:2px;
...
}А многие погромисты клали на всех и меняют поведение самого
.ui-corner-all ни на минуту не задумываясь к каким последствиям это приведёт на другом проекте. Я даже встречал особо упоротые решения в которых встречались !important. Ну это шоб, видимо, наверняка.
либо data аттрибутами
Да хоть data, хоть role, я не настаиваю :)
Я имел ввиду, что использование id для верстки плохая идея.
Ваше решение — отлично бы подошло для сайтов — одно-двухстраничников.
Раздумывая о данной идеи я подразумевал блогоориентированные сайты и магазины, которые составляют порядка 90% сайтов.
header может «спускаться» за пользователем
Не вижу проблем реализации данной «фишки» в предложенной мной концепции.
Можно также фиксировать на CSS или JS, что больше нравится.
Если разобрать Вашу идею можно найти множество проблем данного кода
Так ведь ради этого статья и затевалась, чтобы попробовать выявить проблемы и может быть их решить. Если есть желание разумеется.
Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
Я думаю подобные сайты много на чем не реализуешь и надо много писать уникального ручками.
Да хоть data, хоть role, я не настаиваю :)
Я имел ввиду, что использование id для верстки плохая идея.
Ваше решение — отлично бы подошло для сайтов — одно-двухстраничников.
Раздумывая о данной идеи я подразумевал блогоориентированные сайты и магазины, которые составляют порядка 90% сайтов.
header может «спускаться» за пользователем
Не вижу проблем реализации данной «фишки» в предложенной мной концепции.
Можно также фиксировать на CSS или JS, что больше нравится.
Если разобрать Вашу идею можно найти множество проблем данного кода
Так ведь ради этого статья и затевалась, чтобы попробовать выявить проблемы и может быть их решить. Если есть желание разумеется.
Сайт уровня usatoday.com на данных «идеях» построить вам не удастся
Я думаю подобные сайты много на чем не реализуешь и надо много писать уникального ручками.
Объясните, пожалуйста, почему «id для js — плохая практика»? Разве id не быстрее работает, чем class?
Мммм а как на счёт выбрать по id 20 ссылок на странице) Интересно будет посмотреть на это)
речь про конкретную фразу… «id для js — плохая практика»
Естественно, если нужно выбрать много элементов, то нужен класс, а id используется для одиночных элементов. Это настолько элементарно, что обсуждать это просто смешно.
«id для js — плохая практика» — а эта фраза и вовсе смех!
Естественно, если нужно выбрать много элементов, то нужен класс, а id используется для одиночных элементов. Это настолько элементарно, что обсуждать это просто смешно.
«id для js — плохая практика» — а эта фраза и вовсе смех!
«id для js — плохая практика» — а эта фраза и вовсе смех!
Да, это в фонд золотых цитат, однозначно.
Не в случае одиночных сугубо уникальных элементов да id хорошо… Но в последнее время не часто встретишь такое… Попапы если только… И да я про более менее серьёзные проекты… А не одностраничники…
Но в последнее время не часто встретишь такое…
И да я про более менее серьёзные проекты… А не одностраничники…
Вы на полном серьезе такое пишите? Это где же «не часто встретишь» использование id для привязки эвентов к элементам?
И часто вы встречаете проект с 50 видами попапов к которым эвент на открытие привязан по id? Интересно было бы на вашу лапшу из js посмотреть… Небось ещё и на страницу её вываливаете вместо того что бы спрятать в отдельный js файл…
Вы бы уже остановились нести чушь… и взялись бы за учебники что ли… я даже не знаю что тут посоветовать (не сочтите за оскорбление). При чем тут попапы? Перечислю для примера немного:
— Кнопка toggle меню открывает скрытое меню
— Меню при mouseleave должно скрываться
— И самое сладкое: найдите мне 50 плагинов jQuery, которые не используют в селекторе иницализации id…
Вы должны понимать, что использовать тут класс еще хуже или вы строите свои приложения через биндинг эвентов в атрибутах?
— Кнопка toggle меню открывает скрытое меню
— Меню при mouseleave должно скрываться
— И самое сладкое: найдите мне 50 плагинов jQuery, которые не используют в селекторе иницализации id…
Вы должны понимать, что использовать тут класс еще хуже или вы строите свои приложения через биндинг эвентов в атрибутах?
Я пожалуй выскажусь прямо! Вы похоже человек очень не далёкий… И честно говоря не особо блещете разумом! Я где нибудь писал что селект по id плохо? Харе уже нести тупую чушь!
Перечислю для примера немного…
На странице 50 элементов при нажатии на каждый из них должен показыватся соответствующий попап ваши действия? Исходя из того что вы мне тут пишите вы собираетесь детать что то вроде
$(function(){
$('#id1, #id2, #id3, #id4 ....').popup();
})
или ещё хуже
$(function(){
$('#id1').popup();
$('#id2').popup();
$('#id3').popup();
$('#id4').popup();
$('#id5').popup();
})
И это для всех 50 попапов, а теперь представим что попапов не 50, а 100 и на каждой странице свой набор
Не лучше ли сделать вот так?
$(function(){
$('.popup-opener').click(function(){$('#'+$(this).data('popup-name')).popup()});
})
Или я не прав? Давайте приведите мне логическое доказательство моей не правоты, коль вы такой «умный»… А то раскидались тут примерами которые вообще не относятся к тому о чём я говорю… Научитесь читать для начала…
Перечислю для примера немного…
На странице 50 элементов при нажатии на каждый из них должен показыватся соответствующий попап ваши действия? Исходя из того что вы мне тут пишите вы собираетесь детать что то вроде
$(function(){
$('#id1, #id2, #id3, #id4 ....').popup();
})
или ещё хуже
$(function(){
$('#id1').popup();
$('#id2').popup();
$('#id3').popup();
$('#id4').popup();
$('#id5').popup();
})
И это для всех 50 попапов, а теперь представим что попапов не 50, а 100 и на каждой странице свой набор
Не лучше ли сделать вот так?
$(function(){
$('.popup-opener').click(function(){$('#'+$(this).data('popup-name')).popup()});
})
Или я не прав? Давайте приведите мне логическое доказательство моей не правоты, коль вы такой «умный»… А то раскидались тут примерами которые вообще не относятся к тому о чём я говорю… Научитесь читать для начала…
У меня нескромный вопрос, не по теме диалога: Уважаемы, вы с vanilla JS знакомы?
А как классами вы планируете закрывать 100500тый popup «из вне»?
Предположим такую дикую ситуацию.
На странице при загрузке открывается 100500 «popup'ов»
Задача, по определенному событию закрыть 9768 popupот рождества христова с момента генерации оных, но вы не знаете, сколько уже было закрыто.
Ваши действия? Высчитывать popup? Устанете считать и не сможете.
При увеличение условий задачи (расширяемости приложения) Ваш пример рушится. В моей задаче необходимо будет сгенерировать через цикл 100500 идентификаторов.
И Вам уже ответили выше
Предположим такую дикую ситуацию.
На странице при загрузке открывается 100500 «popup'ов»
Задача, по определенному событию закрыть 9768 popup
Ваши действия? Высчитывать popup? Устанете считать и не сможете.
При увеличение условий задачи (расширяемости приложения) Ваш пример рушится. В моей задаче необходимо будет сгенерировать через цикл 100500 идентификаторов.
И Вам уже ответили выше
Естественно, если нужно выбрать много элементов, то нужен класс, а id используется для одиночных элементов. Это настолько элементарно, что обсуждать это просто смешно.
Раз уж вы так просите, «недалекий вы наш», то я вам опишу почему это определение подходит конкретно к вам.
— Niksg написал: «Объясните, пожалуйста, почему «id для js — плохая практика»? Разве id не быстрее работает, чем class?»
— На что вы ответили: «Мммм а как на счёт выбрать по id 20 ссылок на странице) Интересно будет посмотреть на это)»
— За что и получили 11 минусов (мои поздравления)
— Далее вы написали: «Не в случае одиночных сугубо уникальных элементов да id хорошо… Но в последнее время не часто встретишь такое… Попапы если только… И да я про более менее серьёзные проекты… А не одностраничники…»
— Откуда следует логический вывод: вы почему-то думаете что все проекты написаны при помощи классов, этот вывод можно также сделать добавив ко всему ваши попытки защитить / объяснить логику сообщения в первом посте "id для js — плохая практика", которое, как я уже выше писал, является нереально смешным.
И где же я не слежу за тем что вы пишиште? Если вы не умеете доносить до людей мысль таящуюся в вашей голове — это ваши проблемы, это также подтверждают минусы, которые вы полностью заслужили.
Насчет 50 попапов, видимо вы реально так не умеете выражать свои мысли, что привязались к этим попапам, я могу сделать вывод, что все что вы делали в фронтенде — создавали попапы, еще попапы, много попапов.
И если вы уж так хотите знать как я поступил бы если бы нужно было сделать много попапов на странице:
Я напишу для вас пример, который вы можете распечатать и повесить на стену и больше никогда не спорить и тем более называть кого-то «недалеким» не зная о человеке ничего: jsfiddle.net/T2NAn/3/
— Niksg написал: «Объясните, пожалуйста, почему «id для js — плохая практика»? Разве id не быстрее работает, чем class?»
— На что вы ответили: «Мммм а как на счёт выбрать по id 20 ссылок на странице) Интересно будет посмотреть на это)»
— За что и получили 11 минусов (мои поздравления)
— Далее вы написали: «Не в случае одиночных сугубо уникальных элементов да id хорошо… Но в последнее время не часто встретишь такое… Попапы если только… И да я про более менее серьёзные проекты… А не одностраничники…»
— Откуда следует логический вывод: вы почему-то думаете что все проекты написаны при помощи классов, этот вывод можно также сделать добавив ко всему ваши попытки защитить / объяснить логику сообщения в первом посте "id для js — плохая практика", которое, как я уже выше писал, является нереально смешным.
И где же я не слежу за тем что вы пишиште? Если вы не умеете доносить до людей мысль таящуюся в вашей голове — это ваши проблемы, это также подтверждают минусы, которые вы полностью заслужили.
Насчет 50 попапов, видимо вы реально так не умеете выражать свои мысли, что привязались к этим попапам, я могу сделать вывод, что все что вы делали в фронтенде — создавали попапы, еще попапы, много попапов.
И если вы уж так хотите знать как я поступил бы если бы нужно было сделать много попапов на странице:
Я напишу для вас пример, который вы можете распечатать и повесить на стену и больше никогда не спорить и тем более называть кого-то «недалеким» не зная о человеке ничего: jsfiddle.net/T2NAn/3/
Смотрим ваш же пример… closeBtn: '.js-b-popup__close-btn' и этим всё сказано. Прежде чем учить других придерживайтесь сами своих же суждений и методов…
Если вы не понимаете почему там стоит класс, а не ID я очень вам сочувствую) Почитайте немного про «расширяемость приложения»
Тогда смотрим на вашу расширяемость))) $wrapper: $('#js-b-popup__wrapper'),
и? что вы пытаетесь доказать? или вы уже ничего не можете нормальное привести в пример, что пичкаете всякую неоднозначную информацию на хабре?
Имеет ли значение куда плейсить попапы, если они поверх всего? Это ведь попапы. Я не знаю что вы имели ввиду в своем замечании, но единственное, что я могу предположить, так это вариант что в один момент можно открыть 2 попапа или более (но это бессмысленно). Но предположим что это так. То что я написал как было расширяемым так и остается. Вариантов масса, от генерации попапов при загрузке страницы и нахождении их в скрытом состоянии до вызова, до дата-биндинга с сылкой на врапперы куда плейсить конкретный попап.
Замечу интересную вещь: Изначально я не хотел писать обертку .hide() для скрытия элементов, а думал просто очищать враппер и каждый раз заного генерировать попап, НО я уже тогда догадывался, что ваш неспокойный мозг так и будет искать лазейки, чтобы тыкнуть «ой а вот тут не очень», у вас манера такая дурацкая в жизни видимо и я вам опять же не завидую. Удачи вам в вашей жизни на этом я откланиваюсь и завершаю данную ветку бессмысленной беседы жирной точкой.
Имеет ли значение куда плейсить попапы, если они поверх всего? Это ведь попапы. Я не знаю что вы имели ввиду в своем замечании, но единственное, что я могу предположить, так это вариант что в один момент можно открыть 2 попапа или более (но это бессмысленно). Но предположим что это так. То что я написал как было расширяемым так и остается. Вариантов масса, от генерации попапов при загрузке страницы и нахождении их в скрытом состоянии до вызова, до дата-биндинга с сылкой на врапперы куда плейсить конкретный попап.
Замечу интересную вещь: Изначально я не хотел писать обертку .hide() для скрытия элементов, а думал просто очищать враппер и каждый раз заного генерировать попап, НО я уже тогда догадывался, что ваш неспокойный мозг так и будет искать лазейки, чтобы тыкнуть «ой а вот тут не очень», у вас манера такая дурацкая в жизни видимо и я вам опять же не завидую. Удачи вам в вашей жизни на этом я откланиваюсь и завершаю данную ветку бессмысленной беседы жирной точкой.
PS прежде чем писать что-то научитесь анализировать текст, который вы сами пишите:
Речь зашла про что? Про:
— в последнее время не часто встретишь такое… (использование ID)
— Попапы если только… (лолчто? вот это да..)
— И да я про более менее серьёзные проекты… (лолчто №2? вот это да… снова. И опять же повторюсь во всех! ВСЕХ! проектах используются ID! Везде всегда! Даже тотже ангуляр взять и там будут использоваться при подключении плагинов)
Оставлю вас с размышлениями и анализом постов.
Не в случае одиночных сугубо уникальных элементов да id хорошо… Но в последнее время не часто встретишь такое… Попапы если только… И да я про более менее серьёзные проекты… А не одностраничники…
Речь зашла про что? Про:
— в последнее время не часто встретишь такое… (использование ID)
— Попапы если только… (лолчто? вот это да..)
— И да я про более менее серьёзные проекты… (лолчто №2? вот это да… снова. И опять же повторюсь во всех! ВСЕХ! проектах используются ID! Везде всегда! Даже тотже ангуляр взять и там будут использоваться при подключении плагинов)
Оставлю вас с размышлениями и анализом постов.
Я уверен, что для тех, кто использует не уникальные ID для элементов в Аду заготовлен специальный, особо жаркий котёл.
На самом деле идея далеко не нова, но сами подумайте, вы, будучи в восторге от широчайших возможностей CSS3 и HTML5 пытаетесь запихать все эти возможности в некие рамки, ограниченные изначальным HTML-скелетом. Смысл?
На самом деле идея далеко не нова
Я как бы об этом аккуратно намекнул
Уверен, что идея не новая и её кто-то уже высказывал.
вы, будучи в восторге от широчайших возможностей CSS3 и HTML5 пытаетесь запихать все эти возможности в некие рамки, ограниченные изначальным HTML-скелетом. Смысл?
evalexdy, боюсь вы немного преувеличили. Да, мне нравятся возможности CSS3 (как и JS, PHP и не только) и я хочу их использовать на «полную катушку», но я не хочу запихивать их в рамки, а как раз наоборот — дать волю CSS3. И главное отказаться от простыни в class. Я не говорю о полном отказе от классов, о чем и писал. Я говорю о создание некого универсального скелета HTML. Ни в коем случае я не претендую данной идеей на все сайты сети, а лишь на определенные области.
И главное хотелось бы услышать мнения, замечания и предложения.
Приведу пример. Кто знаком с Wordpress уже сталкивался и поймет.
К примеру основное меню уже имеет свои классы заложенные в движке и их не исправить. И от темы к теме они не меняются. Поэтому всегда можно взять кусок CSS отвечающий за меню из одной темы в другую и быть уверенным что они заработают (разумеется если меню сделано согласно этим классам, без десятка своих оберток).
ЗЫ Сорри, почему то тег blockquote не срабатывает
Я как бы об этом аккуратно намекнул
Уверен, что идея не новая и её кто-то уже высказывал.
вы, будучи в восторге от широчайших возможностей CSS3 и HTML5 пытаетесь запихать все эти возможности в некие рамки, ограниченные изначальным HTML-скелетом. Смысл?
evalexdy, боюсь вы немного преувеличили. Да, мне нравятся возможности CSS3 (как и JS, PHP и не только) и я хочу их использовать на «полную катушку», но я не хочу запихивать их в рамки, а как раз наоборот — дать волю CSS3. И главное отказаться от простыни в class. Я не говорю о полном отказе от классов, о чем и писал. Я говорю о создание некого универсального скелета HTML. Ни в коем случае я не претендую данной идеей на все сайты сети, а лишь на определенные области.
И главное хотелось бы услышать мнения, замечания и предложения.
Приведу пример. Кто знаком с Wordpress уже сталкивался и поймет.
К примеру основное меню уже имеет свои классы заложенные в движке и их не исправить. И от темы к теме они не меняются. Поэтому всегда можно взять кусок CSS отвечающий за меню из одной темы в другую и быть уверенным что они заработают (разумеется если меню сделано согласно этим классам, без десятка своих оберток).
ЗЫ Сорри, почему то тег blockquote не срабатывает
Раздумывая о данной идеи я подразумевал блогоориентированные сайты и магазины, которые составляют порядка 90% сайтов.
А откуда такая цифра — 90%, у вас есть какая-то статистика? Может тут имеет смысл рассматривать правило типа «20% сайтов составляют 80% оборота денег и 80% сайтов приносят остальные 20%»?
Кто знаком с Wordpress уже сталкивался и поймет
Ну вот здрасьте-пожалста, исходя из этой цитаты можно вообще не заморачиваться версткой, готовых шаблонов (тем) в этих ваших интернетах столько, что можно вообще не знать никаких технологий, в редакторе меняешь логотип, с десяток картинок и, пользуясь неким абстрактным редактором тем — менять палитру сайта.
А давайте еще в эту же кучу сунем конструкторы типа wix.com, ipage.com, у них вообще drag-n-drop билдеры для создания собственных страничек (на базе готовых шаблонов, кстати), при этом и на изучение CMS времени тратить не надо, кнопок вида «Create page», «Edit», «Delete» и «Make it kwel» вполне достаточно.
Вообще-то нигде в вашей статье я не увидел, что вы подразумеваете те самые «блогоориентированные сайты и магазины». Вы бы определились, что вы хотите добиться продвижением вашей идеи: сделать очередной bootstrap, ipage, ну или просто аналог конструктора из разряда «сделать сайт за 5 минут для чайников»?
>А откуда такая цифра — 90%, у вас есть какая-то статистика?
Это субъективная оценка и не претендует на истину
> что можно вообще не знать никаких технологий, в редакторе меняешь логотип, с десяток картинок и, пользуясь неким абстрактным редактором тем — менять палитру сайта.
И вам Здрасте :)
Я же специально написал фразу:
«Теперь не надо знать как работает тот или иной атрибут и как сделать на Vanilla CSS какую нибудь фишку. И это напоминает какой-то DW (визуальный режим) или Artisteer… Ну да ладно, немного отвлекся.»
И всё я предлагаю поговорить о высоком и не спускаться на эту грешную землю.
> что вы хотите добиться продвижением вашей идеи
Я пока ни чего не хочу добиться. Я лишь предлагаю размышлять.
И ни каких конструкторов. Шаблонов — да, но не конструкторов.
Я предлагаю попробовать посмотреть в сторону шаблонов на чисто СSS, без изменения DOM/верстки
Это субъективная оценка и не претендует на истину
> что можно вообще не знать никаких технологий, в редакторе меняешь логотип, с десяток картинок и, пользуясь неким абстрактным редактором тем — менять палитру сайта.
И вам Здрасте :)
Я же специально написал фразу:
«Теперь не надо знать как работает тот или иной атрибут и как сделать на Vanilla CSS какую нибудь фишку. И это напоминает какой-то DW (визуальный режим) или Artisteer… Ну да ладно, немного отвлекся.»
И всё я предлагаю поговорить о высоком и не спускаться на эту грешную землю.
> что вы хотите добиться продвижением вашей идеи
Я пока ни чего не хочу добиться. Я лишь предлагаю размышлять.
И ни каких конструкторов. Шаблонов — да, но не конструкторов.
Я предлагаю попробовать посмотреть в сторону шаблонов на чисто СSS, без изменения DOM/верстки
Ну, для ленивых никто не отменял js, в частности — jQuery)
Сталкивался с задачей, когда нужно было полностью сменить дизайн на давно работающем сайте под WP, в котором была кучка категорий и куча разного рода материалов, сделанных через редактор в админке. В итоге index.php/page.php сверстал с 0, а вот с содержимым пришлось справляться при помощи jQuery, благо, вложенные категории имели более-менее схожую верстку/особенности(вроде схожего url), за которые можно было зацепиться и применить js для обработки нужных элементов.
В итоге получилось много-много какокода, однако обошлось без переверстки нехилого кол-ва контента в админке.
Сталкивался с задачей, когда нужно было полностью сменить дизайн на давно работающем сайте под WP, в котором была кучка категорий и куча разного рода материалов, сделанных через редактор в админке. В итоге index.php/page.php сверстал с 0, а вот с содержимым пришлось справляться при помощи jQuery, благо, вложенные категории имели более-менее схожую верстку/особенности(вроде схожего url), за которые можно было зацепиться и применить js для обработки нужных элементов.
В итоге получилось много-много какокода, однако обошлось без переверстки нехилого кол-ва контента в админке.
При таком
body > header, body > footer подходе вы очень сильно рискуете, изменение ДОМа развалит вашу верстку и упаритесь концы искать. Излишнего наследования как раз таки следует избегать, тем более в век респонсива, потому как проще переписать один класс, а не всю цепочку наследования. Чем длиннее такие цепочки, тем сложнее за ними уследить, а на больших проеках это вообще смерть. Не фанат БЭМа, но идея верстки независимыми блоками, по моему мнению лучшее решение на данный момент, так как дает ясность структуры и контроль.>изменение ДОМа развалит вашу верстку
1) я как раз и размышляю (призываю) тут, чтобы не было необдуманных изменений DOM, т.е. верстки. Прежде чем менять, придется думать.
2) дело в том, что терминология не мой конек, поэтому статья немного сумбурная и просто размышлизмы. Я предлагаю использовать своего рода блочность CSS (об этом в статье явно не сказано) или как вы выразились «идея верстки независимыми блоками» просто немного с другого ракурса. Чтобы если что-то вдруг измениться в DOM — знать в каком куске CSS кода искать проблему.
3) ну и пересекая два предыдущих пункта — если что-то изменится в CSS сегодняшних фоеймворков — тоже замучаешься концы искать. Об этом Quiz верно сказал выше (#comment_7537547)
>Излишнего наследования как раз таки следует избегать, тем более в век респонсива
Вот тут я категорически не согласен. Вы, как мне кажется намекаете на респонсив через JS. Я верстал неоднократно респонсив на CSS и проблем не было ни разу. Для этого есть media query, которым не помеха наследование.
Я сейчас вызову батхерт на себя, но я считаю, что это всё мысли после передоза Bootstrap'ом и Модернизмом
1) я как раз и размышляю (призываю) тут, чтобы не было необдуманных изменений DOM, т.е. верстки. Прежде чем менять, придется думать.
2) дело в том, что терминология не мой конек, поэтому статья немного сумбурная и просто размышлизмы. Я предлагаю использовать своего рода блочность CSS (об этом в статье явно не сказано) или как вы выразились «идея верстки независимыми блоками» просто немного с другого ракурса. Чтобы если что-то вдруг измениться в DOM — знать в каком куске CSS кода искать проблему.
3) ну и пересекая два предыдущих пункта — если что-то изменится в CSS сегодняшних фоеймворков — тоже замучаешься концы искать. Об этом Quiz верно сказал выше (#comment_7537547)
>Излишнего наследования как раз таки следует избегать, тем более в век респонсива
Вот тут я категорически не согласен. Вы, как мне кажется намекаете на респонсив через JS. Я верстал неоднократно респонсив на CSS и проблем не было ни разу. Для этого есть media query, которым не помеха наследование.
Я сейчас вызову батхерт на себя, но я считаю, что это всё мысли после передоза Bootstrap'ом и Модернизмом
Автор, в самом же бутстрапе рекомендуют не писать в HTML'е class=«col-bla red-color cool-feature», а писать свой семантический типа class=«breasts», а уже в Less'е для него использовать миксины и прочие встроенные классы, типа:
.breasts {
.make-col(bla);
.color(red);
.cool-feature;
}
Можно пойти дальше и в большинстве случаем обходится вообще без классов, как в статье:
и т. д. Вот тут подробнее на эту тему.
body { @extend .container; }
body > header { @extend .page-header;
p { @extend .lead; }
}
и т. д. Вот тут подробнее на эту тему.
О! За
Единственно, что вообще без классов тяжко, когда у нас куча компонентов и мы именно им пишем.
Отсюда то и пошёл яндексовский БЭМ, когда мы не одним проектом думаем, а компонентами реюзабельными.
@extend спасибо. Я эту или подобную статью и имел в виду.Единственно, что вообще без классов тяжко, когда у нас куча компонентов и мы именно им пишем.
Отсюда то и пошёл яндексовский БЭМ, когда мы не одним проектом думаем, а компонентами реюзабельными.
Это, кстати, был SASS, в LESS это выглядит чуть-чуть по-другому.
Почему все так боятся трогать HTML?
Как человек, которому «по долгу службы» приходится работать с огромным количеством различных CMS, в том числе и с самописными (к огромному моему сожалению), могу точно сказать, что не люблю лазить в HTML-шаблоны, если можно обойтись CSS, по одной простой причине: никогда не можешь быть уверен, что тот идиот, который работал с сайтом до тебя — сделал все по-человечески, не напихал генерации HTML напрямую в программинг, минуя шаблоны, ну или хотя бы не сунул в WYSIWYG-редактор HTML-муть, которую даже валидатор визивига не смог нормально переварить и которая рушит любовно выстраиваемое DOM-дерево какими-нибудь незакрытыми тегами.
Может потому что то что делается на CSS — не сделаешь на HTML и наоборот?
Например сейчас хочу двинуться в сторону AngularJS или иного MVC из-за вашего вопроса: что бы бэкенд мне отдавал контент, а куда и как я его пристрою, как перелопачу шаблон — моё фронтовое дело. Нет, правда. Весь вопрос с макетированием (HTML-ом) заключается именно в том, что бэкендеры хотят статичной разметки, куда они выкидывают данные, а стилями это нужно разукрасить. Но иногда, когда дизайнер дает тебе параллельно новые картинки страниц, ты понимаешь, что разметку стоило бы поменять, а у тебя все бэкендеры заняты, как звери, а деплой на носу… И вот ты городишь магию из ничего — из классов и наследований, что бы и себя прикрыть и команду, и фирму, и всю семью. В моем случае я говорю о практике использования того же Bitrix'а в разработке топовых проектов ру-нета. Что применимо к любой студийной истории на любом CMS.
Да, когда речь идёт о фреймвокарх — чистота, а особенно размеры кода, всегда в опасности. Но если уж говорить о CSS-фреймворках, а в статье проскочил Bootstrap (именно по причине таких повторений я и забыл о нём навсегда), то не могу упомянуть о прекраснейшем Foundation. Из него я частенько использую только сетку, когда попросту нет времени возиться с media queries. Классы с окончанием -small-up, -large-down и т.д, достаточно эффективно позволяют избежать подобных поездов. Ну и, разумеется, полностью кастомизируемый SASS-пакет. По какой причине Bootstrap перешел на SASS лишь только недавно — загадка.
никто на sass не переходил. Они поддержали форк оффициально. Вас тормоза sass не напрягают?
63ms — сборка пачки из 50 файлов/компонентов, с генерацией микшинов, вычислений в функциях, генераций datauri и многим прочим. Ищите проблему у себя. Т.е. написал и сразу виден результат, взгляд не успеваешь перевести.
Меня напрягали, но потом я перешел на libsass, у которого есть обертки в виде node-sass, grunt-sass и gulp-sass. Сногсшибательная вещь.
Совсем отказываться от классов не стоит, а вот проблемы кучи классов решаются препроцессорами: все необходимые классы-ассеты (трейты, миксины) подмешиваются в некоторый определяющий (смысловой) класс. Этот интегральный класс и выносится в разметку.
О том, что фреймворки всегда уступят ручной работе спорить смысла нет, у них другие преимушества, остальное вкусовшина. Например теги header, nav и прочие в первую очередь все же предназначены для маркировки уникального контента страницы от обших и управляюших элементов, использовать их для указания стилей скорее вредный совет, чем полезный, если давать его всем и каждому, независимо от проекта.
Возьмите тот-же Bootstrap, возьмите, например, LESS и напишите
button {
.btn;
.btn-primary;
...
.что-то-там-ещё;
}
Замечательная тема для холивара.
Зачем? Зачем изучать классы Bootstrap, если проще воспользоваться атрибутами CSS.
Очень часто 1 класс использует 1-2 атрибута, где второй атрибут дублирующий из другого класса.
Хочешь сделать кнопку?
Идешь на сайт Bootstrap, ищешь где там кнопки в доках или демке, смотришь классы, из них выбираешь те что тебе надо, вставляешь к себе в код и надеешься что заработает ни чего не забыл. А да, может быть, что дизайн рисовался не под Bootstrap, тогда ещё и переписываешь стили под дизайн.
Зачем всё это?!
Зачем? Зачем изучать классы Bootstrap, если проще воспользоваться атрибутами CSS.
Очень часто 1 класс использует 1-2 атрибута, где второй атрибут дублирующий из другого класса.
Хочешь сделать кнопку?
Идешь на сайт Bootstrap, ищешь где там кнопки в доках или демке, смотришь классы, из них выбираешь те что тебе надо, вставляешь к себе в код и надеешься что заработает ни чего не забыл. А да, может быть, что дизайн рисовался не под Bootstrap, тогда ещё и переписываешь стили под дизайн.
Зачем всё это?!
Фреймверк юзают обычно в больших командах, где команда, отвечающая за верстку, может насчитовать приличное количество людей. Для них в любом случае придется писать гайды по стилям, чтобы все писалось в определенных рамках выбранного для проекта стиля.
Твиттер бутстрап просто уже сделали эти гайды, но они не последняя инстанция, но уже неплохой бэкграунд для дописывания поверх готовых стилей собственных. Как уже было замечено ранее, можно не писать .btn.btn-active.btn-primary, а сделать в less собственный класс .btn-accept, в котором смешать все три класса. Дописываем во внутренний гайдлайн проекта наши новые классы, все.
Твиттер бутстрап просто уже сделали эти гайды, но они не последняя инстанция, но уже неплохой бэкграунд для дописывания поверх готовых стилей собственных. Как уже было замечено ранее, можно не писать .btn.btn-active.btn-primary, а сделать в less собственный класс .btn-accept, в котором смешать все три класса. Дописываем во внутренний гайдлайн проекта наши новые классы, все.
Наверно, потому, что гораздо лучше, если классы имеют семантичные названия. Проще говоря, смысл. Ибо, смотря на приведенную в статье портянку, невозможно понять, к чему относятся эти кнопки и в каком месте они находятся.
Освоить LESS не так уж и сложно.
Освоить LESS не так уж и сложно.
<sarcasm>Зачем читать и изучать фреймворк, если можно не изучать? Давайте все изобретем свой собственный велосипед. Возможные баги? Пфф, я лучше сам наступлю на грабли, чем воспользуюсь чужим маршрутом. Кроссбраузерность? Да никто уже не пользуется старыми ослами и линухом!
</sarcasm>
Странно, что автор не упомянул (не слышал?) про CSS Zen Garden. В котором даже во времена CSS2 создавали на одном и том же html коде такие разные дизайны.
Спасибо добрый человек. Не знал про такое. Именно об этом я и говорил.
Конечно как верстальщик со своей колокольней я вижу там огрехи ещё, но и они о многих сами знают
> Эти избыточные дивы и спаны были изначально предназначены для вставки дополнительных картинок.
> Сегодня у нас есть полная поддержка ::before и ::after, используйте лучше их.
> Старые элементы останутся для исторической совместимости. Но могут однажды исчезнуть.
И в комментариях по ссылке говориться ещё много того, что стоило и мне упомянуть в статье, но думал если идея понравится и окажутся единомышленники, то написать в следующей статье.
> — Используйте :first-child, :last-child и :nth-child для обращения к элементам без классов.
> — Используйте псевдоэлементы ::before и ::after для дополнительного оформления.
> — Используйте сколько угодно фоновых картинок для элементов, перечислив их через запятую.
> — Если будет нужно, используйте метод Келлума для замены текста картинкой goo.gl/GXxdI
> — Не полагайтесь на дополнительные блоки в конце, используйте вместо них ::before и ::after.
И статья написана красивее, чем я тут накорябал :)
Конечно как верстальщик со своей колокольней я вижу там огрехи ещё, но и они о многих сами знают
> Эти избыточные дивы и спаны были изначально предназначены для вставки дополнительных картинок.
> Сегодня у нас есть полная поддержка ::before и ::after, используйте лучше их.
> Старые элементы останутся для исторической совместимости. Но могут однажды исчезнуть.
И в комментариях по ссылке говориться ещё много того, что стоило и мне упомянуть в статье, но думал если идея понравится и окажутся единомышленники, то написать в следующей статье.
> — Используйте :first-child, :last-child и :nth-child для обращения к элементам без классов.
> — Используйте псевдоэлементы ::before и ::after для дополнительного оформления.
> — Используйте сколько угодно фоновых картинок для элементов, перечислив их через запятую.
> — Если будет нужно, используйте метод Келлума для замены текста картинкой goo.gl/GXxdI
> — Не полагайтесь на дополнительные блоки в конце, используйте вместо них ::before и ::after.
И статья написана красивее, чем я тут накорябал :)
Мрачно подозреваю, что http://w3c.github.io/webcomponents/spec/custom/ (и вообще http://www.w3.org/TR/components-intro/) восторжествует в качестве решения этой проблемы.
Тогда <save-button>Save</save-button> и всё такое.
Тогда <save-button>Save</save-button> и всё такое.
В начале статьи, вы привели пример с кучей классов, а далее размышляете о создании однотипных сайтов.
Суть описания строкой из классов, это будущий рост и изменения проекта. Мы не знаем какие страницы/блоки/элементы появятся в будущем на проекте, при этом уже имеем представление общего дизайна. Поэтому можем сформировать несколько универсальных классов, которые в будущем с большой вероятностью будут на новых страницах. Они могут использоваться вместе, а могут по отдельности. Поэтому имеется необходимость их разделения, при этом сохраняется возможность управления глобально (БЭМ).
В случае когда проект не предполагает будущий активный рост, использование такой «портянки» в html, действительно неоправданно. Можно обойтись простой компоновкой классов/правил на этапе старта. При этом допустимо написание как с нуля, так и с фрейворком.
Фреймворки в некотором роде дают возможность универсального старта с готовыми наборами. Они предназначены для лёгкой/быстрой разработки малыми силами, стараются покрыть универсальностью под разные проекты. У профессионалов как правило есть свои наработки, подходы, фреймворки, системы сборки.
Нужно понимать какой проект в руках и что с ним делать. Нельзя использовать всегда bootstrap или например всегда писать с нуля.
Рассуждать и обозначать плюсы/минусы целесообразности того или иного подхода нужно в контексте задачи. Смешивать подходы/задачи и искать смысл/решение в этом, бессмысленно. :)
Используя препроцессоры и инструменты автоматизированной сборки, мы можем лавировать между задачами с большей гибкостью. В том числе и оптимизируя дублирующие классы компоновкой.
Суть описания строкой из классов, это будущий рост и изменения проекта. Мы не знаем какие страницы/блоки/элементы появятся в будущем на проекте, при этом уже имеем представление общего дизайна. Поэтому можем сформировать несколько универсальных классов, которые в будущем с большой вероятностью будут на новых страницах. Они могут использоваться вместе, а могут по отдельности. Поэтому имеется необходимость их разделения, при этом сохраняется возможность управления глобально (БЭМ).
В случае когда проект не предполагает будущий активный рост, использование такой «портянки» в html, действительно неоправданно. Можно обойтись простой компоновкой классов/правил на этапе старта. При этом допустимо написание как с нуля, так и с фрейворком.
Фреймворки в некотором роде дают возможность универсального старта с готовыми наборами. Они предназначены для лёгкой/быстрой разработки малыми силами, стараются покрыть универсальностью под разные проекты. У профессионалов как правило есть свои наработки, подходы, фреймворки, системы сборки.
Нужно понимать какой проект в руках и что с ним делать. Нельзя использовать всегда bootstrap или например всегда писать с нуля.
Рассуждать и обозначать плюсы/минусы целесообразности того или иного подхода нужно в контексте задачи. Смешивать подходы/задачи и искать смысл/решение в этом, бессмысленно. :)
Используя препроцессоры и инструменты автоматизированной сборки, мы можем лавировать между задачами с большей гибкостью. В том числе и оптимизируя дублирующие классы компоновкой.
Пункт «что-то еще» самый важный во всех списках.
Фреймворки CSS появились изначально ради сеток и развились ради простоты адаптивности.
Остальное же просто плюшки для быстрой вёрстки.
Проблема не в фреймворках, а в том, что их предназначение искажённо понимают большинство заказчиков, отсюда появляются и не грамотные исполнители.
Остальное же просто плюшки для быстрой вёрстки.
Проблема не в фреймворках, а в том, что их предназначение искажённо понимают большинство заказчиков, отсюда появляются и не грамотные исполнители.
Я, конечно, не волшебник, но все же… Как я понял для вас html5+css3 это только новые теги, вам приятнеё писать <save-button>Save</save-button> вместо <button class=«save-button»>Save</button> и, соответственно, стили body save-button {… } вместо body .save-button {… }?
Сразу видно опытного верстальщика.
В Вашем прмере должно быть тогда уж вот так:
А Вы городите что попало.
Используйте теги по назначению, уважайте коллег, мойте руки перед едой и будет всем счастье и мир во всём мире.
В Вашем прмере должно быть тогда уж вот так:
<input type="submit" class="my-save-button" value="Save" />
input[type="button"].my-save-button {
...
}
А Вы городите что попало.
Используйте теги по назначению, уважайте коллег, мойте руки перед едой и будет всем счастье и мир во всём мире.
input[type="submit"] конечно же. Сам же и ошибся… -_-Может, раз такой оооопытный верстальщик, поведаете всему миру заодно отличие
<button> от <input type="button"> ?Я похож на справочник?
Мне не надо. Просто, если Вы один весь в белом, то извольте изъясниться :)
Quiz, ты похож на гугл :D
morgen2009, а вас гугл забанил?
htmlbook.ru/html/button
morgen2009, а вас гугл забанил?
htmlbook.ru/html/button
Тег <_button_> создает на веб-странице кнопки и по своему действию напоминает результат, получаемый с помощью тега <_input_> (с атрибутом type=«button | reset | submit»). В отличие от этого тега, <_button_> предлагает расширенные возможности по созданию кнопок. Например, на подобной кнопке можно размещать любые элементы HTML, в том числе изображения. Используя стили можно определить вид кнопки путем изменения шрифта, цвета фона, размеров и других параметров.
Теоретически, тег <_button_> должен располагаться внутри формы, устанавливаемой элементом <_form_>. Тем не менее, браузеры не выводят сообщение об ошибке и корректно работают с тегом <_button_>, если он встречается самостоятельно. Однако, если необходимо результат нажатия на кнопку отправить на сервер, помещать <_button_> в контейнер <_form_> обязательно.
Важно понимать что Bootstrap и ему подобные не фреймворки а UI тулкиты. Они были созданы для того чтобы клепать/копипастить быстро и не задумываясь. Если говорить об архитектуре, то ясное дело нужен CSS фрейворк. То что вы предлагаете похоже на фреймворк, советую взглянуть на intuitcss. (хорошие размышления на эту тему)
Я тоже не люблю Bootstrap, в том числе из-за большого количества классов и избыточной верстки, но все-таки
не то же самое, что
так как второй вариант можно считать сухим(DRY), в этом и заключается отличие подхода.
Не советую злоупотреблять дочерними селекторами так как попадете в ловушку «неповоротливой верстки» из-за большой специфичности.
Спасибо за поиск ;D
Я тоже не люблю Bootstrap, в том числе из-за большого количества классов и избыточной верстки, но все-таки
<button style="text-align:right; font-weight:bold; display:inline; font-size:12pt; border-radius:1em; backgrund-image: url("..")">не то же самое, что
<button class="ui-btn-right ui-btn-b ui-btn-inline ui-mini ui-corner-all ui-btn-icon-right">так как второй вариант можно считать сухим(DRY), в этом и заключается отличие подхода.
Не советую злоупотреблять дочерними селекторами так как попадете в ловушку «неповоротливой верстки» из-за большой специфичности.
Спасибо за поиск ;D
У вашего предложения есть еще один существенный недостаток: браузеры «читают» css справа налево. Если крайним правым селектором оказывается название того или иного элемента, сначала выбираются эти элементы, а затем происходит уточнение через привязку к родителям.
Идельным вариантом, исходя из этого, было присваивать каждому элементу id и ссылаться в стилях на него. Но мы хорошо понимаем, что это невозможно в реальной жизни, посему без классов (как с одной стороны обобщающий момент, а с другой — наоборот) не обойтись.
Идельным вариантом, исходя из этого, было присваивать каждому элементу id и ссылаться в стилях на него. Но мы хорошо понимаем, что это невозможно в реальной жизни, посему без классов (как с одной стороны обобщающий момент, а с другой — наоборот) не обойтись.
Автору следует поработать в большой команде и все эти идеи об улучшении «этики и эстетики» верстки путем отказа от классов пропадут сами собой.
На деле то как выглядит верстка в файле играет малую роль, куда важнее скорость и масштабируемость разработки.
На деле то как выглядит верстка в файле играет малую роль, куда важнее скорость и масштабируемость разработки.
Лично для меня большим адом в примере выглядит часто встречающаяся попытка реализовать элемент для выполнения js-кода через a, а не span или button.
Магия Бутстрапа в том, что это фреймворк, а не набор готовых стилей. Звучит немного странно, но есть безмерно прекрасный пост на coderwall, как использовать Бутстрап и все возможности препроцессоров. В итоге сохраняется в порядке семантика, есть минимизация классов, о которой говорит автор, а также все возможности Бутстрапа.
Недавно начал практиковать такой подход — очень рад, что теперь HTML чист и прекрасен.
Недавно начал практиковать такой подход — очень рад, что теперь HTML чист и прекрасен.
Абсолютно не согласен с автором. В сети достаточно много трудов от опытных фронт-енд разработчиков которые описывают Модульный / Компонентный / Объектно-ориентированный CSS, да тот же БЭМ, разрабатываемый для многократного повторения.
Ваш пример
Совершенно никуда не годится. Если так верстать, то конечно может показаться что фреймворки это плохо.
Я часто полагаюсь на theme классы и наследование, а ваш пример трещит от helper-классов и модификаторов. Такой винегрет даже писать не хочется, не то что поддерживать. Но да ладно. Я не об этом.
В современной веб разработке такие понятия как минификация уже стали нормой, по этому говорить о количестве строк кода в фреймворках бессмысленно. Всегда в порядочном проекте есть dev и build (min) версии, по одной идет разработка, а другая компилируется в продакшн и их размеры ничтожно малы.
Ту концепцию, что предлагаете Вы будет сложнее поддерживать чем БЭМ, просто потому что декларирование в HTML-шаблонах задача куда более простая, нежели «алхимия в css» (С) Николас Галлахер.
Завязывая оформление сайта на составных селекторах Вы будете зависимы от четкой HTML структуры, которая никогда не изменяется. Это приведет к большей шаблонности, которую Вы, как говорите, пытаетесь избежать, не говоря уже про селекцию по тегам и скорость рендеринга браузером такого сайта. Компонентная структура бутстрапа или другого CSS фреймворка как раз завязана на том чтобы использовать компонент или элемент в любом месте в разметке. Компонент / элемент в бутстрапе это виджет в готовом проекте. Вы сможете создать файл с виджетом и архитектуру подключения виджетов, в параметрах которой передавать темы и модификаторы для конкретного виджета. Весь код можно будет разбить на отдельные сущности и шаблоны, чего нельзя будет сделать при фреймворке завязанном на CSS.
Чтобы избавится от кучи модификаторов и хэлперов для элемента следует рассмотреть изменение этого самого элемента в контексте других компонентов. Например тот же btn будет выглядеть всегда так и так, а если он находится в контексте thumbnail или navbar, то его вид немного изменяется. Так же можно оперировать и темами. Если кнопка располагается внутри navbar-default она имеет одни свойства а внутри navbar-inverse уже другие.
Вы рассуждаете в статье о CSS3 и о том какие возможности он предоставляет. Сестринские селекторы, :nth-child. Да все верно. Эти возможности прекрасны, но их потенциал раскрывается не тогда когда вы верстаете постранично, а когда верстка идет покомпонентно. Приведу пример:
Мне недавно попались два, на первый взгляд, не плохих сайта на переоформление и поддержку. Во время переоформления я столкнулся с тем что разрабочтики завязали весь сайт на контекстных селектоорах. То есть просто btn я бы никогда не создал, а свойства обтекания каждый раз применяются заново и заново к новым элементам, без использования хэлперов. Таким образом любое изменение в структуре рушило весь сайт. А для изменение стилей для одной и той же кнопки в списке товаров / в карточке товара / в списке акций приходилось искать три различных селектора в CSS. Для того чтобы повторить какую то часть верстки, мне приходилось копировать имеющиеся стили в новый контекст, что раздувало CSS до ужасных размеров. Если бы разработчики создали компоненты, вместо постраничной верстки, такие компоненты которые можно было воспроизвести на абсолютно пустой странице, то даже изменения в CSS были бы менее болезненными. При этом не обязательно пользоваться бутстрапом, но не закладывать изначально возможности развития и кастомизации в проект это зло, которое потихоньку исторгается.
Да раньше была табличная верстка, я помню свои первый табличные сайты и первый скрипты еще до появления jQ и им подобных и это было ужасно скажу я Вам. Блочная верстка долгая время была под конекстом идентификаторов, и казалось что контентс ID создает как бы компонент на странице. Дальше пошли классы но проблема осталась та же. И то что Вы описываете в статье как раз такие прошлые подходы с новыми инструментами, а не наоборот.
Ваш пример
<a href="#" class="ui-btn-left ui-btn ui-btn-inline ui-mini ui-corner-all ui-btn-icon-left ui-icon-delete">Cancel</a>
Совершенно никуда не годится. Если так верстать, то конечно может показаться что фреймворки это плохо.
Я часто полагаюсь на theme классы и наследование, а ваш пример трещит от helper-классов и модификаторов. Такой винегрет даже писать не хочется, не то что поддерживать. Но да ладно. Я не об этом.
В современной веб разработке такие понятия как минификация уже стали нормой, по этому говорить о количестве строк кода в фреймворках бессмысленно. Всегда в порядочном проекте есть dev и build (min) версии, по одной идет разработка, а другая компилируется в продакшн и их размеры ничтожно малы.
Ту концепцию, что предлагаете Вы будет сложнее поддерживать чем БЭМ, просто потому что декларирование в HTML-шаблонах задача куда более простая, нежели «алхимия в css» (С) Николас Галлахер.
Завязывая оформление сайта на составных селекторах Вы будете зависимы от четкой HTML структуры, которая никогда не изменяется. Это приведет к большей шаблонности, которую Вы, как говорите, пытаетесь избежать, не говоря уже про селекцию по тегам и скорость рендеринга браузером такого сайта. Компонентная структура бутстрапа или другого CSS фреймворка как раз завязана на том чтобы использовать компонент или элемент в любом месте в разметке. Компонент / элемент в бутстрапе это виджет в готовом проекте. Вы сможете создать файл с виджетом и архитектуру подключения виджетов, в параметрах которой передавать темы и модификаторы для конкретного виджета. Весь код можно будет разбить на отдельные сущности и шаблоны, чего нельзя будет сделать при фреймворке завязанном на CSS.
Чтобы избавится от кучи модификаторов и хэлперов для элемента следует рассмотреть изменение этого самого элемента в контексте других компонентов. Например тот же btn будет выглядеть всегда так и так, а если он находится в контексте thumbnail или navbar, то его вид немного изменяется. Так же можно оперировать и темами. Если кнопка располагается внутри navbar-default она имеет одни свойства а внутри navbar-inverse уже другие.
Вы рассуждаете в статье о CSS3 и о том какие возможности он предоставляет. Сестринские селекторы, :nth-child. Да все верно. Эти возможности прекрасны, но их потенциал раскрывается не тогда когда вы верстаете постранично, а когда верстка идет покомпонентно. Приведу пример:
Мне недавно попались два, на первый взгляд, не плохих сайта на переоформление и поддержку. Во время переоформления я столкнулся с тем что разрабочтики завязали весь сайт на контекстных селектоорах. То есть просто btn я бы никогда не создал, а свойства обтекания каждый раз применяются заново и заново к новым элементам, без использования хэлперов. Таким образом любое изменение в структуре рушило весь сайт. А для изменение стилей для одной и той же кнопки в списке товаров / в карточке товара / в списке акций приходилось искать три различных селектора в CSS. Для того чтобы повторить какую то часть верстки, мне приходилось копировать имеющиеся стили в новый контекст, что раздувало CSS до ужасных размеров. Если бы разработчики создали компоненты, вместо постраничной верстки, такие компоненты которые можно было воспроизвести на абсолютно пустой странице, то даже изменения в CSS были бы менее болезненными. При этом не обязательно пользоваться бутстрапом, но не закладывать изначально возможности развития и кастомизации в проект это зло, которое потихоньку исторгается.
Да раньше была табличная верстка, я помню свои первый табличные сайты и первый скрипты еще до появления jQ и им подобных и это было ужасно скажу я Вам. Блочная верстка долгая время была под конекстом идентификаторов, и казалось что контентс ID создает как бы компонент на странице. Дальше пошли классы но проблема осталась та же. И то что Вы описываете в статье как раз такие прошлые подходы с новыми инструментами, а не наоборот.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В который раз этот класс?