SelenIT

Ток-то бывает и в электролитах, где разные ионы двигаются навстречу друг другу, так что абстракция отчасти оправдана. А вот в терминологии... Разве нормально, когда sleep mode в русифицированной Windows внезапно стал «ждущим режимом», а «спящим режимом» оказался hibernate? А в CSS такие ловушки сплошь и рядом. Например, как перевести block box, line box, inline box и inline block, чтобы эти вещи не перепутались?. Или тот же «интерлиньяж», чему он соответствует: английскому leading или line height (правда, здесь уже в трактовке русского термина неоднозначность, в пределах самого типографского контекста)? Забота о чистоте языка понятна и важна, но, имхо, в узкой специальной области однозначность трактовки важнее, а потому у буквальной кальки, не несущей побочных ассоциаций, есть все шансы оказаться наименьшим злом. Хотя поспорить на эту тему бывает интересно.

Нужно! Эта запись бессмысленна и бредова. relative может быть position, а left может задавать смещение при position: relative. Но значение "relative" для "left" недопустимо, поэтому вся запись просто игнорируется.

"Функционально" правильнее-то, но дальше... Если float: left — «обтекаемый слева» элемент, то почему текст обтекает его с правой стороны?

Селекторы читаются справа налево. Буквально: ссылка, являющаяся первым потомком своего родителя, лежащая где угодно внутри li, лежащего где угодно в элементе с классом menuleft. Этому условию соответствуют все ссылки в меню, а не только ссылка в первом li (для нее селектор был бы li:nth-child(1) a).

Всё тривиально. Главное, чтобы теги не перекрывались (т.е. table должна быть целиком внутри form).

Конечно, можно. И часто делается. В form можно вкладывать table.

Можно же одним вызовом css(), по аналогии с animate() чуть ниже?

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

Почему, будет — как margin:0 . Хотя да, ради одной стороны по факту логичнее было бы написать margin-bottom: -65px;.

Ну, как минимум, будет шанс получить похвалу в другой теме

Ну ресет-то ресетом, но «знать врага в лицо» (кого ресетим и почему именно так), имхо, лишним не будет...

Справедливости ради, у новых браузеров разнобой гораздо меньше, всё более-менее приближено к спецификации. Посмотреть можно в Firebug (включив «Show User Agent CSS» и глядя, что берется из System) и Dev. tools Хрома (там стили из «user agent stylesheet» показываются по умолчанию).

Всё равно это явный баг браузера, надо сообщить куда надо, чтоб не затягивали с фиксом. В последнем Хроме-Канарейке (30-ка) я тоже заметил косяки с hover-ом. Сначала с наследованием border-color от текущего color, меняющегося по hover-у (помогло явное задание border-color: currentColor), а после очередного обновления даже с обычным background-color'ом началась свистопляска. Так что такие досадные регрешны в погоне за сверхновыми крутотенюшками и мегаскоростью у них, увы, бывают...

Конкретно в Notepad++ можно без этого обойтись, там, кроме "Encode in <названиеКодировки>" есть функция "Convert to <названиеКодировки>", которая это и делает. Но в общем случае, да, это самый надежный вариант.

А у td-шек случайно не выставлена ширина, типа 100% у каждой?

Запретить нельзя, но убрать можно (лучше на серверной стороне).

Увы... Но, надеюсь, ненадолго. Впрочем, чисто для горизонтальной сетки можно и включить. UPD: теперь уже будет display:flex без вариантов.

А по-моему очень как раз. Например, для текущего актуального на момент поста Fx, который те же флексбоксы формально вроде как поддерживает (даже без префикса!), а фактически — едва-едва наполовину, потому что нет wrap-а. Благодаря @supports можно «доверять» ему флексбоксы лишь с того момента, когда он научится научился (с 28-й версии) понимать их на все 100, не засоряя при этом код браузероспецифичными хаками...

Там в комментах Пол Айриш навел относительную ясность, что это относилось к старой реализации (синтаксис 2009 года). А новые флексбоксы, по его данным, получились в два с лишним раза быстрее старых и в полтора раза быстрее table-cell'ов. Так что оптимизированы они, видимо, неплохо. А флексбоксы, у которых от «флекс-» одно название, как здесь (flex: none), по идее, тем более не должны вызывать каких-то лишних оверхедов — размеры известны заранее, пересчитывать/перерисовывать ничего, кажется, не надо...

Подумалось тут в развитие старой темы. По сути, используя инлайн-блоки со «скукоженными» пробелами между ними, мы ведь пытаемся эмулировать «новые» флексбоксы (в т.ч. в многострочном режиме — flex-flow: row wrap) с flex: none. И у нас есть надежное средство «скукожить» пробелы везде, кроме вебкита (отриц. word-spacing с запасом), лекарство для старых вебкитов (display: table для контейнера) и... собственно флексбоксы в новых вебкитах (Хром-Канарейка и т.п.) . А также @supports, чтобы все остальные могли перейти со старых костылей на правильный флексбокс, как только смогут сделать это наверняка. Тем самым мы избавляемся от подгонки «магических» значений для двух похожих, но сильно неодинаковых по действию свойств (word-spacing и letter-spacing) и, по идее, получаем решение, с которым история как в ссылке выше уже точно не приключится. Старые костыли будут использоваться только в старых браузерах, где баги/фичи, на которых они основываются, заведомо работают. А новые браузеры будут плавно переходить на стандартное решение, не требующее костылей. Чем не прогрессивное улучшение? Правда, в новых вебкитах (и будущих браузерах) и всём остальном задача решается разными технологиями — но фактическое поведение очень похоже. Причем старая технология, можно сказать, проверена временем, а новая зато специально «заточена» именно для этой задачи. Прошу посмотреть пример (я взял за основу те же YUI Grids, откуда расползлись эти загадочные -.43em) и покритиковать идею и реализацию

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

Метка порядка байтов в многобайтных кодировках. Для UTF-8 необязательна и чаще создает проблемы, чем решает, поэтому по возможности лучше сохранять файлы без нее. У "блокнота", к сожалению, такой возможности нет.

Эффект называется «parallax scrolling». Есть куча готовых jQuery-плагинов для его реализации. В простейшем виде как-то так.

Насчет библиотеки не знаю. Для IE7 фильтры требуют hasLayout (включается указанием размеров или zoom:1), в IE8 должно работать и так. Можно взглянуть на проблемный код? Для второй задачи — можно тоже фильтром, AlphaImageLoader(src='...', sizingMethod='scale'). Бывают побочные эффекты в виде потери кликабельности ссылок внутри такого блока, обычно лечится заданием им position: relative. Зато так можно накладывать два фона сразу (один фильтром, второй стандартно).

В принципе, логично. Тем более аргумент за то, чтобы эта тень не была привязана к белому футеру. Может, всё-таки ее на .wrap:after повесить, а боковые тенюшки к .top-у прицепить, с которым они и визуально связаны?