SelenIT

А по-моему, как раз разрешение не должно волновать вебмастера. Разворачивать окно браузера на весь экран или на пол-экрана, занимать пол-окна полезными и бесполезными сайдбарами и т.п. — святое неотъемлемое право пользователя, и создавать ему любые препятствия в этом — прямое и грубое нарушение статьи 19 Всеобщей декларации прав человека (о праве на информацию. Так что подстраивать удобство восприятия имеет смысл (если вообще имеет) исключительно под рабочую область, а разрешение — сугубо для статистики.

Унаследовать шрифты я имел в виду в CSS. Тогда, мне кажется, все необходимое от JS-части сведется к предложенной строчке (ну, может, где-то поправки для браузеров понадобятся)...

Унаследовать все шрифты em-ами от шрифта body, и сделать что-то вроде onload = onresize = function() { document.body.style.fontSize = parseInt(document.body.offsetWidth/80) + 'px' } не вариант?

Потому что дело не в версии языка разметки, а в режиме рендеринга браузера. В HTML4.01 Strict, XHTML1.0 и HTML5 то же самое.

Задать его картинкой через стили. А не через непонятно откуда взятую тарабарщину на несуществующем языке

На ноутах, особенно с маленьким (физически) экраном, нередко по дефолту бывает 120dpi ("крупный шрифт" в настройках экрана), соответственно, шрифт на четверть крупнее.

Не, до маразма - это что-то вроде document.onmousemove=function(evt){if('me' == ((evt&&evt.target)||event.srcElement).id){alert('Попался!')}}

Aleko, мысль интересная, но приведенный вариант не работает в IE. А кроссбраузерный вариант уже не так прост...

Баг IE. Подробности на cssing.org.ua.

Скорее всего, дело в hasLayout. Попробуйте поубирать у ul/li все CSS-свойства, которые его врубают.

У меня Avast заверещал, что по ссылке вирус. Дальше идти побоялся(.

Задать разумный max-width типа 1400px и сделать картинку такого размера — не вариант? А обладателей двухметровых широкоформатников никто не заставляет разворачивать браузер на весь экран (как и юзеров офисных "семнашек", между прочим...

Можно задать фон в виде url(about:blank). Работает как минимум в IE7 и Opera 10b1.

s0rr0w, а в Опере разве можно? Если да, то давно? Хотя, по мне, для анимации передавать параметры особо ни к чему — вся нужная инфа уже есть в свойствах стиля анимируемого объекта (а если не вся, так никто не мешает навесить на него кастомное свойство)...

Еще, имхо, полезный ресурс для "вхождения в тему": http://softwaremaniacs.org/blog/category/web/primer/

Fu-tai, "безликие", не имеющие собственной семантики теги — блочный div и инлайновый span (рисоваться они могут и по-другому, но сути своей, которая content-model, от этого не меняют) — это крайняя вынужденная мера, когда необходимо реализовать хитронавороченную структуру (напр., сложный микроформат) или оформительское извращение (резиновый по всем направлениям полупрозрачный блок с фигурными уголками, рамкой и тенью и для этого нет стандартных средств (списка, цитаты, адреса, смыслового выделения и т.п.). В текущем черновике HTML5 даже есть специальная ремарка про опасность злоупотребления div-ами ради самой разметки, а не как средством расширения логики. Имхо, к span-ам это тоже применимо. Img сам по себе — полноценный инлайновый блок (причем надежно работающий даже в браузерах, не поддерживающих inline-block!), к нему можно применять padding-и, border-ы и даже фоновые картинки, поэтому для простых оформительских задач типа одинаковой рамки у ряда картинок одного фиксированного размера обертка не нужна (замечу, что речь идет именно об оформлении картинки, а не блока с картинкой, поэтому эти свойства для нее никак не лишние, и перенос этих свойств на искусственный, только ради этого введенный элемент как раз ломает семантику!). В фотогалереях и т.п. вещах картинка, как правило, уже обернута в другой строчный тег — ссылку, которая там оправдана по смыслу и вполне может взять на себя и оформительские задачи. Ну а если и этим не удовлетворить неуемную фантазию дизайнера — тогда, да, без "бессмыссленного" абстрактного span-а никак... termoplus, Я стараюсь придерживаться общего правила: если без обертки можно обойтись с разумными трудозатратами — лучше обходиться без нее.

Еще пара вариантов: - display: inline-block (на данный момент у него есть проблемы с кроссбраузерностью, так что рабочий вариант примерно следующий): .layer { display: -moz-inline-box; /* для FF2, может глючить */ display: inline-block; padding:7px 18px; background-color:#3d2e1e; } * html .layer { /* аналог inline-block для IE6 */ display: inline; zoom: 1; } *+html .layer { /* то же для IE7 */ display: inline; zoom: 1; } - display: table (к сожалению, не поддерживается IE7-, поэтому понадобится тот же фикс, что в примере выше).

Вообще обычно чем меньше лишнего, тем семантичнее, любые обертки с точки зрения семантики — как правило, оформительский мусор (всякие фигурные рамочки с тенюшечками и т.п.). Но если пожалуй, есть смысл обернуть ее во что-то блочное (не span, а p или тоже div) для большей логичности структуры, на мой взгляд.

Что именно? application/xhtml+xml или text/xml с трансформацией?

Не наоборот ли? По сути да. Но шаблон все-таки, как ни крути, является программой на языке шаблонизатора...

По мне (если моя телепательная машинка не врет и это для обрезки текста для анонса) обрезать примерно с двукратным запасом для худшего случая (замерить эмпирически), а остальное убирать на клиенте, тем самым overflow:hidden + вариации на тему text-overflow:ellipsis. Кроме прочего, это еще и проблему изменения размера шрифта (в разумных пределах) решит. И для поисковиков больше зацепок останется...

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

AFAIK, XSLT — сам по себе язык программирования. Функциональный. А реализации — это уже конкретные XSLT-процессоры... Угу, только его придумал тот самый Билли Гейтс в 98-м году По сабжу — HTML (в лице 5-й инкарнации с изменениями и дополнениями) останется основой клиентской части веба как минимум все ближайшее десятилетие. Для рядовых пользователей ориентированность HTML на поточную загрузку, "либеральный" к ошибкам парсинг, позволяющий получить вменяемую DOM-структуру даже при битой разметке, отсутствие "желтых экранов смерти" и т.п. — явные плюсы.

А не указывать width и height в этом извр... оригинальном тайтле - не вариант? Пусть хотя бы выводит с реальными размерами, не искажая...

Int, нормальные редакторы в большинстве случаев сжимают в png-8 лучше, чем в gif (кроме ну очень уж маленьких картинок, типа однопиксельных двухцветных полосок).