rash

Нет, пункты являются абсолютными единицами, как, например, сантиметры. И именно поэтому их не нужно переопределять для печати, потому что они абсолютны и не зависят от устройства вывода.

Ну я особых различий не видел, обычно разница только в отсутствующих стандартных шрифтах.

> < и никаких пробелов не надо

Тут дело в dpi, скорее всего. Фотошоп по умолчанию создает новые файлы с разрешением 72 dpi. Разрешение большинства мониторов - 96 dpi. Поэтому если в фотошопе размер текста, скажем, 16pt, то для отображения на веб-странице текста с таким же визуальным размером ему нужно задать размер 16*72/96 = 12pt. Ну или при создании нового изображения явно задавать ему разрешение 96 dpi.

Вообще, чаще всего не стоит (ни в таблицах стилей, особенно с помощью импортов, ни для скриптов). Если файлов не слишком много, то зачем? А если слишком много, то стоит реорганизовать код, объединить некоторые из них так, чтобы их стало меньше.

Для создания идеального сайта нужен идеальный контент, идеальный дизайн и идеальный код.

Может, отклонения станут меньше. Но полного совпадения макетов не будет все равно, это понятно.

Чтобы оставалось совсем чисто, ставьте рисунок фоном какому-нибудь элементу. А если достаточно, чтобы просто на месте незагрузившегося рисунка не было текста - задайте ему атрибут alt=""

Попробуйте все значения задать в пикселях, но я не уверен, что это сильно изменит ситуацию...

А если будет отключено сглаживание, то текст перестанет попиксельно совпадать. А на маке он уж точно не будет соответствовать макету с точностью до пикселя. Варианта решения проблемы есть 2: — объяснить, что HTML не предназначен для реализации полиграфических макетов; — отказать заказчику, если первый пункт не пройдет. Ну или вставить картинку. Такого полного контроля над страницей, как вам нужно, HTML/CSS не дают.

Упрощенно говоря, он нужен для того, для чего нет стандартных тегов.

Зато можно точно сказать, что происходит в браузере, если значение сохранено в переменной.

То, что при заполнении левый текст оказывается поверх правого, как у вас на рисунке.. Ну так задайте для него правый отступ...

Риск при этом, на самом деле, практически такой же. Разве что просто кому-то будет лень...

А ничего не будет, весь контент как был, так и останется, в том же положении, на тех же строках и будет совершенно ясно, что к чему относится.

Ну так укажите :-) Никому от этого хуже не будет, зато без стилей поле не будет слишком маленьким.

О чем я и говорю, одинаково интенсивно использовать на практике все знания вам, скорее всего, не придется.

Себе льстить не надо, можно знать что-то очень хорошо, многое - хорошо и очень многое - посредственно.

Конечно, я не могу говорить со стопроцентной уверенностью, но мне кажется что одинаково хорошо знать столько технологий не получится. Какими-то придется заниматься чаще, какими-то — реже, и естественно, что часто используемые вы будете знать лучше, чем те, которые используются от случая к случаю.

Math.pow(2, 1/3); Не то?

Вам принципиально, чтобы решение было именно на css? Это сделать можно (повоевав с IE), но получится громоздкий и плохо адаптируемый код. Если использование CSS не принципиально, то поищите готовые решения на Javascript (их достаточно). Если важно использовать преимущественно css, то посмотрите примеры фотогалерей и слайдшоу здесь.

Бывает нужен, если требуется использовать iframe, например.

Вот и я не знаю, зачем нам XHTML.

Затем, что именно для этого XHTML и разрабатывался, чтобы можно было использовать XML-парсеры для разбора страниц. А не-веллформед документы у меня исправно вызывали ошибки отображения в фаерфоксе (во втором во всяком случае), опере и сафари, при соответствующем заголовке с сервера. Попробуйте помимо meta-тега использовать расширение ".xhtml".

Нет, XHTML должен обрабатываться XML-парсером. На самом деле за то, что они не поддерживают XHTML я им благодарен. Так больше шансов, что в светлом будущем мы перейдем на HTML 5, а не на XHTML.