Префікси. Навіщо і як правильно

Вадим Макєєв: Добрий день! Я працюю в компанії Opera Software, ми робимо різні браузери. У своїй доповіді я буду не рекламувати якісь круті новинки, а розповім про технології, які ми використовуємо повсякденно. Поговоримо про префіксах.

Префікси використовують все, але навіть найдосвідченіші фахівці подеколи не до кінця розуміють, як вони працюють. Для того, щоб писати їх правильно, потрібно знати деякі прості речі, які іноді виявляються зовсім не простими. Саме тому я розповім вам про те, як це все працює.

Що може бути простіше стільця? Якщо в реальному житті нам потрібен стілець, потрібно одну просту дію - взяти і поставити його. Але багато хто з вас пишуть код, і ви періодично помічали, що деякі властивості доводиться повторювати. Якщо у вас є властивість «стілець», вам потрібно написати «-о-стілець», щоб все це нормально відобразилося в Opera. Потім вам знадобиться «-ms-стілець», «-moz-стілець» і «-webkit-стілець». Виходить нагромадження, і зовсім незрозуміло, що з ним робити. І сісти на такий «стілець» можна, і переносити незручно.

Якщо ви кожен день стикаєтеся з префіксами, то, чесно кажучи, вони псують вам життя. 99% людей мріє, щоб вони зникли і ніколи не з'являлися. Частково вони мають рацію, частково ні. Я поясню, чому.

Що собою являють префікси? Префікс, як правило, ставиться перед значущим елементом і вказує на певний браузер або виробника будь-якої техніки. Префіксів існує дуже багато. Вони можуть починатися як з дефіса, так і з нижнього підкреслення. Префікси - з'явилися не в CSS 3, де вони використовуються для таких речей як градієнт або "border-radius", а ще в CSS 2.1. Це один із способів розширити CSS, додаючи туди власні властивості, які згодом можна стандартизувати.

Насправді префікси не "засмічують код». Спочатку вони були придумані для того, щоб допомагати розробникам браузерів адаптувати специфікацію під свої потреби і писати в них якісь нові речі. У підсумки префікси в більшій мірі стали використовувати розробники. Саме в цьому криється проблема.

До речі, правильно називати префікси саме «браузерних», а не «Вендорний». У російській мові у слова «вендор» дуже широке значення. «Вендора», наприклад, може бути і компанія-постачальник холодильників. «Браузерних префікс» - це більш вдалий переклад.

Звідки взагалі беруться префікси? Давайте уявимо таку історію ...

Десь в Каліфорнії, в Силіконовій долині вранці прокидається розробник webkit. Може бути, в офісі Google він заснув - буває, трудоголіки з роботи не йдуть. І уві сні цього розробнику прийшла ідея властивості "lol-cat". Він подумав, що класним значенням для цього властивості буде ось такий милий смайлик.

«Треба б впровадити це властивість», - вирішує розробник. Але властивість не можна впроваджувати в тому вигляді, в якому воно йому наснилося. Спочатку він повинен заховати його за простором імен webkit.

Через деякий час в Європі прокидаються розробники з компанії Mozilla. Вони кажуть: «Ага, хлопці з Каліфорнії придумали класне властивість" lol-cat ", давайте-но ми теж щось придумаємо. Насправді, у нас в Європі прийнято інші смайли малювати. Тому нам потрібно зробити інше значення! »І вони замість« будиночків »роблять« кругляшки ». Кот у нас виходить менш щасливим - може, він француз?

Але це не важливо. Важливо, що розробники в Європі вважають, що значення у властивості має бути іншим. Вони дуже вчасно додають префікс «-moz-», щоб це властивість ні з чим не конфліктувало, щоб тільки їх браузер «розумів» це властивість і його значення. Браузер Mozilla префікси «-moz-» «розуміє».

Потім справа доходить до Норвегії, де нашого «кота» захотіли зробити здивованим, і придумали властивості ще одне значення.

Просто у кожного розробника є своя думка щодо того, як все повинно бути. Саме тому у нас був пекельний пекло років 10-15 тому - якраз через те, що розробники не могли домовитися один з одним. Це нормальний процес, це конкуренція. Є маса людей, кожен з яких створює щось, що, на його думку, буде працювати краще. Для тих, хто живе в Каліфорнії, краще виявляються одні речі, а для тих, хто живе в Європі, - інші.

Префікси дозволяють «ховати» всі ці відмінності під браузерних просторами імен і не заважати один одному.

Але проходить півроку або рік, минає два роки, три роки, п'ять років, і прокидаються розробники з Консорціуму всесвітньої павутини (W3C). Вони кажуть: «Ніяких смайликів в значенні не буде. У нас там буде стояти слово "smile", тому що воно читаемо, зрозуміло представникам всіх культур і виглядає серйозно ».

Ці розробники пишуть специфікацію, вказують типи смайликів, перевіряють, щоб сумісність цієї властивості з іншими була нормальною, все тестують і випускають специфікації. Її довго обговорюють, приймають версію «Кандидат в рекомендації». Після цього W3C дає вказівку використовувати беспрефіксную версію з тим значенням, яке вони затвердили. Після прочитання нової специфікації власники всіх браузерів повинні позбутися від префіксів, прибрати їх з коду і використовувати нову властивість. Але події розвивалися дещо по-іншому. Про це я ще розповім.

Припустимо, у нас є властивість "box-shadow". Коли сумісність була неповною, нам був потрібен префікс. Ми писали ось так. Але це не правильно. Здавалося б, це природно: піраміда повинна стояти на найширшій межі, щоб бути стійкою. Спочатку йде "box-shadow", потім "-moz- box-shadow", потім "webkit-box-shadow". Здавалося б, яка різниця, в якому порядку властивості записувати, все одно кожне властивість адресується кожній браузеру. Якщо ВО «розуміє» властивість без префікса, воно «зрозуміє» його без префікса, якщо воно «розуміє» webkit, то воно «зрозуміє» webkit. Але немає, все повинно бути ось в такому порядку.

«Піраміда» повинна «висіти» вістрям вниз. Необов'язково, щоб спочатку йшла частина з "webkit- ...", а потім частина з "-moz-", їх можна поміняти місцями. Головне, щоб властивість "box-shadow" йшло останнім. Організація рівною «піраміди» просто допомагає візуально визначити, чи все у вас в порядку з префіксами.

Навіщо це взагалі потрібно? Уявіть, що виробники браузерів не встигли відмовитися від префіксів. Припустимо, webkit-браузери практично не відкидають префікси, у них така політика. Тобто вони свідомо не надходять так, як їм рекомендує W3C. Думаю, вони не роблять цього тому, що є старі версії iTunes, які частково використовують webkit, і треба, щоб вони справлялися з рендерингом сторінок.

В результаті браузер, який зробив нормальну реалізацію властивості, застосує "smile". А якщо це Mozilla Firefox, він дійде до властивості з префіксом "-moz-", то він може після правильного "smile" застосувати старе значення - виникне помилка. Якщо в браузері реалізовано 2 типу властивостей (з префіксом і без нього), то будуть застосовані ті властивість і значення, які розташовані останніми. Тому в кінці повинно стояти нову властивість без префікса.

Це головне правило, яке потрібно знати при використанні префіксів. Багато хто цього не розуміють. Властивість без префікса йде останнім.

Хтось може запитати: інакше що? Я покажу, що станеться в цьому випадку. Припустимо, у елемента є властивість "webkit-box-shadow", розмір тіні 400 пікселів, відступ від центру 200 пікселів, тінь чорного кольору. Є властивість "box-shadow" з тими ж самими значеннями, вони абсолютно однакові. Ось в такому порядку ми їх записали - спочатку з префіксом, потім без.

Поточний Chrome або Safari Рендер це ось так.

У нас є блок нульових розмірів, до якого застосована така тінь. Якщо ми поміняємо порядок властивостей (спочатку властивість без префікса, а потім властивість з префіксом), то у нас вийде ось що.

Візуалізація тіні залежить від порядку властивостей, тому що під версією без префікса «захована» більш якісна і сумісна реалізація. Можливо, вона навіть швидше працює. Але головна її цінність в тому, що вона сумісна з іншими браузерами.

Тобто у всіх браузерах буде ось така хороша тінь.

А в браузері, для якого ви запишете префікси в неправильному порядку, буде то щось, яке я показував.

Тому, щоб застосувати найновіші і останні специфікації, пишіть властивість без префіксів останнім. Всі властивості з префіксами потрібні для підтримки старих браузерів на Android 2.1, наприклад.

Що можна порекомендувати при роботі з префіксами? У нас є безліч властивостей для різних старих браузерів. Якщо ви робите градієнти, застосовуєте "transform", "transition origin", коду стає дуже багато. Є варіанти того, як цього можна уникнути.

Найцікавіший варіант з тих, що мені траплялися за останній час, це Prefix Free. Лія Віру, яка теж виступала тут на конференції РІТ ++, написала JavaScript-бібліотеки, яка знаходить властивості без префіксів і додає до них префіксние властивості, до того ж не всі, а тільки необхідні.

У самій бібліотеці немає списку префіксів. JavaScript перевіряє, які префікси «зрозуміє» браузер, і додає тільки їх. Це класне винахід. Тому що в більшості своїй препроцесори просто беруть і додають все, що можна. А ця бібліотека динамічна і додає тільки те, що потрібно. Тому код у нас не «розпухає». Кількість правил в блоці, нехай навіть невалидность правил, може впливати на продуктивність.

У цієї бібліотеки є деякі недоліки. Зі складним CSS начебто імпорту вона не працює, тому що всередину не забирається. По-моєму, це теж можна вирішити, але це сильно ускладнить код. Ще один недолік полягає в тому, що бібліотека навантажує отрисовку.

Припустимо, якщо ви робите якийсь JS-fiddle, щоб швидко подивитися, як працює ваш код, така бібліотека буде ідеальним варіантом. Лія Віру навіть створила свій сервіс для перегляду демонстрацій - Tablet.Com. Там використовується ця бібліотека. Якщо ви напишіть там градієнт без префіксів, він запрацює в усіх браузерах, тому що бібліотека автоматично його підставить.

Це швидке JavaScript-рішення. Для серйозних речей воно не годиться. Для них використовуються препроцесори. Зв'язка Sass і Compass працює на Ruby, вони просто запускаються на локальній машині і обробляють ваші файли. Less і Stylus можуть працювати як в якості запущених скриптів з читанням з файлів, так і при підключенні в браузері. Це дозволяє легко виконувати налагодження без необхідності кожного разу переписувати файли заново. Але у них є деякі особливості.

Препроцесори популярні, тому що всім нам подобається, коли коду мало. Проте, у них є одна головна проблема - це їх «дурість». Я зараз розповім про кожного з них.

Почнемо з Compass. Compass дозволяє писати властивості в двох нотациях. Через «собаку» - @include border-radius, також можна писати властивість через знак «плюс», що заодно допоможе відмовитися від фігурних дужок. В обох випадках ми отримаємо додавання префіксів для даного властивості. Це дозволить отримати і "-webkit-border-radius", і "-moz-border-radius", і так далі. Значення ви вказуєте тут же.

Які провали є у Compass? Коли Compass додає префікси, у нас з'являються 2 властивості, яких не існує в природі. Їх ніколи не було і ніколи не буде. Властивості "-o-border-radius" і "-ms-border-radius" не потрібні в принципі. У нас є надмірність у вигляді 2 зайвих рядків коду. Творці не витратило зайвих півгодини, щоб вивчити, які властивості дійсно потрібно розгортати. Modernizer, до речі, відмовився від властивостей khtml, тому що браузера під Linux, з ідеї якого «народився» webkit, не існує. Розробники khtml самі сказали, що будуть використовувати останній webkit для свого браузера Conqueror. Таким чином, три властивості з префіксами, які пропонує Compass, зайві.

Які ще провали Compass варто згадати? Забутий префікс "-ms-" для властивостей "transform" і "transition. У властивості "box-shadow" маса непотрібних префіксів. Є непотрібний префікс "-o-" для властивості "column", яке робить кілька колонок. Для властивості "background-size" теж є непотрібний префікс "-o-", ми його підтримуємо без префікса. Якщо ви використовуєте в коді "opacity", Compass автоматично понаписує там "filter: progid: DXImage ...", причому він використовує стару і невалидность версію, без "-ms-filter- ...", без лапок і так далі. Ваш код буде зіпсований.

До речі, на пошук всіх цих помилок у мене пішло не більше 15 хвилин. Не знаю, скільки часу потрібно, щоб їх виправити. Хвилин 10, напевно. Незважаючи на всі помилки, це як і раніше одна з найпопулярніших бібліотек для роботи з префіксами.

Тепер поговоримо про бібліотеку Less. Вона дозволяє писати властивості через точку. І або в коді, або в якихось окремо підключаються речах у вас буде записуватися, що відбувається, які значення він приймає. І ось він розгортається в такі рядки з префіксами. Здавалося б, все нормально. Але на сайті, в офіційній документації використаний неправильний порядок властивостей. Ті, хто робить бібліотеку для роботи з префіксами, не знають, як працює префікс.

Ще один приклад з Less. Там все правильно, там немає зайвих префіксів, наскільки я зрозумів, але порядок властивостей вони виводять неправильний за замовчуванням. Ви можете написати власні сніппети, але правильний порядок не передбачається за замовчуванням, у всіх. А людей, які пишуть власні сніппети, одиниці.

Stylus - це, на мій погляд, самий гнучкий з існуючих препроцесорів. Це одна з найбільш адекватних бібліотек для роботи з префіксами, тому що вона дозволяє писати код дуже гнучко. Можна використовувати масу нотацій, прибирати фігурні дужки, крапки з комою, оголошувати змінні без всяких префіксів. У моєму прикладі "fonts" - це змінна, не потрібно значка долара, підкреслень або ще чогось. Просто пишете «дорівнює» і можете цю змінну далі використовувати.

Stylus - «наймолодший» препроцесор. У ньому є проблеми. Наприклад, якщо ви поставите такі дужки, все поламається. Я «відбиваю» останню дужку, мені зручніше читати код, коли дужка «відбита». А тут виходить так: «відбив» дужку - зламав цілий файл. Це несерйозно, хоча в іншому бібліотека хороша. Всім, хто робить такі бібліотеки, раджу писати пул запитів.

Префікси можна використовувати не тільки в CSS, але і в JavaScript. Якщо у вас є якась анімація, наприклад.

Як ми звикли працювати з властивостями в JavaScript? Якщо властивість складається з двох слів, розділених дефісом, ми беремо і прибираємо дефіс, а наступну букву робимо великої. Це називається «верблюдізаціей» (Lower Camel Case), тобто перша буква рядкова, а всі інші літери заголовні. Це багато де описано, ми звикли працювати з цим.

Те ж саме має відбуватися з префіксами. Ми беремо і заміняємо префікс на букву. А оскільки це перша буква, то вона буде малої, а решта великими. Вийде приблизно так.

За ідеєю, все просто. Треба написати кілька рядків коду, щоб властивості заробили у всіх браузерах. Припустимо, нам потрібно задати Transition Timing Function.

На перший погляд, все нормально. Тестуємо в браузері ... Рядки для префіксів "-moz-" і "-o-" не працюють. Саме властивість браузер підтримує, але рядки не працюють.

Спробуємо зробити перші літери великими.

Тоді перестає працювати рядок, що починається з "Ms" для IE.

Читаємо специфікацію. Дослівно там прописано, що з префіксами слід чинити так: дефіс і буква перетворюються в велику літеру. Це повинно застосовуватися всюди. За специфікації, перша буква повинна бути заголовної.

А за фактом в браузерах є відмінності. Mozilla і Opera буквально слідують специфікації, Firefox і Opera «розуміють» префікси тільки тоді, коли перша буква прописна. Internet Explorer «понімаeт» їх тільки тоді, коли перша буква рядкова. Webkit «понімаeт» обидва варіанти.

Проте, написана тільки прописними буквами рядок GETELEMENTBYID в JavaScript не спрацює. З'являються якісь подвійні стандарти: в одному місці є гнучкість, в іншому її немає. Чому б не зробити JavaScript незалежним від регістру?

Насправді, всім виробникам браузерам варто уважніше читати специфікацію. Періодично до нас звертаються розробники, які скаржаться, що у них щось не працює. Ми їм відповідаємо, що все реалізовано в суворій відповідності зі специфікацією, а не з орієнтацією на інші браузери. Таке періодично трапляється. Розробникам мої роз'яснення не допомагають, природно. Я себе відчуваю винним через те, що ми зробили щось не так, як в інших браузерах.

Гряде страшний!

А зараз я змушений попередити вас про те, що скоро все буде дуже погано. Opera, Mozilla і Microsoft збираються підтримувати властивості з префіксом "-webkit-". Компанія Mozilla заявила про це. Вони в цьому зацікавлені, тому що їм здається, що їх ігнорують розробники, які пишуть для iPhone. Opera і Microsoft теж зацікавилися підтримкою цього префікса. На заході CSS Working Group це обговорювалося. Можливо, я зараз видаю інсайдерську інформацію, але це питання вже вирішене. Це трапиться дуже скоро.

Безумовно, коли ми почнемо підтримувати властивості з префіксом "-webkit-", ми випустимо тестову збірку, щоб всі могли перевірити, що «відвалиться» у них на сайтах, що почне працювати краще, і так далі.

Насправді, це не просто якась вільність. Було проведено Спеціальне дослідження. Аналітікі компании Alexa взяли Топ 100 сайтів по всьому світу и порахувалі, Які Властивості там Використовують. Властівостей "-webkit-box-shadow" виявило почти 800 штук. Властивостей "-moz-border-radius" трохи менше, "- webkit-border-radius" практично стільки ж. Далі вже розрив набагато більше. Тут немає ні властивостей Opera, майже немає властивостей Microsoft Internet Explorer.

На діаграмі в процентному змісті показано розподіл властивостей, які в цілому використовують розробники. Тобто про "-moz-" пам'ятають, про "-webkit-" пам'ятають, а про "-o-" і "-ms-" практично ніколи не пам'ятають, навіть якщо браузер підтримує ці властивості.

Тому потрібно щось робити. У нас в компанії є цілий відділ Open Relations, там йде робота над проектом "Open the Web", де люди займаються тим, що пишуть розробникам: «Будь ласка, не блокуйте Opera! Ми підтримуємо цю властивість. Напишіть рядок коду!» А розробники нам відповідають: «Так? А ми думали, що Opera - це мобільний браузер ... Окей!» Іноді вони не погоджуються, посилаючись на малу поширеність Opera. Так, наш браузер по-різному поширений в різних регіонах світу, але це не привід не давати йому то, що він може «зрозуміти»!

Тому і ми, і компанія Mozilla (яку згадують часто), вирішили зайнятися цим сумнівним справою з підтримкою властивостей "-webkit-". Можливо, від цього багато поламається, але багато і виправиться.

Ми вже робили так раніше. Подивіться будь-User Agent браузера - що там написано? Там написано "like Mozilla", тобто все ідентично. Це спосіб зробити User Agent сумісним з сайтами, які його перевіряють і так далі. Зараз User Agent кожного браузера є «кашу». Там безліч рядків, які відповідають тільки за те, щоб старі сайти не зламалися. Довгий час браузери підтримували "document.all", деякі до цих пір його підтримують. Якщо ви протестуєте підтримку "document.all", ми скажемо, що її немає, а якщо ми їй скористаємося, виявиться, що вона буде. Для забезпечення сумісності.

Буде надано підтримку проектам в повному обсязі властивості "-webkit-", а тільки вибрані і потрібні. Якщо ми поки не підтримуємо 3D-трансформацію (над цим наші фахівці поки працюють), ми не будемо робити вигляд, що ми її підтримуємо. Буде надано підтримку проектам тільки ті властивості, які «розуміє» наш браузер, ті, які поліпшать сумісність.

Якщо зараз через Opera Mobile зайти на сайт, зроблений для iPhone, виявиться, що у нас білий текст на білому тлі.

Якщо автоматично додати потрібні префікси якимось простим скриптом, все буде працювати добре, - буде чорний текст на синьому тлі, наприклад.

Ми намагаємося поліпшити те, що бачить користувач, ми не намагаємося зіпсувати життя розробникам. Я сам розробник, я сам був не в захваті від цієї ідеї спочатку. Поступово звикаю до цієї думки.

Властивості "-webkit-" будуть застосовуватися тільки в разі відсутності властивостей для Opera. Якщо будуть знайдені властивості для Opera, вони будуть застосовуватися насамперед. Каскади будуть зберігатися, сайти для iPhone зароблять.

Я передчуваю, що що-небудь обов'язково зламається. Тому ми при початку підтримки властивостей "-webkit-" постараємося повідомити про це всім. Потрібно, щоб всі встигли протестувати свої сайти.

Може трапитися ще дещо інше. Нещодавно я говорив з людиною з CSS Working Group, який займається в тому числі і специфікаціями, він мій колега. Він розповів, що в CSS Working Group є й інша ідея щодо роботи з префіксами. Поясню на прикладі.

Браузер «ікс» впровадив властивість "lol-cat: smile" без префікса, але в якийсь момент виявилася помилка. Щоб виправити цю помилку, він запровадить виправлену версію цієї властивості з префіксом. Тоді розробники зможуть виправити помилку, використавши префікс.

Як видно з прикладу, порядок властивостей тут інший. Поточний підхід передбачає використання «піраміди» вістрям вниз, а підхід, який, можливо, запропонує CSS Working Group, пропонує іншу «піраміду» - вістрям вгору. Так що невідомо, що буде вважатися правильним в перспективі. Поки правильно те, про що я говорив на початку доповіді. Що буде через рік, два або три, ми не знаємо. Префікси не дадуть нам нудьгувати. Пам'ятайте головне: властивість без префікса йде останнім.

Наведу посилання на статті, в яких є більш докладна інформація про роботу з префіксами. Перша стаття Еріка Мейєра дана в перекладі. В інших ведеться дискусія про префіксах, яка триває вже півроку. Люди буквально б'ються за те, щоб або прибрати префікси зовсім, або, нарешті, зробити їх зручними.

Велике вам спасибі за увагу. Чекаю питань.

Питання та відповіді

Репліка із залу: Привіт. Хочу зробити коментар. Почну з того, що "khtml" був давно прибраний з Compass, а "transform" був виправлений. Opacity з префіксами не працює вже, їх не потрібно додавати.

Вадим Макєєв: Там з opacity проблема в тому, що додається невалідний CSS-код.

Репліка із залу: Цей невалідний CSS-код потрібен, щоб підтримувався старий IE.

Вадим Макєєв: Все, зрозумів.

Питання із залу: Питання про інше. Чи є які-небудь ідеї (може бути, ти їх знаєш), чомусь їх не впроваджують ... Чому б не зробити загальний префікс для всіх браузерів, наприклад, "-beta-" і залишити префікси для всіх браузерів на випадок, якщо якісь -то браузери реалізують це властивість неправильно?

Вадим Макєєв: Тоді тобі в коді доведеться писати не 6, а 7 рядків.

Репліка із залу: Але більшість властивостей реалізовано всіма браузерами однаково.

Вадим Макєєв: Розумієш, якщо у тебе якийсь великий проект, і тобі важлива повна сумісність, ти будеш писати все властивості ... Тобто ти пропонуєш цю ситуацію ще більше погіршити ...

Репліка із залу: Але потім щось буде краще, коли «помруть» старі браузери, які не підтримували загальний префікс ...

Вадим Макєєв: Насправді, таких дискусій дуже багато. Головна ідея, з якою згодні всі: префікси в поточному стані всіх «дістали». З ЦІМ нужно щось робити. Є ще приголомшливий аргумент: префікси - це експериментальні властивості. У вас стабільний проект, навіщо йому експериментальні властивості? Ми ввічливо посміхаємося хлопцям з W3C і говоримо: «Звичайно, ви молодці, що пишете специфікації, але сайти ви хоч раз розробляли?» Дискусій багато. Я розповів про те, що є. Про те, що буде, я не можу розповісти. Я не гадалка.

Репліка із залу: Я, наприклад, намагаюся писати префікси вручну і бути в курсі, що зараз де використовується ...

Вадим Макєєв: Таких, як ти, мало.

Питання із залу: Штука в тому, що пам'ятати про це і стежити за змінами не завжди просто і не завжди потрібно. Насправді, нас ще в університеті вчили, що не потрібно нічого запам'ятовувати. Потрібно думати і шукати інформацію. Зараз для того, щоб знайти список актуальних префіксів, потрібно перебрати приблизно п'ять статей, гарненько «полазити» по сайтам виробників ... Чи не було коли-небудь думки створити зведений проект по префіксам, де можна буде подивитися, в яких версіях двигунів що працює або не працює? Просто хочеться знати, що підтримується ...

Вадим Макєєв: Потрібно «перелопатити» величезну кількість даних. Останнім часом на Заході дуже популярні проекти типу «Все властивості такого-то браузера», «Все префікси такого-то браузера», підтримка CSS 3, HTML 5, і так далі. Зараз багато таких проектів. Не здивуюся, якщо в якийсь момент з'явиться і те, про що ви говорите. Є парочка сторінок, на яких збираються всі властивості з префіксами всіх відомих браузерів. Дві з них я знаю. Посилань на них я не давав, але їх можна знайти досить легко. Зведеного проекту немає, але я б із задоволенням взяв участь в його створенні.

Репліка із залу: Я б теж хотів взяти участь в його створенні. Є основний момент ... Збирати ці властивості з якихось сторонніх сторінок вкрай неприємно. Скажи, наскільки можливо спілкування безпосередньо з виробниками браузерів, залучення їх до участі в такому проекті? Або хоча б «витягати» дані з конкретних місць, де вони будуть їх розміщувати.

Вадим Макєєв: Я так розумію, що ти б хотів, щоб самі виробники браузерів викладали який-небудь файл XML або JSON з усіма префіксами? Це буде дуже накладно, ми ж все дуже зайняті люди. Але я знаю, кого смикнути за рукав, щоб отримати актуальні списки - в принципі, це реально. Але ось оновлювати їх все-таки доведеться вручну.

Питання із залу: Що ти маєш на увазі? Доведеться кожного разу запитувати у фахівця список, або в якомусь вигляді на якомусь ресурсі цей список буде фігурувати?

Вадим Макєєв: Припустимо, у нас є сторінка, на якій є все властивості з префіксами.

Репліка із залу: Ви практично святі в цьому плані. Не варто узагальнювати.

Вадим Макєєв: Документація хороша, мені правда подобається. Так, іноді ми додаємо туди властивості із запізненням на тиждень, на місяць. У нас сильно завантажений людина, яка займається документацією.

Репліка із залу: Ок.

Репліка із залу: До речі, щодо гордості за документацію: мої переклади ви так і не опублікували!

Вадим Макєєв: Ми з вами зв'яжемося!

Репліка із залу: З приводу єдиного сайту, де вказані всі префікси ... На сайті Mozilla Developer Center завжди вказані префікси і версії, в яких все це працює. Єдиний виняток - там практично не відображено інформація для якихось технологій, які не працюють в Mozilla, але їх досить мало.

Вадим Макєєв: Насправді, найпростіший спосіб знайти префікси прямо зараз - це зайти на сайт webstandards.ru і ввести в рядку пошуку слово «префікси». Приблизно півроку або рік тому ми писали новина з посиланнями на сторінки, де описані всі браузерні префікси. Ще питання?

Питання із залу: Коли Opera почне префікси webkit, вона буде підтримувати їх так, як це у вас вже реалізовано, або так, як це реалізовано в webkit?

Вадим Макєєв: Ні, ми просто будемо «мапіть» існуючі властивості на властивості webkit. Є ще один момент ... Ми зараз працюємо над новою специфікацією Flexbox, вона вже настільки фіналізована, що її можна впроваджувати. За останні півроку її переписали практично з нуля. Там є загальні слова, але суть там дуже сильно змінилася. Коли ми впровадимо нову специфікацію Flexbox, ми подивимося сайти і, можливо, зробимо сумісність зі старою. Ми не просто будемо реалізовувати специфікацію, а «замапім» потрібні властивості у вигляді посилання.

Припустимо, ви пишете якийсь webkit Flexbox або просто Flexbox в старій нотації, а він раз - і починає працювати по специфікації. Ми не будемо писати другу реалізацію, що не будемо «Форкал».

Репліка із залу: У мене не питання, а невелике застереження. Ви компетентний фахівець, і в вашому доповіді прозвучали нотки антиагітації проти використання Less і інших подібних інструментів, правильно? Було таке, нехай і в неявному вигляді. А інструмент хороший, просто в ньому є деякі нюанси, які ви перерахували. Але сам інструмент дуже полегшує життя. Я дивився в вихідні Less. На перших порах було багато проблем з парсинга CSS, були якісь помилки, не можна було вставити коментарі всередину значення CSS-властивості. Всі «валилося», та й зараз так, по-моєму. Вся проблема Less в тому, що вони розбирають CSS регулярними виразами. Напевно, інші препроцесори працюють схожим чином. А це, по-моєму, абсолютно неправильно. У CSS занадто складна структура для того, щоб розбирати його на регулярні вирази.

Вадим Макєєв: У молодої людини, який з мікрофоном ходить, є проект CSScomb, який розбирає CSS не регулярними виразами, а за рядком. Не просто намагається зрозуміти, як CSS працює, але розбирає його на якісь прості структури.

Репліка із залу: На прості структури можна розбити CSS, описавши CSS у вигляді БНФ, тобто форми Бекуса-Наура. У Mozilla Developer Network всі специфікації у вигляді псевдо-БНФ ... Якщо так описати, то буде дуже гнучкий інструмент для аналізу і трансформації CSS.

Вадим Макєєв: Якщо там написано вираз (англ. Expression), в яке вставляється таблиця ... Так?

Репліка із залу: Як раз SCSS під проекти SASS (оперативний синтаксис, сумісний з CSS) не використовує регулярні вирази, він чесно все парсит, і коли він вийшов, було заявлено, що його парсер впорається з будь-яким дійсним CSS-документом, включаючи невалидность розширення для IE.

Вадим Макєєв: Тобто якщо там «лапки» таблиця на 300 рядків, він не зламається?

Репліка із залу: Якщо це нормально обробляється в браузерах, то проблем не буде.

Питання із залу: У мене питання: чому ви не перейдете на движок webkit?

Вадим Макєєв: Тема занадто велика. Спробую відповісти коротко. Тому, що це не має сенсу взагалі. Нам доведеться звільнити всіх наших інженерів. Втім, є більш важливий аспект. Я не з того пункту почав. Проект webkit контролюється компаніями Apple і Google. Щоб отримати право відправляти поновлення (англ. Commit) в основне ядро ​​проекту, потрібно мати перевіряючих (англ. Reviewer) де-небудь в Каліфорнії, платити їм як віце-президентам нафтових компаній. Також варто мати на увазі, що 90% перевіряючих ядра webkit пов'язані з Apple і Google. Все, що їм не сподобається, вони будуть відхиляти. Щоб почати розробляти движок, не можна просто «форкнуть» Google і почати його писати. Це здається класним і цікавим. Але це спричинить за собою величезну кількість проблем. Ми обговорювали цю можливість, це адекватно. Ми не хочемо підтримувати щось своє, але погане. Ми хочемо, щоб користувачам було зручно. Але для того, щоб їм було зручно, ми повинні мати можливість гнучко розробляти те, що ми хочемо. Перехід на webkit нам цієї гнучкості не дасть. Ми просто розоримося.

Репліка із залу: У мене не питання, а зауваження з приводу дискусії про webkit і так далі. Я ще пам'ятаю часи, коли дуже поширеним браузером був IE5. Монополія движка якогось одного браузера ні до чого доброго не приводить. Зараз прекрасний час. Конкуренція дає масу переваг. Ми зараз ними користуємося, і будемо користуватися ще досить довго. Добре, що у нас є різні браузери. Здорово, що вони продовжують з'являтися і що вони роблять один одного краще.