Красивых логотипов тред

[Gozar]

Я за последнее время понял только одно. Нет лучших решений, есть наименьшее зло!

[ТОТ_САМЫЙ]

Нет лучших решений, есть наименьшее зло!

Ну у меня только один минус, некрасивое использование, то что приходится лезть и прописывать КЛАСС который задаст background-image это не оч красиво и может расходиться с некоторми методологиями верстки.. идеальным решением было бы со стороны браузеров обеспечить поддержку <symbol> нормальную

чтобы можно было писать так: background-image: url(file.svg#logo) и чтобы он от туда только нужное доставал.



Ну а пока есть что есть, по этому я приведу последний раз свои аргументы, и попробуйте их перекрыть:

1) Много svg файлов обединенных в один лучше сжимаются чем каждый из них по отдельности.
2) Один файл грузится быстрее чем мнго маленьких. И на http2 и на http1, потому что сжатые и склеенные svg занимают не более 500 килобайт, а скорость одного потока не успевает за такое время упасть. По этому лучше распараллелить загрузку компонентов сайта, где файл с иконками один "компонент", нежели грузить каждый пук отдельно.
3) Подобное запаковывание svg в css позволяет делать лайврелоад svg без перезагрузки страницы.
4) Тот факт что третий пункт есть в WebPack не означает что не нужно порадоваться что я такой молодец написал плагин еще и на галп, к тому же я возможно напишу и на вебпак плагин.
5) У меня в css инлайнится не base64 кодирование а encodeURIComponent кодирование, оторое меньше весит и лучше сжимается.
6) Заодно плагин делает еще и оптимизацию svg другим плагином.

[kobezzza]

1) Много svg файлов обединенных в один лучше сжимаются чем каждый из них по отдельности.

Ну тут я конечно соглашусь, но с оговоркой, что всё такие "пак", должен быть действительно паком, а не набором принципиально и структурно разных изображений.

Один файл грузится быстрее чем мнго маленьких. И на http2 и на http1

В HTTP2 в рамках одного коннекшена в обе стороны могут обрабатываться множество различных запросов, а сами заголовки будут сжиматься + протокол бинарный, а не текстовый. Т.е. вся возня с оптимизацией ложиться на плечи HTTP серверу/клиенту, а не разработчику. Более того, в HTTP2 можно вместе с ответом на конкретный файл сервак может подцепить файл, который клиент вообще не просил, но который он может попросить, т.е. там всё очень хитро. И кстати, всё это дело можно гзипить.

***

Я наконец понял твой кейз, но дело в том, что мне гораздо проще использовать векторные шрифты или генерация SVG по JS шаблону (который в свою очередь описан на языке шаблонов).

Кстати про шрифты, возможно скоро веб-шрифты научаться передавать цвет (намёк на возможную реализацию фичи).

Потому что gulp это спцециализированный инструмент сборки а не таск раннер.

Опять ты упрямишься. Я тоже так думал и думал что мне впаривают очередной велосипед, серьёзно. Но потом я потратил пару дней на изучение (да, там реально не просто) и меня как из ведра окатило.

[kobezzza]

Вот уже есть плагины для данной задачи для WebPack:

https://github.com/kisenka/webpack-svg-sprite-loader
https://www.npmjs.com/package/webpack-svgstore-plugin

(не удивляйся, что в примере не CSS, т.к. в вебпак нет разделения на сущности файлов, а всё выстраивается конвеерами, например, css!svg-sprite!stylus)

[ТОТ_САМЫЙ]

гораздо проще использовать векторные шрифты

Разноое сглаживание и собственно все, так же нельзя использовать анимации, а я могу svg еще и анимировать и интерактивный сделать и все это в качестве ФОНА).

вся возня с оптимизацией ложиться на плечи HTTP

Нет противостояния моего плагина и http2. твои решения используют тольк http2 а мои и http1 и http2 грубо говоря. то есть у меня и там и там быстро работает, а у тебя толькто в http2.


svgstore-plugin есть и на галп и он совсем другое делает, он делает запаковку которую мождно использовать в html лишь как <svg> <use link='file.svg#logo'> но как background-image в css использовать нельзя. background-image: url(file.svg#logo) будет просто весь svg рисовать или пустоту (так как все запаковано в обекты <symbol> а они невидимые). svg-sprite-loader делает то же самое. они просто запаковывают много svg в один svg. и его нельзя использовать как background-url, именно из-да background-url и было принято решение запаковывать все в css файл. Ну и как побочный эффект это дало лайврелоад. Название плагина моего, я напомню, gulp-svg-to-css вполне отражает суть.

[ТОТ_САМЫЙ]

мне гораздо проще использовать

У нас дизайнеры рисуют в кореле и илюстраторе, они обомлели когда я им показал что файл просто сохраняешь, даешь диву класс с именем файла и он начинает работать, а ты продолжаешь редактировать файл а он и в браузере меняется) да я сам от такого офигел), мы даже не мечтали о такой фитче) обычно приходилось все a png рендерить и сохранять в папку потом прописывать стиил и.т.п. а они не умеют и прописывал я и.т.п. а потом не нравились резкие контуры, и процедура повторялась). А тепрь все как и должно быть, в папке src вккторные исходники которые можно открывать и редактировать, а в public_html все компилируется) я уже молчу про то что все запаковывается в спрайт и автоматически сжимается.

[ТОТ_САМЫЙ]

kobezzza, шрифтом вот так не сделаешь http://uijs.ru/#about

[kobezzza]

kobezzza, шрифтом вот так не сделаешь http://uijs.ru/#about

Почему? Я задам блоку с шрифтом CSS анимацию и всё

Главный недостаток шрифтов на мой взгляд, что нельзя сейчас использовать множество цветов.

[ТОТ_САМЫЙ]

kobezzza, разное сглаживание и размытие сильнейшее так что невозможно использовать для иконок. один цвет на всю иконку. нельзя анимировать. давай еще раз, нельзя анимировать, можно ли анимировать? НЕТ. Ты не сможешь анимировать. ТО что ты сказал это не анимация. Поанимируй например точку у буквы i ) НО основное это конечно не то что плохая пригодность, а НЕ пригодность для использования в качестве иконок из за размытия и сглаживания ужасного. Браузер сглаживает их как текст и поулчается ад, пруфы легко гуглятся.

[kobezzza]

Иди спать, пол пятого)