Нажимаю на ссылку на дополнительный материал и дополнение к информации-меня возвращает на первую страницу лекции. Подскажите, что делать? Или дополнительный материал платный? |
Приложение B: Замечания относительно Исполнения, Разработки и Дизайна
Сценарии
Синтаксис, зарезервированный для будущих макросов сценариев
Эта спецификация резервирует синтаксис для поддержки в будущем макросов скриптов в атрибутах HTML CDATA. Замысел в том, чтобы атрибуты устанавливались в зависимости от свойств объектов, появившихся ранее на странице. Синтаксис таков:
attribute = "... &{ macro body }; ... "
Текущая практика для макросов сценариев
Тело макроса состоит из одного или более операторов на языке сценариев по умолчанию (как и у внутренних атрибутов событий). Точка с запятой перед правой скобкой необходима всегда, поскольку иначе символ " } " рассматривается как часть тела макроса. Нужно также отметить, что кавычки всегда необходимы для атрибутов, содержащих макросы сценариев.
Атрибуты CDATA обрабатываются так:
- Разборщик SGML вычисляет все мнемоники SGML (напр., ">").
- Затем макросы сценариев вычисляются машиной скриптов.
- Наконец, результирующая строка символов предаётся приложению для последующей обработки.
Обработка макросов имеет место при загрузке документа (или перезагрузке), но не происходит при изменении размера документа, перерисовке и т.п.
Фрэймы
Поскольку нет гарантии, что имя целевого/target фрэйма уникально, можно попробовать описать существующую практику поиска фрэйма, установленного как целевой:
- Если имя целевого фрэйма является зарезервированным словом, оно применяется как описано.
- Иначе выполните первичный поиск в иерархии фрэймов в окне, содержащем ссылку. Используйте первый фрэйм, имя которого совпало точно.
- Если в (2) такой фрэйм не найден, примените шаг 2 к каждому окну, в порядке спереди-назад. Остановитесь сразу, как только найден фрэйм с именем, совпадающим точно.
- Если в (3) такой фрэйм не найден, создайте новое окно и назначьте ему целевое имя.
Доступность
Инициатива W3C по Доступности Вэб - Web Accessibility Initiative ( "[WAI]" ) даёт серию рекомендаций по повышению доступности Web для людей с ограниченными физическими возможностями. Есть три блока рекомендаций:
- Web Content Accessibility Guidelines ( "[WCGL]" ) - для авторов и менеджеров сайтов. Пожалуйста, проконсультируйтесь в Web Content Accessibility Guidelines о том, как применять альтернативный текст для изображений, аплетов скриптов и т.д.
- User Agent Accessibility Guidelines ( "[UAGL]" ) - для разработчиков пользовательских агентов (ПА) (браузеров, мультимедиа плэйеров, технологий-помощников). Пожалуйста, используйте эти рекомендации как руководство по обработке альтернативного текста.
- Authoring Tool Accessibility Guidelines ( "[ATGL]" ) - для разработчиков авторских утилит.
Безопасность
Якоря, внедрённые изображения и др. элементы, содержащие URI, как параметры могу модифицировать URI в ответ на действия пользователя. В этом случае, необходимо рассмотреть вопросы безопасности в "[RFC1738]" , раздел 6. Широко используемы методы отправки данных формы - HTTP и SMTP - не гарантируют конфиденциальности. Провайдеры, запрашивающие частную информацию с помощью форм, - особенно через элемент INPUT, type="password" - должны быть уверены, и убедить своих пользователей, в конфиденциальности передачи информации.
Вопросы безопасности форм
ПА не должны пересылать все файлы, запрашиваемые пользователем. Таким образом, HTML ПА должны требовать подтверждения обработки любых файлов, которые могут быть запрошены в атрибуте value элемента INPUT. Скрытые элементы управления не должны специфицировать файлы.
Эта спецификация не содержит механизма шифровки данных; это должно выполняться каким-либо другим механизмом шифровки передачи данных.
Как только файл загружен, ПА должен обработать и сохранить его соответствующим образом.