Похоже, у нее такая же проблема, как и Fontsquirrel, кушает бублики —
Chrome
Firefox
IE
Но статья действительно могла бы быть более полная, есть куча важных вещей помимо рендеринга — нормализация вертикальных оступов, разные способы вычесление line-height и line box, располовинивание line gap и прочее прочее.
PS. Скринил под виртуалкой на thunderbolt, реальность может отличаться.
Насчет самого первого на Дальнем Востоке хотелось бы вас разочаровать, к сожалению, лет 5-6 назад у нас проводился хакатон для перловиков (если кто-то помнит еще такой язык ;). Правда упоминания о нем уже покрылись паутиной и пылью, даже не могу припомнить, как он называется.
Зачем? Разберитесь с отдельной тулзой лучше, а лучше с командной строкой.
coffee --watch --map
будет сразу создавать source map и chrome developer tools к примеру, будет указывать ошибки именно в coffeeScript, а не в созданном из него js.
Еще дополнение по поводу пункта 5:
Во многих проектах, таких как github, gitlab, redmine и прочих, можно прямо в сообщениях к коммиту делать ссылки на соответствующие issue, к примеру «Resolve bug with ugly modal window in IE9 #123» станет ссылкой на issue 123 в веб-интерфейсе. Можно даже управлять issue при помощи определенных слов, к пример «Resolve bug with ugly modal window in IE9,fix #123» автоматически закроет этот тикет.
Являюсь сторонником грамотно написанных сообщений к коммитам, но некоторые советы написанные в статье — это через чур, по крайней мере для моего workflow.
autocmd Filetype gitcommit setlocal spell textwidth=72 и Никогда не используйте флаги для сообщения -m
Достаточно спорные советы — если вы правильно пользуетесь гитом и у вас частые атомарные коммиты, то вы будете повторяться в сообщениях к каждому коммиту, просто для того чтобы обойти ограничение.
Покажу на примере — мне нужно сделать модальное окно для авторизации. Что делаем сначала? Правильно, создаем новую ветку в названии которой уже можно проследить, для чего она создана, к примеру — feature-authorization-on-modal-windows. Потом делаем частые маленькие коммиты, описывающие зачем мы это сделали (специально посмотрел сейчас log — в основном коммиты по 50-70 символов). Когда задача сделана и протестирована, вливаем ее в qa или основную ветку, а вот тут, в merge коммите и можем описать все что написано в 4 пункте и зачем, и почему именно так, и какие проблемы могут возникнуть.
В общем к чему это я — не копируйте слепо, то что вам советуют, применяйте к своему рабочему процессу. Ну и, конечно, пишите грамотные сообщения к коммитам, всегда думайте, а можно ли определить по этому сообщению, что именно я сделал, без использования diff.
По моим наблюдениям в основном из упертости и нежелания учить что-то новое (что довольно странно для нашей сферы, да и что там учить?).
Не один из знакомых разработчиков попробовавший coffee хотя бы в течении дня, а не посмотревший на код сказав «Блиииин, как тут можно разобраться, где функция начинается, где фигурные скобки, ничего не понятно :(» не сказал потом что coffee не удобный или не понятный. Да, сначала есть трудности, да, не привычно для тех кто не писал на ruby/python, но понимание приходит через максимум неделю активного юзанья. Зато потом от лаконичности написанного кода и простоты его поддержки и расширения испытываешь одно удовольствие. Так что, имхо, игра стоит свеч, и те кто не пробывал CoffeeScript из-за каких-то непонятных побуждений и надуманных причин — попробуйте пописать на нем хотя бы день и я уверен, вы будете приятно удивлены… или хотя бы выучите диалект которого так боитесь, в любом случае никаких минусов.
Простейший sass mixin выдает мне png для старья, которые автоматически сконверчены из svg по средствам ImageMagick.
Я прекрасно знаю, что такое Local Storage, а вот вы похоже не совсем… или я вас не правильно понимаю. Что вы хотите сохранять с его помощью, причему тут svg, а тем более js скрипты для его поддержки в старых браузерах?
«Сейчас в поисковики не попадают ембеды и обжекты — только картинки.»
Апрув или не было :) Google индексирует svg с 2010 года во всех его проявлениях.
Так и не увидел особых сложностей в вашем посте. Если у вас сервер отдает неправильные mime-type, то это проблема сервера, а не svg формата. Ну а фолбек для старых браузеров всегда был и будет, это обратная сторона быстрого развития технологий, стоит давно привыкнуть.
2) Древние эксперименты с разными методами вставки svg.
3) С чего вы взяли? Производительность должна быть одинаковая, рендер проводится браузером. Другое дело — количество запросов. Поэтому для меня оптимальный способ inline svg или base64 в стилях.
Глюк в ff воспроизводить нет времени, но можете попробовать назначить viewBox или изменить shape-rendering.
Вы понимаете, что эти костыли сделаны для браузеров не поддерживающих svg? У вас, к примеру, ie8 вообще ничего не отобразит. Все эти костыли строятся автоматически — мне не сложно.
Клиенту не важно что это img, inline svg или object — ему важно отображение.
Что сохранять? Какой LocalStorage? Я вас не понимаю :)
Дайджест свежих материалов из мира фронтенда за последнюю неделю №248 (30 января — 5 февраля 2017)
Тестирование конвертеров шрифтов
Chrome
Firefox
IE
Но статья действительно могла бы быть более полная, есть куча важных вещей помимо рендеринга — нормализация вертикальных оступов, разные способы вычесление line-height и line box, располовинивание line gap и прочее прочее.
PS. Скринил под виртуалкой на thunderbolt, реальность может отличаться.
DVHack 2013. Было здорово. Или первый хакатон на Дальнем Востоке
DVHack 2013. Было здорово. Или первый хакатон на Дальнем Востоке
YaC: почему важно не пропустить главную технологическую конференцию Яндекса в 2013 году
Если кто-то еще едет, как написал хабраюзер выше — давайте кооперироваться!
Робосезон 2013: из-под воды в небо
Стихи в коде
Псевдо 3D: Анимация вращения планет и других шароподобных объектов
Знакомство с CoffeeScript
coffee --watch --mapбудет сразу создавать source map и chrome developer tools к примеру, будет указывать ошибки именно в coffeeScript, а не в созданном из него js.
Пять полезных советов при составлении коммит сообщения
Во многих проектах, таких как github, gitlab, redmine и прочих, можно прямо в сообщениях к коммиту делать ссылки на соответствующие issue, к примеру «Resolve bug with ugly modal window in IE9 #123» станет ссылкой на issue 123 в веб-интерфейсе. Можно даже управлять issue при помощи определенных слов, к пример «Resolve bug with ugly modal window in IE9,fix #123» автоматически закроет этот тикет.
Пять полезных советов при составлении коммит сообщения
Достаточно спорные советы — если вы правильно пользуетесь гитом и у вас частые атомарные коммиты, то вы будете повторяться в сообщениях к каждому коммиту, просто для того чтобы обойти ограничение.
Покажу на примере — мне нужно сделать модальное окно для авторизации. Что делаем сначала? Правильно, создаем новую ветку в названии которой уже можно проследить, для чего она создана, к примеру — feature-authorization-on-modal-windows. Потом делаем частые маленькие коммиты, описывающие зачем мы это сделали (специально посмотрел сейчас log — в основном коммиты по 50-70 символов). Когда задача сделана и протестирована, вливаем ее в qa или основную ветку, а вот тут, в merge коммите и можем описать все что написано в 4 пункте и зачем, и почему именно так, и какие проблемы могут возникнуть.
В общем к чему это я — не копируйте слепо, то что вам советуют, применяйте к своему рабочему процессу. Ну и, конечно, пишите грамотные сообщения к коммитам, всегда думайте, а можно ли определить по этому сообщению, что именно я сделал, без использования diff.
MVC-фреймворки на JavaScript: сравнение Marionette и Chaplin
Статья не видел, спасибо, почитаю.
MVC-фреймворки на JavaScript: сравнение Marionette и Chaplin
Не один из знакомых разработчиков попробовавший coffee хотя бы в течении дня, а не посмотревший на код сказав «Блиииин, как тут можно разобраться, где функция начинается, где фигурные скобки, ничего не понятно :(» не сказал потом что coffee не удобный или не понятный. Да, сначала есть трудности, да, не привычно для тех кто не писал на ruby/python, но понимание приходит через максимум неделю активного юзанья. Зато потом от лаконичности написанного кода и простоты его поддержки и расширения испытываешь одно удовольствие. Так что, имхо, игра стоит свеч, и те кто не пробывал CoffeeScript из-за каких-то непонятных побуждений и надуманных причин — попробуйте пописать на нем хотя бы день и я уверен, вы будете приятно удивлены… или хотя бы выучите диалект которого так боитесь, в любом случае никаких минусов.
Инструменты и примеры кода для разработки ARIA
Первое апреля в Интернете-2013
Adobe Blank: Шрифт для разработчиков
Логотип по стандартам HTML5 или Как поставить векторную картинку на веб-страницу
Логотип по стандартам HTML5 или Как поставить векторную картинку на веб-страницу
Я прекрасно знаю, что такое Local Storage, а вот вы похоже не совсем… или я вас не правильно понимаю. Что вы хотите сохранять с его помощью, причему тут svg, а тем более js скрипты для его поддержки в старых браузерах?
«Сейчас в поисковики не попадают ембеды и обжекты — только картинки.»
Апрув или не было :) Google индексирует svg с 2010 года во всех его проявлениях.
Так и не увидел особых сложностей в вашем посте. Если у вас сервер отдает неправильные mime-type, то это проблема сервера, а не svg формата. Ну а фолбек для старых браузеров всегда был и будет, это обратная сторона быстрого развития технологий, стоит давно привыкнуть.
Логотип по стандартам HTML5 или Как поставить векторную картинку на веб-страницу
3) С чего вы взяли? Производительность должна быть одинаковая, рендер проводится браузером. Другое дело — количество запросов. Поэтому для меня оптимальный способ inline svg или base64 в стилях.
Глюк в ff воспроизводить нет времени, но можете попробовать назначить viewBox или изменить shape-rendering.
Логотип по стандартам HTML5 или Как поставить векторную картинку на веб-страницу
Клиенту не важно что это img, inline svg или object — ему важно отображение.
Что сохранять? Какой LocalStorage? Я вас не понимаю :)