О моделях поведения элементов
Модели поведения элементов — одна из наиболее значительных новых возможностей браузера Microsoft Internet Explorer 5.5.Они предоставляют возможность определять пользовательские элементы, которые можно использовать таким же образом, как и обычные HTML-элементы на веб-странице. Модель поведения элемента может быть создана в виде скрипта, использующего файл HTML-компонента (HTC), или реализована с помощью двоичной модели поведения динамического HTML (DHTML). Модели поведения элементов — это инкапсулированные компоненты, и они могут добавлять в веб-страницу интересные возможности, улучшая организацию содержимого, функциональность и стиль. Модели поведения DHTML появились в версии Internet Explorer 5 и позволили модифицировать поведение стандартных HTML-элементов путем установки значения атрибута behavior записи в таблице стилей (CSS) или путем использования метода addBehavior в скрипте. Модели поведения DHTML в той форме, в какой они появились в браузере Internet Explorer 5, теперь называются присоединенными моделями поведения, чтобы отличать их от моделей поведения элементов, которые используют другой механизм привязки и имеют другие присущие только им характеристики. Модели поведения элементов можно использовать для реализации чего угодно, начиная от простого эффекта изменения вида при наведении курсора мыши и до сложного интерактивного компонента. Чтобы импортировать модель поведения элемента в веб-страницу, где она синхронно привязывается к пользовательскому элементу, используется специальная инструкция обработки. Как только модель поведения элемента загружена и обработана, она существует в иерархии документа как полноправный элемент и остается постоянно привязанной к пользовательскому элементу. Модели поведения элементов в этом отношении значительно отличаются от присоединенных моделей поведения. Присоединенная модель поведения асинхронно привязывается к элементу и модифицирует его поведение, и ее можно присоединять или удалять программно. Модели поведения элементов привносят несколько улучшений в компонентную модель поведения (Behavior Component Model) в браузере Internet Explorer 5.5. Они предоставляют новые функции в дополнение к существующим возможностям присоединенных моделей поведения, обеспечивая дополнительную устойчивость и надежность. Однако присоединенные модели поведения не вытесняются моделями поведения элементов и остаются полезными во многих сценариях. Особое свойство моделей поведения элементов, называемое viewlink, позволяет инкапсулировать дерево документа в HTC-файл, отделенный от содержимого главной веб-страницы. Это открывает еще одну сферу возможностей, которые отдельно описаны в Обзоре ViewLink. Модель поведения элемента может быть реализована с помощью HTC-файла или двоичной модели поведения динамического DHTML, и используемые приемы в каждом из этих подходов значительно отличаются друг от друга. Эта статья уделяет основное внимание написанию моделей поведения элементов с использованием HTC-файлов. Дополнительную информацию о написании двоичной модели поведения элемента см. в статье Создание двоичной модели поведения элемента с использованием ATL. В этом документе обсуждаются следующие темы.
Терминология В этом разделе определяется терминология, используемая в этой статье.
В этом обзоре основное внимание уделяется моделям поведения элементов, которые для реализации пользовательского элемента используют HTC-файл. Поэтому во всех случаях, когда в этом обзоре используется термин "модели поведения элементов", он не означает реализацию двоичной модели поведения элементов, если не утверждается обратное. Хотя модель поведения элемента и можно использовать для определения пользовательского элемента, это не единственный способ ее использования. Например, присоединенную модель поведения также можно привязать к пользовательскому элементу. Необходимые компоненты Для понимания данного раздела нужно быть знакомым с моделями поведения DHTML и принципами работы HTC-компонентов. Если это новая для вас тема, то для понимания моделей поведения элементов можно изучить документы Введение в модели поведения DHTML и Справочник по HTC, в которых даются необходимые основы. Преимущества Основное преимущество моделей поведения элементов в том, что они позволяют создавать пользовательские элементы, которые можно использовать на веб-странице точно так же, как и стандартные HTML-элементы. Internet Explorer 5.5 был первым браузером, в котором стало можно использовать HTC-файлы для определения пользовательских элементов. Присоединенные модели поведения переопределяют поведение по умолчанию для того элемента, к которому они присоединяются, тогда как модели поведения элементов используются для определения новых элементов. Поскольку модели поведения элементов инкапсулируются в HTC-файл, реализация веб-страницы, использующей пользовательские элементы, организована лучше, и содержимое основного документа может быть гораздо менее загроможденным. Модели поведения DHTML, определенные с помощью HTC-файлов, можно использовать на любой странице в пределах того же домена. Таким образом, модели поведения элементов — это отличный способ создания мощных компонентов, пригодных для повторного использования. Поскольку модель поведения элементов привязывается асинхронно, это означает, что пользовательский элемент инициализируется сразу же, как только завершается его загрузка и разбор. Использование синхронной привязки с моделями поведения элементов делает их равнозначными обычным HTML-элементам с точки зрения их устойчивости и надежности. Устойчивость моделей поведения элементов связана с механизмом привязки. Но как и в случае с любыми другими компонентами, надежность и функциональность модели поведения элемента зависит от качества реализации. Модель поведения элемента не может быть отключена от пользовательского элемента с помощью скрипта или какого-либо иного механизма, что является желаемой возможностью во многих приложениях, использующих модели поведения динамического HTML. Поэтому модель поведения элемента надо рассматривать как вполне настоящий HTML-элемент. Как только выполнен ее разбор и инициализация, она существует в дереве документа как полноправный элемент. В моделях поведения, созданных в виде HTC-файлов, можно реализовать почти все из того, что возможно сделать с помощью бинарных моделей поведения DHTML. Легче реализовать модель поведения элемента в виде HTC-файла, так как функциональность создается в виде скрипта. Уже один этот факт должен приносить облегчение тем, кому не хочется изучать Microsoft Visual C++ для того, чтобы создавать пользовательские компоненты браузера. Кроме того, решение разработчика создавать модели поведения элементов, используя HTC-файлы, не ограничивает существенным образом область действия или функциональность компонента. Бинарные модели поведения DHTML требуются только в следующих случаях: при создании модели поведения при отображении (Rendering Behavior) или если компоненту необходимо использовать службы запросов (Query Services). Проблемы безопасности браузера отчасти упрощаются при использовании HTC-файлов для реализации моделей поведения элементов, в основном потому, что клиент должен разрешить доступ перед тем, как компонент будет загружен в браузер. Когда модель поведения элемента реализована в виде HTC-файла, он загружается автоматически как часть веб-страницы. В результате при просмотре страниц загрузка компонента незаметна для пользователя. Реализация HTC-файлов в Windows Internet Explorer требует, чтобы HTC-файл находился в том же домене, что и основной документ; в противном случае будет отказ в доступе. Разработка мощных интерактивных веб-страниц требует нескольких навыков, и как правило, писатели, программисты и дизайнеры работают над созданием сайта вместе. Раньше традиционный процесс создания означал работу с единым HTML-документом, содержавшим смесь скриптов, содержимого и форматирования. Эта ситуация была результатом популярности HTML, но HTML-файл вряд ли представляет собой идеальное средство для совместной работы команды. Достоинство HTC-файлов в том, что они помогают инкапсулировать содержимое, скрипты и стили в отдельные контейнеры, позволяя каждому специалисту сосредоточиться на конкретных задачах. Появление компонентной модели поведения в версии Internet Explorer 5.5 сделало возможными многие преимущества компонентной разработки веб-страниц. Теперь можно создавать мощные библиотеки HTC-файлов, где код легче в управлении и потребляет меньше памяти. Создание пользовательского элемента Следующие шаги описывают процесс создания пользовательского тега и его использования на веб-странице.
Реализация модели поведения элемента с помощью HTC-файла очень похожа на создание прикрепленной модели поведения. Основное отличие — это реализация компонента в основном документе. Прикрепленные модели поведения привязываются к HTML-элементу с помощью атрибута behavior, которому присваивается значение URL HTC-файла, а в случае моделей поведения элементов привязка делается созданием пользовательского элемента. Определение поведения элемента При определении поведения элемента главная задача — создать HTC-файл. Этот файл использует элемент PUBLIC:COMPONENT. Это обеспечивает контейнер для других элементов, которые определяют интерфейс компонента и устанавливают его свойства по умолчанию. В Справочнике по HTC содержится информация обо всех элементах, которые можно использовать внутри элемента PUBLIC:COMPONENT. Модель поведения элемента использует тег PUBLIC:COMPONENT, чтобы указать имя пользовательского элемента в атрибуте tagName. В следующем примере создается элемент "checkers" ("шашки"). <PUBLIC:COMPONENT tagName="checkers"> </PUBLIC:COMPONENT> В этой каркасной реализации пока не хватает атрибутов для установки внешнего вида доски для шашек, степени игрового мастерства и прочих свойств. Атрибуты пользовательского элемента можно определять с помощью элемента PUBLIC:PROPERTY. В следующем примере в элемент "checkers" добавляется атрибут под названием "boardWidth": <PUBLIC:COMPONENT tagName="checkers"> <PUBLIC:PROPERTY NAME="boardWidth" /> </PUBLIC:COMPONENT> Функция скрипта внутри HTC-файла может быть сделана общедоступной для других компонентов или для скрипта в основном документе. В следующем примере в компонент добавляется элемент PUBLIC:METHOD. Здесь для начала новой партии игры в шашки используется функция newGame. Также добавляется элемент PUBLIC:ATTACH, который назначает функцию "mouseover" обработчиком событий onmouseover. <PUBLIC:COMPONENT tagName="checkers"> <PUBLIC:PROPERTY NAME="boardWidth" /> <PUBLIC:METHOD name="newGame()" /> <PUBLIC:ATTACH event="onmouseover" onevent="mouseover()" /> </PUBLIC:COMPONENT> <SCRIPT Language="Javascript"> function newGame(){ // insert code to initialize a new game here } function mouseover(){ // insert code to handle mouseover events } </SCRIPT> <BODY> </BODY> Чтобы закончить определение поведения, нужно внутрь элемента PUBLIC:COMPONENT добавить элементы для определения остальных методов, свойств и событий для компонента. Готовый компонент "checkers", возможно, будет также включать скрипт для игры в шашки. По завершении, реализация игры в шашки будет полностью инкапсулирована в файле Checkers.htc. Обратите внимание, что реализация компонента для игры в шашки не содержит ссылок на пространство имен; оно объявляется в основном документе, и это объясняется в следующем разделе. Ту же самую модель поведения элемента можно импортировать в несколько пространств имен одного основного документа, и хотя этот прием не используется в примере, он может пригодиться в случаях с другими типами компонентов. Как показано в примере, рекомендуется помещать блоки скрипта после определения PUBLIC:COMPONENT. Также блок скрипта надо помещать или перед тегом <BODY>, или непосредственно перед тегом </BODY>. Дополнительные сведения об использовании тега PUBLIC:COMPONENT с моделями поведения см. в статье Использование HTML-компонентов для реализации моделей поведения DHTML в скрипте. Импорт пользовательского элемента Для импорта пользовательского элемента в основном документе требуются несколько простых дополнений. Сначала в HTML-документе объявляется пространство имен, которое используется для того, чтобы гарантировать уникальность имени пользовательского элемента. Следующий HTML-элемент объявляет пространство имен под названием "games", используя атрибут XMLNS. Установка значения этого атрибута позволяет использовать в основном документе пользовательский элемент с префиксом "games". <HTML XMLNS:games> Следующий этап — импортировать пользовательский элемент в пространство имен. В следующем примере пространство имен "games" импортирует реализацию элемента "checkers" в файле Checkers.htc. <?IMPORT namespace="games" implementation="checkers.htc" > The Директива IMPORT здесь — это ключ к реализации модели поведения элемента в основном документе. Когда браузер начинает обработку директивы IMPORT, он сначала ожидает завершения загрузки содержимого HTC-файла. Способ обработки этой инструкции — это причина того, почему модель поведения привязывается асинхронно к пользовательскому элементу. В конце пользовательский элемент надо поместить в нужное место в теле основного документа. Пользовательский элемент можно использовать так же, как любой другой тег, за исключением того факта, что пользовательский элемент использует в качестве префикса свое пространство имен. Пользовательский элемент для игры в шашки можно определить следующим образом: <games:checkers></games:checkers> Простой пользовательский элемент не требуется определять как блочный элемент, поэтому в этом случае можно использовать также следующую форму. <games:checkers /> Если пользовательский элемент используется без закрывающего тега, как в предыдущем примере, последний атрибут элемента должен быть отделен от завершающих символов Ниже показан полный текст HTML-файла, который реализует элемент "checkers". <HTML xmlns:games> <HEAD> <?IMPORT namespace="games" implementation="checkers.htc" > </HEAD> <BODY> <games:checkers /> </BODY> </HTML> Теперь, когда основные этапы создания модели поведения элемента описаны, можно перейти к более функциональному примеру. Создание тега, изменяющего внешний вид при наведении курсора мыши Этот пример использует модель поведения элемента для создания пользовательского элемента, который реализует эффект изменения вида при наведении курсора мыши. Так обычно делается для текстовых блоков, меняющих вид при наведении на них курсора мыши. Этот эффект используется для того, чтобы дать визуальную обратную связь, показывающую, что элемент можно щелкнуть кнопкой мыши. Хороший способ реализовать простой эффект изменения вида — изменить поведение тега a, используя присоединенную модель поведения, потому что простой эффект изменения вида не оправдывает затраты на создание отдельного пользовательского элемента. Тем не менее, пример демонстрирует некоторые полезные приемы, которые можно легко использовать в более сложных приложениях. Пример использования присоединенных моделей поведения для создания эффекта изменения внешнего вида при наведении курсора мыши см. в статье Использование моделей поведения DHTML. Создание компонента выделения, изменяющего внешний вид при наведении курсора мыши HTC -файл содержит реализацию тега, изменяющего внешний вид при наведении курсора мыши. Тег имеет одно свойство, которое называется "href" и является ссылкой на веб-страницу, на которую переходит пользователь после нажатия кнопки мыши. Для тега требуются обработчики следующих событий:
В следующем примере показано, как создать HTC-файл для тега, изменяющего внешний вид при наведении курсора мыши.
Реализация тега, изменяющего внешний вид при наведении курсора мыши, готова к использованию в основном документе. Создание пользовательского тега, изменяющего внешний вид при наведении курсора мыши В этом разделе показано, как реализовать пользовательский элемент, изменяющий внешний вид при наведении курсора мыши.
Когда указатель мыши наводится на тег, содержащийся в нем текст становится красным, подчеркнутым, а курсор мыши меняется на изображение руки. Когда указатель мыши уводится за пределы тега, курсор снова меняется на изображение стрелки, а текст возвращается к первоначальному состоянию. Если пользователь нажимает кнопку мыши, когда курсор находится на тексте внутри тега, и атрибут "href" определен, загружается URL, указанный в атрибуте "href". Встроенные и блочные элементы По умолчанию модели поведения элементов отображаются в основном документе как встроенные элементы. Чтобы отобразить модели поведения элемента как блочный элемент, необходимо установить стиль показа элемента как "block". Модель поведения элемента в этом примере HTC-файла отображается как встроенный элемент. Скрипт в этом примере устанавливает значение "block" для стиля display мастер-элемента, когда происходит нажатие кнопки мыши на этом элементе. <PUBLIC:COMPONENT TAGNAME="animals"> <PUBLIC:ATTACH EVENT="onclick" ONEVENT="makeBlock()" /> <SCRIPT> //The element behavior renders as an inline element by default. element.innerHTML = "*Element behavior: Click me if you dare."; element.style.cursor = "hand"; element.style.backgroundColor = "orange"; function makeBlock() { element.innerHTML = "Element behavior: Lions and tigers and bears."; //Setting the element's style to 'block' renders it as a block element //in the primary page. element.style.display = "block"; } </SCRIPT> <BODY> </BODY> </PUBLIC:COMPONENT> Основной документ в этом примере содержит фрагмент документа. <HTML XMLNS:ELEMENT> <HEAD> <?IMPORT NAMESPACE="ELEMENT" IMPLEMENTATION="animalBehavior2.htc"> </HEAD> <BODY> <BASEFONT FACE="Verdana" SIZE="4" /> <DIV STYLE="background-color: green; color: white;"> Containing page: The tortoise and the hare. </DIV> <ELEMENT:animals /> <DIV STYLE="font-size: x-small"> <P>*Click the element behavior to change it into a block element.</P> </DIV> </BODY> </HTML> Пример кода: http://samples.msdn.microsoft.com/workshop/samples/author/behaviors/overview/animals2.htm Облегченные HTC-файлы Internet Explorer создает отдельное дерево документа для каждого экземпляра модели поведения элемента в основном документе. Поскольку HTC-файл фактически является документом HTML, при его разборе строится дерево документа для его содержимого. Когда на одной странице собирается большое количество моделей поведения элементов, это приводит к медленной загрузке страницы. Часто есть возможность написать HTC-файл, который вообще не содержит статического HTML. Когда это можно сделать, можно использовать новый атрибут "lightweight" элемента PUBLIC:COMPONENT, чтобы HTC-файл обрабатывался наиболее эффективным способом. Поскольку нет необходимости разбирать облегченные HTC-файлы, создания пустых деревьев документа не происходит. Поэтому в результате использования облегченных HTC-файлов страница загружается гораздо быстрее, особенно когда используется много экземпляров одного и того же пользовательского элемента. Если компонент содержит фрагмент документа и использует функцию "viewlink" для его отображения в основном документе, то HTC-файл обрабатывается эффективно. Во многих случаях применения HTC-файлов модель поведения не требует функции "viewlink" для отображения содержимого, или же содержимое может отсутствовать. В этой ситуации в результате получается излишнее использование памяти, и ситуацию можно исправить, если использовать облегченный компонент. Поэтому везде, где возможно реализовать компонент без собственного дерева документа, нужно реализовывать облегченный компонент, указывая новый атрибут "lightweight" элемента PUBLIC:COMPONENT, как показано в примере: <PUBLIC:COMPONENT tagName="rollover" lightweight = true > </PUBLIC:COMPONENT> Облегченный HTC-файл поддерживает только следующие теги. <PUBLIC:COMPONENT> <?IMPORT> <PUBLIC:PROPERTY> <PUBLIC:METHOD> <PUBLIC:ATTACH> <PUBLIC:DEFAULTS> <SCRIPT> <HTML> Поскольку тег в примере не использует HTML в HTC-файле и может быть использован много раз на обычной веб-странице, здесь можно было бы удачно применить облегченную модель поведения элемента. Пользовательский элемент "checkers" также можно было бы реализовать как облегченный HTC-файл. Хотя облегченные HTC-файлы сами по себе не имеют структуры документа, и поэтому не имеют объекта document, на который можно было бы ссылаться, облегченные HTC-файлы на самом деле могут содержать статический HTML, но в таких случаях содержимое игнорируется. Скрипт в облегченном HTC-файле может использовать метод createElement, чтобы добавить содержимое в основной документ, используя следующий синтаксис: element.document.createElement. Поскольку в облегченном HTC-файле может использоваться инструкция обработки.<?IMPORT>, HTC-файлы могут быть вложенными. Неизменное содержимое Содержимое между открывающим и закрывающим тегами пользовательского элемента может служить многим целям, если его пометить как неизменное содержимое, вместо того, чтобы анализировать и отображать. Разработчик компонента может использовать содержимое пользовательского элемента, манипулировать им или анализировать его любым способом, необходимым для реализации компонента. Когда определяется компонент с неизменным содержимым, то объект innerHTML пользовательского элемента не анализируется и не добавляется в дерево документа, но он доступен через скрипт. Примерами часто используемых элементов с неизменным содержимым в HTML-документах служат теги <SCRIPT> и <XML>. Поведение элемента с неизменным содержимым в можно указать, используя атрибут "literalContent" элемента PUBLIC:COMPONENT: <PUBLIC:COMPONENT tagName="myTag" literalcontent=true > </PUBLIC:COMPONENT> Свойство innerText недоступно для пользовательского элемента, который реализован с неизменным содержимым. Если попытаться установить значение свойства innerText такого элемента, то произойдет ошибка. Если в скрипте попытаться получить значение свойства innerText элемента с неизменным содержимым, то будет возвращено значение null. Для установки и получения неизменного содержимого пользовательского элемента можно использовать свойство innerHTML. Это свойство становится доступным после того, как сработало событие oncontentready. Поэтому в компоненте с неизменным содержимым обработчик, который получает значение свойства innerHTML пользовательского элемента, должен быть присоединен к этому событию. В противном случае произойдет ошибка, означающая, что свойство innerHTML еще недоступно. Событие oncontentsave срабатывает при сохранении, копировании, получении значения свойства innerText, при получении значения свойства innerHTML, или при операции перетаскивания. Таким образом, это событие может пригодиться при создании модели поведения элемента с неизменным содержимым. Хороший пример неизменного содержимого — остров данных XML. Дополнительные сведения см. в статье Острова данных XML Объект defaults Объект defaults используется для установки и получения значений свойств по умолчанию для HTC-файлов. Этот объект также имеет декларативную форму, элемент PUBLIC:DEFAULTS, который используется в разделе определения содержимого HTC-файла для установки начального состояния свойств. Функция "viewlink" устанавливается для модели поведения элемента, когда свойству viewLink присваивается в качестве значения объект, содержащий содержимое документа. Когда функция "viewlink" установлена, значение свойства viewLink ссылается на фрагмент документа. По умолчанию свойство viewLink имеет значение null, которое означает отсутствие фрагмента документа. Дополнительные сведения см. в Обзоре функции ViewLink. Элемент PUBLIC:DEFAULTS имеет несколько атрибутов, которые соответствуют набору свойств объекта defaults. Таким образом, для установки значений свойств можно использовать скрипт или объявления. В следующем примере показано, как можно использовать элемент PUBLIC:DEFAULTS для установки значений свойств стилей CSS по умолчанию для модели поведения элемента: <PUBLIC:COMPONENT tagName="myTag"> <public:defaults style="font-Weight:bold;font-Style:italic" tabStop = "true" > </PUBLIC:COMPONENT> В этом примере также устанавливается значение true для свойства tabStop, это означает, что модель поведения элемента может принимать фокус, в том числе при последовательном переключении фокуса с помощью клавиши табуляции. Доступ к содержимому пользовательских элементов Чтобы получить доступ к содержимому пользовательского элемента, нужно использовать объект element. Скрипт в HTC-файле может получать доступ и изменять содержимое пользовательского элемента посредством ссылки на объект element. element.style.color = "red"; В предыдущем примере цвет текста внутри тега меняется на красный. Доступ к дереву основного документа можно получить из скрипта компонента, используя следующий синтаксис: element.document Если объект document используется сам по себе, он ссылается на объект document HTC-файла. Инициализация компонента Модель поведения элемента привязывается к пользовательскому элементу асинхронно. Поэтому нет необходимости добавлять обработчики событий для проверки того, выполнена ли загрузка и анализ компонента. К тому моменту, когда будет выполняться скрипт компонента, анализ компонента будет сделан. Встроенный скрипт в HTC-файле запускается, как только браузер сможет его запустить, поэтому любая инициализация в этой части скрипта должна применяться только к тем данным, которые не зависят от состояния пользовательского элемента или от какого-либо содержимого основного документа. Когда срабатывает уведомление oncontentready, это означает, что содержимое пользовательского элемента успешно разобрано. HTC-файл должен присоединять функцию к этому событию, если он должен установить значения каких-либо свойств, относящихся к пользовательскому элементу или его содержимому. Также событие oncontentready можно использовать для инициализации функции "viewlink" в скрипте. Когда срабатывает событие ondocumentready, это означает, что документ полностью разобран и дерево документа построено. Если компоненту нужно переходить по структуре основного документа, сюда нужно поместить код, выполняющий инициализацию. Событие ondocumentready уведомляет компонент о том, что вся страница загружена, и оно срабатывает непосредственно перед тем, как событие onload срабатывает в основном документе. Несколько методов, таких как doScroll, требуют, чтобы основной документ был полностью загружен. Если эти методы являются частью инициализирующей функции, они должны выполняться тогда, когда срабатывает событие ondocumentready. Двоичные модели поведения Модели поведения элементов можно создавать также в виде двоичных моделей поведения DHTML, которые обычно пишутся на таких языках, как Visual C++. В этом разделе показано использование двоичных моделей поведения DHTML на веб-странице, но описание процесса их создания выходит за рамки этой статьи. Дополнительные сведения о написании кода двоичных моделей поведения DHTML см. в статье Реализация двоичных моделей поведения DHTML. Следующий пример показывает основной подход к импорту двоичной модели поведения DHTML в основной документ. <html xmlns:mybb> <head> <object id=mytag ... ></object> <?import namespace=mybb implementation=#mytag > </head> <body> <mybb:mytag></mybb:mytag> </body> </html> В этом примере содержится элемент object в разделе <HEAD>, что рекомендуется для двоичных моделей поведения DHTML. Атрибут id имеет значение Инструкция обработки IMPORT может появляться в любом месте HTML-файла, но при реализации двоичной модели поведения важно поместить тег object до инструкции IMPORT. Еще одна причина, по которой тег object находится в разделе заголовка, заключается в том, что тег object не отображает какое-либо содержимое для двоичных моделей поведения DHTML, следовательно он не относится к телу документа. Подразумевается, что любой тег object, не содержащийся в теле документа, содержится в его заголовке. Инструкция обработки IMPORT не является HTML-элементом, она не отображается в основном документе и не является частью дерева документа. Разрешения на загрузку Содержимое в HTC-файле рассматривается, как часть основного документа, таким образом HTC-файлы автоматически загружаются в браузер, и для их загрузки не требуется разрешения пользователя. К HTC-файлу есть одно требование, — он должен загружаться с URL, находящегося в пределах того же самого домена, что и основной документ, иначе произойдет ошибка, отказ в доступе. Дополнительные сведения по вопросам загрузки компонентов см. в Справочнике по HTC и в статье Введение в модели поведения DHTML. Двоичные компоненты отличаются от HTC-файлов в плане безопасности и обычно управляются тем же способом, что и компоненты Microsoft ActiveX. Как правило, они требуют разрешения пользователя перед загрузкой, если не были определены особые настройки безопасности для сайта, содержащего основной документ. Предотвращение проблем с печатью Если модель поведения элемента модифицирует дерево элементов основного документа при помощи скрипта, то при печати страницы содержимое модели поведения элемента может появиться дважды. Таким образом, скрипт, содержащийся в HTC-файле, может выполняться повторно, когда пользователь делает предварительный просмотр этой страницы или печатает ее. Проблем с печатью можно избежать, если заключить скрипт, который модифицирует дерево элементов, в следующий условный оператор: if(document.media != "print") { // script that modifies the element tree goes here } Использование тегов пустых элементов Когда используется тег пустого элемента, такой как
Связанные темы
|
Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.