SelenIT

Не все, что "валидно по стандартам W3C", понимается всеми браузерами (особенно IE). Как раз с PNG-картинками в IE издавна были проблемы (то гамма слишком темная, то прозрачность некорректно работает...). Ради кроссбраузерности приходится идти на компромиссы со строгостью стандартов, как и во многом другом. Имхо...

Точнее, "распирает" элемент изнутри, увеличивая высоту (плюсуясь к ней). Увы, таков стандарт (да, нелогично, но так уж сделали), в строгом режиме (с полным правильным доктайпом) так везде. Как вариант - убрать паддинг вообще, а height заменить на line-height (если надпись на кнопке заведомо однострочная).

Обязательных стилевых параметров, насколько мне известно, нет (в отличие от атрибутов тегов). Все предупреждения валидатора в данном случае продиктованы не какими-то формальными требованиями, а исключительно здравым смыслом. Первые два заботятся о читаемости текста, чтобы в результате вложения/наложения элементов перед юзером не предстала надпись черным по черному или зеленым по зеленому (в т.ч. при наведении на ссылку). Последнее предупреждение говорит о том, что для какого-то элемента одно и то же свойство задается дважды, с разными значениями ("покрась мне вон то зеленым... ой, нет - покрась лучше его фиолетовым", намекая на то, что таблицу стилей, возможно, стоит оптимизировать. Если всё перечисленное использовано осознанно (надписи, совпадающие по цвету с фоном других элементов, заведомо не наезжают на эти элементы, значения переопределяются в целях кроссбраузерности и т.п.), эти замечания можно смело игнорировать. Они лишь страхуют от нечаянных ошибок. Но иногда указание фона бывает необходимо для борьбы с глюками IE (например, искажением текста при задании ему фильтра и включенном сглаживании шрифтов, или для работы CSS-ролловеров). И еще желательно явно задавать цвет фона для html/body - не у всех браузеров он белый по дефолту...

Если в меню больше одного выпадающего уровня, я бы не советовал зацикливаться на чисто CSSных решениях. Яваскриптовые варианты однозначно выигрывают в юзабилити (можно без проблем добавить задержку, чтоб при случайном соскоке курсора не начинать с самого начала, можно сделать красивую плавную анимацию и т.д.), к тому же для IE6 чаще всего все равно нужна JS-добавка. Стю Ничолз (автор cssplay.co.uk), конечно, гений, кроме шуток (каждому бы такую гибкость ума да такой энтузиазм, особенно в его годы!), но он сам признается, что его эксперименты - не более чем "демки" возможностей технологии, а не рецепты для воплощения в реальных проектах. Хотя кое-что, конечно, и стоит взять у него на вооружение

Но только в убогом Quirks mode

Насчет строчного и блочного. Как я понимаю, в доцээсэсные времена соответствие между нынешними content models и visual formatting model было однозначным, и соблюдение требований первого автоматически гарантировало штатный режим для рендеринга (т.е. отсутствие подобного). А теперь, когда структура/семантика сама по себе, а визуализация сама по себе, вебмастеру приходится самому думать и про второе, и, на всякий случай - для невизуальных ПА, к примеру - про первое. Потому что валидности разметки и даже корректности DOM уже мало для нормального отображения, нужна еще логичность стилей. Насколько я понял, Yarik Voronov имел в виду частный случай - открытие документа с локального диска. Тогда порядочные браузеры, действительно, определяют Content-type по расширению файла. Примеры Yarikа Voronovа не нарушают спецификации XML 1.0 (указанного в XML-прологе), это действительно веллформный XML. О валидности первого примера речь идти не может, т.к. нет схемы. Второй пример валиден (насколько я успел заметить) относительно своего оригинального доктайпа, формально он - не XHTML1.x (тем более не HTML4.x), поэтому "валидировать" его по этим спецификациям тоже нет смысла. Но поскольку он остается веллформным XML1.0 и указывает на стандартное XHTML-ное пространство имен, невалидирующие парсеры браузеров могут интерпретировать его как фактически XHTML5 с простительными ошибками (что и делают... Эх, но до чего же познавательный оффтопик получается! По-моему, стоит перенести соотв. часть темы в раздел "HTML" или "Теория", да по-хорошему закрепить...

Ух как от темы-то отошли... Прокомментирую, пожалуй, только это: Не может он изменить это. Он может лишь перекрыть стили по умолчанию, захардкоденные в браузере. DTD определяет базовую семантику элементов, с визуализацией он никак не связан. К парсингу разметки CSS никакого отношения не имеет, CSS (хоть авторский, хоть браузерный дефолтный) применяется позже, к уже отпарсенной и построенной DOM. "Блочность" и "строчность" элементов в DTD и в CSS — разные вещи, совпадающие лишь в том дефолтном CSS (и то не всегда — в IE табличные элементы имеют дефолтный display:block, а не table и т.п., хотя их поведение разительно отличается от обычных блочных элементов, особенно в Quirks mode). Ну а XHTML — действительно, приложение XML. Приложение весьма конкретное — реализующее ту же семантику, что и SGML-приложение под названием HTML 4.01 (XHTML1.0 — один-в-один, не зря оно называется "A Reformulation of HTML 4 in XML 1.0". Не считая синтаксиса, DTD у этих языков идентичны. И возможности "расширения" (точнее, создания новых производных языков разметки на их базе) — тоже. В XHTML1.1 это несколько проще — благодаря модульности соотв. DTD — но практической нужды в этом, имхо, немного. Умеет ли валидатор проверять такие нестандартные DTD, сходу не скажу, проверять надо (гибридные языки типа "XHTML1.1 c внедренным MathML" точно умеет, но это частные случаи)...

Azadi, безумно интересно! Неужели получилось без доп. оберток?

Хм... RPG не увлекаюсь очень давно (со времен первой "дьяблы", которую я так и не прошел, маны не хватило, но подумал именно про нечистую силу — видимо, благодаря "Понедельнику" Стругацких... А веер, да, прочитал как "бип" . Эх, добрый советский BASIC без спрайтов, школьный комп. класс с железными клавиатурами и 32 кило оперативы, беззаботное деццтво... куда только делись ясность, надежды и романтика той поры?..

Ну, уникальный скрипт на уникальной разметке — все-таки вещь штучная, там ручная работа оправдана. Но почему-то мне кажется, что делать в одном проекте два форка одного уже отлаженного компонента с разной разметкой — не лучшая идея в принципе... Если разработчик нормальный, то по первому пункту div сразу исключаем. Если код взят из проекта с ненавязчивым JS, то ссылки в этом куске нет вообще Но вообще лично я никогда при отладке скриптов (и даже сложной верстки с их участием) в голый сурс не смотрю — сам знаю, что там может быть много чего не относящегося к действительности. Только дом-инспекторы/файрбаги/девелопер-тулзы из IE8/драгонфлаи и т.п. средства, показывающие актуальное состояние дел. И все обработчики (а заодно — многие косяки самой разметки) находятся куда быстрее, чем при ковырянии в непонятной мешанине языков. В этом случае как раз оправдано использование фреймворка (чужого или собственного), а нормальные фреймворки как раз поощряют "ненавязчивый" подход. Опять же, все равно никак не пойму, чем отладка 10—20 ненавязчивых скриптов, сгруппированных по функциям и подключаемых в одном месте, труднее отладки 10—20 фрагментированных скриптов, размазанных по всему коду проекта вперемешку с разметкой...Повторюсь, что веду речь о типовых задачах для сайтов "общего назначения" и типовых же админок. Для уникальных веб-интерфейсов к уникальным сложным вещам (уровня GMail'а, вероятно, оправданнее будет подход низкоуровневой ручной работы, с упором на максимальную эффективность. А благодаря чему? Значит, заметили. Видимо, в эту ошибку всё упиралось. Вероятность чего при ненавязчивом подходе гораздо ниже. 1. С какой версии? 2. Как она это делает (технически)? 3. Насколько "неплохо"?

Насколько я в курсе, паддинг вообще отрицательным быть не может.

s0rr0w, по многим пунктам все-таки можно поспорить И чем же удорожает, например, создание удобной галереи использование вариаций на тему LightBox-а (имхо, удачный пример "ненавязчивости")? По сравнению с нудным копипастом onclick-ов для каждой ссылки?К тому же можно отлаживать верстку и функционал по раздельности. И показывать заказчику работающую галерею с открывающимися в новом окне картинками и отдельно демку скрипта, а не набор скриншотов "будет вот так, а при нажатии - вот этак"... А "другими утилитами"? Это как? Весь контент по одному адресу? А как поставить закладку, послать ссылку другу, как быть с поисковиками, в конце концов? Есть мнение, что это какой-то неправильный вебдваноль Это если он ее заметит. Но в FF и Опере яваскриптовые ошибки пишутся только в консоль, никак не проявляя себя внешне. В IE по умолчанию тоже всего лишь рисуется желтый треугольник в статусе, куда юзеры не особо смотрят. И если вместо отвалившегося скрипта произойдет умолчательное действие, напр., переход по ссылке, 80% юзеров ничего не заподозрят и решат, что так и надо . А человека, который пользуется мобильным браузером? Например, Оперой Мини, составляющей (по некоторым оценкам) на сегодняшний день более 15% аудитории по Москве?

Для любого XHTML-доктайпа нужно, потому что это XML. Для любого HTML-доктайпа не нужно, потому что это не XML. А вообще на такие вопросы хорошо отвечает валидатор (ну и документация, само собой). P.S. Имхо, не зная тонкостей различия HTML и XHTML (там не только синтаксис), лучше ставить доктайп HTML 4.01 - меньше сюрпризов будет...

Если очень захотеть, то можно, как-то так: tr.abc td { width: "15%"; } tr.abc td+td { width: "75%"; } tr.abc td+td+td { width: "10%"; } Но IE6, насколько я помню, не понимает. Зато всегда можно назначить ячейкам классы...

Вместо обтекания воспользоваться display:inline-block. И погуглить, как имитировать его для FF2, если его поддержка актуальна...

Неправильно поняли Прекрасно срабатывают, если к моменту назначения искомые элементы существуют. Если скрипт, по правилам хорошего тона, пишется в <head>, это по понятным причинам не выполняется. Можно писать скрипт с назначением обработчиков в конце <body>, но лучше действительно вешать на событие загрузки. Зачем?window.onload = init; Во-первых, у ф-ции есть массив arguments, ее не обязательно вызывать с тем же кол-вом параметров, с каким она объявлена. Во-вторых, данные можно передавать не только аргументами, но и через свойства любых объектов, в т.ч. самой ф-ции. В-третьих, хороший обработчик и не должен зависеть от левой информации, которую нельзя получить из свойств самого события (event) и вызвавшего его объекта (event.target||event.srcElement)... хотя последнее - мое имхо Воспользуйтесь поиском по фразе "ненавязчивый (unobtrusive) Javascript".

Доктайп?

Вдогонку: во многих случаях полезно объединять обе картинки в одном файле и показывать нужный кусок, меняя background-position. Это экономит запросы к серверу и устраняет "моргание" картинок при первом наведении.

Действительно, проблема была в том, что глобальный window.event — чисто IEшная фича. Но передать событие аргументом можно и проще: <script language="JavaScript" type="text/javascript"> function onShowBubble(e,mytext) { document.getElementById('bubble').style.width = "150px"; if (mytext.length>100) document.getElementById('bubble').style.width = "300px"; document.getElementById('bubble').style.left = (e.clientX-10) + "px"; document.getElementById('bubble').style.top = (e.clientY-10) + "px"; document.getElementById('bubble').innerHTML = mytext; document.getElementById('bubble').style.display='block'; } </script> <input type="button" name="" value="Click me" onclick="onShowBubble(event,'Моя подсказка')"/> <div id="bubble" class="bubble" onmouseout="document.getElementById('bubble').style.display='none';"></div>Тогда IE передаст в ф-цию глобальный event, а FF и т.п. - стандартный, но внутри ф-ции это станет уже неважно. rus, работать-то этот пример работает... Но это — танк времен первой миро... то есть браузерной войны: проползет даже по грязи и болоту типа NS4, но медленный, неповоротливый и совершенно непригодный для современных дорог (пардон, браузеров). Так писали аккурат 10 лет назад, когда стандартов еще толком не было. Сегодня не осталось ни одного браузера, ради которого стоило бы городить этот огород с eval-ами. Не говоря о том, что это — решение вообще другой задачи, более простой, которая сегодня решается вообще одним CSSом

Браузеры пытаются помочь юзеру прочитать инфу, даже если она по какой-то причине (от криворукости автора до разрыва при передаче) пришла битой. Поэтому они пытаются исправлять ошибки. Каждый на свой лад. В разных режимах (зависит от доктайпа и типа контента) - в разной степени. Для первых двух есть стандартные средства (getElementsByTagName и getElementsByName соотв-но), которые возвращают коллекцию, поэтому проблем нет. Но getElementById рассчитывает на уникальный id, для неуникальных его поведение не определено. В FF (по крайней мере, раньше) он возвращал первый попавшийся элемент. В IE - возвращает коллекцию, что может быть сюрпризом для скрипта (а еще IE путает id и name). А document.all из вашего примера - вообще древняя нестандартная вещь, которая в строгих режимах (напр., в Safari для полноценных XHTML-страниц) имеет законное право вообще не работать, поэтому полагаться на него нельзя.А по поводу "можно, никто же не мешает"... Гулять по улицам с расстегнутой ширинкой тоже вроде как можно, прохожие, как правило, хорошо воспитаны и пальцем тыкать не будут. Но все равно, разве это приятно?

Значит, 100% дело в локали.

Сорри за оффтоп, но, если не ошибаюсь, канонический вариант сей просьбы звучал как "ОТВЕЧАЙТЕ НА МОЙ ПОСТАВЛЕННЫЙ ОТВЕТ"

Не можешь! И по стандарту, и по здравому смыслу ID обязан быть уникальным. partiz, бегом учить матчасть, чтоб впредь не позориться перед людьми как "бюро вредных советов" Gamer, меню или чекбокс, не принципиально -- функция вызывается по событию, которое может происходить на любом элементе. Вопрос лишь в том, как сгруппировать поля. Как вариант, можно различать нужные элементы по классу контейнера, типа такого: <script> function filter(type) { var items = document.getElementById('myform').getElementsByTagName('label'); for (var i=0; i<items.length; i++) { items[i].style.display = (items[i].className == type) ? '' : 'none'; } } </script> <select onchange="filter(this.value)"> <option value="red">Red only</option> <option value="green">Green only</option> <option value="blue">Blue only</option> </select> <form id="myform"> <label class="red">Красный инпут 1<input type="text"></label> <label class="blue">Синий инпут 1<input type="text"></label> <label class="red">Красный инпут 2<input type="text"></label> <label class="green">Зеленый инпут 1<input type="text"></label> <label class="blue">Синий инпут 2<input type="text"></label> <label class="green">Зеленый инпут 2<input type="text"></label> <label class="red">Красный инпут 3<input type="text"></label> </form>

Position:relative не работает с ячейками и строками таблиц (по спецификации).

Проблема в локали, практически точно. Нужно узнать у хостера, как называется правильная локаль для русского языка. В крайнем случае, попробовать перебрать другие вероятные названия локалей кроме "ru_RU" (например, "ru_RU.CP1251" и т.п.).