SelenIT

Еще пара мелочей в порядке имха: отключение стилей — текст должен остаться логичным и понятным. Отключение картинок — надписи должны остаться читаемыми. Масштабирование — блоки не должны съезжать, при масштабировании только текста (FF - "Zoom Text only") надписи не должны пропадать при масштабировании хотя бы на 2 шага в обе стороны (сейчас, возможно, не так актуально, но тоже показатель качества верстки, особенно для информационных сайтов). Формы — навигация tab-ом не должна приносить сюрпризов, кнопки, в идеале, должны получать фокус и нажиматься без мышки. Если используется HTML5, полезно проверить логическую структуру outliner-ом (напр., этим). Поскольку новые браузеры любую разметку воспринимают как HTML5, это в любом случае не завредит . Если речь про FF-овский HTML Validator, то у него просто три режима — Tidy (по умолчанию), SGML (оффлайновый аналог W3C-шного) и оба вместе (сперва второй, потом первый). Они неплохо дополняют друг друга (напр., tidy ловит нелепые ошибки типа <div/>, которые пропускает W3C-шный для XHTML, зато ругается на некрасивые, но формально допустимые пустые спаны). Только надо помнить, что tidy — не валидатор в строгом смысле, а скорее "советчик по улучшению стиля кода". Увы, название аддона лишь плодит путаницу...

Ч.т.д. — "не читатель, а писатель". Досадно, но факт. Например, такая мелочь, что он решал задачу ТС в отличие от варианта с двумя window.open и return false. Ну и мой пример был сразу помечен как "так делать не надо" Спорный вопрос. Утрированный пример: человек спрашивает, на какой рыболовной леске лучше повеситься, один отвечающий настаивает "выкинь этот бред из головы", а другой пишет "возьми две миллиметровки, как раз выдержат". Кто скорее заслуживает упрека в дефиците мозгов — тот, кто пытался отговорить от опасной глупости, или тот, кто помог ее осуществить?

Для умеющих читать проблема в таком стиле была решена еще 5 апреля . Мне не нравится, когда такие давно решенные темы с высокомерным видом "осеняют своим присутствием" самозванные просветители. И вдвойне обидно, когда люди, сетующие на нехватку мозгов у других, сами упорствуют в нежелании учиться. Особенно там, где вся нужная информация буквально в двух шагах... notTrue, да. Но мой вопрос с подковыркой предназначался darekd

notTrue, plz чуть внимательнее: там речь про ссылки с псевдопротоколом javascript (вещь вредная сама по себе, но эта конкретная строка там при деле — говорит браузеру, что по ссылке — результат выполнения javascript-кода). Но в примере у darekd эта строка сидит как раз не в ссылке, а в обработчике — в этом и пикантность ситуации... Ну логично: если убрать лишнее — ничего не изменится, но если добавить другое лишнее — всё может и поломаться... браво, Кэп! Именно то, что этот пример копируется вместе с этой ненужной строкой — верный признак бездумной копипасты (он мог бы выглядеть и как onclick="i_am_idiot:window.open..." — держу пари, что его копировали бы точно так же, с аналогичным объяснением). Что, увы, в сочетании с той репликой про мозги выглядит прямо трагикомично... Впрочем, для того, у кого нет проблем с мозгами и гуглом, вряд ли составит много труда назвать браузер и ситуацию (экзотичную, но всё же), когда от этой строчки есть реальный прок... в таком случае я готов не только извиниться за подколки, но даже компенсировать минусы.

Да я не спорю, что этот копипаст работает, я спрашиваю, нафига в нем конкретно это слово "javascript:", что оно дает именно здесь и что изменится, если его тупо убрать

Нашлось по ссылке с гугловских "расширенных фрагментов" — оно?

ну-ну... два попапа по одной локальной недоссылке, кто больше? нафейхоа? что здесь дают эти букаффки?

Кстати, да. Настоящий display:block для таблицы (вместо родного display:table) теоретически может стать источником проблем...

Еще вспомнил: по элементам ЖHTML статус поддержки браузерами помечается в самой спеке WHATWG (напр. для того же datalist нарисован значок Оперы с пометкой "Latest Opera beta or preview build: has nearly complete support for this feature, but does not yet pass all the relevant test cases").

Что именно понимается под "поддержкой браузерами элементов HTML"? На мой взгляд, наиболее близкая к делу информация по таким вещам — http://caniuse.com/

Юзают, но одно другому не мешает...

Разделение стилей по браузерам — это крайний отчаянный выход, вроде ампутации с установкой протеза. Не надо прибегать к нему там, где достаточно смазать йодом и заклеить пластырем . Ваша проблема — не от косячности Оперы (хотя косяки у нее и есть), а от излишней сложности стилей. Заставлять несчастную кнопку одновременно сползать на 36px вверх и на 10% вниз, да еще на 5px налезать на верхнего соседа, да еще убраться вправо за любые мыслимые границы — от такой кучи взаимоисключающих требований кому угодно башню снесет, не только "капризной северной красавице" . Попробуйте просто убирать лишние правила одно за другим, в какой-то момент браузеры наверняка придут к консенсусу. А лучше просто покажите, чего хотите добиться — наверняка вам подскажут простое надежное решение без таких подвыподвертов...

Эх, сложная судьба была у этого тега... Нет, это ошибка. В ЖHTML можно — для контактной инфо автора каждой <article> + для автора всего документа.

Семантика тут ни при чем — смена display через CSS на модель содержимого не влияет, логически li остается блочным даже при фактическом display:inline. Другое дело, что при отрисовке, когда браузер заставляют рисовать блочные боксы внутри строчных (опять же — независимо от участвующих в этом безобразии элементов), ему приходится выкручиваться через неуправляемые анонимные боксы-обертки, поэтому возможны сюрпризы. Общее правило "в строках — только инлайны, в блоках — либо инлайны, либо блоки" в идеале должно соблюдаться и в разметке, и в стилях, но причины чуть разные (в первом случае — семантика, во втором — логика отображения). А display:inline в сочетании с float — скорее всего, лекарство для IE6 (от его давнего бага — удвоения маргинов), больше оно ни на что не влияет.

Не ставить в фотошопе галочку "что-то там про цветовые профили"? В любом случае, в FF6 проблему не вижу (Win 7 x64). И вообще, зачем фоновая картинка аж под 20 кБ для того, что на экране выглядит однотонным прямоугольником?..

Можно, с помощью clip. Но неудобно, имхо...

По сравнению с комбо из rgba-заливки + градиентный фильтр с ARGB-цветом — минус IE6, плюс Опера 9. Что кроссбраузернее — еще бабуля надвое сказала . А еще лишний запрос на сервер...

А может, здесь наш фирменный способ с инлайн-блоками подойдет?

В двух словах сложновато, но вот есть статья с примерами приблизительно по теме

Если верить msdn — практически всё, что можно делать с текстом/шрифтами. Насчет :hover, правда, не уверен (вроде когда-то пробовал — не вышло, на досуге опять поэкспериментирую)... Кстати, интересно, что спека CSS разрешает для col задавать только фон, бордеры, ширину и видимость, но в спеке HTML4/XHTML1 для них вполне разрешен "гадкий презентационный" атрибут align — и он, что удивительно, даже не deprecated!

так и дефолтный серый бордер к li применяйте, делов-то...

Не должен сайт интересоваться размерами экрана, ему всегда должно хватать размеров окна. Допустим, я — 3D-моделлер, у меня на огроменном экране 2560?xxxx тихонько рендерится сцена, и я, продолжая приглядывать за процессом, открыл где-нибудь сбоку узенькое окошко браузера, чтоб, пока процесс идет, посерфить для релакса . Нафига мне куча горизонтального скролла только из-за того, что горе-вебмастер не справился с измерением размеров viewport-а? Тем более конкретно для Оперы (как и остальных норм. браузеров) и это не нужно — всё необходимое можно сделать через media queries, заодно автоматически решив проблему ресайза окна. Скриптовые костыли нужны лишь для IE8 и ниже. А для специфических мобильных нюансов, завязанных на конкретное физическое разрешение — единственная, имхо, ситуация, когда интересоваться им может быть осмысленно и оправдано — к счастью, есть специальные фичи у соотв. платформ, к которым привязываться в разы удобнее...

Почему бы border-top'ом и не сделать? По дефолту сереньким, по :hover — перекрашивать...

Боюсь, что с условием "чтоб работало в IE8" — разве что как-то так А с покраской каждого пикселя мозилловцы, конечно, прикольно придумали... Но, имхо, практическая применимость даже у варианта с тенями слегка повыше

Я именно про текст говорю. Ничего не могу с собой поделать — смотрю на надпись "10.10.2011 20:12" и упрямо вижу в ней этот чертов пробел, никак не выходит у меня прочитать ее как "10.10.201120:12" . И убивать этот пробел ради оформления я по-прежнему считаю неправильным. Можно же просто заменить один inline-block на float (а то и оба на table-cell, по ситуации) — и пробел оформлению мешать не будет, и текстовые парсеры будут довольны. В частном случае даты и времени соглашусь, если эти спаны — часть микроформата (подпадают под более "козырную" конвенцию). В общем случае, имхо, необязательно. Машина вполне может искать "знакомые" паттерны в нормализованном текстовом содержимом разметки...