SelenIT

Вот не могу я согласиться, что аватарка, адрес почты и какое-то описание равны друг другу. Нельзя же обратиться к человеку по аватарке, например. Если в примере из спеки части определения отвечают за разные аспекты, но всё же имеют смысл каждое само по себе (напр. для кого-то в словаре важно только произношение), то аватарка, адрес и описание — всё же явно части одного составного определения (карточки контакта), что ли. По-моему, для таких вещей идеальны schema.org, на крайняк микроформаты. Но грань тонкая, да, как всегда в спорах про семантику Лично для меня необходимость такой обертки — еще один аргумент, что это не dl, а что-то другое (напр. ul-список сущностей с заголовками). Полноправный dl, как правило, в такой обертке не нуждается (по крайней мере, в моей практике). Имхо, в общем случае не очень, я бы всё-таки рассматривал логотип как часть информации о партнере (карточки партнера) и использовал ту самую общую обертку. Но вполне могу представить ситуацию, когда уместно рассматривать логотипы как «ключи» (напр, если они используются в текстах вида «на прошлой неделе мы совместно с провели презентацию нового мобильного приложения»)

Там обычная страница, некоторым элементам которой задано position: fixed; overflow: auto. При переходе по ссылке она перегружается целиком.

Это не проблема. Пример из статьи обходится статичными html-файлами (плюс один файл js, тоже статичный), а сам jquery, если что, можно подключать с внешнего CDN. Никакого серверного программирования не понадобится.

rem не удовлетворяет требованию, чтобы размер подстраивался Так-то с кучей media queries для разных значений ширины с шагом, скажем, 50px, можно и в пикселях размеры задавать. И будет работать в тех же IE9+. Но писать (особенно если без препроцессоров) придется мнооогоо...

Забудьте про фреймы и ископаемые доктайпы (чай, не в эпоху нетскейпа 3 живем). Подгружайте контент на обычную страницу аяксом, с jquery это проще простого: $("#id_блока").load("адрес_html_файла.html"); Можно сделать, чтобы jquery автоматически подхватывал клики по ссылкам в меню и подгружал их аяксом вместо обычного перехода, как в примере из этой статьи.

Оно-то так, но всё равно, имхо, емейл, аватарка и что там еще — части одного составного значения для одного «ключа» (имени). А у множественных dd для одного dt скорее семантика разных альтернативных значений (напр. несколько значений слова в словаре, несколько людей на одной роли в проекте либо несколько ролей у одного человека в команде, и т.п.). С постом, имхо, еще проще, в 99% случаев пост — единая самодостаточная сущность, т.е. article с заголовком. Если важен порядок постов (по дате публикации, числу просмотров и т.п.), может быть смысл обернуть их в ol/li. Если нет, то нет). А еще, имхо, dl из одного ключа/значения — почти всегда неправильный dl. Как-то я поднимал такой вопрос в твиттере (как пример — легенда/расшифровка условных обозначений географической карты). Пришли к выводу, что это вполне легитимный пример dl (только для картинок в dt обязательно должен быть указан осмысленный alt-текст).

Строки таблицы по умолчанию не должны никуда переноситься. Можно увидеть проблему на примере?

Пик Балмера?

20000em под водой впечатляют, но дело явно не в них, с менее аццкой фиксированной шириной ситуация не исправляется. А вот скрипт по-хорошему надо отлаживать, да.

Раньше в Фоксах (да и в Хроме) бывало подобное при анимации какого-либо свойства, переключавшего рендеринг на GPU (напр. opacity), лечилось хаками типа *-backface-visibility: hidden. Сейчас потестировал - из всего того арсенала вроде бы успокаивает дрожание transform:translateZ(1px). Но по-хорошему надо разбираться, что конкретно происходит при анимации. Возможно, делу поможет смена анимации свойства left на анимацию transform:translateX (а тж. замена jQuery-анимации на CSS-анимацию по возможности).

Если я правильно понял, что речь про эти завитушки наверху, то множественные фоны.

С рамкой выпадушки (которая не работает:) не всё ОК. На закруглениях углов ее толщина пляшет, а на стрелочке она вообще потерялась(

В этом-в этом. Перевернулся весь див, занимающий по умолчанию всю доступную ширину контейнера. Попробуйте задать этот же стиль для #org:hover img.

А в каком браузере не выравнивается?

Потому что в HTML4 по пьяному делу смешали в одной классификации логическую роль элемента (контейнер для текста, контейнер для абзацев, выделение внутри текста, придание фрагменту текста интерактивности ссылки и т.п.) и визуальное представление по умолчанию (с новой строки или нет). Забыв, правда, объяснить, почему и в «блочные» элементы другие «блочные» можно вкладывать далеко не во все и не всегда (напр. P, DT, H1-H6, ADDRESS — «блочные», но могут содержать только текст). Поэтому не дурите головы себе и другим «блочностью и строчностью», а просто соблюдайте 2 правила: В HTML: строго соблюдайте Content model, указанную в спецификации для каждого элемента. Если для элемента указано, что его Content model — «phrasing content», значит, внутри может быть только текст и его фрагменты в пределах абзаца, и неважно, к какому типу контента относится сам этот элемент (тому же Phrasing, как span, Flow, как p, или Interactive, как button). Чтобы не запоминать Content model для каждого элемента, почаще сверяйтесь со спецификацией и/или валидатором. В CSS: по возможности старайтесь, чтобы у каждого элемента с display:block/table/flex («блочного снаружи») был явный контейнер с фактическим display:block/inline-block/table-cell («блочный внутри»). Тоже абсолютно вне зависимости от того, что это за элементы.Если соблюдать оба этих правила, то и логическая, и визуальная структуры страницы будут логичными и устойчивыми, и вопросов не будет возникать ни у парсеров при разборе страницы (в т.ч. у поисковиков), ни у браузеров при ее отрисовке. Первое правило строго обязательно, второе — опционально, но крайне желательно

Все браузеры очень по-разному реализуют размытие теней (у кого-то насыщенность тени убывает почти линейно, у кого-то — почти по экспоненте), поэтому варианты, когда из-под элемента выглядывает лишь кусочек тени, всегда будут давать разбежку. Вместо 35px 0px 10px -38px лучше задавать что-нибудь вроде 35px 0px 7px -35px (чтобы видимая часть тени начиналась сразу от кромки элемента), но ставить начальную прозрачность поменьше — так результаты разных браузеров будут больше похожи между собой.

Как вариант — использовать CSS-колонки. Либо просто сделать отдельные контейнеры для левой и правой половинки меню.

Анимация скроллинга вызывает срабатывание $(window).scroll(). А поскольку первое срабатывание происходит при $(window).scrollTop() <=450, происходит сброс стилей всех ссылок меню, отменяя результат обработчика клика. А смещение, насколько я понимаю, происходит от того, что при первом клике у sticky header'а нет класса "to-top", и координаты целевого блока определяются без его учета. Варианты решения — либо, как советуют на SO, в $(window).scroll() проверять флаг, вызван ли скроллинг скриптом или действием юзера, либо вызывать $('#header-sticky').addClass("to-top) по клику по ссылке, а addClass("active") для ссылки вызывать по завершению анимации (через 4-й параметр для animate). Первое, наверное, проще

Функционально идентично (если абстрагироваться от странностей ископаемых IE, которые легко обходятся явным заданием того же type="submit" для button и правильной проверкой запроса на сервере). Но возможности для стилизации у button несколько шире (ей можно задавать псевдоэлементы и т.п.). А в чем принципиальная разница? В обоих случаях лучше задействовать родной механизм HTML, а не опираться исключительно на скриптовый костыль. Или вам нужна возможность послать ссылку "логин" другу/недругу/поисковику, чтобы любой из них мог зайти под вашим аккаунтом?

Во многих частных случаях можно совместить «фирменные» хаки для старых IE с флексбоксами для новых браузеров, напр. наподобие такого.

Это и есть практическое определение отдельного блочного контекста Во всём новом (IE10+) есть флексбоксы. Ну и display: table/table-cell рановато совсем списывать в утиль (напр. в качестве фолбэка для тех же флексбоксов в IE8-9).

Не совсем «так же», но это выделяет содержимое блока в отдельный блочный контекст форматирования (наряду с display:inline-block, display:table(-cell) и overflow:hidden/auto/scroll). Соответственно, необходимость в clearfix-е отпадает.Наглядно разницу между работой clearfix-а и отдельного блочного контекста можно увидеть в примере из этой статьи. К сожалению, ни один вариант нельзя назвать идеальным, у каждого свои ограничения. Всё-таки флоаты для раскладки — действительно хак…

Флексбоксы всё-таки лишь один из механизмов. Более мощный и универсальный, чем флоаты, но всё-таки не революция. По местам (причем буквально) всё будет расставлять Grid Template layout, и, возможно, CSS Regions. Но когда еще это будет...

Грань между чистой и нечистой довольно размыта . Например, простейший список флоатов/инлайн-блоков в резиновом контейнере автоматом подстраивается к ширине, меняя количество столбцов: это еще "чистая резина" или уже зачатки "отзывчивости"? А по классическому определению "отзывчивый макет = резина + media queries" выходит, что одно простенькое медиавыражение, убирающее float у сайдбара при некой граничной ширине, уже превращает немодную резину в модную, и не думаю, что это настолько сложно Опять же, есть точка зрения, что HTML отзывчив по умолчанию

Резина всегда актуальна, в т.ч. как часть респонсива.