Коротка довідка: Microsoft Edge – це новий дефолтний браузер Windows 10, що прийшов на зміну Internet Explorer. Крім нового свіжого інтерфейсу, під капотом браузера також знаходяться і оновлені движки EdgeHTML (спочатку — форк движка IE11) і Chakra (для JS). Якийсь час браузер був відомий під тимчасовою назвою «Project Spartan».
Разом із зростанням Windows 10 ви, напевно, могли помітити на своїх сайтах і зростання числа користувачів Microsoft Edge. Тому саме час зробити кілька рухів, щоб ваші сайти працювали в Edge ще краще.
Поради, які я наводжу нижче, в основному, мають узагальнену природу. Іншими словами, від їх реалізації користь отримають не тільки користувачі Edge, але і інших браузерів.
Уникайте визначення браузера – визначайте наявність функціональності
Колись давним-давно в специфікації HTTP/1.1 і, відповідно, специфікації HTML було введено поняття User Agent, який повинен ідентифікувати браузер (або будь-який інший клієнт), який звертається до сервера. Ця функція, у багатьох випадках корисна і важко замінна (наприклад, для збору статистики), у реальному житті також здобула погану славу утилізації в цілях поділу браузерів на «погані» і «хороші».
Не вдаючись у перипетії браузерних баталій, зазначу лише, що були часи, коли розробники, спираючись на значення рядка UA, одним браузерам віддавали одну верстку, а іншим іншу. Чому було багато смутку у користувачів і болю у розробників браузерів. Останні, намагалися обдурити долю інтернет-роздачі і ховалися за чужими UA в надії на світле майбутнє.
За сучасними рядками UA популярних браузерів можна вивчати історію вебу:
(Ви ж в курсі, що згідно специфікації HTML5, navigator.appCodeName завжди дорівнює «Mozilla», а navigator.product – завжди «Gecko»? Все заради сумісності.)
В ідеальному світі, звичайно, хочеться вірити, що часи баталій давно пройшли, але статистика, на жаль, говорить зворотне. В сучасному інтернеті все ще величезна кількість сайтів, які в тій чи іншій мірі використовують детектування браузера для того, щоб віддавати йому ту чи іншу верстку або реалізовувати ту або іншу логіку на JavaScript.
Як кажуть джедаї, які стали на світлу сторону, правильний код дивиться на можливості браузера, а не судить за його User Agent String. Цьому підходу було дано ім’я Feature Detection, про що написано багато статей і сказано багато слів.
Порада №1: застосовуйте гнучкі рішення в коді, спираючись на доступну в браузері функціональність, а не версію або ім’я браузера.
Бібліотеки зразок Modernizr можуть вам в цьому допомогти.
Як би там не було, нова рядок User Agent в Microsoft Edge виглядає так:«Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240». Вона навмисно дуже схожа на рядок Chrome, хоча і має в кінці відмітний ідентифікатор Edge.
Команда Edge цілеспрямовано працює над тим, щоб забезпечити сумісність не тільки з веб-стандартами, але їх реалізацією в інших браузерах, зокрема, Chrome і Firefox. Тому в більшості випадків «верстка для Chrome сучасного вебу повинна просто працювати».
Тонкість тут в тому, що якщо на вашому публічному сайті ви детектируете Chrome, щоб використовувати функціональність, доступну тільки в ньому, і ця функціональність критична для UX, то люди з Edge будуть засмучені непрацюючим сайтом.
Якщо вам потрібно визначити платформу, робіть це правильно
Впевнено рухаючись до світлого майбутнього сумісності на десктопі, як ви знаєте, веб пропустив потужний удар в мобільному світі. Ми про це поговоримо трохи пізніше саме в контексті сумісності, а зараз продовжимо розбиратися з детектуванням браузера.
Автори багатьох сайтів та веб-додатків (не всі, звичайно) у мобільну епоху задумалися не тільки про те, щоб додати своїм ресурсів мобільний «look and feel», але також і про те, щоб обзавестися мобільними додатками під різні платформи.
Потім вони почали думати, як розповісти користувачам сайту з мобільних пристроїв, що їм тепер треба користуватися мобільними додатками. І тут вони знову згадали про рядок юзер-агента… і понеслася.
Загалом, як тільки IE зник, а на його місце прийшов Edge, який прикидається Chrome, який прикидається Safari, який прикидається Gecko і KHTML, які все прикидаються Mozilla… Edge користувачі Windows 10 Mobile раптом замість рідних додатків почали отримувати рекомендації поставити додаток під Android.
Часто це робить самописний код, часто скопійований з чергового блог-посту або StackOverflow, часто готові бібліотеки, наприклад, jQuery Smart Banner…
Як лірико-практичного відступу: я тут якось відкрив на одному російському новинному сайті js-код в налагоджувач і жахнувся бібліотеці 2012 року (час виходу iOS6 і Windows 8). Рік-два вона справно працювала, але тут спочатку вийшло оновлення WP8.1, а потім і мобільна версія Edge – і «все зламалося».
User Agent в мобільній версії Edge виглядає так: «Mozilla/5.0 (Windows Phone 10.0; Android 4.2.1; Nokia; Lumia 520) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Mobile Safari/537.36 Edge/12.10130».
Як ви можете здогадатися, десь у нетрях бібліотеки, згаданої вище і використовуваної на сайті, всі це розбирається приблизно таким кодом:
if (UA.match(/Android/i) != null) {
this.type = 'android'
} else if (UA.match(/Windows NT 6.2/i) != null && UA.match(/Touch/i) !== null) {
this.type = 'windows'
}І, очевидно, у разі мобільної версії Edge відпрацьовує перша гілка. В результаті благий намір розробників сайту перетворюється в микроад для користувача. Не кажучи вже про те, що тут знову граблі версійності: Windows 10 версія платформи NT – 10, а не 6.2, причому в Windows 8.1 вже була версія 6.3. Втім, розробник, навряд чи міг про це здогадуватися в 2012 році.
Що ж робити? Виявляється, навіть UA-рядок, повна жодних «цікавих подробиць, повинна, згідно специфікації, слідувати простому правилу: всі перераховані продукти повинні розташовуватися в порядку пріоритетів, як їх бачить розробник клієнта (браузера).
Порада №2: розбираючи UA-рядок, враховуйте порядок входжень, а не тільки наявність ключових слів.
Якщо браузер каже, що він, в першу чергу, Windows Phone, і лише по-друге хоче отримувати контент для Android, то, напевно, він хоче, щоб ви в якості ОС сприймали саме WP.
Відносно невелика зміна в коді на сайті може принести вам нових щасливих користувачів мобільного додатку.
Оновлюйте бібліотеки до свіжих версій
Ми трошки поисследовали веб і з’ясували, що більше половини найпопулярніших 20000 сайтів використовують JavaScript-бібліотеки, які мають відомі проблеми, які усуваються в більш свіжих версій.
Ми зробили сканер для сайтів, який дозволяє перевірити:
До речі, вихідний код сканера доступний на GitHub. Якщо ви виявите баг, повідомте нам в репозитарії.
Проблема з застарілими бібліотеками має деколи дуже специфічну природу, сильно перекликающуюся з самою динамікою веба і реалізацією веб-стандартів, зокрема. Тут і копипастный код, і вендроные особливості і фішки, і стандарти, що змінюються в процесі стабілізації, і погані практики програмування. Повний букет.
На що варто звернути увагу при виборі бібліотек:
- Мінімальні вимоги до браузерів і їх движка. Повинно відповідати вашим мінімальним вимогам щодо підтримки браузерів.
- Відсутність посилань у коді на версії браузерів і в цілому детектування браузерів. Хороша бібліотека повинна дивитися в майбутнє і бути нейтральною, а не чіплятися за певний поточний зріз.
- Використання стабільних крос-браузерних API, а при використанні нових і, як правило, експериментальних API — наявність fallback-гілок на випадок відсутності їх підтримки в тому чи іншому браузері.
- Мінімізація використання вендорних API (як правило, з префіксами), краще – відсутність таких викликів і відсилань, а за наявності – обов’язковий fallback до стандартних «безпрефиксных» API. Іншими словами, бібліотека повинна надавати перевагу стандартизованим API.
- Стабільність версії і динаміка розвитку. Це завжди пошук правильного балансу. Стабільна бібліотека повинна забезпечувати середньострокову надійність, а динаміка розвитку повинна показувати, що це не мертвонароджений проект не цікавий більше своїм авторам.
Порада №3: використовуйте свіжі і браузеро-нейтральні бібліотеки зі стабільним кодом.
Наприклад, якщо у бібліотеки є офіційний репозиторій на GitHub не полінуйтеся перевірити, скільки в ній є відомих проблем і як часто вона оновлюється.
Уважний читач помітить, що в цьому розділі я ні разу не сказав, що мова йде тільки про JavaScript. І, дійсно, все це стосується не тільки JS (і відповідних API), але і будь-яких CSS-фреймворків і, зокрема, прекрасних експериментів, як зробити що-небудь прекрасне засобами нових фішок CSS, описаних в чернетці чергового стандарту або документації одного з виробників браузерів.
Слідкуйте за помилками, збирати статистику
Історія з бібліотеками підказує, що важливо не тільки грамотно підходити до написання свого коду та інтеграції чужого, але і відстежувати зміни в навколишньому середовищі, то й справа трапляються у світі інтернету. Десь стандарт змінився, десь браузери вимкнули підтримку експериментальної функціональності (наприклад, в префиксном вигляді, який ви використовували), де-то в новій версії стався баг реалізації, десь бібліотеки перестали стикуватися один з одним…
Загалом питання в тому, що, розробляючи деяке рішення, важливо не тільки переконатися в його працездатності в моменти самої розробки і безпосередньо впровадження, але і в ході подальшої експлуатації.
І якщо на першому етапі ви готові витратити помітні зусилля на те, щоб перевірити, як поводиться ваш веб-додаток в актуальних браузерах, то далі, якщо тільки мова не йде про постійно розробляється і динамічним проекті (а більшість сайтів не такі!), перевірки трапляються рідко або не трапляються зовсім.
А реакція і виправлення проблем, як правило, відбуваються в реакційному режимі, коли знаходиться якийсь черговий користувач з проблемою, про яку він знаходить сміливість і бажання розповісти.
У такій ситуації розумним виходом є впровадження збору статистики і її наступний аналіз. Іншими словами, ваш код повинен вміти «у разі непередбаченого», тобто у разі виникнення виняткових ситуацій, генерувати події і відправляти мета-дані в певний сервіс збору інформації. А, з іншого боку, ви або замовники сайту повинні мати можливість розуміти, що і як відбувається з сайтом в поточних історичних реаліях. Причому не тільки з точки зору маркетингу і продажів, але і з технологічної точки зору.
Порада №4. Впроваджуйте аналітику і відстежуйте непрацюючу функціональність або некоректну поведінку сайту.
У довгостроковій перспективі це, як мінімум, може допомогти бути обізнаним про проблеми сумісності.
«Хвилина реклами». Як ви, напевно, вже чули, у нас є спеціальний хмарний сервіс для розробників, зроблений для таких цілей – Application Insights Microsoft Azure. (Для студентів сервіс доступний в програму DreamSpark.) Крім відстеження загальних подій, начебто відвіданих сторінок, він також дозволяє вам вводити власні події і метрики, які ви можете відправляти в аналітику в потрібний момент часу свого коду:
appInsights.trackEvent // or trackPageView, trackMetric, ...
("WinGame",
// String properties:
{Game: currentGame.name, Difficulty: currentGame.difficulty},
// Numeric metrics:
{Score: currentGame.score, Opponents: currentGame.opponentCount}
);Тепер давайте повернемося до CSS.
Уникайте префиксных властивостей CSS, використовуйте стандартні властивості
Колись здавалося, що впровадження виробниками браузерів експериментальних CSS-властивостей з вендорным префіксами – це відмінна ідея, що дозволяє і поекспериментувати, і «ніби» не забруднювати інтернет.
Виявилося, що це не так. Добра ідея, як це зазвичай буває, зіткнулася з суворою реальністю життя, в якій зачаровані красою багато веб-розробники почали експлуатувати нестандартні реалізації в живих проектах.
Ви, напевно, пам’ятаєте всі ці історії про драматичні зміни синтаксису градієнтів, що відбулися між початковою реалізацією в движку Webkit (Safari) і фінальною версією у відповідному веб-стандарті.
Ви також, напевно, уявляєте і як код з подібними фішками потрапляє в розмітку багатьох сайтів, будучи банально скопійованим з чергової красивої статті. Проблема в тому, що часто такий код написаний саме в демонстраційних цілях, а тому для спрощення або виходячи з міркувань компактності (або за яким-небудь ще непорозуміння), не містить повної історії. Тобто не розповідає, як його варто (і чи варто взагалі) застосовувати в експлуатації на реальних сайтах.
Останнє на практиці означає, що потрібно 1) перерахувати всі варіанти для різних браузерів і 2) не забути вказати версію коду, відповідну стандарту (можливо, проектованому).
Некоректне використання експериментальних і нестандартних можливостей може призводити банально до того, що сайт не просто виглядає менш красиво», але й банально перестає реалізовувати свою ключову функціональність. У наведеному вище прикладі застосування –webkit-transition без згадки альтернатив і стандартної версії призводить до того, що меню сайту перестає відкриватися в не-webkit браузерах. І це сумно.
Порада №5. Мінімізуйте використання вендорних префіксів і завжди додавайте як мінімум стандартну альтернативу.
Повторю, це стосується як коду, який ви пишете самі, так і копируемого коду і коду підключаються бібліотек. В якості прикладу візьмемо досить популярну бібліотеку normalize.css, яка має, як випливає з назви і опису, приводити відображення різних елементів в різних браузерах у більш-менш однаковий вигляд. Нижче приклад коду з бібліотеки:
html {
font-family: sans-serif;/* 1 */
-ms-text-size-adjust: 100%;/* 2 */
-webkit-text-size-adjust: 100%;/* 2 */
}Як легко помітити, тут явно чогось не вистачає. Наприклад, властивості –moz — префіксом і версії, сумісної з розробляються стандартом. До слова, сканер, який я згадував вище, вміє такі речі визначати.
Виробники браузерів, зі свого боку, намагаються з цим боротися: розробникам сайтів ми розповідаємо, що так робити недобре, а ось для кінцевих користувачів нам доводиться реалізовувати в браузерах підтримку «чужих» префиксных API.
Просто для орієнтиру: Microsoft Edge підтримуваних –webkit — префіксів вже більше, ніж власних префіксів –ms-. (Не те, щоб нам це дуже подобалося… але потрібно.)
Обходитеся без плагінів там, де це можливо
Плагіни в браузерах – це довга історія багатьох цікавих рішень, прекрасних для свого часу, технологій та довгих і не дуже сумних падінь. Коротка версія стану справ на сьогодні: браузери рухаються до моделі без бінарних розширень.
Наприклад, це робить Chrome з відмовою від NPAPI і це робить Microsoft Edge з відмовою від ActiveX. Для всього цього є три прості і зрозумілі причини:
- Заміщення веб-стандартами (єдиними і стерпним)
- Зменшення поверхні для атак і потенційних дірок безпеки (а, як правило, мова йде про інтеграцію в браузер сторонніх мало контрольованих плагінів)
- Спрощення внутрішньої архітектури браузерів на користь використання тих же технологій, що і на веб-сайтах, які вони відображають (HTML, CSS, JavaScript).
Якщо ви робите рішення для мобільного веба, тв-веба і будь-яких інших недесктопных платформ, майже напевно, у відповідному браузері не будуть підтримуватися популярні на десктопі плагіни. Тому історія з бесплагинным вебом вам добре знайома.
Якщо ви робите рішення виключно для десктопа, то і ви обов’язково вже повинні бути в курсі всіх сучасних тенденцій на послідовне заміщення тієї чи іншої функціональності плагінів (наприклад, Flash і Silverlight) аналогічними або альтернативними можливостями.
Графіка, 3d-графіка, анімація, управління звуком – все це вже можна робити в сучасних браузерах, використовуючи такі технології, як SVG, Canvas, WebGL, CSS-анімації, WebAudio – все це в зв’язці з JavaScript. Наприклад, Unity вже дозволяє використовувати цей стек для ігор у браузері.
Одна з ключових ніш використання плагінів на сайтах – це програвання аудіо — і відео-контенту, в тому числі із захистом авторських прав.
HTML5 Audio/Video в поєднанні з DASH/CENC/MSE/EME і реалізацією DRM на апаратному або софтверному рівні цілком дозволяють замінити собою плагіни.
Рада №6: скрізь, де можна, намагайтеся замінити використання плагінів на сучасні веб-стандарти.
Як мінімум, для сучасних браузерів.
З впровадженням таких технологій, як WebRTC (ORTC), бесплагинный світ буде відкритий і для відео — та аудіо-комунікацій у браузері. Думаю, що впровадження веб-компонентів також дозволить істотно зменшити частку використання Flash в рекламному сегменті.
Звичайно, реальне впровадження технологій займає час і майбутнє без плагінів, яке ми чекаємо вже кілька років як, все ще ніяк не настане, але особисто я продовжую вірити, що «якщо не завтра, то коли-небудь вже точно».
Стежити за статусом впровадження тієї чи іншої функціональності можна на сайтах: Microsoft Edge, Webkit (Safari), Blink(Chrome і ін) – чи відстежувати загальну динаміку через caniuse.com.
Тестуйте сайти Microsoft Edge: безпосередньо або віддалено
І остання порція рекомендацій про те, як тестувати сайти безпосередньо в Microsoft Edge.
Перше, що потрібно розуміти: для роботи Edge потрібна Windows 10. Якщо у вас немає Windows 10 (нагадаю, що оновитися до Windows 7/8/8.1 можна безкоштовно), то ви можете поставити собі віртуальну машину з Windows 10 і новим браузером.
Ми постаралися підготувати образи для всіх популярних операційних систем (Windows, Mac OSX, Linux) і платформ для віртуалізації (HyperV, VirtualBox, VMWare, Parallels).
Друге: для налагодження сайтів ви можете використовувати різні інструменти. Це можуть бути як оновлені інструменти розробника F12 tools, вбудовані в браузер, так і віддалені кошти, наприклад, Vorlon.js. Ви також можете використовувати WebDriver для автоматизації тестування.
І третє: як ви, напевно, чули, з Microsoft Edge порівняно з Internet Explorer зникло багато застарілих і нестандартних речей. Тому, якщо ви на них покладалися в IE, не сподівайтеся їх використовувати Edge – ми всі випиляли.
Порада №7: додайте Microsoft Edge в список браузерів, в яких ви перевіряєте ваші сайти.
Якщо ви виявили проблеми в самому браузері (наприклад, відхилення від стандарту або відмінність з реалізацією в інших браузераз), повідомте нам через Connectу веб-переглядачі функцію «Send feedback» або в твіттері@msedgedev.
Підсумки
Нарешті, спробую зібрати всі поради разом:
- Застосовуйте гнучкі рішення в коді, спираючись на доступну в браузері функціональність, а не версію або ім’я браузера. (Feature Detection)
- Якщо вам потрібно визначити платформу, розбираючи рядок UA, враховуйте пріоритезацію.
- Оновіть бібліотеки до свіжих версій, вибирайте бібліотеки, нейтральні до браузерів.
- Впроваджуйте статистику на сайті не тільки для знімання маркетингових показників, але і для обліку технічної телеметрії.
- Використовуєте стандартні властивості CSS, мінімізуйте використання префіксів, а якщо додаєте їх, то робіть це для всіх браузерів.
- У міру можливостей замінюйте плагіни на технології, що мають в основі веб-стандарти.
- Слідкуйте за динамікою користувачів і додайте Microsoft Edge в список протестованих браузерів.