SelenIT

Как вариант, сначала через Tidy, потом через любой XML-парсер. Или как другой вариант, попробовать библиотеки для HTML5, во многом эмулирующие парсинг в браузерах (типа такого).

Я бы ограничился двумя пунктами: 1) Знать, для чего каждый тег предназначен (семантика); 2) Помнить, что во что можно вкладывать (структура документа, во многом определяется семантикой -- если чуть подумать, станет очевидно, что в списке могут быть только элементы списка, а в ссылке не может быть других интерактивных элементов типа кнопок). И всё. Эти два правила гарантируют, что независимо от стиля кодинга результатом разметки будет вменяемая DOM. А вот бездумное механическое соблюдение правил XML - увы, нет.

Логично, div не закрыт и при построении DOM-дерева скорее всего тупо вываливается из ссылки (можно проверить firebug-ом, developer tools'ами из IE8 и т.п.). Правильный CSS показал psywalker. Но для надежности лучше вкладывать в ссылку не div, а span (задав ему display:block), до HTML5 div внутри ссылки невалиден. Это совсем разные вещи. Первое -- элементы с классом "one", второе -- ссылки внутри элементов с этим классом. С псевдоклассом абсолютно то же самое.

В общем случае искомое "лекарство" называется контекстом форматирования.

«Незакрытый тег это как незастегнутая ширинка: вроде и штаны не падают, но что-то с окружающими людьми не так.» ©

Вывод неверен . Потомками UL могут быть как раз только LI, ничего больше. А вот в LI уже можно спокойно вкладывать хоть ссылки, хоть что. И в P ссылку тоже нужно вкладывать внутрь, а не натягивать наружу. Иначе непредсказуемость.

Вот эта, увы, бойанистая картинка:

Как вариант, матрешка из 3-х дивов. Наружный - width: 100%; min-width: 1280pх, равнение по правому краю, левый выезжающий фон. В нем див с min-width: 1024px; max-width: 1280px, равнение по левому краю, правый выезжающий фон. В нем контент шириной 1024px.

Прикол в доктайпе. Без него странички отображаются в Quirks mode (в манере "диких 90-х"), и браузеры "додумывают" за автора, что он имел в виду, например, задавая (статически или скриптом) стиль "width:100" — пиксели или еще какие-либо единицы. А с доктайпом браузеры полагают, что автор знает, что делает, и так не самовольничают (по крайней мере, некоторые).

Спасибо за поздравления! От души присоединяюсь! С наступившим!

Мне просто интересны мотивы, побуждающие людей к, гм... конструированию такого кода . Прекрасно понимаю, когда есть обычная ссылка (возможно, "облагороженная" аяксом и иже с ним), и хочется сделать ее покрасивше, с отдельным заголовком и отдельным пояснением (ради этого в HTML5 даже узаконили вложение в ссылку блоков). Могу понять, когда глухая недоссылка используется для hover-эффекта (тех же выпадающих при наведении подсказок и т.п.) ради простоты совместимости с IE6. Могу понять, когда по этой же причине (плюс нездоровая фантазия дизайнера и нехватка времени на укрощение <button>-ов) недоссылка используется вместо кнопки отправки формы (и даже готов прислушаться к аргументации, что юзеры без JS сегодня коммерчески не значимы). Но кто/что заставляет людей упрямо натягивать ссылку на абсолютно неподходящую к ней ситуацию, если от нее не видно никакого другого проку?

Можно нескромный вопрос: на кой ляд там вообще ссылка, если переход по ней мало что на "решетку", так еще и явно заблокирован, а hover-эффект (который мог бы хоть как-то оправдать такую горе-недоссылку в контексте никак не подыхающего IE6) все равно реализован скриптом, а не стилями? Какие преимущества тут дает тег <a> (использование которого таким образом запрещено актуальными спецификациями) по сравнению с любым разрешенным тегом — хоть тем же самым <div>? Хотя вообще аццкая мешанина "чистого" JS и JQuery (?) прямо посреди разметки в задаче, в наши дни на ура решаемой голым CSS, вызывает... гм... недоумение

Так сами теги меняться и не должны. <base> меняет их поведение ("расшифровку" относительных ссылок) при нажатии. Кстати, что делают div-ы до head-а? Это штучки юкоза или баг сайта? Никаких отображаемых тегов до </head>, иначе браузер неявно его закроет, <base> туда вообще не попадет и результат окажется непредсказуемым!

Взять фактическую внешнюю высоту родительского элемента, умножить на 0.8 (т.е. на ту часть, что должна остаться от высоты этого род. эл-та за вычетом двух 10%-ных оступов, ноль перед точкой в JS можно не писать) и дописать к этому строку 'px' (при этом всё значение — дробное, в общем случае, число — неявно приведется к строке). Получится легитимное значение CSS-свойства height, которое и применится к эл-ту. По идее, оно будет пересчитываться и переприсваиваться при любом событии, ведущем к перерисовке (reflow) окна — ресайзе, изменении размера шрифта, изменении innerHTML и т.п... но тут я уже не уверен, IE неистощим на сюрпризы Кстати, возможно, в данном случае лучше цепляться к внутренней доступной высоте (clientHeight) предка, т.к. offsetHeight, насколько я в курсе, включает в себя толщину border-ов.

Только я бы this.parentNode.offsetHeight за скобки вынес, а в рабочем проекте и вовсе упростил бы весь экспрешн до this.parentNode.offsetHeight*.8+'px'

Вообще-то XHTML — частный случай XML, так что его знание уже подразумевает знание XML (как общей базовой основы: синтаксис и парсинг, веллформность, схемы и валидация, сущности и пространства имен...). Следовательно, если кто-то считает, что "знает XHTML, но не знает XML" — он как минимум в одном заблуждается . Впрочем, на самом деле большинство сложностей XML кажущиеся, а на практике всё оказывается ещё проще . А JS в современном вебе просто необходим. И он, наоборот, поначалу кажется очень простым, а на деле полон маленьких и больших хитростей (и вообще много лет был самым недопонятым языком программирования в мире). Но дорогу осилит идущий . А вообще очень неплохо сориентироваться в самых основах — что-такое веб, что из себя представляет его самый главный протокол и в чем ключевое отличие веб-приложения от обычной программы (по ссылкам речь о PHP, но не в том суть — азы справедливы для любой серверной платформы), в чем специфика клиентской и серверной сторон и т.п. Тогда и выбор инструмента для каждой задачи станет легким и очевидным

Смотря где. Первое - это <ul id="Header">, а второе - это <whatever id="Header">...<ul>. "Покрасить 7-й дом по ул. Заречной" и "покрасить все дома по ул. 7-й Заречной" - немного разная работа ведь, верно?

По изначальному вопросу - архирекомендую эту статью: трепанация DTD Насчет списка "что где можно" - на самом деле в спецификации всё есть. Для XHTML 1.0 всё точно так же, как для HTML 4.01 того же подвида (Strict, Transitional или Frameset), разница только в более жестком (как правило XML-синтаксисе. Для разрабатываемого и понемногу входящего в моду HTML5 есть похожая табличка.

Мне кажется, что движение чего-то вокруг явного центра притяжения сам Кеплер велел рассчитывать в полярных координатах, а в декартовы преобразовывать уже на выходе, непосредственно при отрисовке. Все-таки основу траектории (эллипс/парабола/гипербола) явно Солнце задает, планеты лишь возмущения накладывают. Для начала с вполне приличной точностью, имхо, хватит Юпитера с Сатурном, остальное уйдет в погрешность. И, кстати, разве планеты все время движения этой кометы так и будут стоять как вкопанные?

html, body { margin: 0; padding: 0; } ?

Пыха жаловалась, что до отдачи заголовков был какой-то вывод. Возможно, BOM-метка (если файл в utf-8 и сохранен в блокноте). Надо пересохранить в нормальном редакторе без BOM (на самый крайням — в блокноте в ANSI).

Можно написать симулятор эволюции живых организмов. Организм -- массив некоторых величин ("генов"), начальные значения всех величин абсолютно случайны, но некоторые значения предпочтительнее (критерий отбора). Организмы могут обмениваться генами друг с другом в процессе полового размножения, порождая новые организмы с их случайной комбинацией, кроме того, гены могут мутировать — менять значение на совсем произвольное с какой-то очень маленькой вероятностью (напр., у каждого тысячного "новорожденного" организма). Организмы с менее оптимальным набором генов имеют меньшую вероятность оставить потомство, чем с более оптимальными. И посмотреть, что получится через сотню-тысячу поколений . На Хабре был занятный пример про эволюцию часовых механизмов (там вроде даже ссылки на какой-то код были), можно взять за основу

psywalker, я попытался ответить, но форум мне сказал что-то типа "письмо не может быть отправлено, т.к. почтовый ящик адресата забит под завязку"...

Имхо, кастомный селект лучше всего делать на базе набора радиобаттонов с лейблами (или чекбоксов, если он multiple — тогда вообще доделка минимальна . Функционально (для серверного обработчика) разницы никакой, так что "изящная деградация" получится по построению.

А процентам-то есть от чего отсчитываться? html, body { height: 100% } или что-то подобное стоит?