Пользователь
0,0
рейтинг
15 июля 2010 в 17:37

Дизайн → К вопросу о кроссбраузерном использовании SVG

Для векторной графики в Интернете формат SVG — самое то. Во-первых, он поддерживает масштабирование любой степени. Во-вторых, можно обращаться к любым составляющим элементам такой картинки — адресовать их, стилизовать и скриптовать. В-третьих, за исключением совсем маленьких файлов, этот формат выигрывает по компактности перед любыми растровыми представлениями, особенно если применить gzip-сжатие. В-четвёртых, сие есть стандарт W3C.

Но как поместить SVG-картинку в HTML-документ?

Как вставить SVG в HTML



Известно, что есть три способа:

  • непосредственно в код (но — увы и ах! — IE этот способ не приемлет, да и остальные браузеры допускают лишь в XHTML-документе, что не всегда возможно);
  • в плавающий фрейм iframe (это я даже пробовать не стал, считая фреймы устаревшим злом);
  • через тег object (вот этим приёмом и займёмся).


Первый сюрприз нам преподносит… угадайте, какой браузер? Ну, конечно, это IE не даёт скриптовать встроенную посредством тега object SVG-картинку и заливает белым её прозрачный фон! К счастью, он предоставляет свой проприетарный тег embed для этих целей. Посредством условных комментариев и управлением стилями можно легко и валидно добиться, что нормальные браузеры будут отображать SVG через object-элемент, а IE — через embed. Но будет ли?

Второй сюрприз: не будет, пока мы не установим плагин — например, Adobe SVG Viewer. Правда, Adobe, вроде бы, прекратила его поддержку с 1 января 2009 г., но уже сделанного пока что должно хватить, да и, в конце концов, есть ещё RENESIS Player 1.0 for Internet Explorer и Ssrc SVG Plugin. Кроме того, как ни разобижена Microsoft за свой VML, с коим W3C её кинул в 1999 г., ввести нативную поддержку SVG её уламывают такие авторитеты как Google и Wikimedia Foundation. Обнадёживающая новость, что «Microsoft подала заявку на вступление в рабочую группу развития формата SVG в организации W3C» на Хабре уже обсуждалась. Так что тут есть все основания для оптимизма.

Далее. В описаниях тега embed во множестве мест в Интернете можно прочитать, что у него есть такой замечательный атрибут pluginspage, указывающий адрес, по коему, якобы, «будет направлен пользователь в том случае, если его браузер не поддерживает SVG-графику».

Не верьте! Это — третий сюрприз: в реальности IE игнорирует сей атрибут.

А чтобы заставить его работать, существует весьма малоизвестный (судя по тотальному отсутствию ссылок в тематических материалах в Интернете) хитрый способ с применением скриптов на JScript и VBScript. В принципе, ничего страшного, но об этом нужно знать.

Модернизация решения Adobe



Решение это, однако же, не вполне хорошо. Во-первых, оно не валидно, во-вторых, рассчитано на какие-то допотопные браузеры, коими уже никто не пользуется, но, в-третьих, не работает с современными браузерами (строго говоря, оно вообще не работает в том виде, в каком дано). Однако, основная идея решения верна, поэтому попытаемся сделать его работоспособным и современным.

Для начала, есть проблема вот с этой строчкой:

<script language="JavaScript"><!-- checkAndGetSVGViewer(); // --> </script>


Функция в ней не выполняется, если только мы не перенесём её вызов на новую строчку. Только в XHTML экранирование будет выполняться ещё сложнее, посему вынесем-ка мы вызов функции во внешний скрипт:

<script language="JavaScript" src="viewSVJ.js"></script>


Идём дальше. Нынешний код считает, что Firefox, Chrome и Safari для отображения SVG нуждаются в плагине, а Opera в этом отношении вообще безнадёжна. Однако, Opera имеет нативную поддержку SVG с версии 8.0 (19 апреля 2005 г.), Firefox — с версии 1.5 (30 ноября 2005 г.), Safari — с версии 3.0 (11 июня 2007 г.), а Chrome — с рождения (2 сентября 2008 г.). Фактически, все ухищрения нужны только для «Просмотрщика Интернета», сиречь Internet Explorer, у коего такая поддержка ожидается лишь в 9-й версии.

Тогда все три подключенных скрипта можно скрыть от прочих браузеров в условный комментарий (ну и насчёт языка перестаём притворяться, что это — JavaScript):

<!--[if IE]>
	<script language="JScript" src="svgcheck.js"></script>
	<script language="VBScript" src="svgcheck.vbs"></script>
	<script language="JScript" src="viewSVJ.js"></script>
<![endif]-->


Там, где непосредственно подключается SVG-картинка мы можем заключить рекомендованный код в такой же комментарий, а следом написать что-нибудь такое:

<!--[if !IE]>-->
	<object type="image/svg+xml" data="hello.svg" height="200" width="600"></object>
<!--<![endif]-->


В сумме получается довольно громоздкая конструкция, да ещё смешивающая представление с поведением. На самом деле можно просто написать:

<!--[if IE]>
	<embed src="hello.svg" height="100" width="100" type="image/svg-xml" pluginspage="http://www.adobe.com/svg/viewer/install/">
<![endif]-->
<!--[if !IE]>-->
	<object type="image/svg+xml" data="hello.svg" height="100" width="100"></object>
<!--<![endif]-->


А в подключаемом скрипте viewSVJ.js, если SVG-плагин всё-таки не установлен, будем перебирать элементы embed и заменять их на предупреждения со ссылками:

checkAndGetSVGViewer();
window.attachEvent(
	"onload",
	function(){
		if(window.svgInstalled)//если SVG-плагин установлен
			return;
		var embeds=document.getElementsByTagName("embed");
		for(var embedNumber=0, embedTypeAttr; embedNumber<embeds.length; embednumber++){
			embedtypeattr=embeds[embedNumber].attributes["type"];
			if(embedtypeattr="image/svg-xml" /*MSIE 5*/ || embedtypeattr.value="image/svg-xml")
				embeds[embednumber].outerhtml="<p>To view this page you need an SVG viewer. <a href=\""+getSVGInstallPage()+"\">Click here</a> for more information.</p>";
		}
	}
);


Но HTML-код всё равно выглядит чрезмерно раздутым. Ведь условный комментарий с элементом embed надо писать для каждой SVG-картинки, а ссылки на несколько скриптов (и тоже с условным комментарием) — для каждой содержащей их страницы! Конечно, существует шаблонизация, но… Вдобавок, эти скрипты замусоривают глобальное пространство имён, а лезть разбираться в их устаревший код не хочется.

Укротим сперва скрипты. Будем цеплять к странице один скрипт fixSVG.js, где для IE напишем свою ветку, в которой будем подгружать в динамически созданный плавающий фрейм (да, я фыркал по их адресу, но это же решение для браузера, который пока лучшего и не заслужил!) скрипты от «Эдоуби» (Adobe); выполнять с их помощью проверку на наличие установленного SVG-плагина; если он не установлен, подменять картинки на соответствующие уведомления со ссылкой; и, наконец, удалять этот фрейм (чистоты страницы ради). Детали реализации смотрим ниже.

Наконец, от тяжеловесной конструкции на месте каждой картинки можно избавиться, если пожертвовать браузером IE с установленным SVG-плагином, но отключенным JScript. Я склонен решительно пожертвовать. Всем известно, насколько этот браузер требует костылей для соблюдения стандартов, так что если человек отключает в нём скрипты, он молчаливо соглашается видеть Интернет «условно».

Можно писать просто:

<object type="image/svg+xml" data="hello.svg"></object>


Впрочем, если кому-то вышеописанный вариант дорог, как память, можно и так:

<object type="image/svg+xml" data="hello.svg">Для просмотра этой страницы нужен <a href="http://www.adobe.com/svg/viewer/install/">SVG viewer</a>.</object>


Затем для IE мы должны подменять элемент object на элемент embed, если SVG-плагин установлен, и на уведомление со ссылкой, если он ещё не установлен.

В заголовочной части страницы, как уже указано, пишем:

<script type="text/ecmascript" src="fixSVG.js"></script>


Файл fixSVG.js выглядит так (с использованием уже скриптового условного комментария):

/*@cc_on
	if(@_jscript_version<9)
		window.attachEvent(
			"onload",
			function(){
				var iframe=document.createElement("iframe");
				iframe.src="js/fixSVG_IE_5-8.html";
				document.body.appendChild(iframe);
			}
		);
@*/


Содержимое fixSVG_IE_5-8.html, подгружающееся в динамически созданный плавающий фрейм:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
		<title>Fix SVG for IE 5-8</title>
		<script type="text/jscript" src="svgcheck.js"></script>
		<script type="text/vbscript" src="svgcheck.vbs"></script>
		<script type="text/jscript" src="checkSVGViewer.js"></script>
	</head>
	<body></body>
</html>


Скрипты svgcheck.js и svgcheck.vbs — адоубивские, нетронутые. А fixSVG_IE_5-8.js — наш:

checkAndGetSVGViewer();//проверяем наличие SVG-плагина

if(window.svgInstalled){
	var objects=window.parent.document.getElementsByTagName("object");
	for(var objectNumber=objects.length, objectNode, objectTypeAttr, embedNode, codebase, attrNumber, attrNode; objectNumber--;){
		objectNode=objects[objectNumber];
		objectTypeAttr=objectNode.attributes["type"];
		if(objectTypeAttr=="image/svg+xml" || objectTypeAttr.value=="image/svg+xml"){
			embedNode=window.parent.document.createElement("embed");
			embedNode.setAttribute("type", "image/svg-xml");
			embedNode.setAttribute("pluginspage", "http://www.adobe.com/svg/viewer/install/");
			embedNode.setAttribute("wmode", "transparent");//обеспечиваем прозрачность фона
			codebase=objectNode.getAttribute("codebase");
			embedNode.setAttribute("src", ((null===codebase)?"":codebase)+objectNode.getAttribute("data"));
			for(attrNumber=objectNode.attributes.length; attrNumber--;){
				attrNode=objectNode.attributes[attrNumber];
				if(//сюрприз! IE не поддерживает indexOf!
					attrNode.name!="archive" &&
					attrNode.name!="classid" &&
					attrNode.name!="codebase" &&
					attrNode.name!="codetype" &&
					attrNode.name!="data" &&
					attrNode.name!="declare" &&
					attrNode.name!="standby" &&
					attrNode.name!="tabindex" &&
					attrNode.name!="type" &&
					attrNode.name!="usemap"
				)
					embedNode.setAttribute(attrNode.name, attrNode.value);
			}
			objectNode.parentNode.replaceChild(embedNode, objectNode);
		}
	}
}
else
	if(window.svgViewerAvailable){//для проформы (мы знаем, что для IE 5-8 такой плагин есть!)
		var message;
		switch(navigator.browserLanguage.substr(0,2)){
			case "ru":
				message="Для просмотра этой страницы нужен";
				break;
			case "en":
			default:
				message="To view this page you need an";
		}
		var objects=window.parent.document.getElementsByTagName("object");
		for(var objectNumber=objects.length, objectTypeAttr; objectNumber--;){
			objectTypeAttr=objects[objectNumber].attributes["type"];//objects[objectNumber].getAttribute("type")===null!
			if(objectTypeAttr=="image/svg+xml" || objectTypeAttr.value=="image/svg+xml")//тут учтён IE5
				objects[objectNumber].outerHTML="<p>"+message+" <a href=\""+getSVGInstallPage()+"\">SVG viewer</a>.</p>";
		}
	}

window.frameElement.parentNode.removeChild(window.frameElement);//удаляем плавающий фрейм, вызвавший этот скрипт


SVG-графика в Webkit-браузерах



Google Chrome и Safari, однако, обнаруживают две проблемы. Для начала, они не обеспечивают пропорционального масштабирования SVG-картинки в общем случае. 4-е версии для этого требовали, чтобы у элемента svg были заданы атрибуты width и height, а 5-е, напротив, чтобы они не были заданы! Но и при этом масштабирование получается не вполне удовлетворительное.

Вторая проблема серьёзней: если у вставленной через object SVG-картинки прозрачный фон, он заливается белым (это баг! причём очень старый, более чем двухлетней давности — и в 5-х версиях этих браузеров он не исправлен), как и в IE (но там мы можем просто добавить embed-элементу атрибут wmode со значением transparent).

Если использовать не object, а img, то всё отлично, но Firefox пока что такого способа вставки SVG-картинки не понимает. Поэтому пишем в вышеупомянутый файл fixSVG.js скрипт для Webkit-браузеров (смирившись с белым фоном в ненормальной ситуации отключенного Javascript), подменяющий в загруженном документе object с SVG-картинкой на img:

if(/AppleWebKit/.test(navigator.userAgent))
	window.addEventListener(
		"load",
		function(){
			var objects=document.getElementsByTagName("object");
			for(var objectNumber=objects.length, objectNode, codebase, imageNode, attrNumber, attrNode; objectNumber--;){
				objectNode=objects[objectNumber];
				if(objectNode.getAttribute("type")==="image/svg+xml"){
					imageNode=document.createElement("img");
					codebase=objectNode.getAttribute("codebase");
					imageNode.setAttribute("src", ((null===codebase)?"":codebase)+objectNode.getAttribute("data"));
					imageNode.setAttribute("alt", "SVG");//совсем без alt нельзя по стандарту HTML
					for(attrNumber=objectNode.attributes.length; attrNumber--;){
						attrNode=objectNode.attributes[attrNumber];
						if(-1===["declare", "classid", "codebase", "data", "type", "codetype", "archive", "standby", "tabindex"].indexOf(attrNode.name))
							imageNode.setAttribute(attrNode.name, attrNode.value);
					}
					objectNode.parentNode.replaceChild(imageNode, objectNode);
				}
			}
		},
		false
	);


Увы, но на вставленных таким образом картинках перестают работать скрипты, так что решение не универсально!

Вот так. Только помним при стилизации и скриптовании, что в Firefox, Opera и, очевидно, IE 9 будет элемент object, в Safari и Google Chrome (надеюсь, когда-нибудь везде) — img, а в IE 5—8 — embed.

Скриптование внедрённой SVG-картинки



В передовых браузерах получение доступа из HTML-документа к SVG-документу тривиально. По событию load нам оказывается доступен элемент object, на него тоже можно навесить событие load и в его обработчике мы замечательным образом получим искомое. Посредством jQuery это можно было бы сделать примерно так:

$(
	function(){
		$("object#SceletonObject").load(
			function(){
				var SVGDocument=$(this)[0].getSVGDocument();
				…
			}
		);
	}
);


Проблемы возникают в Internet Explorer. В нём мы можем после загрузки страницы получить элемент embed и у него даже уже доступен SVG-документ, но только — вот беда! — он совершенно пуст. Навесить на элемент embed событие load мне не удалось; похоже, оно вообще не поддерживается (впрочем, те из якобы поддерживаемых событий, что я пробовал, тоже не работают).

Кроме того, выяснилась ещё одна подлянка: содержимое таких элементов, как object и embed загружается асинхронно, в отдельном потоке. Это означает, как я понимаю, что, с одной стороны, пока не закончен парсинг основной страницы, элемент ещё недоступен для навешивания на него обработчика события, а когда он закончен — событие загрузки элемента может уже сработать и тогда обработчик навешивать уже бесполезно. Кажется, именно последний случай я периодически наблюдал в экспериментах, не улавливая никакой закономерности в глюке.

Да и по спецификации, кстати, событие load у элемента object отсутствует — оно есть в HTML только у элемента body. Так что то, что оно вообще где-то работает — это неправильно!

Выход найден следующий (не очень элегантный, но… будем ещё думать!): событие load пишем внутри SVG-кода у элемента svg, вызывая оттуда функцию HTML-документа. Как-нибудь так:

<svg xmlns="http://www.w3.org/2000/svg" onload="InitSVG(document);">


Ну, или, чтобы, уж, единообразно работало во всех браузерах:

<svg xmlns="http://www.w3.org/2000/svg" onload="if('InitSVG' in window) InitSVG(document); else parent.InitSVG(document);">


Или даже просто (поскольку parent в окне верхнего уровня указывает на само это окно):

<svg xmlns="http://www.w3.org/2000/svg" onload="parent.InitSVG(document);">


В функции InitSVG мы уже можем получить SVG-документ и из него — все его элементы. Лепота!

Только следует иметь в виду, что работать с SVG-элементами средствами jQuery не получится (может быть, есть какой-то обходной маневр, но мне его раскопать или изобрести пока не удалось и лично я посчитал, что овчинка выделки не стоит). Дело в том, что его функции ожидают получить от метода getElementsByTagName результат типа HTMLCollection, из коего можно отбирать элементы по индексу, как из обычного массива. А тут мы получим (везде, кроме Firefox) результат типа NodeList, из коего элемент можно будет выцепить только посредством особого метода item(индекс). Фреймворк на такое не рассчитывает и обламывается (во всяком случае, так было осенью, когда я с этим экспериментировал). Так что придётся работать непосредственно с DOM-методами, держа кроссбраузерность в уме. Сие напряжно, но возможно.

Два частных наблюдения по скриптованию SVG-документа. Во-первых, обнаружилось, что заданные в нём стили изменять скриптом не получается; всю динамику надо реализовывать через атрибуты (что, конечно, не очень правильно, если речь идёт об оформлении, к примеру, о цветовой заливке — fill). Во-вторых, если у SVG-элемента не стоит никакой заливки, то события mouseover и mouseout срабатывают только на рамке и вполне могут не успеть сработать вообще (к счастью, можно прописать атрибут fill один раз у элемента-предка и он пронаследуется).

Забавно, что этот способ перестал работать локально в Chrome 5.0 из-за каких-то его заморочек с безопасностью. Совсем не забавно, что, как уже указано, в Webkit-браузерах он вообще не работает, если мы используем тег img.

Как отдавать с сервера SVGZ



SVG-графику рекомендуется подвергать gzip-сжатию. Оно и правильно, размер файла тогда может стать в три-четыре раза меньше. Если кому-то, как и мне, не хочется возиться с запускаемой из командной строки утилитой gzip, он может воспользоваться для этой цели не менее бесплатным, но наделённым графическим интерфейсом архиватором 7-Zip (в настройках архивирования обязательно выбрать метод Gzip!).

Заархивировали, сменив расширение с образующегося автоматически .svg.gz на .svgz, после чего с изумлением убеждаемся, что получившийся файл адекватно воспринимают только Opera и Internet Explorer, а Firefox, Safari и Chrome воротят нос, ругаясь на синтаксис XML. Ну, конечно, какой там XML, пока не разархивируешь? А почему, собственно, они не разархивируют?

Оказывается, виноват Apache. До сих пор (версия 2.2.12) он, в конфигурации по умолчанию, посылает браузеру требующийся для SVG-формата заголовок Content-Type: image/svg+xml, но не требующийся для его gzip-ованной версии заголовок Content-Encoding: gzip. Посему лезем исправлять в конфигурацию сервера или просто пишем в файл .htaccess строчку «AddEncoding gzip .svgz».

Встречался мне ещё совет дописывать туда же (ради Firefox) следующее:

<FilesMatch \.svgz$>
	<IfModule mod_gzip.c>
		mod_gzip_on No
	</IfModule>
</FilesMatch>


Возможно, это имеет смысл, если на сервере настроено автоматическое gzip-ование отдаваемых файлов; не знаю.

Недавно я имел по этому вопросу смешные бодания с техподдержкой своего хостера, кои продолжались месяц. Я так понял, что перед Apache там стоит фронт-ендом nginx, что неким образом ограничивает возможность использования директив Apache. Конкретнее, директива AddType срабатывает, а AddEncoding — нет. Разумеется, раздел «Помощь» на сайте провайдера не содержит про эту закавыку ни слова и даже вообще ни единого упоминания про nginx. Техподдержка упорно не хотела мне внимать и выдавать свои тайны, потчуя меня безумными отписками: «Заголовок не отдается, поскольку на сервере не установлен необходимый для
работы директивы AddEncoding модуль Apache Mod_gzip», «За сжатие отвечает nginx, остальные директивы Apache поддерживаются в полном объёме» (неправда, кстати), «Приносим извинения. Передавать формат svgz можно лишь при наличии модуля mod_deflate, который, к сожалению, отсутствует на серверах, используемой Вами услуги» (и тут же предложение купить впятеро более дорогой план!). В конце концов, мне так и не объяснили, в чём у них закавыка, но сдались и стали отдавать правильный заголовок сами.
Олег Торбасов @torbasow
карма
102,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Дизайн

Комментарии (41)

  • +2
    Как вставить SVG в HTML. Известно, что есть три способа:
    Про image src и background-image вы забыли?
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      а скриптовать как?
    • 0
      Во-первых, в статьях, по которым я (когда-то) осваивал SVG, эти способы вообще не назывались, так что не так уж они известны — во всяком случае, не так, как перечисленные. Во-вторых, нет, не забыл; внедрение через тег img в статье всплывает. Забыл только про background-image, как, если уж на то пошло, и про SVG-favicon и про SVG-шрифты. В-третьих, не работает же в моём любимом «Файерфоксе»! Да и в Уэбкит-браузерах работает условно, не скриптуется.
  • 0
    А как на счёт заюзать raphael.js?
    достаточно просто написать скриптик конвертирующий строки из svg в нужный рафаелю формат для отрисовки canvas.
    • +3
      raphael это не canvas.
      • 0
        Cсори перепутал, действительно raphael использует svg и vml(в IE).
    • +2
      Рафаэль — это все же не нативный SVG для IE, там используется VML. Хотя, несмотря на фундаментальность топика, я тоже больше склоняюсь к варианту с Рафаэлем вместо таких вот танцев с поддержкой SVG в осле. ИМХО, заставлять пользователя ставить доп. плагины для чего-то на сайте неправильно с точки зрения юзабилити.
      • –1
        флеш и сильверлайт как-то все поставили и ничего, не подавились
        • +1
          Не подавились — не синоним юзабилити
          • –3
            зато синоним «не так страшен чёрт, как его малюют».
            развелось, блин, юзабилистов… плагин в 2 клика поставить пользователю видите ли сложно, а вот тыкаться в уёбищный поисковик по сайту — легко и просто…
            • –1
              Да иди ты в пень с таким гонором. От такого отношения к пользователям и появляется Виста, вместо МакОС. При чем тут вообще поиск по сайту?
              • –1
                при том, что на подавляющем большинстве сайтов есть куда более серьёзные проблемы с юзабилити, но избирательность мышления заставляет их не замечать.
                а семёрка мне нравится больше макоси, так что сам иди в пень :-Р
                • 0
                  Мы же не про подавляющее большинство сайтов говорим и вообще не о сайтах в целом, а о конкретной технологии. С точки зрения использования SVG-графики на сайте заставлять пользователя только для этого ставить плагин… В общем, благими намерениями сами знаете куда дорога выстлана ;)

                  А на счет 7 — да, она хороша, мне тоже нравится. Лично у меня это первый продукт мелкомягких, который мне понравился в использовании. Но при этом до макоси (с точки зрения именно юзабилити в целом для обычного пользователя, а не гика) винде еще как до луны пешком.
                  • 0
                    один раз поставить плагин и далее наслаждаться жизнью

                    я гик и пользователь. от макоси с её тупыми дизайнерскими ограничителями меня тошнит. я люблю систему подстраивать под себя, а не себя под систему.
                    • –1
                      SVG plugin от Adobe не поддерживается самой Adobe.
                      Читаем:
                      “Please note that Adobe has announced that it will discontinue support for Adobe SVG Viewer on January 1, 2009.”
                      То есть полтора года уже как.
                      Не говоря уже про то, что не всякий пользователь имеет на компьютере достаточно прав чтобы установить плагин.
                      • 0
                        да мне как-то пох, поддерживается он или нет. он работает — этого достаточно.

                        значит они скорее всего и без флеша сидят, который используется на подавляющем большинстве сайтов. ну, что поделать, значит не судьба.
        • +2
          до сих пор обхожусь без силверлайта и жив пока
    • 0
      Сейчас так, наверное, лучше. Но если смотреть на перспективу и рассчитывать на нативную поддержку SVG в 9-ке, то не факт, что стоит связываться с лишней библиотекой и языком VML. Честно говоря, я не знаю, какие тут могут быть подводные камни, но сильно подозреваю, что они могут быть.
  • +2
    насколько же проще создавать svg скриптом:
    var svgDoc = document.implementation.createDocument("http://www.w3.org/2000/svg", "", null);
    var svg = svgDoc.createElementNS("http://www.w3.org/2000/svg", "svg");
    // и добавляем svg куда хотим (внутрь html-элемента)
    
    • 0
      в хтмл зафигачивать его тоже не сложно…
    • 0
      Я так понимаю, это то же самое, что inline SVG (IE против!), но зачем-то Javascript-ом. Не так?
  • +1
    IE9 поддерживает inline SVG.
    • +7
      ie9 ещё не существует %-)
  • +3
    Ну и, кстати, единственная в мире ужималка SVG:

    bolknote.ru/files/svgcrush.phps
  • +5
    Вам не кажется, что геморроя от использования SVG сейчас на порядок больше, чем профита?
    • 0
      Кажется. Но лично я считаю, что это благородный геморрой.

      Впрочем, огромные проблемы возникают только при поиске философского камняуниверсального решения, а частные задачи на моей практике решались вполне гладко.
  • +7
    В этой статье явно не хватает вставленной картинки в формате SVG.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    «Когда в товарищах согласья нет,
    На лад их дело не пойдёт.

    Однажды Лебедь, Рак и Щука
    Задумали сыграть квартет...»

    © Иван Андреевич Крылов
    • 0
      Что ж Вы мою любимую басню так исковеркали? =(
      • 0
        Драматичности для, не хохмы ради…
  • +2
    Отличное исследование.
    Поделитесь тайной, зачем вам понадобилось любой ценой обеспечить поддержку SVG в IE?
    По-моему, гораздо проще еще на этапе прорисовке дать дизайнеру по рукам за элементы, требующие SVG
    • 0
      Нужна была интерактивная схемка со сложными активными областями. SVG, по-моему, вполне подходил (и на практике отлично подошёл). Да и какая тут особо «цена»?
      • 0
        Не очень сложную в свое время решал png и наложенными сверху div'ами:)
        А работало достаточно шустро в итоге, со всеми костылями?
        • 0
          Вполне. Только фактически там был скрипт только для IE. Прозрачность фона была не критична.
  • –1
    слишком громоздко, вот мой вариант: habrahabr.ru/blogs/webdev/99248/
    • 0
      Ах, вот оно что! Атрибут codebase работает так, как предполагалось, что должен работать pluginspage! Спасибо, не знал.

      Кстати: а IE с уже установленным плагином и остальные браузеры по этому адресу не ломанутся?

      Проверил: не ломятся (кстати, почему?). Но происходят странные, тревожные вещи. «Файерфокс» загружает SVG-шку внутрь элемента embed, а IE 8 — в object, причём, конечно, с непрозрачным фоном.
      • 0
        они туда поломятся только если не смогут отобразить

        у меня они ломятся наоборот
  • +1
    А я для SVG внедрения и скриптования пользуюсь jquery.svg.js, брать тут keith-wood.name/svg.html
  • 0
    Спасибо за статью, она мне только что очень помогла. :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.