swetlana

осторожность — это однозначно хорошо, но в разумных пределах. В отдельных случаях действительно имеет смысл писать на старом добром html4, но это именно отдельные случаи.

пока нет полной уверенности в своих действиях и чёткого понимания работы браузеров, лучше использовать только проценты и обходиться без рамок. А вообще можно комбинировать что угодно как угодно, ограничивая себя от нежелательных эффектов хотя бы даже тем же min-width.

Капитан Очевидность подсказывает, что тестировать нужно весь сайт во всех моментах

в долгу не остаются обычно здесь.

а при чём тут саппорт Хрома? Хром правильно отрабатывает. $j('.unit').addClass('showDiv'); $j('.showDiv').mouseover(function(){ $j(this).addClass('showme'); $j('.showme div.abs').addClass('absshow'); $j(this).mouseout(function(){ $j(this).removeClass('showme'); $j('.abs').removeClass('absshow'); }); }); Это ж чушь какая-то. Синтаксис метода hover позволяет передавать две функции: при наведении мыша и при уходе мыша с элемента. И вот этот мудрёж с определением mouseout внутри mouseover не нужен. Имеет смысл использовать более подходящий метод hover(). Это если признать, что тут в принципе нужен jquery. А на самом деле такое гораздо проще и надёжнее делается на чистом css.

ну вообще-то сама спецификация разрабатывается уже давнее. А мозильная команда позиционирует себя как прогрессивная. Очень спорно. Таким образом получается, что разработчик теряет контроль над результатом своей работы. Правильным был бы один из последовательных и непротиворечивых подходов: либо делаем всё по правилам, не допуская никаких ошибок (любое несоответствие спеке — синий экран смерти), либо же допускаем несоответствие, обрабатываем в меру своего понимания, но с максимальным соответствием задумке автора. А в данном случае ФФ действительно ведёт себя непоследовательно, нелогично — пытается сделать хорошую мину при плохой игре. Перекраивает DOM, якобы считая структуру ошибочной, при этом другие ошибки спокойно пропускает. По какой спецификации он вообще работает? По каким правилам? нет. Это означает, что опасно не тестировать.

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

хорошо, приведу пример. Из недавней работы. Есть элемент <figcaption>. Читаем спеку: http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figcaption-element внимательно читаем строку «Content model: Flow content.». Проходим по ссылке и читаем, что же такое Flow content: http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#flow-content Замечаем среди этого великолепия <article> и полный набор заголовков. То есть, по спецификации спокойно можно ставить <article> и <h3> внутрь <figcaption>. Если провести тест, всё и будет как задумано. Читаем спецификацию дальше. На этот раз про <a>: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-a-element Обращаем внимание: «Content model: Transparent, but there must be no interactive content descendant.» интерактивных элементов в тесте не присутствует, а про transparent тоже почитаем ещё внимательно: http://www.whatwg.org/specs/web-apps/current-work/multipage/content-models.html#transparent то есть, пофикк. Что допустимо в родителе, то и в <a>. Казалось бы, <a> можно ставить спокойно куда угодно. Например, внутри <figcaption> обернуть <article>. По спецификации так можно делать. И мне в одном из недавних проектов было удобно сделать так. И что же сделал ФФ? А сделал он чёрт знает что: Просто переколбасил DOM так, как ему захотелось. При этом все остальные браузеры (и даже IE странных версий) отобразили всё как надо. В ФФ4 при этом уже всё нормально. Вот я о такого рода случаях. Это частный пример, но уже доводилось сталкиваться с аналогичными не раз.

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

Про контактную информацию объяснение куда проще. Об удобстве пользования сайтом задумываются дизайнеры уровня самизнаетекого. А дизайнеры эконом-класса делают не сайты, а статичные макеты, и сдают не сайты, а картинку. При этом важным считают картинки, цвета, но никак не то, что будет интересно клиенту заказчика. Да и цвета-то интересуют лишь в том статичном виде, в каком они сдают макет. Достаточно редко бывает указан цвет ссылки при наведении, цвет активного пункта меню и всего такого.

Основное уже написали выше. Ещё одна важная особенность: ФФ версии до 4 имеет особенность считать себя умнее всех, и время от времени перекраивает DOM в соответствии со своими взглядами. Решается эмпирически. Надо в каждом проекте просто внимательно смотреть на поведение этого чудо-браузера, да при необходимости корректировать.

и я

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

как обычно, как и сейчас: двумя пальцами по тачпаду.

а разница-то только в коде. Где вы кроме кода разницу нашли? понятия не имею.

тем мне и нравится новая спецификация. Она описывает, как есть на самом деле, а не пытается фантазировать нечто абстрактно-отвлечённое.

привычка. <body>, кстати, есть. Без него будут проблемы в IE. вообще говоря, если я правильно понимаю новые парсеры, им радикально пофикк, html или xhtml синтаксис. Единственное, что есть в xhtml-синтаксисе, что не вписывалось в рамки старых версий html — слэш в одиночных тэгах. а теперь его разрешили.

боюсь, что тут вообще никаких не хватает У вас на странице только одна картинка. да, собственно, это и есть картинка, а не html-документ А картинка, извините, не интерактивна.

пока что следует поддерживать IE6. Но лишь в той мере, чтобы в нём информация оставалась читаема, чтобы не разваливалось всё до непотребного состояния. Идеальное соответствие не нужно, если оно не оговорено с заказчиком специально. Да и чтобы оговаривать такое, нужны увесистые причины. Пользователей ИЕ6 остаётся около 3%, а времени и сил на него потребуется много. Стоимость разработки может увеличиваться раза в два. Если окупает себя — можно пойти на такое.

Чаво, пардон? К нужному элементу добавляешь id, а в адресе этот id через решётку. То есть, где-то в середине кода, куда нужно прокрутить, есть примерно такое: <div id="place"> и адрес указывается не просто http://site.foo/page.html, а http://site.foo/page.html#place

сейчас, пожалуй, не воспроизведу. Но если встречу ещё такие косяки, поделюсь с общественностью.

Serlutin, это всё в теории. На практике самый распространённый браузер очень болезненно относится именно к <article>. У него какие-то свои оригинальные взгляды на то, что может в нём находиться, а что — нет. Если он считает, что что-то недостойно находиться внутри <article> (а его мнение может меняться в зависимости от обстоятельств), то он просто тупо выкидывает этот элемент в DOM куда-нибудь за пределы. И у 40% посетителей сайта будет перед глазами каша. Оно надо?

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

и тут глюк. Узнать, чей профиль, можно лишь по косвенным признакам. Большими буквами ник нигде не написан

столь же малообоснованное подозрение и у меня есть. Но тут вот в чём дело: Пишу шаблон для cms. На месте "<section class="content">" шаблон прерывается, и далее идёт контент, подвластный лишь исключительно контент-менеджеру сайта. Когда этот контент заканчивается, пишем "</section>" — и далее продолжается код шаблона. Что внутри — можем только догадываться. Насколько это допустимо внутри <article> — тоже. А кроме семантики есть ещё и браузеры, полагающие своё мнение более значительным, чем мнение автора сайта. Например, ФФ. Неужели никто не видел, как он перекраивает DOM на свой лад, если ему вдруг покажется, что один элемент не может быть внутри другого?