Для каждого оператора есть облегченная версия с более коротким названием (без приставки all). Разница в том, что allinurl отыщет ссылки со всеми словами, а inurl - только с первым из них. Второе и последующие слова из запроса могут встречаться на веб-страницах где угодно. Оператор inurl тоже имеет отличия от другого схожего по смыслу - site . Первый также позволяет находить любую последовательность символов в ссылке на искомый документ (например, /cgi-bin/), что широко используется для поиска компонентов с известными уязвимостями.

Попробуем на практике. Берем фильтр allintext и делаем так, чтобы запрос выдал список номеров и проверочных кодов кредиток, срок действия которых истечет только через два года (или когда их владельцам надоест кормить всех подряд).

Allintext: card number expiration date /2017 cvv

Когда читаешь в новостях, что юный хакер «взломал серверы» Пентагона или NASA, украв секретные сведения, то в большинстве случаев речь идет именно о такой элементарной технике использования Google. Предположим, нас интересует список сотрудников NASA и их контактные данные. Наверняка такой перечень есть в электронном виде. Для удобства или по недосмотру он может лежать и на самом сайте организации. Логично, что в этом случае на него не будет ссылок, поскольку предназначен он для внутреннего использования. Какие слова могут быть в таком файле? Как минимум - поле «адрес». Проверить все эти предположения проще простого.

Inurl:nasa.gov filetype:xlsx "address"

Пользуемся бюрократией

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

Например, обязательный в канцелярии министерства обороны США штамп Distribution statement означает стандартизированные ограничения на распространение документа. Литерой A отмечаются публичные релизы, в которых нет ничего секретного; B - предназначенные только для внутреннего использования, C - строго конфиденциальные и так далее до F. Отдельно стоит литера X, которой отмечены особо ценные сведения, представляющие государственную тайну высшего уровня. Пускай такие документы ищут те, кому это положено делать по долгу службы, а мы ограничимся файлами с литерой С. Согласно директиве DoDI 5230.24, такая маркировка присваивается документам, содержащим описание критически важных технологий, попадающих под экспортный контроль. Обнаружить столь тщательно охраняемые сведения можно на сайтах в домене верхнего уровня.mil, выделенного для армии США.

"DISTRIBUTION STATEMENT C" inurl:navy.mil

Очень удобно, что в домене.mil собраны только сайты из ведомства МО США и его контрактных организаций. Поисковая выдача с ограничением по домену получается исключительно чистой, а заголовки - говорящими сами за себя. Искать подобным образом российские секреты практически бесполезно: в доменах.ru и.рф царит хаос, да и названия многих систем вооружения звучат как ботанические (ПП «Кипарис», САУ «Акация») или вовсе сказочные (ТОС «Буратино»).

Внимательно изучив любой документ с сайта в домене.mil, можно увидеть и другие маркеры для уточнения поиска. Например, отсылку к экспортным ограничениям «Sec 2751», по которой также удобно искать интересную техническую информацию. Время от времени ее изымают с официальных сайтов, где она однажды засветилась, поэтому, если в поисковой выдаче не удается перейти по интересной ссылке, воспользуйся кешем Гугла (оператор cache) или сайтом Internet Archive.

Забираемся в облака

Помимо случайно рассекреченных документов правительственных ведомств, в кеше Гугла временами всплывают ссылки на личные файлы из Dropbox и других сервисов хранения данных, которые создают «приватные» ссылки на публично опубликованные данные. С альтернативными и самодельными сервисами еще хуже. Например, следующий запрос находит данные всех клиентов Verizon, у которых на роутере установлен и активно используется FTP-сервер.

Allinurl:ftp:// verizon.net

Таких умников сейчас нашлось больше сорока тысяч, а весной 2015-го их было на порядок больше. Вместо Verizon.net можно подставить имя любого известного провайдера, и чем он будет известнее, тем крупнее может быть улов. Через встроенный FTP-сервер видно файлы на подключенном к маршрутизатору внешнем накопителе. Обычно это NAS для удаленной работы, персональное облако или какая-нибудь пиринговая качалка файлов. Все содержимое таких носителей оказывается проиндексировано Google и другими поисковиками, поэтому получить доступ к хранящимся на внешних дисках файлам можно по прямой ссылке.

Подсматриваем конфиги

До повальной миграции в облака в качестве удаленных хранилищ рулили простые FTP-серверы, в которых тоже хватало уязвимостей. Многие из них актуальны до сих пор. Например, у популярной программы WS_FTP Professional данные о конфигурации, пользовательских аккаунтах и паролях хранятся в файле ws_ftp.ini . Его просто найти и прочитать, поскольку все записи сохраняются в текстовом формате, а пароли шифруются алгоритмом Triple DES после минимальной обфускации. В большинстве версий достаточно просто отбросить первый байт.

Расшифровать такие пароли легко с помощью утилиты WS_FTP Password Decryptor или бесплатного веб-сервиса .

Говоря о взломе произвольного сайта, обычно подразумевают получение пароля из логов и бэкапов конфигурационных файлов CMS или приложений для электронной коммерции. Если знаешь их типовую структуру, то легко сможешь указать ключевые слова. Строки, подобные встречающимся в ws_ftp.ini , крайне распространены. Например, в Drupal и PrestaShop обязательно есть идентификатор пользователя (UID) и соответствующий ему пароль (pwd), а хранится вся информация в файлах с расширением.inc. Искать их можно следующим образом:

"pwd=" "UID=" ext:inc

Раскрываем пароли от СУБД

В конфигурационных файлах SQL-серверов имена и адреса электронной почты пользователей хранятся в открытом виде, а вместо паролей записаны их хеши MD5. Расшифровать их, строго говоря, невозможно, однако можно найти соответствие среди известных пар хеш - пароль.

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

Intext:DB_PASSWORD filetype:env

С появлением на серверах Windows место конфигурационных файлов отчасти занял реестр. Искать по его веткам можно точно таким же образом, используя reg в качестве типа файла. Например, вот так:

Filetype:reg HKEY_CURRENT_USER "Password"=

Не забываем про очевидное

Иногда добраться до закрытой информации удается с помощью случайно открытых и попавших в поле зрения Google данных. Идеальный вариант - найти список паролей в каком-нибудь распространенном формате. Хранить сведения аккаунтов в текстовом файле, документе Word или электронной таблице Excel могут только отчаянные люди, но как раз их всегда хватает.

Filetype:xls inurl:password

С одной стороны, есть масса средств для предотвращения подобных инцидентов. Необходимо указывать адекватные права доступа в htaccess, патчить CMS, не использовать левые скрипты и закрывать прочие дыры. Существует также файл со списком исключений robots.txt, запрещающий поисковикам индексировать указанные в нем файлы и каталоги. С другой стороны, если структура robots.txt на каком-то сервере отличается от стандартной, то сразу становится видно, что на нем пытаются скрыть.

Список каталогов и файлов на любом сайте предваряется стандартной надписью index of. Поскольку для служебных целей она должна встречаться в заголовке, то имеет смысл ограничить ее поиск оператором intitle . Интересные вещи находятся в каталогах /admin/, /personal/, /etc/ и даже /secret/.

Следим за обновлениями

Актуальность тут крайне важна: старые уязвимости закрывают очень медленно, но Google и его поисковая выдача меняются постоянно. Есть разница даже между фильтром «за последнюю секунду» (&tbs=qdr:s в конце урла запроса) и «в реальном времени» (&tbs=qdr:1).

Временной интервал даты последнего обновления файла у Google тоже указывается неявно. Через графический веб-интерфейс можно выбрать один из типовых периодов (час, день, неделя и так далее) либо задать диапазон дат, но такой способ не годится для автоматизации.

По виду адресной строки можно догадаться только о способе ограничить вывод результатов с помощью конструкции &tbs=qdr: . Буква y после нее задает лимит в один год (&tbs=qdr:y), m показывает результаты за последний месяц, w - за неделю, d - за прошедший день, h - за последний час, n - за минуту, а s - за секунду. Самые свежие результаты, только что ставшие известными Google, находится при помощи фильтра &tbs=qdr:1 .

Если требуется написать хитрый скрипт, то будет полезно знать, что диапазон дат задается в Google в юлианском формате через оператор daterange . Например, вот так можно найти список документов PDF со словом confidential, загруженных c 1 января по 1 июля 2015 года.

Confidential filetype:pdf daterange:2457024-2457205

Диапазон указывается в формате юлианских дат без учета дробной части. Переводить их вручную с григорианского календаря неудобно. Проще воспользоваться конвертером дат .

Таргетируемся и снова фильтруем

Помимо указания дополнительных операторов в поисковом запросе их можно отправлять прямо в теле ссылки. Например, уточнению filetype:pdf соответствует конструкция as_filetype=pdf . Таким образом удобно задавать любые уточнения. Допустим, выдача результатов только из Республики Гондурас задается добавлением в поисковый URL конструкции cr=countryHN , а только из города Бобруйск - gcs=Bobruisk . В разделе для разработчиков можно найти полный список .

Средства автоматизации Google призваны облегчить жизнь, но часто добавляют проблем. Например, по IP пользователя через WHOIS определяется его город. На основании этой информации в Google не только балансируется нагрузка между серверами, но и меняются результаты поисковой выдачи. В зависимости от региона при одном и том же запросе на первую страницу попадут разные результаты, а часть из них может вовсе оказаться скрытой. Почувствовать себя космополитом и искать информацию из любой страны поможет ее двухбуквенный код после директивы gl=country . Например, код Нидерландов - NL, а Ватикану и Северной Корее в Google свой код не положен.

Часто поисковая выдача оказывается замусоренной даже после использования нескольких продвинутых фильтров. В таком случае легко уточнить запрос, добавив к нему несколько слов-исключений (перед каждым из них ставится знак минус). Например, со словом Personal часто употребляются banking , names и tutorial . Поэтому более чистые поисковые результаты покажет не хрестоматийный пример запроса, а уточненный:

Intitle:"Index of /Personal/" -names -tutorial -banking

Пример напоследок

Искушенный хакер отличается тем, что обеспечивает себя всем необходимым самостоятельно. Например, VPN - штука удобная, но либо дорогая, либо временная и с ограничениями. Оформлять подписку для себя одного слишком накладно. Хорошо, что есть групповые подписки, а с помощью Google легко стать частью какой-нибудь группы. Для этого достаточно найти файл конфигурации Cisco VPN, у которого довольно нестандартное расширение PCF и узнаваемый путь: Program Files\Cisco Systems\VPN Client\Profiles . Один запрос, и ты вливаешься, к примеру, в дружный коллектив Боннского университета.

Filetype:pcf vpn OR Group

INFO

Пароли хранятся в зашифрованном виде, но Морис Массар уже написал программу для их расшифровки и предоставляет ее бесплатно через thecampusgeeks.com .

При помощи Google выполняются сотни разных типов атак и тестов на проникновение. Есть множество вариантов, затрагивающих популярные программы, основные форматы баз данных, многочисленные уязвимости PHP, облаков и так далее. Если точно представлять то, что ищешь, это сильно упростит получение нужной информации (особенно той, которую не планировали делать всеобщим достоянием). Не Shodan единый питает интересными идеями, но всякая база проиндексированных сетевых ресурсов!

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

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

Структура страницы

Итак, давайте сначала с помощью HTML создадим структуру нашего документа. Для примера я решил использовать табличную верстку, чтобы сделать его более простым для понимания:

Как видите, у нас есть таблица с тремя ячейками, которые расположены горизонтально. Все как у обычного сайта: слева навигация, посередине контент, а в правой части рекламные блоки или новости. Каждой ячейке был присвоен свой id. Для левой части это leftcolumn, для правой – rightcolumn, а для средней ячейки с контентом – content.

Добавляем CSS

Теперь с помощью CSS нужно указать браузеру какие стили он должен использовать для отображения элементов страницы на экране и какие он должен использовать при печати. Создаем style.css и пишем туда следующее:

Первый блок CSS-кода описывает как должны отображаться элементы страницы в браузере. Блок был взят в дополнительные фигурные скобки перед которыми мы дописали @media screen. Это дает браузеру понять что данные стили нужно применить для вывода на экран:

Так выглядит страница при просмотре в браузере

Второй блок описывает отображение тех же элементов страницы, что и первый, но в данном случае в том виде, в котором будет выглядеть документ при печати и обозначается параметром @media print. Поскольку мы хотим чтобы был напечатан только полезный контент, то мы запрещаем для отображения левую (#leftcolumn) и правую (#rightcolumn) ячейки присвоив им значение display: none.

Так выглядит распечатанная версия страницы сайта

Отдельные файлы стилей

Обьединять все в один файл стилей совсем не обязательно. Вместо этого вы можете использовать два файла стилей и при их подключении к страницам сайта указывать браузеру какой файл стилей использовать при печати, а какой для вывода на экран. Первый (для вывода на экран) определяется параметром media="screen", а второй будет использоваться для печати и определяется параметром media="print":

Стили для печати нужно описывать после всех остальных, иначе Opera будет печатать блок контента вместе с цветным фоном, который предназначен для вывода в браузер, а не белый цвет, выбранный нами для печати.

Также при печати мы строго уменьшаем ширину блока с контентом до 600px, потому как при ширине 100% принтер "обрезает" небольшую полосу текста с правой стороны страницы. Обратите также свое внимание на то, что при печати из Opera отступ по краям листа немного меньше чем в Internet Explorer и строчки текста на листе бумаги получаются шире.

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

Копирование статьи запрещено.

Раньше было просто стандартом создавать ссылку или, если быть точнее, кнопку с надписью «Версия для печати». Они нужны для того, чтобы сделать распечатку на бумаге. Версия для печати содержит всю необходимую информацию, но в ней отсутствуют интерактивные элементы: кнопки, формы и тому подобное.

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

Решение - таблицы стилей для печати

Одной из замечательных особенностей CSS является возможность
создания таблиц стилей, ориентированных на разнообразные устройства
вывода. Мы привыкли создавать таблицы стилей для отображения страниц на
экране, но мы еще не привыкли думать о других средствах отображения. И,
как подтверждают ссылки «версия для печати», о печати документа мы
думаем лишь как о представлении документа в другом виде.

Но теперь нам нечего бояться, теперь для создания печатной версии
документа нам нужен всего лишь хорошо структурированный документ и
таблица стилей для печати!

Сегодня вы можете взять любой (X)HTML-документ и подготовить его к
печати с помощью стилевой таблиц, не прикасаясь к разметке. И вот в
прошлое уходят проблемы с созданием и синхронизацией двух версий
документа — одной для экрана, другой — для печати. И что самое
приятное: сделать это проще простого.

Обходим ошибку с плавающими элементами

Браузеры семейства Gecko, такие как Netscape 6.x или Mozilla, имеют
проблему с печатью длинных «плавающих» блоков (long floated elements).
Если плавающий элемент вышел за пределы печатной страницы, то
оставшаяся часть полностью пропадает, так и не появившись на следующей
странице.

Если ваш сайт похож на «A List Apart», т.е. статьи в нём заключаются
в один большой плавающий блок, то это значит, что читатели при
распечатке получат лишь первую страницу статьи.

Решение, как и следовало ожидать, заключается в отмене свойства
«плавающий» у блока с текстом перед печатью. Если вкратце, для всех
плавающих элементов устанавливается стилевое правило «float: none».
Сделав это, вы вернёте все плавающие элементы к обычному виду, и
документ будет напечатан так, как и предполагалось — страница за
страницей вплоть до самого конца.

Итак, именно это я и предложил сделать Зельдману для ALA, и, как
только он это сделал, проблема с печатью исчезла. У броузеров семейства
Gecko эта ошибка по-прежнему не исправлена (на момент написания
статьи), но всё же её можно легко обойти предложенным выше способом.

В путь

Ниже представлена «печатная» таблица стилей, с помощью которой «A List Apart» решил проблему печати плавающих элементов:

#menu { display: none; } #wrapper, #content { width: auto; border: 0; margin: 0 5%; padding: 0; float: none !important; }

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

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

Если посмотреть на содержимое тега новых статей на сайте ALA, мы обнаружим (в гуще начинки) следующие строки:

У нас есть файл таблицы стилей, print.css, применение которого для
печатных устройств «print» было оговорено значением атрибута «media».
Файл таблицы стилей nucss2.css, который импортируется с помощью
конструкции @import дабы скрыть его от Navigator 4.x, будет использован
при отображении страницы на любом устройстве вывода (атрибут
media=»all»). Это может быть дисплей, принтер, проектор, синтезатор
речи и так далее. Разойдясь, мы могли бы записать в таблицу стилей для
печати директивы для фонового цвета страницы и указать шрифты в
пикселях.

Статья по теме: Базовый набор плагинов для WordPress

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

Поэтому давайте немного улучшим нашу таблицу стилей для печати и решим несколько других проблем с расположением ее компонентов.

Отбеливание фонов

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

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

Если мы призовем на помощь свойство background, мы одним махом решим
обе проблемы. Чтобы сделать решение более гибким, зададим для элемента
«body» белый фон, а элементы «wrapper» и «content» пусть имеют
прозрачный фон (и тем самым через них будет проступать белый цвет
«body»):

body { background: white; } #menu { display: none; } #wrapper, #content { width: auto; margin: 0 5%; padding: 0; border: 0; float: none !important; color: black; background: transparent; }

Задание цвета переднего плана (цвет шрифта) не было абсолютно
необходимым, но лучше не забывать об этом. Итак, сейчас у нас есть два
«неплавающих» элемента (#wrapper, #content) с прозрачным фоном, и
страница — с белым фоном.

Вас может взволновать то, как Navigator 4.x обходится со значением
«transparent», но выше нос: NN4.x обращает внимание лишь на таблицы
стилей, у которых атрибут «media» имеет значение «screen». Так же как и
в случае с директивой @import, наши таблицы стилей для печати всегда
сокрыты от подслеповатых глаз Navigator 4. Так что, здесь не о чём
беспокоиться.

Размер шрифта для печати

Общая таблица стилей задаёт размер шрифта равный 11 пикселям. Весьма
неудачный выбор при печати. Само семейство шрифтов — сначала Georgia ,
а потом serif — отлично подходит для печати, так как шрифты с засечками
обычно лучше выглядят на бумаге. Необходимо изменить лишь размер
шрифта. Вот так:

body { background: white; font-size: 12pt; }

«Постойте!», — вероятно, воскликнете вы. — «Пункты — это зло!»

Что ж, да, так он и сказал, и был полностью прав — для экрана нельзя
задавать размеры шрифта в пунктах. При печати же применение пунктов
имеет такой же смысл, как и многие десятилетия назад. Раз уж мы готовим
таблицу стилей для печати, то определить размера шрифта для «body» в 12
пунктов будет правильным и естественным.

Вы, конечно, можете задать любой размер, какой пожелаете, однако
шрифт в 12 пунктов наиболее употребителен. И так как в общей таблице
стилей размеры всех остальных элементов страницы даны относительно
размера в элементе «body», наша работа закончена.

Marginalia

Существующие стилевые правила задают для левых и правых границ
(margins) элементов wrap и content размер в 5%. Это значит, что с обеих
сторон статьи будет «пустое место», и каждое такое «пустое место» будет
составлять 10% ширины области печати. Это следствие того, что блок с
текстом статьи «content» лежит внутри обрамляющего блока «wrapper», и
каждый их них имеет поля по 5% с левой и правой сторон.

Статья по теме: Яндекс.Школа вебмастеров

Исходная общая таблица стилей задаёт 15%-ный правый отступ (padding)
для блока «content». Границы уже дали нам 10%, так что нам надо
добавить ещё 5%. Это достаточно просто сделать:

div#content { margin-left: 10%; }

В другом варианте решения можно бы быть оставить границы (margin) в
покое и добавить 5% к левому отступу (padding). Так как блок «content»
не имеет видимого фона, мы получили бы такой же результат.

К сожалению, некоторые броузеры имеют проблемы с адекватной
обработкой отступов (padding), так что перемещать элементы по странице
лучше с помощью границ (margin).

Ссылки при печати

Был один хитрый вопрос — что же делать с гиперссылками? Очевидно, на
печати они не могут быть столь полезны, как на мониторе, но часто важно
дать ключ к тому, на что же они ссылались в оригинале. Итак, вот что я
изобрёл:

a:link, a:visited { color: #520; background: transparent; font-weight: bold; text-decoration: underline; }

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

В броузере, полностью поддерживающем спецификацию CSS2, мы можем
вывести URL-ы ссылок после них самих, тем самым делая услугу тем, у
кого окажется распечатка и броузер под рукой. Ниже показано правило,
которое применяется только для блока «content», и таким образом URL-ы
других ссылок не выводятся на печать:

#content a:link:after, #content a:visited:after { content: " (" attr(href) ") "; font-size: 90%; }

Попробуйте это в броузерах на платформе Gecko — Mozilla или Netscape
6.x. На распечатке после каждой ссылки вы увидите в скобках относящийся
к ней URL.

В броузерах, не понимающих это стилевое правило, не будет никаких
нежелательных эффектов — ссылки все так же будут темно-красными,
подчёркнутыми и жирными. Просто после текста ссылок не будет выводиться
относящегося к ним URL, вот и всё.

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

С этим новым правилом есть одна эстетическая проблема. Дело в том,
что оно предписывает дословно вставлять в документ значение атрибута
href.

Заглянув в код любой страницы с сайта «A List Apart», мы быстро
заметим там множество так называемых «относительных ссылок» вида
«/issues/144». Они будут вставлены в документ в таком виде, в каком они
есть, а хотелось бы что это были полные URL-ы.

В подобных случаях нам может помочь CSS3. Любой селектор атрибута,
использующий оператор ^=, выбирает элементы, основанные на начале их
значений атрибута. Таким образом, мы можем выбрать любой атрибут href ,
начиняющийся символом слэша, и вставить туда текст, заменяющий
существующее значение атрибута.

#content a:after { content: " (//www.alistapart.com" attr(href) ") "; }

Это правило преобразует все значения типа «/issues/144/», в
«//www.alistapart.com/issues/144/». Это правило не сможет помочь в
случае с относительными URL, которые не начинаются со слэша, но, к
счастью, ALA не использует этот тип ссылок.

ВНИМАНИЕ! ВАЖНО! Как было сказано, селектор вида ^=
относится к селекторам спецификации CSS3. Валидатор для CSS от
консорциума W3 может тестировать лишь на соответствие спецификациям
CSS1 и CSS2. Не понимая селектор, относящийся к CSS3, валидатор будет
сообщать об ошибке даже в том случае, когда селектор не противоречит
рекомендациям спецификации.

Украшаем начало страницы

Просматривая еще раз окончательный вариант стилевой таблицы, я
обнаружил, что мне не очень нравится «шапка» страницы. Дело скорей было
не в самой шапке, а в самом «подчеркивании» названия сайта. Это
подчеркивание разумеется заканчивалось там, где заканчивалась картинка
заголовка. Мне вдруг пришло в голову, что было бы неплохо растянуть эту
линию подчеркивания на всю ширину страницы.