[ Главная страница ]  [ Омар Хайям ]
[ Гадание на рубаи ]  [ Популярная наука ]  [ Живая История ]  [ Гостевая книга ]  [ Новости сайта ]



Семь золотых правил для начинающих,
но подающих надежды WEB-мастеров

Лирическое вступление.

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

На экране возникает отвратительное "Alert", "Ошибка сценария на странице". Или Вы натыкаетесь на текст, который не читается ни в одной из кодировок. Как опытный, многое повидавший пользователь, конечно, жмете на "Encoding" или "Язык", но все тщетно... Другой вариант: не прорисовывается часть картинок (разумеется, самых интересных). В редких случаях возможны и более неприятные ситуации - зависание браузера и даже системы.

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

Должен Вас огорчить. К сожалению, все не так просто. В том-то все и дело, что бедолага - хозяин сайта, скорее всего, просто не догадывается о наших проблемах. Он честно протестировал все у себя на компьютере сначала в "off line", затем опубликовал в сети и проверил все в "on line". Да что там проверил, он, как любой хозяин, очень часто бывает на своем родном сайте. Бывает, и каждый раз убеждается, что все в порядке, все загружается и работает. Он, скорее всего, даже не поверит, если Вы расскажете о своих проблемах. Потом, возможно, раздраженно скажет, что нужно уметь настраивать свои браузеры. И только когда придет куда-нибудь в гости, решит показать свой сайт и увидит на чужом компьютере все эти отвратительные окна "alert", пустые места вместо рисунков и крючки вместо букв, - только тогда действительно сильно расстроится.

При создании Web-страниц объективно существует стандартный набор скрытых ошибок и неточностей, которые проявляются нерегулярным образом в зависимости от браузера, системы, сервера, где опубликован сайт, скорости соединения с провайдером, установленных у клиента шрифтов и т.д. Несмотря на то, что многие из этих ошибок описаны, и не раз, они регулярно встречаются почти у всех начинающих Web-мастеров и, сравнительно часто, даже у довольно опытных. Последний раз я убедился в этом, просматривая на досуге сайты участников конкурса "Золотой УРЛ". Это было последней каплей. Я твердо решил написать статью, которую Вы сейчас читаете.

Еще раз повторяю: многое из того, о чем будет далее написано, можно найти где-нибудь в сети (по мере необходимости мы будем давать некоторые ссылки). Тем не менее, число страниц с ошибками не уменьшается, а наоборот растет. Может быть, все дело в методике... Давайте попробуем вместе пройти весь путь борьбы с замаскированными ошибками от начала и до конца. Такой подход мне еще не встречался. Я буду для определенности считать, что мой собеседник знаком с основами HTML и Java Script и что на его (то есть Вашем) компьютере установлена система Windows-95 и 3 типа браузеров - IE-4.0, Netscape 4.0 и Netscape 3.0Gold. Должен заметить, что этот арсенал "бродилок" - минимален, если Вы действительно всерьез задумали заняться WEB-публикациями (IE-3 сейчас уже редко используется).

Приступаем.

Итак, в качестве подопытного кролика мы слепим предельно простую страничку, содержащую все необходимые нам элементы. На первом шаге при ее создании поступим так, как делает большинство начинающих, - запустим редактор "MS FrontPage Editor" (заметим мимоходом, что критика такого подхода не входит в планы данной статьи) и секунд через 30 получим необходимый html-файл. Затем перейдем в какой-нибудь простой текстовый редактор (например, стандартный "Блокнот", если нет лучшего). Там вставим свой баннерный код в начале (дело не только в рекламе, он нам действительно пригодится позже), кнопку и связанную с ней небольшую процедуру на JavaScript, "на лету" формирующую новую страницу. Вот и все. Взгляните на получившийся исходный текст странички.

Знатокам, чтобы им было не скучно, сразу, до продолжения чтения, предлагается поискать и отметить ошибки и неточности. Страница получилась совсем простая. Однако даже этого вполне хватит для наших учебных целей. Я только что загрузил эту страничку в IE-4 в режиме "off line" и, уверяю Вас, все превосходно работает! Ура! (Вы даже не представляете, насколько преждевременна наша радость. До полной победы еще как до Луны.) Теперь переходим ко второму этапу. Подопытного кролика для предстоящих опасных экспериментов можно взять за уши прямо сейчас.

Тестирование в off-line.

Сначала испытаем файл pptest0.htm в IE. Я загрузил страничку win и у меня, как я уже говорил, все работает (кроме баннера, конечно, я ведь в off-line). А у Вас? Как, нет рисунка? Почему же, у меня есть. Смотрим внимательно текст файла и обнаруживаем первую ошибку. Вот она: img src="Banners/knopka1.gif...

Дело в том, что FrontPage Editor при вставке рисунка указал к нему путь от места расположения создаваемого htm-файла. То, какой атрибут "src" запишет FrontPage в тэге <img> зависит от взаимного расположения папки, куда записывается htm-файл, и встроенного в него рисунка. Если они "далеко" друг от друга, то редактор при сохранении выдаст диалоговое окно "Save Embedded Files", и Вы сможете разрешить скопировать встраиваемый рисунок в папку, куда сохраняете файл, - тогда проблем не возникнет. В некоторых случаях (не будем вдаваться в детали, захотите - сами досконально разберетесь), вы получите, например, такое: src="file:///D:/Paper/Banners/knopka1.gif".

В этой ошибке самое неприятное то, что Вы можете очень долго ничего не знать о ней даже после опубликования в сети. Ведь при загрузке странички из INTERNET на Ваш компьютер рисунок просто будет вставляться с винчестера, и Вы ничего плохого не заметите (особенно, если рисунок маленький, если большой - может насторожить высокая скорость загрузки). А вот посетители Вашего сайта рисунка так никогда и не увидят. Все сказанное относится и к атрибуту href.

Для поиска таких ошибок полезно время от времени переименовывать у себя на компьютере папку с макетом сайта. Все это - давно известные, многократно описанные вещи, но, сколько этих ошибок в INTERNET! Если вместо рисунка - дырка, или ссылка мертва, - посмотрите исходный текст. Вы почти наверняка увидите там что-то вроде scr="file:///..." href="file:///...". Итак,

Правило 1. Если при создании странички Вы пользовались WYSIWYG html-редактором, то перед публикацией обязательно поищите контекстным поиском конструкцию "file:". Внимательно проверьте в тексте созданной страницы все атрибуты "scr", и "href". После публикации в сети, переименуйте на своем компьютере папку с файлами Вашего сайта.

Решение максималиста: никогда не использовать программу FrontPage Editor и другие подобные редакторы.

Исправляем везде "Banners/knopka1.gif" на "knopka1.gif" и продолжаем работу.

Теперь смотрим в Netscape. В четвертом - у меня все нормально (у Вас, я надеюсь, тоже). Хотя нет, не совсем нормально. При нажатии на "Мы объявляем..." на формирующейся странице получается какая-то неприятная гигантская кнопка. Странно, ведь в IE проблем не было. Смотрим текст. Видим, что действительно допустили ошибку. В дочерней странице Контейнер <FONT SIZE="+2"> открывается два раза, а закрывается (</FONT>) - один. Браузеры реагируют на эту неточность по-разному. Netscape распространяет увеличенный шрифт на форму, и кнопка получается большой, а IE - нет. Тестируя только в IE, мы не заметим эту ошибку. Борьба за стандартизацию браузеров ведется, но воз и ныне там... Отсюда

Правило 2. Обязательно тестируйте свои страницы на разных типах и версиях браузеров. Минимальный набор - последние и предпоследние версии IE и Netscape.

Решение максималиста: установить на своем компьютере десяток различных вариартов браузеров, начиная с самых первых версий. Подарок максималисту от Японского Городового: здесь можно поживиться браузером Netscape 1.0!

Ниже Вы еще не раз убедитесь в важности Правила 2. Исправляем ошибку, изменяя строку aline+='WEB-странички</big><br>'; на aline+='WEB-странички</big><FONT><br>'; , и переходим к просмотру в Netscape 3.0Gold. Ого! Ошибки JavaScript при загрузке (окна "alert"), после загрузки кнопка "я хочу..." не работает. Вы можете очень долго искать ошибку в нашем скрипте, тем более, что ее там нет -;). Это - хорошо известный эффект русской буквы "я".

Ох уж эта буква. Не любят ее сети и языки программирования! Опытные пользователи INTERNET хорошо это знают (вспомните хотя бы первую программу ICQ - Аську). Все, что Вам нужно сделать - заменить в скрипте (не спутайте, не в тексте, а только в скрипте!) маленькую букву "я" на комбинацию "\я". Сделали? И не забывайте это делать всегда, ведь любителей Netscape 3 Gold все еще много (я и сам люблю старика).

Кстати, не думайте, что буква "я" может причинить неприятности только третьей версии этого браузера. Я не раз был свидетелем ситуации, когда присутствие "я" в скрипте загружаемой в Netscape 4 странички приводило не только к относительно безобидному прерыванию выполнения скрипта, но даже к полному краху системы (в том числе Windows NT). Окна "Alert" начинают размножаться до бесконечности, этот кошмар ничем не остановить, пока не рухнет система. Правда это ошибка нерегулярная, проявляется только в "on line", зависит от сервера. Представляете, как будет Вам благодарен ваш гость, если такая неприятность случится именно с ним? Придет ли он еще когда-нибудь на ваш сайт? Я бы не рискнул.

Тут нам придется немного забежать вперед и вспомнить, что в кодировке KOI8 (про кодировки - ниже), буква "я" превращается в другую битовую комбинацию и непосредственной опасности не представляет. Но тогда возникает вопрос, а не обращается ли какая-нибудь другая буква в то, что в WIN1251 выглядит как буква "я". Так оно и есть. Этим грешит большой твердый знак "Ъ". У нас в скрипте он как раз присутствует. Значит нужно еще заменить "Ъ" на "\Ъ" Если про букву "я" знают и помнят многие, то уж про "Ъ" забывают практически все. Кроме того, если в выводимом на экран тексте странички необходимо присутствие тэгов html (как, например, в этой статье), не забывайте заменять символ "<" на комбинацию "&lt;", чтобы браузер не перепутал текст с тэгами. Из всего сказанного

Правило 3. Везде в скриптах своей странички замените маленькую букву "я" на комбинацию "\я", а большой твердый знак "Ъ" - на "\Ъ". Везде в тексте страницы следует вместо символа "<" использовать блок "&lt;".

Решение максималиста: никогда не использовать букву "я" и "Ъ" в текстах своих программ -;)

Поддержка разных кодировок кириллицы.

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

Но, не будем о грустном. Можно, конечно, не идти на поводу у русофобов и всенародно объявить, что признаете только какую-то одну из кодировок, а все остальные - гнусные происки врагов. Так некоторые делают. Смотря что Вы, в итоге, хотите получить. Если выпендриться (правда, не понятно перед кем) - это ваш путь и шанс. А если хотите, чтобы большинство посетителей сайта могло прочитать Ваш текст - тогда, будьте любезны, обеспечьте, как минимум, поддержку двух кодировок - WIN 1251 и KOI8.

Позвольте, скажут знатоки ("убивать надо таких знатоков..."), но ведь это не наше дело, это автоматически производит сам сервер. Во-первых, далеко не всякий сервер, а, во-вторых, даже если и производит, - все равно Вас, скорее всего, попросят представить файл в кодировке KOI-8, естественной для UNIX (я предполагаю, что веду разговор не с хозяином сервера - ему вряд ли интересен этот текст). Так что, в любом случае, перекодировка необходима. Для этого можно применить любую из множества программ перекодировки или использовать возможности сети.

В результате всей процедуры имеем на выходе два файла - pptest.htm (кодировка WIN1251) и pptest8.htm (KOI8). Оставайтесь с нами! Если хотите работать вместе, можете взять эти файлы здесь. Переходим к следующему этапу.

Тестируем в off-line файл в кодировке KOI8 - pptest8.htm.

Здесь все браузеры совершенно единодушны. Все они показывают фердипюксы на экране вместо нашего текста. Причем никакие наши попытки перейти в кодировку KOI8 ([options/document encoding/Cyrillic KOI8-R], или [View/Encoding/Cyrillic KOI8-R], или [Вид/шрифты/Кириллица KOI8]) ни к чему не приводят. Странно. Но только на первый взгляд.

Все дело в строке, автоматически добавленной FrontPage. Вот она: <meta http-equiv="Content-Type" content="text/html; charset=windows-1251">. Эта строка навязывает браузеру кодировку "charset". Ее приоритет выше (!!!), чем ваши приказы браузеру. Во всем виноват FrontPage? Ну, не совсем так, никто, в общем-то, не виноват. Ведь, если бы Вы в редакторе FrontPage готовили свою страничку в KOI8 [File/Page Properties/Language/Cyrillic (KOI8-R)], редактор бы вставил другую строку: <meta http-equiv="Content-Type" content="text/html; charset=koi8-r">. Ага, скажете Вы. Теперь все ясно! Просто заменим вручную в файле pptest8.htm один charset на другой. Хорошо, давайте попробуем.

Нужно отдать должное IE-4 - к нему претензий нет, все показывает, как задумано. Ничего удивительного, так и должно быть - что ни говори, а он действительно полноценно русифицирован. А вот в экспериментах с Netscape Вы, возможно, обнаружите проблемы ("нерегулярные") с текстом в окне, открывающимся после нажатия кнопки "я хочу это прокричать". Дело в том, что IE-4 раскодирует "потоковое" окно той же кодировкой, что и материнское, игнорируя при этом все навязываемые пользователем варианты. Короче говоря, если имеется строка с "charset", - она все полностью и определит. Большинство версий Netscape, напротив, - выводят вторичное "потоковое" окно в кодировке, ранее заданной в панели "encoding".

Это может приводить к определенным проблемам при просмотре нашей странички. Если, например, до нас пользователь рассматривал что-то, требующее KOI8, а потом загружает pptest.htm, то сначала он увидит нормальный текст (charset сработает!), зато после нажатия на кнопку он получит нечто абсолютно нечитаемое, дискредитирующее Web-мастера (то есть нас с Вами). Если он по привычке полезет в encoding, это не всегда поможет - Netscape-4 просто проигнорирует (надо, мол, раньше было думать), а третья версия перекодирует, но не полностью, оставляя старые надписи на кнопках -:)). А вот если убрать "charset", то пользователь сразу после загрузки pptest.htm увидит бред на материнской страничке, полезет в "encoding", и дальше проблем уже не возникнет.

Должен, правда, оговориться - в последних рилизах Netscape 4 эта особенность устранена, он поступает с wysiwyg-окнами, как IE, но где гарантия того, что Ваш посетитель пользуется именно последними версиями?

И еще одно. Многие серверы держат у себя странички только в кодировке koi8 (это, разумеется, весьма разумно и правильно) и автоматически перекодируют их при отправке к нам в соответствии с установленной в момент запроса кодировкой нашего браузера. Он их перекодирует в win, но строка с "charset=koi8-r" останется. Она может ввести в заблуждение наш (и Ваш) браузер, заставляя его показывать в кодировке koi8 то, что давно перекодировано в win. Да, действительно, - настоящая диверсия...

Так, может быть, просто везде убрать "charset" и доверить все пользователю? Может быть, но пока воздержимся от таких кардинальных выводов. Во всяком случае, мы уже с уверенностью можем сформулировать

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

Решение максималиста: всегда вычищать строку с "charset" со своих страниц

Нужно сказать, что проблема charset-а достаточно популярна в сети, хотя единой точки зрения по этому вопросу нет. Заинтересованный читатель может узнать мнения Артемия Лебедева, Станислава Жаркова и Андрея Чернова.

В последний раз просматриваем странички и замечаем, что в Netscape-3 вторая часть фразы в кодировке KOI8 по прежнему не читается! Смотрим текст. Видим, что не читается после тэга <font face="Arial">. Попробуем разобраться.

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

Хуже, если шрифт с таким названием есть, но он приспособлен к кодировке, отличной от кодировки страницы. В нашем случае так и получилось, когда Netscape-3 использовал "Arial" для странички, закодированной в KOI8-R. Четвертые версии браузеров с этой проблемой справляются, применяя так называемую систему unicode, в которой распознавание кодировки - дело программы, а не шрифта.

Теперь давайте подумаем, для кого мы делаем страничку в KOI8. Каков круг ее потенциальных посетителей? Это, во-первых, наши соотечественники - пользователи UNIX (никогда не забывайте о них, - это солидные, близкие к провайдерам люди, как правило, - хозяева серверов). А, во-вторых, - русскоязычные зарубежные пользователи WINDOWS. Между тем, в системе UNIX шрифты имеют не такие названия, как в WINDOWS, и наши усилия по навязыванию шрифта будут просто проигнорированы. С другой стороны, применив <font face="Arial"> , мы отсекли от нашей странички зарубежных посетителей - пользователей третьей версии Netscape. Это совсем нехорошо. Вот и выходит

Правило 5. Воздержитесь от использования атрибута "face" в страничках c KOI8-кодировкой. Помните также, что шрифты одинаковой гарнитуры имеют разное название в OS Windows и UNIX.

Решение максималиста: до лучших времен полностью отказаться от атрибута "face"

О проблеме использования шрифтов можно прочитать, например, у А.Носика, С.Жаркова и А.Владимирова.

Но пора переходить к следующему этапу:

Тестирование в режиме online.

Для чистоты эксперимента зашлем страничку на два разных сервера (зеркала, понимаешь...). Ну, к примеру, на российский всем известный Chat, поддерживающий автоматическую перекодировку кириллицы, и на еще более известный - американский GeoCities. Зарегистрировались (халява, Сэр!), заслали, смотрим, что получилось:

GeoCities win koi8-r
Chat Автоматическая перекодировка сервером

Вроде бы все работает. Однако, продолжая эксперименты, рано или поздно, вы обязательно натолкнетесь на ошибку в IE - при нажатии на кнопку "Прокричать" выскакивает такое отвратительное окно:

Тревожное окно в IE-4

Самое неприятное, что оно появляется не всегда, поэтому и здесь Вы очень долго можете ничего не знать. Причина в том, что вы нажали на кнопку в тот момент, когда страничка с программой не успела загрузиться (для этого и был нужен баннер!), и выполнение скрипта еще невозможно. В этом случае Netscape проигнорирует Ваши действия (и правильно сделает!), а вот IE выдаст ошибку.

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

Достаточно просто. Добавить часть скрипта, проверяющего факт загрузки при нажатии пользователем кнопки. Например, вводим переменную loaded и присваиваем ей значение var loaded=false; в начале программы. Затем функцию: function load(){ loaded=true; } и заставляем ее исполняться при загрузке страницы <body OnLoad="load()">. И последнее, изменяем форму с кнопкой: вместо onClick="newpage()" используем onClick="if(loaded) newpage()". Теперь IE не ругается и покорно ждет загрузки страницы, а мы запишем

Правило 6. При использовании на странице кнопок, связанных с исполняемыми скриптами, обязательно проверяйте факт загрузки страницы. Если Ваш скрипт использует объект из другого фрейма, обязательно проверяйте его наличие.

Решение максималиста: вообще не использовать скрипты на своих страницах (явно погорячился, бедный)

Вот что у нас в конце концов получилось после всех описанных выше исправлений:

GeoCities win koi8-r
Chat Автоматическая перекодировка сервером

Ну вроде теперь уже все работает. Можно тяжело вздохнуть и начинать раскручивать странички в сети.

Если Вы действительно так думаете, то весь наш разговор был напрасен и "не в коня корм". К этому моменту уже пора понять, что все работать просто не может. Ведь Internet еще так молод и так быстро развивается... Уверяю Вас, что придут удрученные (гневные) письма от тех, у кого тестирование проходило не так, как у нас. Кроме того, эта статья была посвящена лишь ошибкам, а дело ведь не только в ошибках.

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

Правило 7. При любой возможности заходите на свой сайт с чужих компьютеров. Всегда есть шанс обнаружить ошибки, о существовании которых Вы не догадываетесь.

Решение максималиста: до лучших времен полностью отказаться от разработки и публикации своих страниц.




  | Сообщает https://zhytlonews.com/. | www.tichk.org |


  [ Главная страница ]  [ Омар Хайям ]
[ Гадание на рубаи ]  [ Популярная наука ]  [ Живая История ]  [ Гостевая книга ]  [ Новости сайта ]


Вернуться к главной странице

Copyright c 1999 Японский Городовой
E-mail: gorodovoi@nev.ru