Comments 68
Но мы можем сделать ход конем и добавить SVG на страницу с помощью iframe или object:
Главное — смотреть, чтобы при этом этот SVG не порезался каким-нибудь АдБлокером
Зачем iframe и object, если SVG можно вставлять напрямую в HTML?
А зачем писать CSS в отдельных файлах, если можно оформлять элементы прямо в HTML?)
- Мы делаем код красивее и лаконичнее.
- Отделяем струкруту документа от изображений.
Не обязательно их "руками" вставлять, пусть это делается при сборке.
Это понятно. Когда есть возможность, можно все автоматизировать. У нас на одном из проектов использовался js скрипт, который вытягивал исходный код SVG из тега <img /> и вставлял на страницу. Но, в любом случае, это идет во вред размеру страницы или производительности. Иногда это заметно, а иногда нет.
Если вариант с iframe проще и он работает, то почему бы его не использовать?
Если вариант с iframe проще и он работает, то почему бы его не использовать?
Вы хотите сказать, что iframe с SVG лучше по размеру или производительности, чем тот же SVG, вставленный в HTML?
iframe — нет, object — да.
Почему?
Потому что
короче, чем
<object data="icon.svg" type="image/svg+xml"></object>
короче, чем
<iframe frameborder="0" src="icon.svg">
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg id="Layer_1" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="0 0 17 15" enable-background="new 0 0 17 15" xml:space="preserve">
<defs>
<rect x="3" y="5" width="5" height="4">
<rect x="9" y="5" width="5" height="4">
<rect x="3" y="10" width="5" height="4">
<rect x="9" y="10" width="5" height="4">
<path d="M11,0C9.9,0,9,0.9,9,2H8c0-1.1-0.9-2-2-2C4.9,0,4,0.9,4,2s0.9,2,2,2l2.5,0L11,4c1.1,0,2-0.9,2-2S12.1,0,11,0 z M7,3H6C5.4,3,5,2.6,5,2s0.4-1,1-1c0.6,0,1,0.4,1,1V3z M11,3h-1V2c0-0.5,0.4-1,1-1c0.5,0,1,0.5,1,1S11.5,3,11,3z">
</svg>
</iframe>
Но ведь лишний запрос на сервер, да и в SVG есть use, правда не уверен, что shadow dom позволяет для него CSS писать.
Если у нас много повторяющихся иконок на странице, мы сделаем только 1 запрос и сильно сократим код.
symbol и use вам помогут, если есть цсс анимации — тогда беда (обсуждали в предыдущих темах)
Можете написать подробнее или дать ссылку на пример?
Определяете иконки в одном шаблоне через symbol, а потом многократно используете через use со своими стилями. вот тут писали больше подробнее и обсуждали проблему с анимациями (в коментариях).
А вообще, если вы используете джангу не только как жсон апи (что почти наверняка так) то вообще можете подключать иконки инлайном прямо в серверных шаблонах.
А вообще, если вы используете джангу не только как жсон апи (что почти наверняка так) то вообще можете подключать иконки инлайном прямо в серверных шаблонах.
Тоже интересный вариант, хоть и не без недостатков (приходится загружать весь набор иконок на страницу, а он может быть довольно большим).
В любом случае, решение очень интересное, спасибо!
В любом случае, решение очень интересное, спасибо!
Кстати symbol не особо и нужен, ибо можно просто создать группу (g) с id и юзать её.
Можно использовать веб-компоненты и не извращаться с отдельным js, вытягивающим код SVG. И с чего вы взяли, что SVG во внешнем файле это более легкое и производительное решение? В обоих случаях фетчится и рендерится XML, только в случае с внешним файлом вы еще получаете отдельный запрос, как минимум. А еще SVG можно вставлять в CSS, и LESS, к примеру, этот процесс умеет автоматизировать.
Ну если одна иконка используется на странице N раз, то что ещё делать?
HTML5 + CSS3
.dotted {
text-decoration-style: dotted;
}
.wavy {
text-decoration-style: wavy;
}
Это жестоко. Нехватает только text-decoration: blink и text-decoration: marquee
Учтите, что в данный момент работают новые свойства только в Firefox и, частично, в Safari.
…
Надеюсь, описанные здесь вещи показались вам интересными, а кому-то даже пригодятся на практике.
Надеюсь никому и никогда это не пригодится на практике.
На многих сайтах есть псевдоссылки, оформленные с помощь border-bottom: dotted (например, ссылка "Написать комментарий на Хабре"). Разве не логичнее было бы оформить ее через text-decoration: underline dotted, раз уже это ссылка?
text-decoration-style: wavy; тоже вполне может пригодится, дизайны-то бывают разные. В школе мы подчеркивали прилагательные волнистой линией, так почему в CSS у нас не должно быть возможности подчеркнуть прилагательное правильно?
text-decoration-style: wavy; тоже вполне может пригодится, дизайны-то бывают разные. В школе мы подчеркивали прилагательные волнистой линией, так почему в CSS у нас не должно быть возможности подчеркнуть прилагательное правильно?
Потому что wavy переходит ту грань, где уже css начинает управлять дизайнером, а не дизайнер управляет css. То самое, от чего ушли в html, теперь возвращается в css (тег u, например).
Вместо инструмента нам дают готовый кусочек дизайна и это считается нововведением. Отвратительно.
Вместо инструмента нам дают готовый кусочек дизайна и это считается нововведением. Отвратительно.
Не совсем понимаю, почему text-decoration: underline или border-style: dotted — это инструмент, а text-decoration-style: wavy — кусочек дизайна, управляющий дизайнером?
Вы не поделитесь своим инструментом для подчёркивания текста волнистой линией с помощью CSS?
Давайте. Итак, я выступаю против "инструмента для подчёркивания текста волнистой линией", потому что он слишком специализирован.
Соответственно, чтобы расширить специализацию, можно предложить инструмент для подчеркивания текста любым паттерном. Хотя и это слишком узко. Мне бы подошел инструмент для рисования линейных паттернов на любом элементе.
Пожалуйста, вот он: border-image.
Уже сейчас вы можете рисовать волнистые, квадратнистые, и любые другие *истые линии на Ваше усмотрение (http://caniuse.com/#feat=border-image)
Или ждать пока большинство производителей даст вам возможность выбрать из… скольки? четырех? пяти? паттернов (http://caniuse.com/#search=text-decoration-style)
Встречный вопрос — как вы вообще посмели называть text-decoration-style инструментом для подчёркивания текста волнистой линией, если он поддерживается только в Firefox и Safari, в 18.53% браузерах по данным caniuse?
Соответственно, чтобы расширить специализацию, можно предложить инструмент для подчеркивания текста любым паттерном. Хотя и это слишком узко. Мне бы подошел инструмент для рисования линейных паттернов на любом элементе.
Пожалуйста, вот он: border-image.
Уже сейчас вы можете рисовать волнистые, квадратнистые, и любые другие *истые линии на Ваше усмотрение (http://caniuse.com/#feat=border-image)
Или ждать пока большинство производителей даст вам возможность выбрать из… скольки? четырех? пяти? паттернов (http://caniuse.com/#search=text-decoration-style)
Встречный вопрос — как вы вообще посмели называть text-decoration-style инструментом для подчёркивания текста волнистой линией, если он поддерживается только в Firefox и Safari, в 18.53% браузерах по данным caniuse?
text-decoration-style это претендент на "инструмент для подчёркивания текста волнистой линией": https://drafts.csswg.org/css-text-decor-3/#text-decoration-style-property
text-decoration-style это "претендент на инструмент для подчёркивания текста волнистой линией"
кавычку не там поставили.
В любом случае — я против и таких "претендентов", и таких "инструментов", по причинам выше.
кавычку не там поставили.
В любом случае — я против и таких "претендентов", и таких "инструментов", по причинам выше.
Любые инструменты — это новые возможности, что, априори, здорово. А ЗЛО — это то, что из этого сотворит плохой дизайнер или разработчик. Можно и с помощью только одобренных вами инструментов создать люто убогий сайт.
Почему бы нам не получить в распоряжение стандартное средство для подчеркивания ошибок и прилагательных (wavy), глаголов (double), наречий и псевдоссылок (dashed)? Давайте тогда и обычный text-decoration уберем, и будем обычное подчеркивание оформлять только border-ом!
Почему бы нам не получить в распоряжение стандартное средство для подчеркивания ошибок и прилагательных (wavy), глаголов (double), наречий и псевдоссылок (dashed)? Давайте тогда и обычный text-decoration уберем, и будем обычное подчеркивание оформлять только border-ом!
Можно и с помощью только одобренных вами инструментов создать люто убогий сайт.
Можно создать люто убогий сайт вообще без CSS, так что ваш комментарий бесполезен чуть более чем полностью.
Почему бы нам не получить в распоряжение стандартное средство для подчеркивания ошибок и прилагательных (wavy), глаголов (double), наречий и псевдоссылок (dashed)?
Потому что настолько специализированные стандарты не работают. Вот не работают и все, никто это не будет использовать. Доказано Web 1.0 сайтами.
Внезапно. Спасибо, буду знать про товарища
border-image
.Имхо, text-decoration-style: wavy лучше чем border-image: url(wavy.png). Зачем нам картинки, если того же самого можно добиться CSS-ом?
Наверное затем, что картинку можно кастомизировать, а это подчёркивание (пока что) нет. Более того — подобную картинку можно перегнать в base64. Я конечно понимаю, что 100 символов base64 картинки 5х5 пикселей больше 4х для "wavy", но с другой стороны инструмент намного гибче. Именно по-этому браузеры\стандарты имеют в последнее время развиваться в сторону теневого DOM, когда куча монолитных элементов могут разбиваться на тучу кастомизированных примитивов.
Так что я соглашусь — подобное подчёркивание — зло, но не столь серьёзное, как монолитные инпуты или селект. С другой стороны никто же не мешает забить на этот wavy и грузить ту же самую картинку.
Так что я соглашусь — подобное подчёркивание — зло, но не столь серьёзное, как монолитные инпуты или селект. С другой стороны никто же не мешает забить на этот wavy и грузить ту же самую картинку.
Они на разных уровнях находятся. border — под базовой линией. Так что неравная замена. wavy нужно для подчёркивания ошибок.
В том-то и дело, что JS необязателен, если мы перематываем страницу к якорям стандартными средставами HTML (<a href="#some-block"></a>).
Если же мы все-таки используем js, нам не нужно заморачиваться описыванием работы анимации. Мы только указываем, куда прокрутить страницу.
За полифил спасибо, пригодится)
Если же мы все-таки используем js, нам не нужно заморачиваться описыванием работы анимации. Мы только указываем, куда прокрутить страницу.
За полифил спасибо, пригодится)
Меня, скорее всего, сейчас заминусуют, но всё-таки зачем этот пост?
С SVG можно поступить так:
- все svg помещаются в папку, с помощью плагина gulp-svg-sprite автоматически собирается спрайт
- в "разработческом" html подключаем спрайт и ссылаемся на его элементы (плагин gulp-file-include).
Например:
<div class="infographics_svg_sprite" style="display: none;">>@@include('../symbol/svg/sprite.symbol.svg')</div> ... <svg> <use xlink:href="#britain_digits"/> </svg>
- собираем итоговый html. Вот он-то и будет захламленным, но поскольку код мы пишем не там, то нам будет всё равно.
Да, со сборщиками все куда проще, но ведь размер итоговой html страницы тоже имеет значение.
Вы привели хороший пример, но вариант с iframe мне тоже кажется интересным. Если он работает, то почему бы и нет?)
Вы привели хороший пример, но вариант с iframe мне тоже кажется интересным. Если он работает, то почему бы и нет?)
Имхо, количество запросов критичнее размера страницы.
Зависит от самой страницы.
К примеру, на странице с лентой новостей много повторяющихся иконок (поделиться, комментировать, количество просмотров и т.д. ). В случае с object, мы получим 1 запрос на каждую картинку и гораздо меньше итогового кода.
К сожалению, для стилизации SVG нет идеального метода. Приходится выбирать меньшее из зол.
К примеру, на странице с лентой новостей много повторяющихся иконок (поделиться, комментировать, количество просмотров и т.д. ). В случае с object, мы получим 1 запрос на каждую картинку и гораздо меньше итогового кода.
К сожалению, для стилизации SVG нет идеального метода. Приходится выбирать меньшее из зол.
> text-decoration сразу несколько значений (причем это работает уже очень давно)
But then
> text-decoration-color
> text-decoration-style
WTF! Неужели такое свойство «работает уже очень давно», а я верстал блядские псевдоссылки и нестандартное подчеркивание через border-bottom
> новые свойства только в Firefox и, частично, в Safari
Okay
But then
> text-decoration-color
> text-decoration-style
WTF! Неужели такое свойство «работает уже очень давно», а я верстал блядские псевдоссылки и нестандартное подчеркивание через border-bottom
> новые свойства только в Firefox и, частично, в Safari
Okay
Какая-то подборка вредных советов…
1) Text-decoration ладно, может быть полезным, но раз пока нет поддержки в Chromium, то и говорить не о чём.
2) За плавную прокрутку карать. Бесит везде, где появляется.
3) С новой строкой куда проще будет
1) Text-decoration ладно, может быть полезным, но раз пока нет поддержки в Chromium, то и говорить не о чём.
2) За плавную прокрутку карать. Бесит везде, где появляется.
3) С новой строкой куда проще будет
.break:after {
content: '';
display: block;
}
1) ПОКА нет. Можете считать это анонсом. Знать, какие свойства появятся в будущем лишним не будет.
2) За что карать? Мне вот нравится понимать, куда проматывается страница по отношению к тому месту, где я находился.
3) C display: block могут быть проблемы, если рядом есть элементы с float. Мне кажется, растягивание псевдоэлемента на всю ширину может быть чревато другими последствиями. Правильнее будет просто перенести текст на новую строку, вместо того, чтобы разделять текст блоками.
2) За что карать? Мне вот нравится понимать, куда проматывается страница по отношению к тому месту, где я находился.
3) C display: block могут быть проблемы, если рядом есть элементы с float. Мне кажется, растягивание псевдоэлемента на всю ширину может быть чревато другими последствиями. Правильнее будет просто перенести текст на новую строку, вместо того, чтобы разделять текст блоками.
а в HTML лезть не хочется (или невозможно),
но всё равно без того, что бы лезть в html не получится сделать. В примере нужно слово обрамляется классом, что не сделаешь без того, чтобы не лезть в html.
Разумеется!
Подразумевалось, что у нас есть возможность обратиться к нужному месту через селектор.
Подразумевалось, что у нас есть возможность обратиться к нужному месту через селектор.
Но мы можем сделать ход конем и добавить SVG на страницу с помощью <iframe> или <object>
А можно просто "полифил" сделать. Например вот так:
var styles = document.querySelectorAll('svg style')
for (var i = 0, l = styles.length; i < l; i++) {
document.head.appendChild(styles[i])
}
Селектором svg styles мы.не сможем обратиться к стилям в файле SVG, если он вставлен через <img/>. Иначе мы бы просто обращались к нужным элементам в SVG через наш основной CSS.
Можно немного модернизировать ваш полифил, чтобы он сначала вытаскивал исходный код из удаленной SVG и заменял им <img/>, но это грузное решение.
Можно немного модернизировать ваш полифил, чтобы он сначала вытаскивал исходный код из удаленной SVG и заменял им <img/>, но это грузное решение.
Я для SVG использую такой JQuery код:
Он автоматом заменит все
на
, которые можно видоизменить через css и класс .name
/*
* Replace all SVG images with inline SVG
*/
jQuery('img.svg').each(function(){
var $img = jQuery(this);
var imgID = $img.attr('id');
var imgClass = $img.attr('class');
var imgURL = $img.attr('src');
jQuery.get(imgURL, function(data) {
// Get the SVG tag, ignore the rest
var $svg = jQuery(data).find('svg');
// Add replaced image's ID to the new SVG
if(typeof imgID !== 'undefined') {
$svg = $svg.attr('id', imgID);
}
// Add replaced image's classes to the new SVG
if(typeof imgClass !== 'undefined') {
$svg = $svg.attr('class', imgClass+' replaced-svg');
}
// Remove any invalid XML tags as per http://validator.w3.org
$svg = $svg.removeAttr('xmlns:a');
// Replace image with new SVG
$img.replaceWith($svg);
}, 'xml');
});
Он автоматом заменит все
<img class="name">
на
<svg>
, которые можно видоизменить через css и класс .name
А картинки так не будут дважды с сервера запрашиваться? Один раз — как src тега img, второй — через $.get.
И если одна картинка на странице встречается 10 раз, то 10 одинаковых запросов на сервер уйдёт?
И если одна картинка на странице встречается 10 раз, то 10 одинаковых запросов на сервер уйдёт?
Да, нам тоже так пришлось делать в свое время. И это решение нам очень не нравилось из-за своей грузности (было заметро, что новые SVG-шки загружались секунды через 2-3 после загрузки страницы).
и не слово про
хотя тоже самое появление элемента с opacity:0; до opacity 1; делает так же плавно как и animation или fadeIn()...
P.S что-то маловато frontend-хитростей…
transition
хотя тоже самое появление элемента с opacity:0; до opacity 1; делает так же плавно как и animation или fadeIn()...
P.S что-то маловато frontend-хитростей…
с SVG проблема в том, что стили для него удобно определять в общем CSS документе, а вставлять его в код неудобно. а если добавлять его как IMG то он не будет управляемым (не появится в DOM как набор свойств)
часто работаю с SVG и нашёл для себя такое решение:
https://github.com/svgdotjs/svgdom
https://github.com/iconic/SVGInjector
эти две библиотеки позволяют манипулировать SVG как обычным элементом.
svgdom делает это через JQuery (с этой библиотекой вы работаете с SVG как с обычными HTML элементами)
а SVGInjector открывает все ссылки img с классом inject-me и заменяет их на код из SVG. в инициализации выполнить:
часто работаю с SVG и нашёл для себя такое решение:
https://github.com/svgdotjs/svgdom
https://github.com/iconic/SVGInjector
эти две библиотеки позволяют манипулировать SVG как обычным элементом.
svgdom делает это через JQuery (с этой библиотекой вы работаете с SVG как с обычными HTML элементами)
а SVGInjector открывает все ссылки img с классом inject-me и заменяет их на код из SVG. в инициализации выполнить:
var mySVGsToInject = document.querySelectorAll('img.inject-me');
SVGInjector(mySVGsToInject);
Sign up to leave a comment.
Несколько неочевидных frontend-хитростей