SelenIT

А Кук их знает Похоже, новая стратегия конторы включает в себя атаку и на бюджетный сегмент в том числе. Сперва мини-айпады, потом айфон 5ц, теперь вот бесплатная операционка и, соответственно, более доступные ноуты. И работает ведь — как минимум, одного покупателя (в моем лице, с мини-айпадом как раз) завоевали...

Если инфа в профиле верная, то автор вряд ли знаком с практиками дизайна 8-летней давности (кстати, с недавно прошедшим ). Другое дело, что юкоз — однозначно не лучшее место, чтобы учиться хорошему в плане дизайна. Лучше начать со специализированных дизайнерских ресурсов. Хороший способ подбирать цветовую гамму — взять за основу красивую фотографию по теме. Имхо, для «волчье-лунной» темы могло бы подойти что-то вроде такого, такого или такого. Есть сервисы, умеющие генерировать такие наборы цветов по произвольной фотографии (например, такой или такой).

Может, на том компьютере был включен «вид без стилей» (в Fx можно включить через меню)?

Имхо, именно сейчас брать безретиновый Эйр как-то обидно, потому что вот-вот можно будет доплатить всего ничего и взять такого же размера новый ретиновый Про... А так из предложенного, имхо, если бюджета хватает, то однозначно Асус. И экран "на вырост" (можно и с фото поработать, и сайт "всю катушку" оттестировать, а будет мелко — поставить шрифт 150%), и железо в целом посерьезнее. Я тут было приценивался к одному Деллу (тоже матовый FullHD-экран, Core i7, правда, как я понял, донельзя урезанный, тоже 2.2 кг веса при тех же 15.6" вместе с DVD-приводом, и всего за 850 у.е.), но остановили сомнения насчет мощности и откровенно слабая (особенно с учетом "ультраэкономичности" проца) батарейка. Так что пока коплю... не решил еще, может, на Асус, может, на MBP, а может, на что-нибудь совсем новое с 4k-экраном... )

Я тоже пока не понял. Видимо, дело в том, что float — вообще очень странный предмет: вроде в потоке, а вроде и нет. Отсюда и разночтения в том, как флоаты влияют на своих соседей, тем более сама спецификация многое дает на откуп браузерам...

Похоже, что каким-то необъяснимым образом .img-wrap.left распирает фактическую высоту .brown, мешая нижеследующему блоку «наехать» на нее (несмотря на фикс. высоту). Задание ему (img-wrap.left) нижнего margin-а в -10px вроде бы решает проблему и не должно мешать остальным. Возможно, издержки плясок с float-ами и клиренсами, хотя по первому впечатлению очень смахивает на баг.

Не получаются большие точки — делайте обычного размера кружочки ●●●●

Есть.

Можно, например, задать релатив позиционирование (которое тоже неявно включит z-index)

Для двух уровней есть вот такой прием. Но как сходу применить для этого случая, где и сверху (у заголовка блока), судя по всему, высота динамическая — сходу не соображу, надо еще покумекать...

У li-шек, которые d:i-b, v-a дефолтный — baseline. baseline'ом инлайн-блока по умолчанию (без смены overflow и т.п.) считается таковой нижней строки текста в нем. В данном случае нижняя строка текста — это текст кнопки. Который и сдвигается при наведении, сдвигая базовую своей li-шки. Проще всего решить, сменив v-a для li-шек.

Не то чтобы прямо уж нужно, но крайне и весьма желательно

Если задача — максимально спрятать логотип от поисковиков, то второй вариант. Если, наоборот, желательно, чтобы его находили (в т.ч. через поиск по картинкам — а вдруг?), то лучше первый, и обязательно указать картинке адекватный alt (а хорошо бы еще и title).

Чисто визуально — да, можно. Но мы ведь, кажется, начинали спор про семантику

Я смотрю на то, что добавляет та или иная разметка. Упорядоченный список — единственный способ присвоить сущности порядковый номер на уровне самой разметки (не считая микроданных и прочих расширений), это бывает важно, особенно для постранично разбитых перечислений. Неупорядоченный список сам по себе своим элементам никакой машиночитаемой семантики не добавляет, и чем крупнее сущность, тем объединяющая роль списка менее очевидна. Для перечисления ингредиентов кулинарного рецепта, например, списочная природа очевидна (без списка это были бы просто непонятные обрывки слов), но уже для рекламного отрывка, в котором каждый абзац описывает одно преимущество чего-либо, разница между списком и просто последовательность абзацев начинает стремительно ускользать. Если же сущности являются самостоятельными секциями, список, имхо, становится избыточным, как для глав (разделов) в книге (наличие разделов уже подразумевает объединенность их в нечто более общее). Честно говоря, я бы и для товаров от списка отказался, но меня Хикси уговорил

В спеке есть такое Отсюда лично я вывожу для себя правило, что если у последовательных сущностей есть заголовки, то они, скорее всего, не список. Обычные разделы документа (напр. главы в книге) мы же в список не заворачиваем — так и здесь. Еще одно правило я вывел, когда понял, что дефолтное браузерное оформление HTML-элементов — не зло, с которым нужно всеми силами бороться, а хорошая подсказка по их использованию. Если вид элемента с дефолтными стилями не помогает пользователю, а только запутывает его — скорее всего элемент выбран не по назначению. Если что-то будет выглядеть нелепо с дефолтными кружками-буллетами — скорее всего, это что-то не список по природе. Если список настоящий, ему и с буллетами хорошо. Исключение, на мой взгляд — сущности, явно отсортированные по опред. параметру (напр. товары в каталоге, упорядоченные по цене или по рейтингу). Там уместен упорядоченный же список ol (и дефолтная нумерация беды не сделает).

Точки можно градиентом нарисовать. А копируется :after или нет — это же, вроде, от браузера зависит?

Смотря какой таблицы. Хотя и dl, по-моему, в расширенном понимании из актуальной спеки тут уместен.

Какое-то время казалось, что да. Сегодня вот опыт показал, что нет

Полагаю, под «сеткой» автор подразумевал Grid Layout.

jQuery может использоваться как фреймворк (быть основой и главным связующим звеном архитектуры веб-приложения). Но лучше так не делать, а использовать его лишь как библиотеку. На одном из недавних WSD был целый доклад на эту тему.

Вопрос в том, где какой стиль считать установленным. Например, в том же БЭМ-е, который сегодня вырос вполне себе в общемировую тенденцию (как минимум, не ниже всяких SMACSS и прочих OOCSS), вовсю используются и дефисы, и подчеркивания (причем для разных, строго специфицированных целей).

Ходят упорные слухи, что есть. И в любом случае валидную верстку проще поддерживать.

Почему, поворачивать можно столько раз, сколько нужно. Главное, чтобы суммарный угол всех поворотов был равен нулю (картинка вернулась в норм. положение).

Если не можете сказать уверенно, почему эти атрибуты там оказались, зачем они нужны и нужны ли вообще — да, лучше убрать. В принципе, достаточно универсальное правило (в коде должно быть только то, что однозначно нужно для дела, бессмысленный лишний код — потенциальный источник проблем).