10 частых ошибок начинающих веб-разработчиков

Original author: Michael Palermo
  • Translation


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

Использование старого HTML


Ошибка: На заре интернета было куда меньше возможностей по оформлению страниц, чем сегодня. Но старые привычки трудно изжить, и многие разработчики всё ещё пишут на HTML так, словно они застряли в 1990-х. Например, используют для создания макета страницы; применяют или в случаях, когда более уместны иные, более подходящие к содержимому тэги; используют тэги, не поддерживаемые текущим стандартом HTML (например, или ); или применяют для разделения элементов большое количество  .

Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы и, как следствие, к непредсказуемости её отображения в разных браузерах. И далеко не только в Internet Explorer.

Как избежать: Для начала перестаньте использовать для создания структуры страницы и применяете его только для вывода табличных данных. Ознакомьтесь с более современными инструментами. Используйте HTML для описания самого контента, а не способов его отображения. А для корректного отображения применяйте CSS.

«У меня в браузере всё работает»


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

Последствия: Будьте готовы к тому, что сайт, «заточенный» под один браузер, в других будет выглядеть просто ужасно.

Как избежать: Конечно, тестировать свой сайт во всех существующих браузерах и их версиях было бы пыткой. Но нужно хотя бы периодически проверять, как ваш сайт выглядит в некоторых наиболее популярных браузерах. Сегодня для этого есть бесплатные инструменты: виртуальные машины, сканеры сайтов. Например, с помощью http://browsershots.org/ или https://www.browserstack.com/ можно сделать снэпшоты того, как будет рендериться конкретная страница на всевозможных платформах. Работая с CSS, убедитесь, что «сбросили» все значения по умолчанию.

Кстати, если вы используете какие-то специфические CSS-решения, заточенные под конкретные браузеры, то обратите внимание на характерные для разных вендоров префиксы вроде -webkit-
, -moz- или -ms-. Чтобы быть в курсе текущих тенденций, можете изучить эти ссылки:

A break from the past, part 2: Saying goodbye to ActiveX, VBScript, attachEvent

CSS vendor prefixes considered harmful

On Internet Explorer supporting -webkit- vendor prefixes

Там описывается, почему стоит отойти от использования подобных префиксов. Практические рекомендации, как работать без префиксов, можно найти здесь: http://davidwalsh.name/goodbye-vendor-prefixes.

Плохие формы ввода


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

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

Как избежать: Во-первых, удостоверьтесь, что вы безошибочно донесли до пользователей, какая именно информация вам от них нужна. Если вы просите ввести «адрес», то уточните, какой: рабочий, домашний, электронный? Чтобы дополнительно подстраховаться, используйте проверку корректности вводимых данных. Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные. Никогда не используйте сцепленные T-SQL выражения для работы с полученными от пользователей данными без подтверждения корректности по каждому полю ввода.

Слишком большие ответы на сетевые запросы


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

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

Как избежать: Не думайте, что раз интернет из года в год становится быстрее, то это оправдывает раздувание размеров страниц. Вместо этого оптимизируйте свои проекты ради ускорения обмена сетевыми пакетами. Основная причина, по которой страницы становятся «тяжёлыми», — изображения. Чтобы минимизировать их влияние:

  1. Спросите себя, действительно ли необходима вся используемая вами графика? Откажитесь от ненужных графических украшательств. Можно воспользоваться сетевыми инструментами, чтобы определить, какие изображения нуждаются в дополнительном сжатии.
  2. Уменьшите размер изображений. Например, с помощью Shrink O’Matic или RIOT.
  3. Используйте предзагрузку. Это не ускорит первичную загрузку, но зато даст преимущество при просмотре других страниц сайта. Подробности можно почерпнуть из статьи: https://perishablepress.com/3-ways-preload-images-css-javascript-ajax/

Миницифируйте залинкованные CSS- и JS-файлы. Для этого есть множество инструментов, например, Minify CSS и Minify JS.

И наконец, старайтесь использовать наиболее современную версию HTML и внимательно используйте тэги и .

Создание кода, который должен работать


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

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

Как избежать: Необходимо принять как данность, что людям свойственно ошибаться. В том числе и вам. Если вы пишете на JavaScript, то применяйте грамотные методики для предотвращения и поиска ошибок. Можно воспользоваться большинством советов из этой статьи: http://www.palermo4.com/post/JavaScript-for-Windows-Store-Apps-Error-Handling.aspx, несмотря на то, что она предназначена для JS-разработчиков Windows-приложений. Также хорошим подспорьем в создании качественного кода будет модульное тестирование.

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

Написание ветвящегося кода


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

Последствия: С выходом новых версий браузера вам будет всё труднее поддерживать проект, он будет всё более громоздким.

Как избежать: Внедрите в код определение возможностей браузера, а не проверку браузера/версии. Это позволит очень сильно уменьшить объём кода, сделает его более читабельным. Например, можно воспользоваться библиотекой Modernizr, которая поможет автоматически поддерживать старые браузеры, не знакомые с HTML 5 или CSS 3.

Неадаптивный дизайн


Ошибка: При создании сайта разработчики и дизайнеры используют мониторы одного размера/разрешения.

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

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

Создание "бесполезных" страниц


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

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

Как избежать: Используйте SEO и поддержку специальных возможностей в HTML. Добавляйте в тэги ключевые слова и описания. В частности, об этом хорошо написано на About Tech. Чтобы помочь пользователям, которые не могут похвастаться орлиным зрением, добавляйте ко всем изображениям описание с помощью атрибута alt; есть ещё немало советов на эту тему. Можете также протестировать свои страницы с помощью Cynthia Says на предмет соответствия Section 508.

Слишком много обновлений страницы


Ошибка: Создание сайтов, которые для каждого действия требуют полностью обновить страницу.

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

Как избежать: Определите, действительно ли нужно каждый раз обращаться к серверу? Иногда скрипты на клиентской части можно использовать для немедленного предоставления данных пользователю. Также очень популярна технология AJAX. Можно пойти ещё дальше и применить методику SPA. С внедрением этих подходов вам помогут различные библиотеки, например, JQuery, KnockoutJS, AngularJS.

Работа с рассвета до заката


Ошибка: Вы тратите очень много времени на создание веб-контента, на повторяющиеся задачи, или просто на набор текста и кода.

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

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

Также обратите внимание на разнообразные веб-инструменты. Скажем, средства для упрощения процесса тестирования на разных платформах и устройствах. Экономить время можно и с помощью автоматизации процессов: например, Grunt может автоматизировать минификацию файлов, а Bower облегчает управление библиотеками и фреймворками.

* * *

Бывает, что даже достаточно опытные веб-разработчики допускают какие-то из вышеописанных ошибок. И важно не только знать, чего нужно избегать, но и понимать возможные последствия тех или иных неверных решений. Это позволит упростить и облегчить процесс разработки, создавая действительно качественные и приятные в использовании сайты.
NIX Solutions
66.17
Company
Share post

Comments 64

    +5
    ИМХО, это ошибки скорее не «начинающего» разработчика, а плохого разработчика который ляпает лишь бы как мотивируя это тем что «работает же!». Любой начинающий веб-разработчик в начале первой же попавшейся книги или статьи увидит список по типу «жмите стили, скрипты, картинки — тестируйте код — валидируйте формы — тестируйте во всех браузерах», и т.д. Это ж прописные истины.
      –34
      1. Использование PHP
        0
        Когда в «студиях» на «своем движке» на каждой странице повторно грузится фоновая графика\логотипы
        Когда текст со страница лень вставить в текстовый редактор и проверить на ошибки.

        И вообще есть ошибки в дизайне, есть ошибки в безопасности кода, есть ошибки в навигации и логике\структуре сайта.
        Но часто писакам, влом читать как надо и как не надо. И они думают что если они прочитали статью 10 ошибок… то все. По каждой тематике порой не одна книга написана. Суть конечно можно ужать.

        Все проблемы обычно от-того что всем занимается 1 человек или ему в один прекрасный момент пофиг что он делает говно! Некоторым пофиг сразу. (они сразу не читают и не хотят знать как нужно\лучше\правильно)

        Но идея подачи проблема\последствия\Решение правильная имхо. (Но материал подан поверхностно (это не упрек))

          +13
          Ругать PHP конечно мейнстрим и все такое, но на нем написано достаточно много всего, и язык продолжает развиваться и активно использоваться.

          P.s. Замечено было, что зачастую фразу «PHP — говно» кидают люди, никогда не кодившие на PHP, а просто потому что ругать PHP — модно.
            +4
            Замечено было, что зачастую фразу «PHP — говно» кидают люди, никогда не кодившие на PHP, а просто потому что ругать PHP — модно.
            Или трогавшие php3 в конце 90х и, возможно, 4 пых в начале нулевых. И пых того времени — говно, хотя и был несколько удобнее того же perl'а для cgi.
              +1
              В нашу организацию влилась молодая и талантливая команда дизайнеров и веб-программистов. По текущему проекту платежной системы их первое предложение было — ууууу, у вас все на Java, а давайте перепишем все на PHP!

              Проблема PHP, как впрочем и любого другого языка, заключается в людях, которые пишут на там где не надо. Такие люди обычно изучают PHP и считают, что всё, дальше уже некуда, на кой черт изучать что-то новое, если все или почти все можно на PHP написать?
                0
                Это другая сторона вопроса. Некомпетентность и узкий кругозор — это всегда боль для окружающих. Примера ради, когда пихают стек EE куда не надо, тоже получается совсем не конфетка.

                Другое дело, что среди php'шников очень много некомпетентного народа, если брать абсолютные цифры. Просто засчёт низкого порога вхождения и его массовости.
                  0
                  Да просто он везде нужен в мелком вэбе. Нужен мелкий сайт. На чем его делать? На PHP, конечно. Брать готовый двиг? Он тоже на PHP. Хочешь — не хочешь, а хоть немного его знать придется чтобы где-то что-то поправить, дописать и т.д
                  Сайт-визитку для небольшой конторы за пару вечеров любой веб-мастер широкого профиля сделает — хостинга бесплатного хватит, 500р (максимум) на домен, двиг бесплатный залил, шаб где-то взял и чуть подправил. Все, готово, давайте деньги.
                    0
                    Не в мелком тоже неплохо используется. Но там понятное дело подход совершенно другой и архитектура совершенно другая.
              0
              blah blah blah
            0
            Со всем согласен, но не понял как совместимо использование bower, который упоминается в конце, и пункт о минимизации CSS/JS.
            И кстати, адаптивный дизайн не панацея. Я бы ставил на мобильную версию.
              +1
              Я бы ставил на мобильную версию.
              Главное, чтобы был переход на полноценную версию, то очень хочется убивать, когда невозможно с мобильника использовать какой-нибудь критичный функционал.
                –4
                Поменяйте User-Agent и вас перекинет на полную версию (скорее всего)
                  +1
                  Вы уверены, что это просто сделать на любом популярном мобильном браузере? А если я хочу на части сайтов использовать полную версию, а на части — мобильную?
                    +7
                    Ещё можно телнетом зайти.
                      0
                      Личкрафтом, ага.
                  +1
                  Я бы ставил на мобильные версии только в случае сложных сервисов, типа соцсетей. Там очень сложные и развесистые интерфейсы, и если делать их адаптивно, они получатся очень тяжелыми и избыточными. Для мелких и большинства средних сайтов адаптивность — оптимальный выбор.
                    0
                    По первому пункту, это вообще не проблема, к примеру в генераторе gulp-webapp сразу при установке компонента, в html автоматически подключаются пути к js и css, а при билде это все склеивается и минимизируется, там правда возникают порой неожиданные проблемы, но все решаемо
                    0
                    Ошибка: Страницы, наполненные полезным контентом, но совершенное недружественные к поисковикам. Не внедрены специальные возможности для слабовидящих пользователей.

                    А это вы как ухитрились в одну ошибку запихнуть такие никак не связанные друг с другом вещи?
                      +7
                      Как там в 2008?
                        +1
                        Ну, кто-то может учил html в 1998.
                          +2
                          разработчика с 17-летним стажем трудно назвать начинающим.
                          • UFO just landed and posted this here
                        +2
                        применяют span или div в случаях, когда более уместны иные, более подходящие к содержимому тэги;

                        А можно подробнее? Строчный и блочный контейнеры, что может быть проще и безобиднее? Как их можно использовать не по назначению?
                          +1
                          Может не в тему, но я когда-то видел пример таблицы, сверстанной div-ами. Причина такого решения до сих пор загадка.
                            0
                            Вполне возможная причина — адаптивный дизайн. На маленьких экранах таблица «разваливается» на другую сетку.
                            • UFO just landed and posted this here
                                0
                                К сожалению, на практике там всплывают нюансы :) Но в общем и целом решение верное, да.
                                • UFO just landed and posted this here
                                    0
                                    Нюанс в том, что таблица перестает быть таблицей и превращается в гору дивов.
                                    Она теряет табличное поведение, выраженное в том, что ячейки в строке будут всегда иметь одну высоту, а в столбце — одну ширину.
                                    Если данные в таблице гарантированно «красивые», это не составляет очень большой проблемы, но если у нас есть вероятность прихода «нетипичных» данных (очень длинная строка, например) — всё может рассыпаться. Нужно очень внимательно за этим сделить и тщательно тестировать верстку на разных данных.
                                    • UFO just landed and posted this here
                                        0
                                        Я понимаю, что это ожидаемое поведение. Имеется в виду, что в реальных задачах оказывается, что совладать с этой псевдо-таблицей бывает значительно сложнее, чем казалось на первый взгляд в теории. А если там ещё и rowspan/colspan есть — вообще туши свет.

                                        Приём с дополнительными атрибутами интересный, да.
                                        • UFO just landed and posted this here
                              0
                              Может дело в том что таблица накладывает ограничения производительности?
                              • UFO just landed and posted this here
                                  +1
                                  У браузеров есть проблемы с отрисовкой больших таблиц, они не поддаются оптимизации. Конкретных цифр я вам дать не могу, но это общеизвестный факт в оптимизации рендера.
                                0
                                >> Может не в тему, но я когда-то видел пример таблицы, сверстанной div-ами
                                Вы увидели bootstrap.

                                .container>.row>.col

                                table>tr>td
                                  0
                                  В стародавние времена… таблица отрисовывалась только после получения закрывающего теги. Дивы это финт ушами для данного, неактуального в наши дни, случая.
                                  • UFO just landed and posted this here
                                      0
                                      Ну я тут откапал свою старые опыты: "Не очевидные истины. Скелет страницы таблицей. Неправильно." и на сколько я вижу проблемы это не решало. Более того, сейчас посмотрел еще раз в последних лисе и хроме под убунтой и таки там страница в итоге отрисовывается на 14-16 секунде только. Причем отчего-то оба варианта.
                                      • UFO just landed and posted this here
                                  +2
                                  Имеется ввиду, что span и div лишены семантического смыслы. В некоторых случаях лучше заменить их на более «значимые» тэги, например, address, nav, header и т.д…
                                    +3
                                    Вероятно, имелось в виду, что нужно использовать не только DIV, но и FOOTER, HEADER, SECTION, ASIDE, NAV; не только SPAN, но и ABBR, CITE и т.д.
                                      +1
                                      Более подходящие — видимо, имеются в виду теги типа ul/li, strong/em, dt/dd и так далее.
                                      +9
                                      Понадергаем рекомендаций из прошлого десятилетия, смешаем теплое с мягким, и получим данную статью. Браво.
                                        0
                                        Объясните объективно, чем div'ы в сочетании с «display: table;» плохи для создания макета? В HTML нет ни одного тега, предназначенного для создания колонок (недавно появился flex-layout, но он поддерживается не всеми браузерами). В этом плане табличная вёрстка наравне с float, «display: inline-block;» и «position: absolute;».
                                          0
                                          Ну как минимум margin-ы у элементов с display: table-cell работать не будут. Зачем городить огород, если все можно обычными флоатами сделать
                                            +1
                                            Зато работает padding, суммарная ширина колонок всегда будет 100% и ни одна колонка никогда не съедет вниз. У каждого из описанных подходов свои плюсы и минусы, лучший определяется контекстом. Ладно, использование — это неверная семантика. Но почему вдруг «display: table;» стал запретным, не понимаю.
                                            • UFO just landed and posted this here
                                                0
                                                Понятно. Флексбоксы поддерживаются начиная с IE10, поэтому пока, к сожалению, рано использовать его в вёрстке публичных страниц.
                                                • UFO just landed and posted this here
                                            • UFO just landed and posted this here
                                            • UFO just landed and posted this here
                                                0
                                                По-моему таблицы надо верстать на предназначенных этому тегах)
                                                • UFO just landed and posted this here
                                                +3
                                                Странно, что в контексте «У меня в браузере всё работает» даже не упомянут normalize.css.
                                                  +7
                                                  Некоторые советы настраивают на неверный подход к обеспечению безопасности. Например:

                                                  «Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные.»

                                                  На сервер можно отправить какие угодно данные, код на клиенте от этого никак не спасёт. Просто с самого начала, разрабатывая серверную часть, привыкайте не доверять данным, пришедшим с клиента. Всегда проверяйте их на сервере.
                                                    +2
                                                    я бы назвал эту статью Десять ошибок разработчиков для министерства образования ;) недавно маман попросила ей работы на конкурс скинуть, так это ахтунг. мало того, что сайт явно указывал, что единственным браузером, в котором он будет хорошо работать — это ie, мол даже не смейте заходить к нам с других кофеварок… так в общем чтобы разобраться с их 'юзабилити' и загрузить три фото + описание работы, разгадать как оплатить заявку, итп — ушло несколько часов. Теперь троллю её, что она попала в тройку, потому что очень мало кто смог загрузить свои работы )) не для обычных людей уж точно
                                                      +1
                                                      Я бы сказал, что это ошибки старого разработчика. Те, кто начал работать недавно и не в курсе что такое «вёрстка таблицами».
                                                      • UFO just landed and posted this here
                                                        0
                                                        Напомнили мне про мой первый (и единственный) сайт, который я делал за деньги компании отца в 2000-2001 годах где-то.
                                                        Сидел ночами, в emacs-е руками все писал, читал стандарты, в GIMP-е картинки рисовал, создавал огромные таблицы, рисуя руками TR/TD, старался соблюдать все требования, которые мог в те годы найти (интернета, можно сказать, почти не было, Дальний Восток).

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

                                                        ==
                                                        Данный сайт оптимизирован для разрешения 1024x768 и, частично, для 800x600. Если Вы просматриваете эту страницу при разрешении меньше 800x600 или если страницы при разрешении 800x600 выглядят «некрасиво», то рекомендуем выключить фреймы, чтобы увеличить свободное место на экране. Также для более комфортного просмотра рекомендуем включить поддержку CSS и JavaScript, если она отключена, и не просматривать сайт броузером Netscape Navigator, т.к. он некорректно поддерживает вложенные таблицы и CSS
                                                        ==

                                                        А в коде нашел это:

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

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

                                                        Еще очень «крутой» фишкой для того времени была подгрузка всех картинок в фоне, тоже придумал и радовался. Тогда все сидели на модемах и когда делаешь mouseover, можно было несколько секунд ждать, пока подгрузится нужная картинка.

                                                        Дааа, юность, азарт, ночи напролет, всё интересно, все взахлёб изучаешь, впитываешь… Лучшее время.

                                                        Вот, кстати, сайт: hiddenman.esy.es/fs (первый попавшийся хостинг). Таблица выбора копировально-множительных аппаратов, подробная информация и т.д.

                                                        P.S. А вот к Хроме, кстати. левый фрейм кривовато отображается. А остальное работает и через 15 лет. Кодировка нигде не указана (тогда другой и не было, кроме непопулярной уже KOI8-R, сейчас браузеры сами понимают, какая она, если что, смените кодировку на CP1251 и насладитесь «шедевром». По сути, только раздел Контакты заполнен и Копировальная техника)
                                                          0
                                                          За деньги для компании, в смысле. Помню, вроде бы $50 заплатили и я купил себе свой первый пейджер. Сайт еще немного обновлялся, на archive.org нашел, но у себя уже не найду исходники.

                                                          Сейчас вспомнил еще, что в те времена успевал невероятно много всего делать, откуда время бралось? За год или два столько всего изучил, столько всяких проектов сделал для Fido, BBS-ок и прочего. А сейчас не успел оглянуться — год прошел — а я так и сижу, читаю какие-то тупые статьи в интернете так ничего и не сделав.
                                                            0
                                                            Чтобы неправильно не поняли — тупая — это я про всякие новости непонятно о чем и т.д. А эта статья полезная.
                                                          +1
                                                          > Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы
                                                          На практике чаще всего наблюдается строго обратная ситуация.

                                                          Only users with full accounts can post comments. Log in, please.