SelenIT

Если есть float, inline не нужен (разве что как лекарство от удвоения крайних маргинов в IE6). Float всё равно по факту блочный.

Если надо сгруппировать блочные элементы, может, проще поменять span на div?

99.5% . Спецификация разрешает и русские буквы, и еще много чего. В исключительных случаях может быть полезно. Но именно в исключительных, злоупотреблять этим нельзя.

В файлике ie.css хотя бы одна строчка с этой бякой у меня обычно находится

Полной поддержки HTML4 нет ни в одном браузере. По крайней мере не помню, чтобы хоть где-то работали атрибут longdesc для <img> и задание размеров типа width="2*" для ячеек таблиц. Да и со многим другим есть проблемы. Поэтому оглядка на возможности браузеров целевой аудитории нужна при любом доктайпе. В теории так, но на практике новые браузеры (Хром, FF4+) любой HTML интерпретируют как HTML5, а доктайп влияет только на режим браузера.

Имхо, лучший на сегодня компромисс для лого — PNG-8 с альфа-каналом. В IE6 будет не хуже, чем в гифе, а во всех остальных — сопоставимо с PNG-24 при меньшем весе файла. И никаких фильтров-шмильтров не надо!

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

С точки зрения логики заголовков XHTML1 - это HTML4, XHTML2 был очень близок к нынешнему ЖHTML, а "XHTML5" - это он, родимый, и есть. Синтаксис логику не меняет...

Возможно, от него бывает польза для поисковиков (кое-что почти по теме от Google и т.п.).

То, что при наведении на текст пропадает выделение рамки, а при наведении на пустоту справа/слева от текста пропадают оба выделения (Хром, ФФ7b) - баг или фича? Выглядит, честно говоря, как баг. Сугубо имхо - чем проще, тем логичнее... И свойства без префиксов (типа border-radius), как правило, лучше указывать последними, после всех "префикснутых" вариантов - чтобы браузеры, поддерживающие как старую глючную, так и новую стандартную реализацию, выбирали именно последнюю. И -khtml- сейчас, по-моему, давно напрочь неактуален.

nl2br - логично, но addslashes-то нафига?

Может, дело в самой картинке (гаммы всякие, цветовой профиль нестандартный и т.п.)? Впрочем, у меня тоже не воспроизводится.

Из перечисленных в той табличке браузеров только IE7 и остался мало-мальски актуальным. Если не мудрить с отступами, все актуальные браузеры накрываются классическим clearfix-ом (псевдоэлемент с clear для всех новых + hasLayout для старых IE), без доп. разметки. Особых подводных камней нет, но и особого толку тоже. Из всей строгости X(HT)ML реальная польза есть разве что от обязательности закавычивания значений атрибутов (слегка подстраховывает от XSS в value полей форм), но уже запрет кратких атрибутов скорее мешает, чем помогает. Главный минус - код валидируется и парсится на практике по разным правилам (для валидатора <img></img> и <div/> - нормально, а для браузера - косяк). Ну и ограниченность словаря Strict-ом запрещает не только старый мусор типа <font> со спорными вещами типа target, но и полезные новые вещи типа атрибута autocomplete... Для тренировки - в целом скорее полезно. Но для практики "не все требования валидатора одинаково полезны", сама по себе валидность еще ничего не гарантирует.

Gaspode, так бардак с огромным красным текстом - это то, что было "до" Имхо, стало поприличнее, но совсем по-хорошему текст надо было бы оттипографировать. И верхняя менюшка выгдядит недоделанной. Имхо, чем такие картинки-закругления, лучше заюзать border-radius. Ну и целый пустой <div> для клиринга... оно-то работает, да, но зачем прямо вот так грубо? И еще: XHTML Strict - объективное требование или личная прихоть для "спортивного" интереса?

Про ширину основных блоков я и не говорил, только про украшательства . Насчет ширины полностью согласен, даром что новые браузеры умеют и ее подгонять под размер окна ("адаптивный зум"). Нетбуки с 1024?600, конечно, отдельная статья, хоть специальную "полумобильную" версию под них делай... Кстати, на одном из сайтов, который я сейчас поддерживаю, набралось за 12% именно 1024?768, причем это не айпады (тех всего 1%) - похоже, именно что динозавры.

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

Древний и тупой, но кроссбраузерный и надежный, как лом, вариант — сделать скрытый iframe, задать его name в качестве target-а формы и отсылать форму туда. Вывод обработчика оформить в виде яваскрипта, обращающегося к элементам родительской страницы (parent.document.getElementById(...)) и записывающий в них (через innerHTML) что угодно. Если задача "быстро сделать и забыть", можно пойти по такому пути. Если задача — разобраться и научиться, лучше добивать Аякс. А по поводу отладки — рекомендую эту статью.

1em — это размер кегля шрифта (максимально возможная высота символа, со всеми верхними и нижними "хвостиками" и диакритиками), т.е. величина, выставленная в font-size. То, что 1em будто бы равен ширине буквы "M" — популярное заблуждение (так было буквально две с половиной тыщи лет назад у древних римлян, которые писали заглавными буквами без отступов, но с тех пор многое в шрифтовом деле поменялось). Однозначно перевести em-ы в количество символов можно лишь для моноширинных шрифтов типа Courier.

Если размеры шрифта увеличиваются, то да, расстояния будут некрасиво дергаться. Но сам по себе inline-block подсветкам ховера и прочим выделениям не только не мешает, но даже помогает . Проблема данного решения может быть в отступе на высоту строки из-за псевдоэлемента, который помогает задействовать justify, но это тоже относительно несложно приводится к общему знаменателю и фиксится. Впрочем, я там привел два варианта — у хардкорно-табличного, по идее, нет и этих проблем...

Или просто document.getElementById('pre').innerText = 'ksdf\r\njdsfk'; (благо IE первым такую удобную штуку ввел. Но суть та же.

Гы, прикольно . Хотя формально вроде как тогда IE ничего не нарушал — innerHTML до HTML5 нигде стандартизован не был, а при нормализации действительно перевод строки и пробел можно считать равнозначными...

Всё тот же overflow:hidden (т.е. его отсутствие).

А это смотря где и как...

А нужна ли ширина?

Априори-то было ясно, но эксперимент в виде фона у потомка (нескругленного) в очередной раз показал справедливость фразы "в теории между теорией и практикой нет разницы, а на практике она огромна"...