SelenIT

Валидатор же уже 2 подсказки дал, одну — прозрачнее некуда:

rash, я не в курсе истории про clip. Это насчет приписки "только для абс. позиционированных эл-тов" или что-то другое? Он пользовался положением монополиста, внедряя то, что себе удобнее. Кое-что из этого оказалось удобным и вообще (тот же XHR, overflow-x/y и т.п.), многое из этого спустя годы признал-таки и Консорциум (в CSS3, HTML5 и т.п.).Сейчас, как мне кажется, чем-то подобным слегка злоупотребляет Apple, "ненавязчиво" пропихивая в стандарты проприетарные наработки из вебкита (причем, по иронии судьбы, нередко делающие то же, что MSовские "расширения CSS" десятилетней давности — тенюшки, свечения, трансформации/искажения и т.п.. А вот такая нужная вещь, специализированные средства для раскладок — до сих пор непроглядный черновик, и реализовывать их почему-то никто не хочет...

Последняя ревизия этого кандидата в рекомендации. Еще энное кол-во ошибок исправили и т.п. Есть версия, что где-то в 99-01 они всерьез испугались новых возможностей веба (в т.ч. тех, что сами придумали, типа AJAX и WYSIWYG-редактирования) — что такими темпами веб-приложения вскоре оставят без работы их десктопные наработки (тот же Офис). Потому и перестали развивать эту сферу. Но объективно W3C, стремившийся стандартизировать что угодно, лишь бы было "не как в IE" (начиная с пресловутой боксовой модели в CSS, которую на тот момент ни поддерживал никто из браузерщиков) по сути невольно сыграл MSу на руку

эх... возьмите меня в такие неудачники, а? Мой первый позорный опыт (по всему, но особенно по содержанию — такая желтизна, фу!) еще жив каким-то чудом на chat.ru. Как говорилось в те времена, best viewed with IE4+/NS4.x/Opera 5-6 . Как давно это было, с тех времен даже кол-во планет поменялось...

Может. Именно что в новых FF (про Сафари не знаю, но не исключаю).

Вот нафига, пардон, ставить доктайп XHTML, чтобы писать под ним <DIV> и <br> (вдобавок размечая ими явный список)? Будьте честны хотя бы перед самими собой и валидатором! И еще желательно в конец onclick-ов дописать return false (или, для краткости, return !1), чтобы длинные страницы не прыгали к началу при скрытии/показе разделов внизу.

FF поддерживает каждую версию по полгода (и правильно делает, имхо), латая лишь критические уязвимости. Включенный Windows Update, кстати, делает почти то же самое, и тоже практически незаметно (ну да, один раз юзеру приходится нажать "ОК"), даже новую версию самого IE ставит... проблема именно в тех, у кого оно выключено. SP2 вот позволил убрать подгрузку фоновых картинок каждый раз заново по :hover (с помощью новой опции для execCommand) — и на том спасибо. Но менять отображение для одного и того же по сути браузера — увольте. Были уже те же Оперы 7.0x/7.1x/7.2x (что ни номер, то свои приколы), была куча сайтов, заточенных под фирменные глюки IE6 (height вместо min-height и т.п.), развалившихся с приходом IE7 — в первом случае спасала относительная малочисленность каждого варианта, во втором — условные комменты. И так возиться с "ослиным" зоопарком при тестировании — целая морока (виртуалки, эмуляторы...) — зачем же еще умножать этот зоопарк, ведь главную проблему (большой процент юзеров, принципиально не желающих обновляться) это бы всё равно не решило! IE6 сам тихо сдохнет вместе с уже почти неподерживаемой XP, массовые продажи Win7 доконают его еще быстрее. И вдобавок уже есть куда более радикальный "патч" для всех IE — Chrome Frame Ну так они и появились намного позже . И во многом равнялись друг на друга в конкурентном развитии. Хотя своих приколов и разночтений (типа неподдержки inline-block в FF по 2-й включительно или дробных процентов в Опере до сих пор) тоже хватало. Не имея официально признанного эталона, рассудить подобные случаи бывает не запросто...

Выпустили они патч, давно уже... IE8 называется . И многие его поставили? То-то и оно. С патчами было бы то же самое. Только если сейчас у нас есть универсальные (более-менее) хаки для всей версии, то в случае с патчем пришлось бы еще колупаться с разными хаками для патченного и непатченного "подвидов"... Тесты — это не просто хорошо, это необходимо. Т.к. стандарт... сорри, спека сама по себе написана не особо понятно, содержит неоднозначности, и формально не противоречащие спеке реализации могут совершенно по-разному выглядеть на практике. Наличие тестов и эталонного результата такие ситуации сводит к минимуму. Именно поэтому для статуса рекомендации и ставят условие 100%-ного покрытия спеки тестами . Но создание тестов — процесс долгий и муторный, в самих тестах то и дело находят ошибки... вот и выходят такие сроки разработки, как 7 (или 11, если от версии 2.0 считать) лет для CSS2.1 (и это только середина пути!) или пугающие многих заявленные 18-20 лет для HTML5... А с другой стороны... вот есть стандарт ISO HTML (основанный на HTML 4.01 Strict и ссылающийся на него). Многие ли браузеры соблюдают его полностью (начиная с честного SGML-парсинга)?

Это нормально, т.к. span изначально строчный (текстовый) элемент, с соответствующей моделью визуализации. Но ему можно задать другое отображение, напр. блочное, а то и абсолютное позиционирование. И повесить на него, например, фон с какой-нибудь иконкой...

Вообще-то два года назад. Вот как раз по части CSS2.1 на M$ушку гнать не надо, минимум две трети официального набора тестов для ее спеки — именно его заслуга (и IE8 вроде как все эти тесты проходит). Если б не стремление M$ в короткие сроки сделать неплохой новый браузер и пропиарить его как полностью совместимый со стандартами, W3Cшники могли бы еще лет 10 "чесаться", а нормальных тестов бы так и не появилось. Я считаю, что одним этим M$ искупил свою вину перед веб-разработчиками за затянувшийся век IE6. И то сам M$ изо всех сил старается избавить веб от собственного старья, нормальные пользователи легальной винды давно получили IE8 как высокоприоритетное обновление, только паранояльные юзеры "пираток" и упрямые админы корпоративного сектора "ломают ништяк"... Нет никакого "CSS3" . Есть модульный CSS, некоторые модули которого "прокачаны" до 3-го уровня. Могут. Если эта высота явно задана.Но вообще, конечно, нынешний рабочий процесс консорциума, CSS WG особенно — это массаракш какой-то. Особенно чехарда с повторными откатами кандидатов в рекомендации обратно в черновики (как было с модулем селекторов и не только). Удивляюсь, как разработчики браузеров в таких условиях вообще умудряются внедрять что-либо (впрочем, по-моему, на черновики 2002-2005 годов все давно забили и внедряют почти исключительно свои проприетарные "игрушки", особенно Эпл). Ну и сам подход "мы рекомендуем только то, что давно реализовано и вовсю используется годами" (условие для перехода спеки в статус только предлагаемой рекомендации — наличие двух независимых и на 100% совместимых между собой промышленных реализаций) — на мой взгляд это просто смешно. Не понимаю, чем был плох подход 90-х, когда принятая рекомендация оставалась незыблемой навеки, а если в ней обнаруживались серьезно мешающие жить ошибки, ее организованно заменяли новой минорной версией (как HTML4.0) или второй редакцией (как XHTML1.0). И модульность спеки, на мой взгляд, себя не оправдывает — печальная судьба XHTML2 тому пример. Любому разработчику реализации или набора тестов ведь намного проще иметь весь материал под руками, а не собирать по кускам что-то растекающееся...

Насколько я понял, главного ограничения не нарушили оба, и вообще в этой ситуации многое оставлено на откуп разработчикам браузера... Но интуитивно Опера более права, горизонтальные маргины-то схлопываться не должны. И IE8, хвастающийся полным прохождением OVER 7000 официальных тестов по спеке, ведет себя так же. P.S. А Хром(ой) ведет себя забавнее их всех

Имхо, про http-equiv — бред какой-то. Где такое пишут, если не секрет?

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

Разве нельзя вложить отдельные таблицы для каждой строки (из первого варианта) в LI-шки от OL? Ну и поиграться с бордерами (плюс, наверное, list-style-position: inside). Например, вертикальные бордеры задать ячейкам, а горизонтальные LI-шкам — вот и будет видимость "автонумеруемой" таблицы . Хотя предложение s0rr0w, конечно, правильнее. Только для IE7- понадобятся "костыли" через экспрешны...

AFAIK, самое надежное лекарство от этой неприятности (хуже всего, что при некоторых настройках кеша картинки-таки действительно каждый раз грузятся заново, воруя трафик!) предложено здесь: document.execCommand("BackgroundImageCache", false, true) Правда, работает только начиная с IE6 SP2, но других, имхо, уже и не осталось. Не совсем. Скорее это некий особый режим отображения блоков, при котором, по необъяснимым историческим причинам, багов проявляется меньше (но есть свои специфические, напр. сбивается нумерация у списков, иногда артачатся отступы справа и т.п.).

Чаще всего zoom:1 используется лишь как более-менее безопасный способ включить в IE6/7 hasLayout (это такое труднообъяснимое логически "лекарство" от множества багов типа пропадающих фонов и прочего, но с побочными эффектами типа сбивающейся нумерации у списков). Еще комбинация этого hasLayout c display:inline дает в старых IE поведение display:inline-block для изначально блочных элементов (для которых там настоящий display:inline-block не работает), это модно и удобно в "резиновых" галереях и т.п. На данный момент мне известны буквально пара примеров использования этого свойства по прямому назначению: коррекция дизайна при нестандартном размере шрифта и обход 100-пиксельного ограничения на высоту элемента hr... ну еще могу нескромно попиарить финт, позволяющий использовать в IE6 шрифты в px (для всего, кроме body) и масштабировать их .

Шило на мыло? Рендерятся-то они одинаково (и стилизуются, соотв-но)... Имхо, простейший вариант - <button type="reset"> с картинкой внутри.

Для изначально блочных элементов в старых IE есть хак: display:inline + что-либо, включающее hasLayout (по моему опыту, самое надежное — zoom: 1). Эта странноватая комбинация как раз дает поведение, ожидаемое от display: inline-block. Больше проблем с FF2, не знающим inline-block ни в каком виде (приходится юзать проприетарщину типа -moz-inline-stack, а внутрь вставлять блочную обертку, иначе содержимое блока "слипнется"). Но FF2 уже можно считать вымершим, имхо. Не совсем. DTD и основанные на нем валидаторы разметки умеют худо-бедно различать типы контента (сплошной текст, структурированный текст, вставка внешнего ресурса), но не имеют никакого представления о том, как этот контент должен взаимодействовать со всем прочим. Понятие "интерактивный контент", насколько мне известно, появилось лишь в HTML5, валидаторы прежних версий не догадывались, что к каким-то элементам у браузера особое отношение/дефолтная реакция, оно описывалось в других стандартах. Поэтому кнопка в ссылке приемлема для валидатора (строка в строке), но вызывает когнитивный диссонанс у браузера. Если, напр., ссылка ведет на Яндекс, а кнопка шлет форму на Гугл, то куда бедному браузеру деваться, когда юзер по ней кликнет — разорваться, что ли, как той мартышке из анекдота? Поэтому валидатор валидатором, а здравый смысл выключать нельзя. А стандарты действительно меняются (напр., валидация по DTD отмирает — именно из-за неумения ловить такие грубые логические ляпы), новые стандарты (тот же HTML5) пытаются учесть больше таких вот факторов реальности...

mishka2, актуальный (4-й) Сафари прекрасно зумит всю страницу, как и актуальный 2-й... упс, уже 3-й Хром. А древние Сафари составляют исчезающие доли процента по любой известной мне статистике. Justnewone, а что в данном контексте есть "лучше"? Имхо, при нестандартном размере всегда приходится выбирать из двух зол: горизонтальный скроллинг vs. искажение пропорций макета, то же искажение пропорций vs. потеря четкости и аккуратности картинок, та же четкость для маленьких рисованных надписей vs. читаемость их без очков и т.п. И каждый выбирает по себе и по задаче...

Это смотря в каком CSS;). Причем чем дальше, тем интереснее!

FF2 было без разницы, что масштабировать — em-ы, пиксели или что-то еще (кроме графики, ес-но). В FF3 можно переключать режим масштабирования — "лупа" для всей страницы или только текст, как в FF2 (я чаще пользуюсь вторым). Итого, получается, единственным браузером, ради которого еще есть смысл заморачиваться с em-ами, остается IE6. И то его можно перехитрить, например, скриптом в одну строчку. На практике, имхо, фаворитом все больше становятся пиксели (с точки зрения пропорционального масштабирования рисованных надписей и т.п.) — что логично, все-таки относительная единица (в отличие от пунктов и сантиметров). Хотя, с внедрением CSS3 (масштабирование фонов) и массовым ростом разрешения экранов до печатного качества (сотни пикселей на дюйм), вполне возможно, абсолютные единицы-таки возьмут верх...

if(!+"\v1") // true only in IE

Еще не забывайте указывать единицы измерения при ненулевых величинах (напр., не left: 500;, а left: 500px;)

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

Object является (в HTML4.01/XHTML1.x). Embed-а там просто нет. А в HTML5 (где есть оба) можно свободно вкладывать в <a> блоки. Скорее всего загвоздка где-то в стилях — возможно, тот самый случай блочного контента в строчном предке