@victorvsk браузер обрабатывает справа налево только в режиме динамической отрисовки — встретил узел, рассчитал каскад, применил к нему правила. Он не ищет все такие элементы в DOM, он отрабатывает их по одному.
По этой причине every declaration just once — одна из самых приоритетных рекомендаций с точки зрения Google.
Вот есть пара десятков правил, которые наследуются. Вы же не убиваете их в каждом селекторе. Так что скорость расчёта каскада с учётом наследования вы не снизите существенно. Я не беру в расчёт говнокод, ибо едва ли вы его плодите. Так что в рамках нормального подхода в скорости второй подход не выиграет.
А вот ещё вопрос — .blockname_title будет использоваться где-либо, кроме как внутри .blockname?
@AntonEssential у вас для #content .desk-desk input стоит transition на все свойства. Вот он плавно высоту и меняет. Вы определитесь — что там плавно меняется и пропишите только эти правила.
@KidsBout какие ещё программы?)) Единственная программа по ссылкам — браузер. Остальное — Javascript. То, что будут советовать — JS-плагины. Назвать эти плагины программой — абсурд.
@SelenIT2 просто упомянуто деление на современные и несовременные:) А так да — в отличие от IE скриптов в DJM Такой тип элемента добавлять не нужно, только display задать. Как и любому элементу с любым именем.
@FFxSquall table-layout работает только для указания ширины. Либо нужно указывать width напрямую, что нам не нужно в этой задаче, либо ждать, когда таблица растянется на полную.
А с width:auto расчёт ширины столбцов с помощью table-layout задать нельзя, увы... Что-то я не подумал про это. А про table-cell вы верно подметили — я забыл написать. Ну вы и сами с усами:)
@Grawl представьте, что вы решили уехать на 3 месяца в Испанию, Таиланд etc. А работать над проектами продолжите. Да и фриланс на постоянной ставке — далеко не редкость.
@Grawl
Тот факт, что Adobe решил в угоду своим проектам прекратить развивать Fireworks, не означает, что я тут же удалю его с компьютера.
Сформулируйте, пожалуйста, то, чего вам не хватает в Fireworks CS6.
На данный момент его возможностей хватает и вполне, а дальше видно будет.
Бумажное проектирование прекрасно, но только как черновой вариант для себя. Настаёт момент, когда нужно показать это в процессе конференц-колла, вставить в документацию, отправить нескольким участникам проекта, расположенных в других городах. Делать сканы — не вариант.
@iiil предлагаю забить. В хорошем смысле этого слова. Сломаешь весь мозг и всё равно не поймёшь до конца. Там же бутсрап, а ты тут со своими размышлениями:)
@rock о да:) Новичку и reduce как матан для аборигена. Вообще эти сентенции насчёт абстрактных новичков, которые якобы что-то не поймут — кто они, эти неведомые люди, чьё неизвестное мнение обязательно является важнейшим аргументом?)
Пусть разбираются и сразу берут за основу то, что данные желательно подготовить перед работой с ними. А то так можно доупрощаться до того, что prototype станет ругательством — сложно ведь, не поймут.
И, хотя я не вижу, где вы раньше предлагали закончить, соглашусь — всё и так предельно ясно.
@rock про то, что for быстрее всех на свете, а обратный for ещё проворнее, известно давно. Если бы вы написали обратный for, да с предзаменой — без раздумий написал бы, что да, ваше лучше.
Но признать решение, которое короче на 20 символов и априори медленней... В чём смысл беседы?)
По этой причине every declaration just once — одна из самых приоритетных рекомендаций с точки зрения Google.
Вот есть пара десятков правил, которые наследуются. Вы же не убиваете их в каждом селекторе. Так что скорость расчёта каскада с учётом наследования вы не снизите существенно. Я не беру в расчёт говнокод, ибо едва ли вы его плодите. Так что в рамках нормального подхода в скорости второй подход не выиграет.
А вот ещё вопрос — .blockname_title будет использоваться где-либо, кроме как внутри .blockname?