Мови, що мало не стали CSS - CSS-LIVE
Якщо ви так і не зрозуміли, що робить цей код, не страшно. В епоху до gzip-стиснення, при типових швидкостях з'єднання порядку 14.4k, стискати до краю вміст цього формату мало сенс. Це конкретне правило задає шрифту (fa) значення "helvetica" (he), а розміру (si) шрифту - значення 18 пунктів.
Цікаво, що у цій пропозиції зовсім не згадувалися одиниці виміру, проте цифри інтерпретувалися за контекстом (наприклад, розміри шрифтів завжди були у пунктах). Це можна пояснити тим, що RRP створювався швидше як «набір ПІДКАЗОК або РЕКОМЕНДАЦІЙ для движка малювання», а не як конкретні вказівки. А це вважалося необхідним, адже одні й ті ж стилі мали працювати як у типових консольних браузерах (на кшталт Lynx), так і в графічних, що стрімко набирали популярності.
Що цікаво, в RRP вже входив метод для завдання колонкової розкладки, без чого CSS мимоволі обходився до 2011-го. Наприклад, три колонки по «80 одиниць» кожна, виглядали б приблизно так:
Розібрати важкувато, але, мабуть, не особливо гірше того ж white-space: nowrap.
Варто зазначити, що в RRP не було жодної «каскадності», яка сьогодні для нас тісно пов'язана із стилями. В одного документа в один момент часу могла бути тільки одна активна таблиця стилів, що цілком логічно для оформлення документа, нехай навіть зараз це нам і незвично.
Марк Андрессен (творець Mosaic, який мав стати найпопулярнішим браузером) знав про пропозицію RRP, але в Mosaic її так і не реалізували. Натомість Mosaic швидко перейшов (як не прикро) на визначення стилів HTML-тегами, вводячи теги типу і .
Viola та війни першобраузерів
То чому вам просто не реалізувати хоч щосьз купи пропозицій для таблиць стилів. Адже це вирішить проблему, якщо зробити все правильно.
І тут я можу вдосталь пояснити: «Ну, спочатку вам доведеться вивчити одну мову, щоб написати сам документ, а потім ще іншу мову, щоб нарешті змусити документ виглядати як треба». Так, люди ну просто в захваті від такої перспективи.
Попри розхожу виставу, Mosaic був не першим графічним браузером. До нього була ViolaWWW, графічний браузер, спочатку написаний Пей-Юан Веєм лише за чотири дні.
Пей-Юан вигадав мову стилів з підтримкою вкладених структур на кшталт тих, що ми сьогодні звикли бачити в CSS:
Тут ми застосовуємо вибрані кольори body і по-особливому оформляємо заголовки H1, що опинилися в body. PWP працює з вкладеністю не повторами селекторів, а системою дужок, що нагадує систему відступів з мов типу Stylus і SASS, що багато сучасних розробників віддають перевагу чистому CSS. Так що синтаксис PWP вже як мінімум в одному міг би перевершити CSS, якому судилося стати загальною мовою, лінгва франка для Інтернету.
PWP також відзначився тим, що ввів спосіб підключення зовнішніх стилів, яким ми користуємося досі:
На жаль, ViolaWWW була написана лише під віконний менеджер X Windowing, а той був популярним лише на Unix-системах. Щойно Mosaic портували на Windows, як він швидко відібрав у Віоли останні шанси.
Таблиці стилів довебських часів
HTML це щось таке, що може бути до смаку хіба що програмісту. Так, він висловлює внутрішню структуру документа, але документи не просто бази даних структурованого тексту; їм важливий і зовнішній вигляд. HTML геть-чисто позбавляє творців документа будь-яких можливостей візуальної творчості.
Мова для опису стилюдокумента був потрібний ще задовго до Інтернету.
Як ви, можливо, в курсі, відомий нам HTML спочатку був заснований доінтернетною мовою під назвою SGML. 1987-го в міністерстві оборони США вирішили з'ясувати, чи можна за допомогою SGML спростити зберігання та передачу колосальних обсягів документації, з якими їм доводилося мати справу. Як у будь-якому урядовому проекті, що поважає себе, насамперед вони стали вигадувати назву. Спочатку команда називалася "Computer-Aided Logistics Support" (підтримка логістики з комп'ютерною допомогою), потім "Computer-aided Acquisition and Logistics Support" (підтримка обліку нових надходжень та логістики за допомогою комп'ютерів) і нарешті "Continuous Acquisition and Life-cycle Support »(Проект з безперервного обліку нових надходжень та підтримки життєвого циклу). Але перші літери у будь-якому разі були CALS.
Одне з непорушних правил Інтернету каже: завжди домагаєшся більшого, якщо під час роботи вдасться довести, що хтось неправий. У 1993-му, всього через чотири дні після пропозиції Пей-Юана, Стівен Хіні запропонував, що краще не «винаходити велосипед», а застосувати для оформлення Інтернету варіант FOSI.
Самі FOSI-документи писалися на SGML, що було навіть у чомусь цілком логічним з огляду на те, що веб-розробники вже знали інший варіант SGML — HTML. Ось приклад такого документа:
Якщо ви трохи дивуєтесь, що таке docdesc або charlist , то учасники листування в www-talk відчували те ж саме. Про контекст цього їм повідомили лише те, що e-i-c означає «елемент у контексті». Однак саме FOSI вперше ввів одиницю em, яка сьогодні стала улюбленим засобом для оформлення у тих, хто знає CSS краще за ваше.
Протистояння мов, що розгорталося на той час, по суті тягнеться з самогопочатку програмування Це була боротьба функціонального синтаксису на кшталт LISP із синтаксисом більш декларативних мов. Сам Пей-Юан описував свій синтаксис як "LISP-подібний", але залишалося чекати зовсім небагато, поки на сцену вийде справжній варіант LISP-а.
Т'юрінг-повна мова стилів
При всій своїй складності, FOSI розглядався лише як тимчасовий засіб для оформлення документів. На майбутнє планувалося створити мову на основі Scheme, функціональної мови програмування, яка дозволяла б найпотужніші трансформації документа, що тільки можна собі уявити. Називалася ця мова DSSSL. Як сказав один із його розробників Джон Босак:
У своєму найпростішому вигляді, DSSSL - цілком зрозуміла мова оформлення:
Оскільки він був мовою програмування, можна було навіть оголошувати функції:
І користуватися математичними конструкціями при оформленні, наприклад, щоб розфарбувати таблицю «зеброю»:
І щоб у вас зовсім вже слинки потекли, DSSSL міг поводитися з успадкованими значеннями як зі змінними, і навіть робити з ними математичні операції:
Та ж команда надалі розробляла XSL, мову для перетворення документів, не менш заплутану, але явно виявилася популярнішою.
Чому CSS виграв у гонці
У CSS немає батьківських селекторів (способу оформляти предка залежно від цього, яких нащадків він містить). Про це часто журяться відвідувачі StackOverflow, але виявляється, що його відсутність далеко не випадкова. Вважалося критично важливим, особливо на зорі Інтернету, щоб сторінку можна було відобразити до того, як документ завантажиться повністю. Іншими словами, потрібно вміти відображати на сторінці початок HTML до того, як повністю завантажиться HTML для її нижньої частини.
Батьківський селектор означав би, що доведеться оновлювати стилі в міру завантаження сторінки. Мови на кшталт DSSSL тут повністю «пролітали», оскільки могли здійснювати операції із самим документом, а моменту, коли час починати щось відображати, він ще був повністю доступний.
Синтаксис самої мови певною мірою «об'єктно-орієнтований»:
Крапка . служила для позначення безпосередніх нащадків, а зірочка * - для вказівки предків.
Ще в його мові була шикарна можливість прямо в стилях визначати, як повинні працювати елементи на кшталт посилань:
В одній із функціональних пропозицій, яку представив джентльмен із ініціалами «C.M.» і прізвищем Спірберг-МакКвін в 1994 р., ця ж поведінка описувалося по-функціональному:
Його мова також ввела ключове слово content як спосіб керувати вмістом HTML-елемента з таблиці стилів, пізніше це поняття ввели в CSS2.1
Як могло б бути
Перш ніж говорити про мову, яка дійсно розвинулась у CSS, варто згадати ще одну пропозицію мови, хоча б за те, що саме про щось подібне веб-розробники тих років мріяли.
Але далі все цікавіше та цікавіше. Наприклад, можна було виражати положення елемента, ґрунтуючись не тільки на вказаних для нього розмірах (Width), але і на фактичних (Actual Width) розмірах, з якими браузер його відобразив:
Ви, напевно, помітили, що «сусід зліва» нашого елемента може служити як точка відліку.
А ще можна додавати у стилі логічні вирази. Наприклад, щоб оформити тільки ті елементи, у яких є href:
Можна скільки завгодно продовжувати в такому дусі, і цього вистачає для будь-яких оформлювальних завдань, що сьогодні вирішуються лише класами:
Якби подібна функціональністьпідтримувалася, мрія про відокремлення оформлення від змісту цілком могла б стати дійсністю. На жаль, на своє лихо ця мова була злегка розширюваною, а це означало, що різні браузери могли реалізувати її дуже по-різному. Крім того, він публікувався у вигляді серії наукових статей, а не в розсилці www-talk, де велася основна робота з функціональних мов. І його так і не вбудували в жодний масовий браузер.
Привид CSS-івського минулого
Мова, від якої - як мінімум назвою - безпосередньо стався CSS, називався CHSS (каскадні таблиці HTML-стилів), а запропонував його в 1994 Хокон Віум Лі.
Як більшість вдалих ідей, початкова пропозиція була досить божевільною.
Зверніть увагу на відсотки наприкінці правил. Вони вказували, скільки "влада" над цим значенням отримувала поточна таблиця стилів. Наприклад, якщо попередня таблиця стилів визначала розмір шрифту заголовка h2 як 30pt, з 60-відсотковим впливом, а в новій таблиці заголовки h2 описувалися як 20px 40%, обидва значення об'єднувалися в одне з урахуванням їх «відсотків впливу», і підсумкове значення виходило -то близько 26pt.
Більш ніж ясно, що ця пропозиція з'явилася в еру простих сторінок-документів, адже в нинішньому світі додатків дизайн на компромісній основі просто немислимий. Тим не менш, у ньому полягала фундаментальна ідея, що стилі мають бути каскадними. Іншими словами, мабуть можна застосувати кілька таблиць стилів до однієї й тієї ж сторінки.
У початковому формулюванні основна важливість цієї думки в тому, щоб кінцеві користувачі могли управляти видимим результатом. У вихідній сторінці буде одна таблиця стилів, у користувача - своя власна, і для відображення сторінки вони об'єднаються. Підтримка кількох таблиць стиліврозглядалася як додатковий елемент особистої свободи в Інтернеті, а не як спосіб полегшити життя розробникам (ті, як і раніше, писали код окремих HTML-сторінок вручну).
Як і в багато з тодішніх пропозицій, до нього входили можливості, які не потраплять до CSS ще багато десятиліть (якщо взагалі потраплять). Наприклад, писати логічні вирази з урахуванням користувача оточення:
У майбутньому, яке бачилося в оптимістичному науково-фантастичному ключі, очікувалося, що браузер зможе визначити найважливіший для вас шматочок інформації та показати його більшим шрифтом:
Ви знаєте, що було далі
Microsoft повністю відданий відкритим стандартам, особливо в Інтернеті.
CSS сам по собі є нагадуванням про те, як багато в нових технологіях залежить від випадку. Наприклад, підтримку контекстних селекторів (body ol li) додали лише тому, що у Netscape вже був спосіб прибрати рамки у картинок-посилань, і здавалося необхідним реалізувати все, що популярний браузер вже вмів. А ця функціональність сама по собі помітно затримала використання CSS, оскільки більшість браузерів тієї пори при розборі HTML не зберігали «стек» батьківських тегів. І це означало, що задля повної підтримки CSS довелося переробляти парсери.
Останній головний суперник
Якщо Netscape 4 ігнорував CSS-правила для елемента і додавав кожному структурному елементу на сторінці порожній простір від балди, а IE4 розумів код для , але плутався у відступах, то який же CSS можна було писати без побоювання? Хтось із розробників взагалі відмовився писати його. Інші писали одну таблицю стилів, щоб виправити огріхи IE4, і іншу, щоб прикрити ляпи Netscape 4.
Можна було навіть визначати функції, що обчислюються щоразу, коли траплявсявідповідний тег:
На думку, що розмежування скриптів і стилів треба було б пом'якшити, однозначно є розумне зерно, і нині вона навіть відроджується у різних випадках у React-сообществе.
Як могло б бути
Завдяки деяким цілющим стусанам від W3C, Internet Explorer 5.5 в 2000 р. вийшов з майже повною підтримкою CSS1. Звичайно, браузерні реалізації CSS відчайдушно глючили, і працювати з ними було важкувато як мінімум ще десятиліття. На щастя, зараз стан справ дуже покращився, і мрії розробників, що одного разу можна буде написати код і він працюватиме (майже) однаково у всіх браузерах, починають збуватися.
Особисто мені вся ця історія допомогла усвідомити, наскільки довільними і ситуативними були багато рішень, що визначали долю наших нинішніх інструментів. Якщо наш CSS був задуманий таким лише для обмежень 1996 року, то, мабуть, через 20 років ми вправі діяти трохи інакше.
У наступному дописі ми з'ясуємо, що ховалося за колосальним прогресом, що дозволило мідним проводам розвинутися від морзянки до сучасних 10-гігабітних ліній. Підпишіться, щоб її не пропустити.