Перед современным веб-разработчиком стоит широчайший выбор платформ для хостинга и хранения данных, инструментов для работы с HTML, CSS и JavaScript, способов фактической реализации дизайна, а также всевозможных библиотек и фреймворков. В помощь тем, кто хочет найти свой путь в этом обилии вариантов, сеть услужливо предоставляет массу статей, обсуждений на форумах и примеров «наилучших» решений. Но вне зависимости от того, как и с помощью чего начинающие разработчики создают сайты, многие совершают одни и те же ошибки. Давайте рассмотрим некоторые из них, чтобы в будущем не наступать на эти популярные грабли.
Использование старого HTML
Ошибка: На заре интернета было куда меньше возможностей по оформлению страниц, чем сегодня. Но старые привычки трудно изжить, и многие разработчики всё ещё пишут на HTML так, словно они застряли в 1990-х. Например, используют
<table> для создания макета страницы; применяют <span> или <div> в случаях, когда более уместны иные, более подходящие к содержимому тэги; используют тэги, не поддерживаемые текущим стандартом HTML (например, <center> или <font>); или применяют для разделения элементов большое количество .Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы и, как следствие, к непредсказуемости её отображения в разных браузерах. И далеко не только в Internet Explorer.
Как избежать: Для начала перестаньте использовать
<table> для создания структуры страницы и применяете его только для вывода табличных данных. Ознакомьтесь с более современными инструментами. Используйте 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 выражения для работы с полученными от пользователей данными без подтверждения корректности по каждому полю ввода.
Слишком большие ответы на сетевые запросы
Ошибка: Страница, заполненная многочисленными изображениями в высоком разрешении, уменьшенными с помощь атрибутов высота и ширины тэга
<img>. Слишком большие CSS- и JS-файлы, залинкованные со страницы. Излишне сложный и громоздкий исходный HTML-код.Последствия: Если ваша страница слишком долго грузится/отображается, то это может заставить многих пользователей не дождаться завершения и закрыть вкладку или нетерпеливо обновлять страницу. Иногда излишне долгое ожидание загрузки может привести к возникновению ошибок.
Как избежать: Не думайте, что раз интернет из года в год становится быстрее, то это оправдывает раздувание размеров страниц. Вместо этого оптимизируйте свои проекты ради ускорения обмена сетевыми пакетами. Основная причина, по которой страницы становятся «тяжёлыми», — изображения. Чтобы минимизировать их влияние:
- Спросите себя, действительно ли необходима вся используемая вами графика? Откажитесь от ненужных графических украшательств. Можно воспользоваться сетевыми инструментами, чтобы определить, какие изображения нуждаются в дополнительном сжатии.
- Уменьшите размер изображений. Например, с помощью Shrink O’Matic или RIOT.
- Используйте предзагрузку. Это не ускорит первичную загрузку, но зато даст преимущество при просмотре других страниц сайта. Подробности можно почерпнуть из статьи: https://perishablepress.com/3-ways-preload-images-css-javascript-ajax/
Миницифируйте залинкованные CSS- и JS-файлы. Для этого есть множество инструментов, например, Minify CSS и Minify JS.
И наконец, старайтесь использовать наиболее современную версию HTML и внимательно используйте тэги
<style> и <script>.Создание кода, который должен работать
Ошибка: Тестирование проекта на сервере и развёртывание без последующей проверки, работает ли он после этого. Хотя сайт работал без ошибок, потому что его тестировал сам разработчик.
Последствия: Без нормального тестирования развёрнутых сайтов может случиться так, что пользователи столкнутся с весьма неприятными ошибками. Мало того, что сайт может работать совершенно некорректно, так ещё могут появиться лазейки для хакеров.
Как избежать: Необходимо принять как данность, что людям свойственно ошибаться. В том числе и вам. Если вы пишете на 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 облегчает управление библиотеками и фреймворками.
* * *
Бывает, что даже достаточно опытные веб-разработчики допускают какие-то из вышеописанных ошибок. И важно не только знать, чего нужно избегать, но и понимать возможные последствия тех или иных неверных решений. Это позволит упростить и облегчить процесс разработки, создавая действительно качественные и приятные в использовании сайты.
Комментарии (63)
imgrey
25.09.2015 12:47-341. Использование PHP
vitektm
25.09.2015 13:26Когда в «студиях» на «своем движке» на каждой странице повторно грузится фоновая графика\логотипы
Когда текст со страница лень вставить в текстовый редактор и проверить на ошибки.
И вообще есть ошибки в дизайне, есть ошибки в безопасности кода, есть ошибки в навигации и логике\структуре сайта.
Но часто писакам, влом читать как надо и как не надо. И они думают что если они прочитали статью 10 ошибок… то все. По каждой тематике порой не одна книга написана. Суть конечно можно ужать.
Все проблемы обычно от-того что всем занимается 1 человек или ему в один прекрасный момент пофиг что он делает говно! Некоторым пофиг сразу. (они сразу не читают и не хотят знать как нужно\лучше\правильно)
Но идея подачи проблема\последствия\Решение правильная имхо. (Но материал подан поверхностно (это не упрек))
jamepock
25.09.2015 13:41+13Ругать PHP конечно мейнстрим и все такое, но на нем написано достаточно много всего, и язык продолжает развиваться и активно использоваться.
P.s. Замечено было, что зачастую фразу «PHP — говно» кидают люди, никогда не кодившие на PHP, а просто потому что ругать PHP — модно.
grossws
25.09.2015 14:13+4Замечено было, что зачастую фразу «PHP — говно» кидают люди, никогда не кодившие на PHP, а просто потому что ругать PHP — модно.
Или трогавшие php3 в конце 90х и, возможно, 4 пых в начале нулевых. И пых того времени — говно, хотя и был несколько удобнее того же perl'а для cgi.
DieSlogan
30.09.2015 15:05+1В нашу организацию влилась молодая и талантливая команда дизайнеров и веб-программистов. По текущему проекту платежной системы их первое предложение было — ууууу, у вас все на Java, а давайте перепишем все на PHP!
Проблема PHP, как впрочем и любого другого языка, заключается в людях, которые пишут на там где не надо. Такие люди обычно изучают PHP и считают, что всё, дальше уже некуда, на кой черт изучать что-то новое, если все или почти все можно на PHP написать?grossws
30.09.2015 15:44Это другая сторона вопроса. Некомпетентность и узкий кругозор — это всегда боль для окружающих. Примера ради, когда пихают стек EE куда не надо, тоже получается совсем не конфетка.
Другое дело, что среди php'шников очень много некомпетентного народа, если брать абсолютные цифры. Просто засчёт низкого порога вхождения и его массовости.
priv8v
01.10.2015 10:39Да просто он везде нужен в мелком вэбе. Нужен мелкий сайт. На чем его делать? На PHP, конечно. Брать готовый двиг? Он тоже на PHP. Хочешь — не хочешь, а хоть немного его знать придется чтобы где-то что-то поправить, дописать и т.д
Сайт-визитку для небольшой конторы за пару вечеров любой веб-мастер широкого профиля сделает — хостинга бесплатного хватит, 500р (максимум) на домен, двиг бесплатный залил, шаб где-то взял и чуть подправил. Все, готово, давайте деньги.
skey
25.09.2015 12:56Со всем согласен, но не понял как совместимо использование bower, который упоминается в конце, и пункт о минимизации CSS/JS.
И кстати, адаптивный дизайн не панацея. Я бы ставил на мобильную версию.grossws
25.09.2015 14:14+1Я бы ставил на мобильную версию.
Главное, чтобы был переход на полноценную версию, то очень хочется убивать, когда невозможно с мобильника использовать какой-нибудь критичный функционал.
dom1n1k
25.09.2015 16:17+1Я бы ставил на мобильные версии только в случае сложных сервисов, типа соцсетей. Там очень сложные и развесистые интерфейсы, и если делать их адаптивно, они получатся очень тяжелыми и избыточными. Для мелких и большинства средних сайтов адаптивность — оптимальный выбор.
gifted
25.09.2015 21:17По первому пункту, это вообще не проблема, к примеру в генераторе gulp-webapp сразу при установке компонента, в html автоматически подключаются пути к js и css, а при билде это все склеивается и минимизируется, там правда возникают порой неожиданные проблемы, но все решаемо
priv8v
25.09.2015 13:01Ошибка: Страницы, наполненные полезным контентом, но совершенное недружественные к поисковикам. Не внедрены специальные возможности для слабовидящих пользователей.
А это вы как ухитрились в одну ошибку запихнуть такие никак не связанные друг с другом вещи?
zodchiy
25.09.2015 13:12+2применяют span или div в случаях, когда более уместны иные, более подходящие к содержимому тэги;
А можно подробнее? Строчный и блочный контейнеры, что может быть проще и безобиднее? Как их можно использовать не по назначению?jamepock
25.09.2015 13:42+1Может не в тему, но я когда-то видел пример таблицы, сверстанной div-ами. Причина такого решения до сих пор загадка.
xaja
25.09.2015 14:12Вполне возможная причина — адаптивный дизайн. На маленьких экранах таблица «разваливается» на другую сетку.
SelenIT2
25.09.2015 14:45+4table, thead, tfoot, tbody, tr, th, td { display:block }— и хоть обадаптируйся. Разве таблицы виноваты, что разработчик не знает CSS?dom1n1k
25.09.2015 16:18К сожалению, на практике там всплывают нюансы :) Но в общем и целом решение верное, да.
SelenIT2
25.09.2015 16:24А где можно узнать про нюансы поподробнее?
dom1n1k
25.09.2015 17:06Нюанс в том, что таблица перестает быть таблицей и превращается в гору дивов.
Она теряет табличное поведение, выраженное в том, что ячейки в строке будут всегда иметь одну высоту, а в столбце — одну ширину.
Если данные в таблице гарантированно «красивые», это не составляет очень большой проблемы, но если у нас есть вероятность прихода «нетипичных» данных (очень длинная строка, например) — всё может рассыпаться. Нужно очень внимательно за этим сделить и тщательно тестировать верстку на разных данных.SelenIT2
25.09.2015 17:44Так это и делается, чтобы избавиться от табличного поведения и сделать ячейки гибкими, а дальше крутить как хочется. Если нужно сделать двухколоночную таблицу с остатками табличного поведения, можно извернуться как-то так: codepen.io/SelenIT/pen/epBOMP
dom1n1k
26.09.2015 02:38Я понимаю, что это ожидаемое поведение. Имеется в виду, что в реальных задачах оказывается, что совладать с этой псевдо-таблицей бывает значительно сложнее, чем казалось на первый взгляд в теории. А если там ещё и rowspan/colspan есть — вообще туши свет.
Приём с дополнительными атрибутами интересный, да.SelenIT2
26.09.2015 12:38+1С rowspan/colspan, согласен, много путаницы (ждем CSS Grid Layout, который сможет с ними —и не только — справляться). А в примере я хотел показать не столько дополнительные атрибуты (они-то не новость), сколько сохранение вертикальной двухстолбцовой структуры благодаря
tr { display: table-row-group; } td { display: table-row; } td::before { display: table-cell; } /* :) */
leMar
26.09.2015 08:19>> Может не в тему, но я когда-то видел пример таблицы, сверстанной div-ами
Вы увидели bootstrap.
.container>.row>.col
table>tr>td
alekciy
27.09.2015 23:33В стародавние времена… таблица отрисовывалась только после получения закрывающего теги. Дивы это финт ушами для данного, неактуального в наши дни, случая.
SelenIT2
28.09.2015 08:55Насколько помню, table-layout:fixed исправлял это даже тогда. А мозилла (к сожалению, не помню, какая, возможно, просто-мозилла-не-файрфокс 1.6:) и без пинков отображала таблицы постепенно (раздражая пользователя «скачками» контента).
alekciy
28.09.2015 09:07Ну я тут откапал свою старые опыты: "Не очевидные истины. Скелет страницы таблицей. Неправильно." и на сколько я вижу проблемы это не решало. Более того, сейчас посмотрел еще раз в последних лисе и хроме под убунтой и таки там страница в итоге отрисовывается на 14-16 секунде только. Причем отчего-то оба варианта.
SelenIT2
28.09.2015 09:48ЕМНИП, браузер грузит код блоками (обычно по 8 кБ, в стародавние времена, ЕМНИП, было по 2) и отображает только по завершении блока. Так что эксперимент будет представительнее, если напихать в ячейки килобайт по 10 простого текста.
Finesse
25.09.2015 14:03+2Имеется ввиду, что span и div лишены семантического смыслы. В некоторых случаях лучше заменить их на более «значимые» тэги, например, address, nav, header и т.д…
AlexKeller
25.09.2015 14:06+3Вероятно, имелось в виду, что нужно использовать не только DIV, но и FOOTER, HEADER, SECTION, ASIDE, NAV; не только SPAN, но и ABBR, CITE и т.д.
dom1n1k
25.09.2015 16:20+1Более подходящие — видимо, имеются в виду теги типа ul/li, strong/em, dt/dd и так далее.
xargon
25.09.2015 13:20+9Понадергаем рекомендаций из прошлого десятилетия, смешаем теплое с мягким, и получим данную статью. Браво.
Finesse
25.09.2015 13:57Объясните объективно, чем div'ы в сочетании с «display: table;» плохи для создания макета? В HTML нет ни одного тега, предназначенного для создания колонок (недавно появился flex-layout, но он поддерживается не всеми браузерами). В этом плане табличная вёрстка наравне с float, «display: inline-block;» и «position: absolute;».
AlexKeller
25.09.2015 14:08Ну как минимум margin-ы у элементов с display: table-cell работать не будут. Зачем городить огород, если все можно обычными флоатами сделать
Finesse
25.09.2015 14:14+1Зато работает padding, суммарная ширина колонок всегда будет 100% и ни одна колонка никогда не съедет вниз. У каждого из описанных подходов свои плюсы и минусы, лучший определяется контекстом. Ладно, использование — это неверная семантика. Но почему вдруг «display: table;» стал запретным, не понимаю.
SelenIT2
25.09.2015 14:57+2Да не стал он запретным (кроме как у
упороупрямых фанатиков). Он так и не стал модным из-за того, что раньше мешали старые IE, а когда перестали — появились более модные и крутые (а в Хроме, говорят, еще и более быстрые) флексбоксы. Но иногда бывают случаи, когда он уместнее их.
Под запретом (и то частичным, в спеке W3C предусмотрена «индульгенция» в видеrole="presentation") только нецелевое использование самого<table>.Finesse
25.09.2015 15:08Понятно. Флексбоксы поддерживаются начиная с IE10, поэтому пока, к сожалению, рано использовать его в вёрстке публичных страниц.
SelenIT2
25.09.2015 15:12+2Часто можно подключать их в порядке прогрессивного улучшения, при необходимости подпирая старые IE альтернативами. Думаю, не будет большой трагедии, если десяток-другой пользователей ископаемого софта на ископаемом железе увидит страницу в облегченном мобильном виде, в одну колонку…
SelenIT2
25.09.2015 14:53+1А зачем городить огород с флоатами (которые еще надо clearfix-ить или изолировать в своем контексте форматирования, и у всех вариантов свои ограничения), если можно поставить display:table-cell и сразу решить задачу, получив бонусом равную высоту колонок?
grossws
25.09.2015 14:06+3Странно, что в контексте «У меня в браузере всё работает» даже не упомянут normalize.css.
Finesse
25.09.2015 14:08+7Некоторые советы настраивают на неверный подход к обеспечению безопасности. Например:
«Неважно, как это будет сделано на стороне браузера, главное, чтобы на сервере были уже проверенные данные.»
На сервер можно отправить какие угодно данные, код на клиенте от этого никак не спасёт. Просто с самого начала, разрабатывая серверную часть, привыкайте не доверять данным, пришедшим с клиента. Всегда проверяйте их на сервере.
Phizio
25.09.2015 23:06+2я бы назвал эту статью Десять ошибок разработчиков для министерства образования ;) недавно маман попросила ей работы на конкурс скинуть, так это ахтунг. мало того, что сайт явно указывал, что единственным браузером, в котором он будет хорошо работать — это ie, мол даже не смейте заходить к нам с других кофеварок… так в общем чтобы разобраться с их 'юзабилити' и загрузить три фото + описание работы, разгадать как оплатить заявку, итп — ушло несколько часов. Теперь троллю её, что она попала в тройку, потому что очень мало кто смог загрузить свои работы )) не для обычных людей уж точно
Andruhon
26.09.2015 13:41+1Я бы сказал, что это ошибки старого разработчика. Те, кто начал работать недавно и не в курсе что такое «вёрстка таблицами».
SelenIT2
26.09.2015 15:21+1Бывают еще начавшие работать недавно самоучки, учившиеся по старым книгам. Плюс масса ископаемого барахла со вредными советами (и его более новые репосты) в Сети, которое новички еще не научились фильтровать…
hiddenman
27.09.2015 21:50Напомнили мне про мой первый (и единственный) сайт, который я делал за деньги компании отца в 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 и насладитесь «шедевром». По сути, только раздел Контакты заполнен и Копировальная техника)hiddenman
27.09.2015 22:13За деньги для компании, в смысле. Помню, вроде бы $50 заплатили и я купил себе свой первый пейджер. Сайт еще немного обновлялся, на archive.org нашел, но у себя уже не найду исходники.
Сейчас вспомнил еще, что в те времена успевал невероятно много всего делать, откуда время бралось? За год или два столько всего изучил, столько всяких проектов сделал для Fido, BBS-ок и прочего. А сейчас не успел оглянуться — год прошел — а я так и сижу, читаю какие-то тупые статьи в интернете так ничего и не сделав.hiddenman
27.09.2015 22:25Чтобы неправильно не поняли — тупая — это я про всякие новости непонятно о чем и т.д. А эта статья полезная.
kaichou
28.09.2015 10:20+1> Последствия: Использование HTML десятилетней «свежести» может привести к излишнему усложнению разметки страницы
На практике чаще всего наблюдается строго обратная ситуация.
vlreshet
ИМХО, это ошибки скорее не «начинающего» разработчика, а плохого разработчика который ляпает лишь бы как мотивируя это тем что «работает же!». Любой начинающий веб-разработчик в начале первой же попавшейся книги или статьи увидит список по типу «жмите стили, скрипты, картинки — тестируйте код — валидируйте формы — тестируйте во всех браузерах», и т.д. Это ж прописные истины.