Объектная модель JavaScript

Большинство объектно-ориентированных языков (например, Java и C++) основаны на двух базовых понятиях: классы объектов и экземпляры (instances) объектов.

• Класс объектов — это абстрактное понятие, описывающее все свойства данного класса (в Java эти свойства называются полями и методами, а в C++ членами класса, но суть от этого не меняется).
• Экземпляр объекта — это реализация класса, т. е. конкретный объект, наделенный всеми свойствами данного класса.

JavaScript, в отличие от этих языков, основан на прототипах и не проводит различия между двумя приведенными понятиями: в нем есть только объекты. Некоторым аналогом класса здесь выступает прототип объекта, который определяет начальный набор свойств нового объекта. В процессе выполнения программы объект может получать новые свойства; более того, он может сам выступать в качестве прототипа при создании новых объектов.

JavaScript в сравнении с Java

JavaScript и Java схожи в одном и фундаментально различаются в другом. Язык JavaScript напоминает Java, но не имеет строгого статического контроля типов. JavaScript во многом наследует синтаксис выражений, правил именования и базовых управляющих структур Java, что послужило основанием переименования его с LiveScript в JavaScript.

JavaScript	Java
Объектно-ориентированный. Нет различий между типами объектов. Наследование осуществляется через механизм прототипов, а свойства и методы могут добавляться в любой объект динамически.	Базирующийся на классах. Объекты разделяются на классы и экземпляры классов с наследованием посредством иерархии классов. Классы и их экземпляры не могут иметь свойства и методы, добавляемые динамически.
Типы переменных не объявляются (динамическое определение).	Типы переменных должны быть явно определены (статическое определение).
Не может автоматически записывать на жесткий диск	Не может автоматически записывать на жесткий диск

 

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

Лет 15 тому назад для того, чтобы сделать шрифт надписи покрупнее и покрасить буквы красным, любой веб-мастер написал бы прямо в HTML-коде вот что: <fontsize="+1" color="#ff0000">очень важная надпись</font>. И оказался бы совершенно прав, ибо других способов добиться желаемого не существовало в принципе. Сегодня же за такое сразу выдают чугунную медаль за профнепригодность.

Лет 10 тому назад реализация эффекта «перекатывания» кнопок меню навигации не обходилась без JavaScript. Спецификация CSS2 уже даже была рекомендацией W3C, но это мало кого трогало — в распространенных на тот момент браузерах она толком не работала.

Лет 5 тому назад такую штуку, как изменение расположения и нюансов внешнего вида блоков на странице в зависимости от ширины окна браузера, можно было сделать только при помощи JavaScript. Сегодня уже можно пользоваться для этих целей возможностями MediaQueries — одного из модулей CSS3. Пока, правда, осторожненько так, но, думаю, в ближайшие пару лет во всех вменяемых браузерах будет реализована адекватная поддержка этого великолепия.

 

Важнейшие аспекты концепции веб-стандартов

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

Семантика

В верстке понятие семантичности разметки означает внимательное отношение к смысловой нагрузке тех или иных структурных единиц при написании кода. Существует несколько уровней использования семантики.

1) На базовом уровне речь идет об использовании элементов HTML-разметки строго по их прямому назначению.

К примеру, структурную единицу, по смыслу являющуюся заголовком первого уровня, необходимо размечать тегом <h1> и только им — другие элементы разметки для этого не подходят по своему назначению. Верно и обратное: использовать тег <h1> надлежит для разметки только и только такого элемента, смысловая роль которого — заголовок первого уровня.

Обычно заголовок первого уровня — это заглавие документа в целом, и такой элемент употребляется на странице в единственном экземпляре. Хотя спецификации HTML отнюдь не запрещают использование множественных элементов <h1> — ну, это к вопросу о духе и букве.

2) Следующий уровень — грамотное именование классов и идентификаторов элементов HTML-разметки. Названия этим классам и идентификаторам следует назначать в соответствии со смысловой нагрузкой соответствующих элементов. Широко распространенная в среде разработчиков практика отталкиваться в именовании классов и идентификаторов от особенностей визуального представления элементов, с точки зрения духа веб-стандартов, является глубоко ошибочной и порочной.

Предположим, дизайн некоторого сайта предполагает использование цветового выделения дат публикации свежих новостей в блоке с информацией о текущих обновлениях. Скажем, оранжевым. Казалось бы, ничто не мешает нам разметить соответствующие элементы примерно следующим образом: <spanclass="orange">07.06.2011</span>, определив стилевые правила для класса orange в CSS-коде. А теперь представьте, что спустя некоторое время нам захотелось модифицировать цветовую схему новостного блока — ну, допустим, изменить выделение дат публикации новостей с оранжевого на синее. Конечно, можно было бы оставить код разметки в покое, заменив только соответствующее стилевое правило, но в таком случае старое, неактуальное уже название класса станет противоречить здравому смыслу и вносить лишнюю путаницу — по-хорошему, код разметки тоже надо поправить. А вот если бы мы сразу поименовали соответствующий класс в соответствии с его смысловой нагрузкой — ну, например, как-то вроде newsdate, — описываемой проблемы не возникло бы в принципе.

Кстати, в HTML5 для разметки информации о дате и времени предусмотрен специальный элемент <time>. Так что, при использовании в верстке сайта именно HTML5, совсем правильным было бы применение для обсуждаемых целей вот этого самого элемента <time> вместо семантически нейтрального <span>.

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

3) На еще более высоком уровне семантики речь заходит о возможности наделять те или иные элементы какими-либо дополнительными метаданными, облегчающими возможную машинную обработку контента, уже сверх уровня обычной HTML-разметки. Примерами соответствующих технологий являются микроформаты, Microdata и RDFa. В целом в среде веб-стандартистов нет однозначного мнения о том, что дополнительная семантика — это вот прямо такая позарез жизненно необходимая штука и вообще единственный путь к спасению. По мнению некоторых специалистов, есть и более насущные материи, требующие более внимательного отношения, нежели микроформаты.

Валидность

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

В случае с веб-разработкой следование букве спецификаций веб-технологий уберегает разработчиков от потенциальных неприятных неожиданностей, связанных с их собственными ошибками. От неожиданностей, вызванных, предположим, ошибками реализации стандартов в браузерах — конечно, не убережет. Но подкрепленная отчетом валидатора уверенность в том, что при разработке было предусмотрено все возможное хотя бы только со своей стороны — это уже само по себе великое дело. Формальное соответствие HTML- и CSS-кода веб-страниц спецификациям W3C можно проверить онлайновыми валидаторами разметки и таблиц стилей (о некоторых подобных сайтах мы расскажем в практической части нашей работы).

Если разработчик относительно консервативен и не выходит в процессе разработки за рамки спецификаций, уже официально утвержденных в качестве рекомендаций W3C (речь идет, например, о сочетании XHTML 1.0 Strict и CSS2.1), в идеале ему необходимо стремиться доводить код до полностью валидного состояния. Тут все, в общем-то, предельно ясно.

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

Как тут поступить? В плане проверки валидности проблем почти нет — онлайновые валидаторы на сайте W3C уже давно научились понимать HTML5 (почти в полной мере) и CSS3 (при этом наблюдается ряд проблем, но баги отслеживаются и исправляются).

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

CSS3 развивается несколькими десятками отдельных модулей, находящихся в разных стадиях проработки (так, CSS ColorModuleLevel 3 уже получил, в один день со спецификацией CSS2.1, статус рекомендации). Особенность процесса развития CSS такова, что спецификация того или иного модуля CSS3 не имеет шансов на утверждение в качестве рекомендации в сколько-либо обозримые сроки до тех пор, пока не появится несколько полных не противоречащих друг другу реализаций данного конкретного модуля в основных браузерах.

Потенциальной возможностью пересмотра тех или иных разделов «сырых» спецификаций порождена необходимость в первое время использовать экспериментальные свойства и значения CSS с вендорными префиксами — например, -moz- (для MozillaFirefox), -webkit- (для браузеров на основе движка Webkit — в частности, Chrome и Safari), -o- (для Opera). Применение конструкций CSS, использующих вендорные префиксы, конечно же, с формальной точки зрения автоматически делает соответствующие таблицы стилей невалидными, но этот «костыль нового поколения» — во всех отношениях разумное и удачное решение, против которого ничего не имеют ни W3C, ни сообщество веб-стандартистов. К слову, у упоминавшегося CSS-валидатора с сайта W3C даже есть опция проверки таблиц стилей с учетом использования вендорных префиксов.

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

Для старых версий IE, пользуясь условными комментариями, веб-разработчики подключают таблицы стилей, содержащие порой та-а-акиехардкорные хаки — и ничего, живем… Нормальным браузерам и валидатору все, что скрыто за условными комментариями, безразлично. Ну да, конечно, это не верх изящества, а вполне себе костыль — но ничего лучше пока не придумали. Абсолютно валидные как в плане разметки, так и в плане стилей страницы, отображающиеся в IE6 не хуже, чем в остальных браузерах, возможны, но их внешний вид напомнит вам о начале века.

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