Езици, които почти се превърнаха в CSS - CSS-LIVE
Ако все още не разбирате какво прави този код, не се притеснявайте. В ерата преди gzip компресията, с типична скорост на връзката от около 14,4k, имаше смисъл съдържанието на този формат да се компресира до краен предел. Това конкретно правило задава шрифта ( fa ) на "helvetica" ( he ) и размера на шрифта ( si ) на 18 точки.
Интересно е, че това изречение изобщо не споменава мерни единици и всички числа се тълкуват според контекста (например размерите на шрифта винаги са в точки). Това може да се обясни с факта, че RRP е създаден по-скоро като „набор от СЪВЕТИ или ПРЕПОРЪКИ за машината за изобразяване“, а не като конкретни инструкции. И това се смяташе за необходимо, тъй като едни и същи стилове трябваше да работят както в типични конзолни браузъри (като Lynx), така и в графични, които бързо набираха популярност.
Интересното е, че RRP вече включва метод за задаване на оформление на колони, без което CSS неволно успя до 2011 г. Например три колони от „80 единици“ всяка ще изглеждат така:
Трудно е да се анализира, но може би не е много по-лошо от същото бяло пространство: nowrap.
Струва си да се отбележи, че в RRP не е имало „каскадиране“, което е тясно свързано със стиловете за нас днес. Един документ в даден момент може да има само един активен лист със стилове, което е съвсем логично за дизайна на документи, дори и да е необичайно за нас сега.
Марк Андресен (създателят на Mosaic, който трябваше да стане най-популярният браузър) знаеше за предложението за RRP, но Mosaic така и не го приложи. Вместо това, Mosaic бързо премина (за съжаление) към дефиниране на стилове с HTML тагове, въвеждайки тагове като и .
Виола и войните на браузърите
Така че защо просто не приложите поне нещоот куп предложения за таблици със стилове. Това ще реши проблема, ако се направи правилно.
И тук мога да обясня напълно: „Е, първо трябва да научите един език, за да напишете самия документ, а след това друг език, за да направите документа най-накрая да изглежда добре.“ О, да, хората просто се радват на такава перспектива.
Противно на общоприетото схващане, Mosaic не е първият графичен браузър. Преди него беше ViolaWWW, графичен браузър, първоначално написан от Пей-Юан Уей само за четири дни.
Pei-Yuan излезе със стилов език, който поддържа вложени структури като тези, които сме свикнали да виждаме в CSS днес:
Тук прилагаме избраните цветове към тялото и придаваме специален стил на заглавията H1, които завършват в тялото. PWP не работи с влагане на повторения на селектора, а със система от скоби, напомняща системата за отстъпи от езици като Stylus и SASS, които много съвременни разработчици предпочитат пред чистия CSS. Така че синтаксисът на PWP вече би превъзхождал поне по един начин CSS, който се оказа универсалният език, лингва франка за мрежата.
PWP беше забележителен и с въвеждането на начин за включване на външни стилове, които все още използваме днес:
Уви, ViolaWWW беше написан само за мениджъра на прозорци X Windowing, който беше популярен само в Unix системи. Веднага след като Mosaic беше пренесен към Windows, той бързо ограби Виола от последните й шансове.
Стилови листове преди уеб
HTML е нещо, което може да бъде по вкуса само на програмист. Да, той изразява вътрешната структура на документа, но документите не са просто бази данни от структуриран текст; Външният вид също е важен за тях. HTML напълно лишава създателите на документа от всякаква визуална креативност.
Език за описание на стиладокумент е необходим много преди интернет.
Както може би знаете, HTML, който познаваме, първоначално е базиран на език преди интернет, наречен SGML. През 1987 г. Министерството на отбраната на САЩ решава да разбере дали SGML може да опрости съхранението и прехвърлянето на огромните обеми документация, с която трябва да се справят. Както при всеки уважаващ себе си правителствен проект, първото нещо, което направиха, беше да измислят име. Първо екипът се наричаше Компютърно подпомагана логистична поддръжка, след това Компютърно подпомагано придобиване и логистична поддръжка и накрая инициативата за непрекъснато придобиване и поддръжка през целия жизнен цикъл. Но първите букви така или иначе бяха 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." и фамилното име Spirberg-McQueen през 1994 г., същото поведение е описано по функционален начин:
Неговият език също така въведе ключовата дума content като начин за контролиране на съдържанието на HTML елемент от стилов лист, концепция, въведена по-късно в CSS2.1
Как е възможно
Преди да говорим за езика, който наистина се разви в CSS, си струва да споменем още едно предложение за език, дори само заради факта, че уеб разработчиците от онези години мечтаеха за нещо подобно.
Но след това става все по-интересно. Например, беше възможно да се изрази позицията на елемент въз основа не само на размерите, посочени за него ( Width ), но и на действителните ( Actual Width ) размери, с които браузърът го показва:
Може би сте забелязали, че "левият съсед" на нашия елемент може да служи като отправна точка.
Можете също така да добавяте логически изрази към стиловете. Например, за да стилизирате само тези елементи, които имат href:
Можете да продължите в този дух колкото искате и това е достатъчно за всякакви дизайнерски задачи, които днес се решават само от класове:
Ако такава функционалностподдържана, мечтата за отделяне на дизайна от съдържанието може да се сбъдне. За съжаление, този език беше, за съжаление, малко твърде разширим, което означаваше, че различните браузъри можеха да го реализират по много различен начин. Освен това той беше публикуван като поредица от научни статии, а не в пощенския списък www-talk, където беше извършена основната работа по функционалните езици. И никога не е бил вграден в който и да е масов браузър.
Призракът от миналото на CSS
Езикът, от който, поне по име, директно произлиза CSS, се нарича CHSS (Cascading HTML Style Sheets) и е предложен през 1994 г. от Haakon Wium Lee.
Като повечето страхотни идеи, първоначалното предложение беше доста лудо.
Обърнете внимание на процентите в края на правилата. Те посочиха колко "сила" има текущият стилов лист над тази стойност. Например, ако предишният лист със стилове дефинира размера на шрифта на h2 заглавие като 30pt, с 60 процента влияние, а новият лист със стилове описва h2 заглавия като 20px 40%, и двете стойности ще бъдат обединени в една въз основа на тяхното „процентно влияние“ и крайната стойност ще бъде някъде около 26pt.
Повече от ясно е, че това предложение се появи в ерата на простите страници на документи, тъй като в съвременния свят на приложения компромисният дизайн е просто немислим. Въпреки това, той съдържаше основната идея, че стиловете трябва да бъдат каскадни. С други думи, трябва да е възможно да се приложат множество таблици със стилове към една и съща страница.
В първоначалната формулировка основното значение на тази мисъл беше, че крайните потребители могат да контролират видимия резултат. Оригиналната страница ще има един стилов лист, потребителят ще има свой собствен и те ще бъдат комбинирани, за да изобразят страницата. Поддръжка за множество стилови таблицисе разглежда като допълнителен елемент на лична свобода в мрежата, а не като начин за улесняване на живота на разработчиците (те все още са писали кода за отделни HTML страници на ръка).
Подобно на много от предложенията по онова време, то включва функции, които няма да влязат в CSS десетилетия (ако изобщо). Например, напишете логически изрази, като вземете предвид потребителската среда:
В бъдеще, което се виждаше в оптимистична научна фантастика, се очакваше браузърът да може да идентифицира частта от информацията, която е най-важна за вас, и да я покаже с по-голям шрифт:
Знаете ли какво стана след това
Microsoft е дълбоко ангажирана с отворените стандарти, особено в Интернет.
Самият CSS служи като напомняне колко голяма част от новите технологии са ad hoc. Например, поддръжката за контекстни селектори ( 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-гигабитови линии. Абонирайте се, за да не го изпуснете.