SelenIT

<a href="tel:...">?

Ну и совсем по мелочи, 93 запроса — это порядка 20 кБ трафика при каждой загрузке на одни заголовки. Причем вне зависимости от того, есть ли контент в кеше.

в регистре?

Стоя аплодирую стилю и слогу. А удаленка поддерживается?

Еще сталкивался с такой подлянкой DW, как самовольная подмена символов (в частности, неразрывных пробелов на обычные) при пересохранении файла. До сих пор не могу ему этого простить!

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

Это да, табличка на двери — явно меньшее зло для честного человека, чем грабли за ней

То, что JS можно отключить. Или вывести исходный код странички и скопировать его. А от скриптов-грабберов, которые, как правило, контент-то и воруют, эта "защита" и вовсе бесполезна — у них и браузера-то нет, яваскрипт ваш им и выполнить нечем. Они работают напрямую с кодом странички — в точности как и поисковики. Какой вопрос, такой и ответ Мусор на входе — мусор на выходе. От копирования — нет. От воровства контента — есть. Авторское право называется.

Так называемый "метод" — обычный JS. Со всеми вытекающими. Эффективность защиты примерно такая же, как от таблички "Do not enter!" на открытой двери. Смысла еще меньше. Весь приведенный код устарел на 15 лет по форме и на 100500 — по сути.

Как решение головоломки, можно сделать как-то так: li.active, .active ~ li { position: relative; } li.active { z-index: 12; } li.active + li { z-index: 11; } li.active + li + li { z-index: 10; } ... /* и т.д. до максимально возможного числа вкладок после активной */ Вот еще вариант на чистом CSS (можно покликать по вкладкам). А ответ на сам вопрос — здесь.

Можно, но не требуется. В HTML5 все заголовки h1-h6 сами по себе равноправны, а их "вес" определяется уровнем вложенности секций. Но поисковики еще могут считать по-старому — единственный h1 главным и т.п. Поскольку для новых парсеров разницы нет, а для старых (у поисковиков) — может быть, вариант с кучей h2 считается надежнее. Однозачно не ради оформления . Ну вот так получилось в этом примере — один блок касательно относящейся к статье информации, состоящий из двух навигационных блоков. Что эта "побочная" секция оказалась без заголовка (outliner подпишет ее как "untitled section" или что-то вроде) — видимо, пример призван показать, что иногда такое может быть оправдано (хотя в целом спека советует такого избегать, но этот совет — не догма, всегда надо отталкиваться от здравого смысла). Ситуацию, когда нужно обернуть каждый <nav> в свой <aside> (оба блока — основная навигация, но при этом они несущественны для понимания основного контента?) представить себе можно, но сложно. А вообще есть мнение (причем не абы кого, а одного из авторов HTML5 Boilerplate и html5please.com!), что важность этих семантических нюансов и тонкостей как минимум несколько преувеличена. Правильно, чтобы внутри <nav> были ссылки . Что эти ссылки окружает — вопрос третий, не связанный с семантикой <nav>, но, возможно, важный для чего-то совсем другого. Минимально достаточный код — правильное решение, но не единственное. Если в этом или похожем проекте уже есть отлаженная пуленепробиваемая менюшка на базе списка, или если один и тот же навигационный блок на одной странице является основной навигацией (<nav>), а на другой нет — не вижу существенных причин переделывать его в минималистский вариант в угоду "семантической чистоте".

Старый добрый див прочнее Не заменяет, у них разные назначения. Можно, конечно, навесить на <aside> еще и оформление, но вдруг в эту же правую колонку придется добавлять, например, еще один <nav> или какой-нибудь <figure>? Мне казалось, milkeyway спрашивал про их список).

Есть 4% смысла — старые IE Неверно с точки зрения структуры документа (document outline) в HTML5. <aside> — это полноценная секция с заголовком, <div> — тупо оформительская обертка. Можно и таким, но я исходил из того, что каждый товар в магазине — самостоятельная единица, достойная отдельной позиции в RSS новых поступлений и т.п. Т.е. отдельный <article>.

milkeyway, с этими элементами все поначалу путаются . Есть хорошая схема по их выбору. Я бы сказал, что каждый блок правой колонки — вполне себе aside, а каждый товар вполне достоин своей персональной article. А div в nav сам по себе не нужен, но может очень выручить на переходный период, если нужна поддержка ископаемых IE (можно всё оформление по старинке навесить на него, не беспокоясь о всяких html5shiv-ах и т.п., а сам nav оставить исключительно для будущих семантических анализаторов).

Что это должно было, по замыслу, обозначать?

Меня главная страница ея смущает. Время последнего обновления форума без малейшего упоминания темы, в которой это обновление произошло... Но оттуда но искомой инфы всего один клик, и впрямь не страшно

По большому счету, свойства с браузерными префиксами — еще никакой не CSS3, а только браузерная экспериментальщина на тему CSS3, сроду не предназначавшаяся для использования на "боевых" сайтах. У этой экспериментальщины даже синтаксис не раз менялся, в т.ч. для одного и того же семейства браузеров. Так что задача "выдавать каждому юзерагенту только его личную экспериментальщину" выглядит не очень логичной: зачем сначала создавать себе проблемы в лице экспериментальщины, а потом "героически" преодолевать их на серверной стороне? К счастью, нормальные CSS3-свойства (типа border-radius и box-shadow) в приличных браузерах давно префиксов не требуют. Возможно, такой подход может быть оправдан для айфонов с айпадами (напр., для тех же нестандартных -webkit-text-size-adjust и -webkit-pixel-ratio). Но вообще выдача разного контента разным юзерагентам — очень скользкий и рискованный путь (объясняйся потом с поисковиками, что это было не для клоакинга... ).

Не вообще для IE, а для IE6 и ниже. В Quirks mode (без доктайпа, с доктайпом HTML 4.01 Transitional без DTD и т.п.) любой IE фактически превращается в IE5.5 и хак работает. В родном режиме IE8+ (с любым стандартным или "полустандартным" доктайпом) такие хаки не работают, но, как правило, и не нужны. Независимо от доктайпа, id-ы на страничке дублироваться не должны, это ошибка, поведение браузеров при дублирующихся id-ах не определено. Юзайте классы, что ли...

В данном случае я бы даже сказал, что это равносильно if($group != 1) $group = 2;т.к. не вижу большого смысла в присвании единицы единице...

В данном случае — это запись числа. Которое нужно перевести в более привычную форму. Автор недостаточно внимательно скопипастил условие

Доктайп — еще не показатель. Хабрахабр отдается как text/html, а значит, технически написан на HTML. Из мало-мальски значимых (когда-либо) сайтов, реально работающих на XHTML (отдаваемых как application/xhtml+xml) сходу могу назвать лишь xpoint.ru. Теоретически у XML-подобного синтаксиса есть преимущество простоты обработки страниц в своем собственном движке (напр., превратить обычную страницу в печатную версию или фид одним наложением XSLT-шки). Но такая задача возникает очень нечасто. К тому же, чтобы XML-подобный синтаксис работал в HTML-браузерах, нужно соблюдать все правила совместимости (валидатор тут помочь бессилен).

Я сам недавно узнал, что фокус начинает ловить любой элемент, которому задан tabindex . Наскоро проверил — вроде какой-то отклик и в IE8 наблюдается...

В актуальной спеке (утвержденной в прошлом году как рекомендация) оставили только первую фразу — про возможность активации с клавиатуры (убрав ссылку на тихо почивший css3-userint, от которой была одна непонятность). Но и в новой спеке, и в том древнем черновике чуть ниже красуется пример с a:focus) Именно так, та многострадальная рамка — и есть индикатор фокуса по умолчанию. Поэтому и нельзя убирать ее совсем, не оставив ничего взамен (для клавиатурщиков).

А что, где-то у ссылки фокуса нет?

Придумали! "Если несколькими частностями пренебречь..."