Http www w3 org 2000 svg: W3C SVG Working Group

Содержание

html — Для чего применяются и на что влияют xmlns и xmlns:xlink в svg?

Чем отличаются? Обязательно ли их использовать?

html
вёрстка
xml
svg
xmlparser

Рассмотрим вопрос на практическом примере, где в шапке SVG файла нет объявления пространства имён xmlns:xlink="http://www.w3.org/1999/xlink"

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" 
      viewBox="0 0 400 400" >  
<symbol>
<rect x="50" y="50" rx="15"  />
</symbol>
 <use xlink:href="#rect" /> 
   <use xlink:href="#rect" x="150" />
</svg>

Если этот SVG код добавлен в HTML, то современные браузеры, включая Edge и IE11 выполнят его без сообщения об ошибке. Для примера, сниппет этого сайта вполне успешно воспроизводит различной сложности svg код, без добавления пространства имен xlink.
Если этот SVG код сохранить, как файл с расширением — *.svg и запустить его в браузере, то получим сообщение об ошибке:

Chrome

Firefox

Если указать вместо xlink:href="#rect только href="#rect сообщения об ошибке парсера XML в этих браузерах не будет.

Почему так происходит? SVG2, в готовящемся к публикации стандарте W3C xlink:href объявлен не желательным, устаревшим (depricate)

Но слишком долго внедряется этот стандарт и некоторые браузеры поторопились внедрить его в свои движки.

Но safari, например не принимает href, для него валидна только xlink:href запись svg версии 1.2

Что делать, чтобы ваш SVG код был рабочим во всех браузерах?

Пока браузерные войны не закончились, пока не внедрён стандарт SVG2 лучше указывать дополнительно и «ссылочное» пространства имен xmlns:xlink="http://www.w3.org/1999/xlink". Можно сохранить для себя шаблон шапки SVG файла и начинать с него создание нового SVG кода:

    <svg version="1.1" xmlns="http://www.w3.org/2000/svg" 
       xmlns:xlink="http://www.w3.org/1999/xlink"
          viewBox="0 0 400 400" >  
       </svg>

Для кроссбраузерного решения можно писать или старую форму записи xlink:href или комбинированный вариант:

<use xlink:href="#rect" href="#rect"" />

xlink в svg нужен, чтобы делать ссылки (как href) из svg: https://ru.

wikipedia.org/wiki/XLink

В каждом svg — не нужен.

svg — стандарт основанный на xml (оформляется по правилам xml). xlink — другой стандарт основанный на xml.

xmlns… — это xml-ное использование пространства имен

xmlns:xlink="http://www.w3.org/1999/xlink" говорит о том, что ниже будет иметься ввиду xlink стандарт, который предложен организацией w3.

Вася имеет право придумать свой способ http://vasya.tk/xlink для описания котиков (который основан на xml). Коля имеет право придумать свой стандарт для описания зоопарка, и в одном из описаний сослаться на способ Васи:

<zoo xmlns:xlink="http://vasya.tk/xlink">
  <xlink:cat xlink:food="fish" />
  ...

И все в демократичном мире xml все поймут, какой где xlink имелся ввиду.

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Масштабируемая векторная графика (SVG) 2

Аннотация

Эта спецификация определяет функции и синтаксис масштабируемого Векторная графика (SVG) версии 2. SVG — это язык, основанный на XML для описания двухмерная векторная и смешанная векторно-растровая графика. Содержимое SVG можно стилизовать, масштабируется до различных разрешений экрана и может просматриваться отдельно, смешивается с содержимым HTML или внедряется с использованием пространств имен XML в другие языки XML. SVG также поддерживает динамические изменения; скрипт можно использовать для создания интерактивных документов, а анимацию можно выполнять с помощью декларативных функций анимации или с помощью сценария.

В этом разделе описывается состояние этого документа на момент его публикации. Этот документ может быть заменен другими документами. Список текущих публикаций W3C и последнюю редакцию этого технического отчета можно найти в указателе технических отчетов W3C по адресу https://www.w3.org/TR/.

Этот документ является кандидатом в рекомендации

SVG 2 от 04 октября 2018 г. . Эта версия SVG основан на втором издании SVG 1.1. за счет повышения удобства использования и точности языка. В приложении «Изменения» перечислены все изменений, которые были внесены с момента второго издания SVG 1.1.
Публикация в качестве рекомендации-кандидата не подразумевает одобрения членами W3C. Этот документ является проектом и может быть обновлен, заменен или устаревшим другими документами в любое время. Неуместно ссылаться на этот документ как на незавершенную работу.
Ожидается, что эта Рекомендация-кандидат будет преобразована в Предложенную рекомендацию не ранее 4 декабря 2018 года.

В настоящее время предварительный отчет о внедрении отсутствует. Рабочая группа SVG работает над набором тестов для SVG2 и планирует подготовить отчет о реализации на основе этих тестов.
Приветствуются комментарии к этой рекомендации-кандидату. Комментарии могут быть подняты как проблемы GitHub (предпочтительно) или, в качестве альтернативы, отправить [email protected], общедоступный список адресов электронной почты по вопросам, связанным с векторной графикой в Интернете. Этот список заархивировано и отправители должны согласиться на то, чтобы их сообщение было публично заархивировано из их первая публикация. Для подписки отправьте письмо на [email protected] с на слово

подпишитесь в теме письма.
Спецификация включает ряд аннотаций, которые рабочая группа использование для записи ссылок на протоколы собраний и резолюции, где конкретные решения о возможностях SVG. Различная окраска также используется для обозначения зрелость различных разделов спецификации:
красный фон указывает на раздел, который не изменился со времен SVG 1. 1 (и поэтому все еще требует пересмотра и возможного переписывания для SVG 2) или раздел, который является новым, но все еще требует существенной работы

желтый фон указывает на проверенный раздел из SVG 1.1. и переписанный при необходимости, или новый раздел, полный и готовый для остальной части рабочей группы для рассмотрения
белый фон указывает на раздел либо из SVG 1.1, либо новый для SVG 2, проверенный рабочей группой и готовый для более широкого обзора
Этот документ был подготовлен Рабочая группа W3C SVG как часть графическая активность в домен взаимодействия W3C. цели рабочей группы W3C SVG обсуждаются в Устав SVG W3C. Рабочая группа W3C SVG поддерживает общедоступную веб-страницу, https://www.w3.org/Графика/SVG/, который содержит дополнительную справочную информацию. Авторы этот документ являются участниками рабочей группы SVG.
Этот документ был подготовлен группой, работающей в рамках патентной политики W3C. W3C ведет общедоступный список раскрытий информации о патентах. сделанные в связи с результатами деятельности группы; эта страница также включает инструкции по раскрытию патента. Лицо, имеющее фактическую информацию о патенте, который, по его мнению, содержит существенные пункты формулы изобретения, должно раскрыть информацию в соответствии с разделом 6 Патентной политики W3C.
Список текущих рекомендаций W3C и других технических документов можно найти по адресу https://www.w3.org/TR/. публикации W3C могут быть обновлены, заменены или устаревшими другими документами в любое время.
Этот документ регулируется технологическим документом W3C от 1 февраля 2018 года.
Все функции в этой спецификации зависят от реализации в браузерах. или авторские инструменты. Если функция не обязательно будет реализована, мы определяем эта функция как «под угрозой». Функции, находящиеся под угрозой, будут удалены из текущего спецификации и могут быть включены в будущие версии спецификации. Если функция, подверженная риску, особенно важна для авторов SVG, эти авторы рекомендуется давать обратную связь исполнителям относительно ее приоритета. следующие функции находятся под угрозой и могут быть удалены в течение периода CR:
Более одного «заголовка» или «описания» для обеспечения локализации
‘масштабирование и панорамирование’
Вложенные ссылки
«неизвестных» элементов и интерфейс SVGUnknownElement.
параметры векторного эффекта, отличные от немасштабируемого штриха
Благодарности
Рабочая группа SVG благодарит следующих людей за внося свой вклад в эту спецификацию с помощью исправлений или участвуя в обсуждениях что привело к изменениям в документе: Дэвид Дэйли, Эрик Иствуд, Ярек Фокса, Дэниел Холберт, Пол ЛеБо, Роберт Лонгсон, Генри Мэнсон, мс2гер, Кари Пихкала, Филип Роджерс, Давид Збарский.
Кроме того, рабочая группа SVG хотела бы отметить вклад редакторов и авторов предыдущих версий SVG — большая часть текста в этом документе получена из этих более ранние спецификации – в том числе:
Патрик Денглер, Microsoft Corporation (версия 1. 1, второе издание)
Джон Феррайоло, бывший Adobe Systems (версии 1.0 и 1.1, первое издание; до 10 мая 2006 г.)
Энтони Грассо, бывший Canon Inc. (версия 1.1, второе издание)
Дин Джексон, бывший W3C (версия 1.1, первое издание; до февраля 2007 г.)
藤沢淳 (FUJISAWA Jun), Canon Inc. (версия 1.1, первое издание)
Наконец, рабочая группа SVG хотела бы отметить очень много людей, не входящих в рабочую группу SVG, которые помогают с процесс разработки спецификаций SVG. Эти люди слишком многочисленные, чтобы перечислить индивидуально. Они включают, но не ограничиваются ранние разработчики языков SVG 1.0 и 1.1 (включая средства просмотра, средства разработки и транскодеры на стороне сервера), разработчики Контент SVG, люди, внесшие свой вклад на [email protected] и [email protected] списки адресов электронной почты, другие рабочие группы на W3C и команда W3C. SVG 1.1 — это действительно совместная работа рабочая группа SVG, остальная часть W3C, а также общественность и преимущества во многом благодаря новаторской работе первых разработчиков и содержанию разработчиков, отзывы общественности и помощь команды W3C.
Расположение имен в пространстве имен XML
Статус этого документа
Этот документ был подготовлен Группа технической архитектуры W3C (TAG). Этот вывод решает проблему TAG имяSpaceState-48. TAG одобрила этот вывод на своем Телеконференция 3 января 2006 г. Дополнительные выводы TAG, как в утвержденном, так и в черновом состоянии, также может быть доступным.
Пожалуйста, присылайте комментарии по поводу этого вывода в общедоступный архив TAG список рассылки [email protected] (архив).
Условия ДОЛЖНЫ , СЛЕДУЕТ , и НЕ СЛЕДУЕТ использовать в этом документе в соответствии с [RFC 2119].
Пожалуйста, присылайте комментарии по поводу этого вывода в общедоступный архив TAG список рассылки [email protected] (архив).
1 Предисловие
Пространства имен представляют собой механизм распределенного управления именами, значительно снижает вероятность того, что две независимые стороны создадут одно и то же имя для разных целей.
Пространство имен XML имеет имя пространства имен (URI) и набор локальных имен (NCNames как определено в [Пространства имен XML]). Использование URI использует понятный URI механизмы распределения [WebArch Vol 1]. [XML Namespaces] определяет синтаксическое сокращение для комбинации имени пространства имен и локального имени: полное имя или «QName». (Обратите внимание, что языки, использующие QName в качестве идентификаторов необходимы для обеспечения сопоставления QNames с URI.)
Предложение определить новое местное имя « id » в пространство имен « http://www.w3.org/XML/1998/namespace » ( xml: пространство имен ) поднял вопрос об идентичности пространства имен. Конкретно, он выявил две точки зрения:
Одна точка зрения заключалась в том, что xml: пространство имен состояло из xml:space , xml:lang и xml:base (и никаких других имен) потому что был момент времени, когда те, где только трое имена из этого пространства имен, которые имели определенное значение.
Другой точки зрения было то, что пространство имен xml: состояло из всех возможные местные имена и что только конечное (но гибкое) число они определены в любой данный момент времени.
В просторечии мы часто говорим о «добавлении имени» в пространство имен. Здесь мы предпочитаем говорить об «определении имени» или, иначе, о лицензировании. толкование имени. Например, [xml:id] Спецификация определяет значение локального имени «id» в xml: пространство имен . Точно так же пространство имен, созданное для хранения имена всех зарезервированных слов в языке программирования будут лицензировать интерпретацию этих QNames без явного определения каждый из них.
2 Определения пространства имен
Публикация [xml:id] как Рекомендация, дал частичный ответ на вопрос о том, какая перспектива правильный. Добавление определения локального имени « id » в xml: пространство имен продемонстрировало, что количество локальных имен определено в xml: пространство имен может быть расширено.
Остается, однако, вопрос, является ли другая позиция когда-нибудь звучать. Это Нахождение занимает положение, которое оно есть.
Пространства имен, изначально предназначенные для предоставления имен элементам XML и атрибуты, были гораздо более широко приняты в Интернете сообщество. Теперь они используются не просто для элементов и атрибутов но для имен функций, токенов и идентификаторов всегда больше целей.
Пространство имен xml: демонстрирует, что некоторые пространства имен воспользоваться политикой, позволяющей определять в них дополнительные имена через некоторое время. Это не исключает возможности того, что некоторые пространства имен выиграют от политики, запрещающей такое расширение. Из этих наблюдений мы делаем вывод, что следующая передовая практика применяется:
Надлежащая практика
Спецификации, определяющие пространства имен ДОЛЖЕН явно указать свою политику в отношении к изменениям в именах, определенных в этом пространстве имен.
No related posts.