Yep. Я говорю о ситуации, когда у вас тег может поменяться. ul/li не могут поменять — это законченный объект на странице. А вот h3 на h4 или даже на strong, p на div иди span — относительно часто могут меняться.
То есть грубо говоря там где верстальщик уже прописал классы — не нужно в стилях ограничивать их каким-либо элементов.
В данном случае теги i, b используются скорее как оформительские вспомогательные элементы (для допололнительных фонов, уголков или еще чего-нибудь). Для них, конечно, нет смысла задавать классы (подразумевается, что класс задается семантически осмысленной единице контента).
Браво! Спасибо за чек-лист, все сам давно собирался сделать такой :)
Вот только я не согласен с тем, что в стилях нужно писать теги. В стилях вообще не должно быть тегов, только классы (и иногда id)! (подразумеваются стилизированных элементов, а не глобальные a, p, table и т.д.).
Т.е. вместо body.contacts div#content div#content-text div.entry div.somenamedblock
пишем #content #content-text .entry .somenamedblock
Аргументация: При программинге не редко приходится менять теги (сеошники тоже, порой, хотят что-то иное), если теги в CSS. Еще где-то было про внутренние требования яндекса к верстке, там тоже об этом говорили, но не могу найти, мб на яндекс.субботниках говорили.
Ну и вообще, если в проекте придерживаются подхода верстки независимыми блоками, то там немного другой чек-лист будет.
Насчёт «выше головы не прыгнешь». Где-то видел интерфейс, где количество создаваемых строк и столбцов увеличивается при приближении мышки к краю. Фактически тоже самое, что и у вас, только без скролла - всегда видно все ячейки, бокс просто увеличивается.
Блин, хабр съел часть сообщения, вот что там было: «Также для таблицы 15x15 и 600x15 используется один и тот же интерфейс, что тоже немаловажно. Следует также учесть, что цифры могут сохранятся, то есть в последующем их не надо будет изменять».
Не минусовал, но мысль такая: вы притягиваете за уши сложность первого метода и слишком упрощаете второй метод.
В реальности же первый метод это — два клика (выделение цифр), три нажатия на клавиатуре (введение цифр, ентер), но при этом человек вводит точное количество строк и ячеек, а не пытается поймать это количество мышкой. Также для таблицы 15
Так сразу бы и сказали, что этот интерфейс подходит и нужен только в вашем проекте. Мы тут все пытаемся мыслить глобально, для среднерядового пользователя среднерядового веб-сервиса.
Хороший подкаст. Я кода увидел (услышал) рекламу этого сайта у Росновского посмотрел и чего-то меня сайт не впечалтил. А вчера прослушал подкасты, и теперь у меня социальные тренды в ленте. Не зря значит подкаст.
То есть грубо говоря там где верстальщик уже прописал классы — не нужно в стилях ограничивать их каким-либо элементов.
Вот только я не согласен с тем, что в стилях нужно писать теги. В стилях вообще не должно быть тегов, только классы (и иногда id)! (подразумеваются стилизированных элементов, а не глобальные a, p, table и т.д.).
Т.е. вместо
body.contacts div#content div#content-text div.entry div.somenamedblockпишем
#content #content-text .entry .somenamedblockАргументация: При программинге не редко приходится менять теги (сеошники тоже, порой, хотят что-то иное), если теги в CSS. Еще где-то было про внутренние требования яндекса к верстке, там тоже об этом говорили, но не могу найти, мб на яндекс.субботниках говорили.
Ну и вообще, если в проекте придерживаются подхода верстки независимыми блоками, то там немного другой чек-лист будет.
В реальности же первый метод это — два клика (выделение цифр), три нажатия на клавиатуре (введение цифр, ентер), но при этом человек вводит точное количество строк и ячеек, а не пытается поймать это количество мышкой. Также для таблицы 15