Похоже, у нее такая же проблема, как и 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? Я вас не понимаю :)
Chrome
Firefox
IE
Но статья действительно могла бы быть более полная, есть куча важных вещей помимо рендеринга — нормализация вертикальных оступов, разные способы вычесление line-height и line box, располовинивание line gap и прочее прочее.
PS. Скринил под виртуалкой на thunderbolt, реальность может отличаться.
Если кто-то еще едет, как написал хабраюзер выше — давайте кооперироваться!
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.
Статья не видел, спасибо, почитаю.
Не один из знакомых разработчиков попробовавший coffee хотя бы в течении дня, а не посмотревший на код сказав «Блиииин, как тут можно разобраться, где функция начинается, где фигурные скобки, ничего не понятно :(» не сказал потом что coffee не удобный или не понятный. Да, сначала есть трудности, да, не привычно для тех кто не писал на ruby/python, но понимание приходит через максимум неделю активного юзанья. Зато потом от лаконичности написанного кода и простоты его поддержки и расширения испытываешь одно удовольствие. Так что, имхо, игра стоит свеч, и те кто не пробывал CoffeeScript из-за каких-то непонятных побуждений и надуманных причин — попробуйте пописать на нем хотя бы день и я уверен, вы будете приятно удивлены… или хотя бы выучите диалект которого так боитесь, в любом случае никаких минусов.
Я прекрасно знаю, что такое Local Storage, а вот вы похоже не совсем… или я вас не правильно понимаю. Что вы хотите сохранять с его помощью, причему тут svg, а тем более js скрипты для его поддержки в старых браузерах?
«Сейчас в поисковики не попадают ембеды и обжекты — только картинки.»
Апрув или не было :) Google индексирует svg с 2010 года во всех его проявлениях.
Так и не увидел особых сложностей в вашем посте. Если у вас сервер отдает неправильные mime-type, то это проблема сервера, а не svg формата. Ну а фолбек для старых браузеров всегда был и будет, это обратная сторона быстрого развития технологий, стоит давно привыкнуть.
3) С чего вы взяли? Производительность должна быть одинаковая, рендер проводится браузером. Другое дело — количество запросов. Поэтому для меня оптимальный способ inline svg или base64 в стилях.
Глюк в ff воспроизводить нет времени, но можете попробовать назначить viewBox или изменить shape-rendering.
Клиенту не важно что это img, inline svg или object — ему важно отображение.
Что сохранять? Какой LocalStorage? Я вас не понимаю :)