Едно пътешествие от трикове към стандарти. От Джефри Зелдман.
Редизайн с CSS в пет лесни стъпки
ИМА ПЪТЕШЕСТВИЯ, които докосват и най-скритите места на човешката същност. И това е едно от тях. Това е пътят от традиционния уеб дизайн - какъвто го познаваме през последните шест години, - към дизайна на бъдещето. С единствената разлика, че няма да го строим утре. Вие вече вървите по него.
От начало ние правехме каквото трябваше да правим, за да накраме нашите сайтове да работят с всеки баузер. В света на нестандартния HTML дизайн ние заковавахме всяка дума, всяка картинка използвайки клетките на таблицата.
И така решавахме проблемите, заменияйки ги с нови. Netscape 4 игнорира
CSS декларацията {margin: 0;}? Тогава ще прибавим към тага
BODY "Четирите конника, които никога няма да минат през валидацията":
LEFTMARGIN, TOPMARGIN, MARGINWIDTH, MARGINHEIGHT. IE4 не подържа напълно
CSS атрибута border? Прецакайте го като го заградите вашата бяла таблица
с друга - черна. Вярно, не би трябвало да работи, но го прави, само дето този сайт
трябваше е готов още вчера. Пиши, тествай, пиши.
Къде бяхме
Така се правеха сайтовете от 1995 година насам, но така се правят и днес. Това е объркан и объркващ бизнес, заради чиято нелогичност WYSIWYG реактори като Dreamweaver, GoLive и FrontPage намериха купувачи. В същото време ние, пишещите на ръка се гордеем не с това, че правим нещо качествено и стандартно, а защото знаем кой нестанартен таг или JavaScript да използваме, за да накараме тъпия браузер да покаже страницата.
Оплакваме се от WYSIWYG редакторите, но сами пишем подобен код. Когато не знаем как да направим нещо, вместо да се обърнем към стандартите на W3C или ECMA, ние си разменяхме кракове по форуми и мейлинг-листи. А когато се появи някой брауър, който наистина поддържа стандартите, ние се оплакваме от това как е разбил нашите заобикаляния на HTML и браузер-специфичния ни DHTML код.
Това е величествено глупав начин за работа. Но когато трябва да променим дизайна става по-лошо. Трябва да се справим с цялото старо съдържание, червиво с FONT тагове и наблъскано в клетките на таблицата. И докато го вкараме в новите шаблони, трябва да препишем всяка таблица, всяка страница, ВСИЧКО.
Къде грешахме
Всички знаем, че бъдещето принадлежи на стандартите в мрежата. А стандартите служат за разделянето на оформлението от съдържанието - представянето от структурата - дизайна от данните.
Всички знаем, че в момента на пазара има браузъри, които повече или по-малко поддържат станартите. IE5, Netscape 6 и Opera 5 поддържат CSS, HTML и JavaScript/ECMAScript толкова добре, че ни позволяват да изоставим тромавите методи на миналото и да освободим мрежата от оковите на HTML дизайна.
Знаем, че милиони разглежат мрежата с 4.0 и по-стари браузъри. И това ни пречи да преминем чертата и да започнем да прилагаме "утрешните" методи сега.
Аз пресякох линията.
Настъпва нова ера
Тук, в ALA, аз реших да поддържам тези стандарти (включително и W3C DOM), дори ако това означава, че браузърите версия 4.0 и по-стари ще показват второкачествени страници в най-добрия случай. Не взех това решение лесно, а когато най-накрая го направих, то връхлетя върху мен като товарен влак.
Това отне много време.
За мен това пътешествие започна през 1997 година, когато Мат Хогли и аз прекарахме една година единствено, за да описваме грешките в начина, по-който Internet Explorer 3 рендваше CSS. Или може би през 1998, когато Глен Дейвис ми прати email, който по-късно доведе до сформирането на The Web Standards Project (WaSP).
Голямото договаряне
Минаваме набързо през старата история и стигаме до миналия месец, когато Емили Котлър и Кели Костело, подготвящи книгата си за уеб дизайна, ме попитаха как стандарти като CSS, HTML и XHTML могат да дадат отражение върху изпълнението на задачите за поддържането и променянето на сайтовете.
Дадох им стандартния отговор за разделянето на оформлението от съдържанието: когато оформлението и съдържанието не спят в едно легло, ще можем да подновяваме и променяме сайтовете си, променяйки единствено таблицата със стиловете (style sheet). Но понеже в нашите сайтове дизайн и съдържание са смесени в HTML таблици, дори и най-малката промяна става огромен проблем, казах аз. Без да споменавам факта, че заради множеството трикове и заобикалки, сайтът рядко минава валидацията.
И тогава издадох обичайните въздишки, мислейки си колко хубаво би било ако можехме да отделим оформлението от съдържанието тук в ALA.
Няма ли да е хубаво?
Когато Ник и аз издаваме новия брой всяка седмица, аз забелязвам малките недостатъци в оформлението. Откривайки подмолни начини да улесним читателите, аз прилагам тези промени само на локално ниво: подобрявам дизайна на броя за тази седмица, докато останалата част от сайта остава непроменена. Ако разгледате старите броеве на ALA, ще забележите, че те стават все по-грозни, трудни за четене и неудобни за употреба.
Ако цялото оформление се съдържаше в една Style Sheet, то ежеседмичните подобрения щяха да се отразяват и на стотиците стари страници. Но като всеки друг уеб дизайнер, който живее в истинския свят, аз не можех да премина към оформление основано единствено върху CSS, след като хиляди от нашите читатели използват 4.0 браузъри, които не поддържат адекватно CSS и другите стандарти.
Все още не виждах начина.
Свързването на точките
Тогава ми писа един разработчик на браузъри - умен младеж, който поддържа стандартите и чиито продукт пръв щеше да подържа CSS-1 напълно. Той ме попита само един въпрос: защо ALA не поддържа напълно стандартите?
"Това е сайт, който за разлика от другите, трябва задължително да е съвместим със стандартите," допълни любезно той.
Няколко дни по-късно Б.К. ДеЛонг възкреси идеята, предложена за прyв път преди няколко месеца от Дори Смит: Инициативата за ъпгрейд на браузърите.
Една проста идея
Кампанията се състои в следното: Първо един уебсайт, някой уебсайт, променя дизайна си, така че да е напълно съвместим със стандартите. Когато посетителите пристигнат, ако техните браузъри поддържат адекватно стандартите, не се случва нищо особено. Те ползват сайта както обикновено. Но ако техните брауъри не са достатъчно добри, вместо да видят страницата, която са очаквали, читателите се оказват на страницата на Инициативата, където научават за браузърите, които поддържат стандартите и имат възможността да си свалят някой от тях.
Във втория вариант, потребителят вижда страницата, която очаква, но освен това вижда и съобщение, което му казва, че брауърът, който използва не поддържа стандартите и му предлага да си свали някой, който го прави. Потребителите със страндартни браузъри въобще не виждат такова съобщение. Този вариант е използван на страницата, която четете сега (бел.пр. Da Groove Manifesto) и на всяка страница от този брой. Ако не го виждате, значи браузърът ви поддържа стандартите, използвани при създаването на тази страница.
Мисълта на Дори Смит беше проста: когато хората използват браузъри съвместими със стандартите, разработчиците могат да създават сайтове, който също са съвместими със стандартите. Затова - нека насърчаваме хората да използват стандартни браузъри по-скоро. Можем да направим това като прилагаме тези стандарти все едно всичките ни посетители използват стандартни браузери, без да се втренчваме в статистиките на сайтовете.
Рискована работа
Като всички мощни идеи, Инициативата за ъпгрейд на браузърите изглежда проста на пръв поглед. Определено беше и леснa за изпълнение. Но в това се състоеше уловката. Тя работи само ако уеб дизайнерите се опитат да я използват на сайтовете си. Дали някой сайт би рискувал да си навлече гнева на читателите, следвайки безприкословно тази идея?
Аз свързах точките.
Бихте могли да кажете, че аз така и не съм решил да обновя ALA, така че да поддържа стандартите, а просто обстоятелствата са ме принудили. Сега вече беше само въпрос на изпълнение.
За съжаление изпълнението се оказа не чак толкова лесно.
В неизвестното
Филмите на ужасите ни учат никога да не влизаме в тъмна стая сами. Затова и аз, преди да поема по напълно новия път на създаване на сайтове, намерих смели спътници, които да ме придружават из тъмните кътчета.
Две от тези смели души бяха експерти по CSS, които са помагали при съставянето на стандартите; те поискаха да останат анонимни и затова ще се обръщам към тях с Анимен Донор А и Б.
По-късно към нашето приключение се присъедини и Дейвид Айзенберг, правейки тестове и променяйки свободно нашите CSS, за да провери как работят в различните браузъри.
Стандарти vs. Стандарти
Ако се замислите ще откриете, че има два начина да се създават съвместими със стандартите сайтове: чрез единия се следва буквата на стандартите, а чрез другия се следва техния дух.
Буквата
Сигурният, консервативен начин следва буквата на стандартите в мрежата като избягва грешките при валидацията. Но що се отнася до духа на стандартите той се проваля, обковавайки оформлението към съдържанието с железни вериги.
Например, сайтът на WaSP винаги е бил съвместим със стандартите и винаги е използвал CSS, за да контролира шрифтовете. Но оформлението се постигаше чрез HTML таблици, така че сайтът да работи с всеки браузър.
Ползата: както казах току що - работи с всеки браузър. Недостатъците:
- Да се промени дизайна означаваше да се редактират на ръка хиляди отделни цветове, височини, широчини на всяка клетка от таблиците или въобще променяне на цялото оформление, което ще отнеме много време и средства.
- Техниките основани на оформление чрез HTML губят своя смисъл, когато се използват нетрадиционни браузери и се считат за вредни от W3C, независимо дали страниците са валидни.
- Тези традиционни техники правят страниците по-недостъпни за някои хора и устройства.
Духът
Но има и втори начин, Светият Граал на уеб стандартите: отделянето на оформлението от съдържанието, използвайки структурния код за данните, а CSS за всички визуални аспекти на дизайна. Аз използвам CSS от 1997 година, но никога не съм надувал звука до 11. Сега, с помощта на моите приятели, щях да направя точно това.
Гъвкавост
Традиционният външен вид на ALA беше лабиринт от сложно групирани клетки на HTML таблица. Когато преди го подновявах, дори и аз не можех да проследя смисъла толкова сложно зависими едни от други редове и колони и в крайна сметка - как съм създал това проклето нещо.
<!-- Dress left --> <table border="0" cellpadding="0" cellspacing="0"> <!-- Your variable left margin --> <tr valign="top"><td width="15%" bgcolor="#ffffcc"> </td> <td width="75%" bgcolor="#ffffcc" valign="top"> <!-- Your actual content -->
Бихте ли превели на английsки, моля? се питах аз като момче на абитюрентския си бал, при мисълта да заменя 10 000 маниакални клетки на таблицата с два или три DIV тага.
Преосмислянето на външния вид
Тук е най-доброто място да поставим въпроса за преосмислянето на външния вид. Дали да го постигаме чрез HTML или чрез CSS? Точно тук се спрях и аз, за да помисля. Традиционният HTML външен вид представляваше едно гъвкаво цяло съставено от три панела. Те се нагласяха и разтягаха, за да се настроят към вашия монитор. Аз исках да пресъздам тази гъвкавост и чрез CSS, но не държах да запазя и трите панела.
Външен вид с три панела в CSS
Бързо реших, че горният панел - този с познатия оранжев етикет - е ненужен и вероятно винаги е бил. От сега нататък етикетът ще бъде в самия панел със съдържанието.
Честно казано, създаването на оформление с три панела чрез CSS изглеждаше като нещо почти невъзможно за постигане, макар поодбни възможности да се предвиждат в CSS-3. (Всъщност, оформление с три панела се постига относително лесно както може да се види в тези примери от Портър Глендинг и от вашия скромен автор. Но по времето, когато променяхме ALA за пръв път, проблемът изглеждаше неразрешим.)
В CSS e лесно да се използва абсолютното позицииониране и тази част от стандарта се избира най-често от уеб дизайнерите. Но гъвкавият дизайн не може да се постигне с позициониране пискел по пиксел. За да може един сайт да се свива и разтяга, елементите на дизайна трябва да са с относителни размери и да са разположени помежду си също на относителни разстояния. Това се постига лесно с HTML таблици и затова ги почитат толкова дълбоко и досега. Как може да се постигне подобно нещо чрез CSS?
Редизайн: стъпка едно
Първата ми мисъл, съвсем очевидна, беше да направя два DIV: един за съдържанието и друг за зеленикавото меню вдясно. И моят първи опит почти свърши задачата си. Таблицата със стиловете е кода на самата страница, така че ще можете да я разгледате на спокойствие. DIV секцията със съдържанието беше описана по следния начин:
.content {width: 75%; padding-left: 10%; padding-right:
10px; padding-top: 10px;}DIV секцията със съдържанието заема 75% от ширината на страницата и има малко padding (уплътнение) между ръбовете (borders) и пълнежа. В същото време DIV секцията с менюто трябваше да заема 25% от ширината на страницата (и 100% от нейната височина):
.menu {position: absolute; left: 75%; top: 0px; height:
100%; width: 25%; margin: 0; padding-left: 15px; padding-right: 10px;
padding-top: 10px; background-color: #cc0; background-image:
url(backgrounds/striperight.gif); font: 10px/14px geneva, arial, helvetica,
sans-serif; color: black; }В IE5/Windows, това работеше както трябва. Но в браузърите, които са считани за далеч по-съвместими със стандартите отколкото IE5/Win, се появяваха хоризонтални и вертикални скролбарове. (Ще ги видите в IE5/Mac, Netscape и Opera 5.)
Какво стана? 100% височина са си 100%, не е ли така? 75% плюс 25% също прави 100%, нали? Защо браузърите се объркваха толкова зле?
Отговорът беше, че те не бъркаха. Аз не бях прав, защото не разбирах правилно моделa за CSS box (същото се отнася и до IE5/Win).
Боксиране с моделите за box
Запомнете това: в модела за CSS box, размерите на уплътненията (padding) и ръбовете (borders) се прибаваят към общия размер.
Една кутия широка 300 пиксела, с 20 пиксела вътрешно уплътнение (padding), е широка 300 пиксела в IE/Windows. Това изглежда правилно, но всъщност е грашно според спецификацията CSS-1.
Една кутия широка 300 пиксела, с 20 пиксела вътрешно уплътнение (padding) от всяка страна , е широка 340 пискела в съвместимите с CSS браузъри (300 + 20 пиксела от ляво + 20 пиксела от дясно). Така се получава, защото въпреки, че се появява от вътрешната страна на кутията, размерът на уплътнението се добавя към общата ширина съгласно CSS-1 спецификацията.
Много от уеб дизайнерите, които се борят с CSS се питат защо IE и Netscape 6 се справят по различен начин с DIV секциите. Отговорът е, че на Макинтош платформата това не е така. IE5/Mac и Netscape 6 (както и Opera 5) разбират правилно CSS box модела. IE5/Win го разбира погрешно. Под Windows, IE и Netscape се различават, защото Netscape разбира модела правилно. Само мога да си мечтая някога IE също да го разбира правилно.
BOX и DOCTYPE
Освен това моделът описващ кутиите (CSS box model) обяснява защо IE5 и Netscape 6 показват ръбовете (borders) по различен начин. Един ръб широк 10 пиксела принципно трябва да се добавя извън DIV секцията или параграфа, или какъвто друг block-level елемент трябва да обхваща. Ако заемете целия екран с едно изоражение и го обградите с ръб широк 10 пиксела, в напълно съвместимия с CSS браузер ще се появят скролбарове, защото общата дължина на изображението ще е с 20 пиксела по-голяма. В IE5/Win? Няма скролбарове. Начинът, по който работи IE5/Win често е предпочитан, но е грашнен.
IE5/Mac емулира нестандартното поведение на IE5/Windows, когато работи в режим Quirks (бел.пр. режим, в който стандартите се заобикалят), но се се придържа точно към стандартите в режим Strict. Вие можете да задействате режима Quirks, като не укажете DOCTYPE или пък в DOCTYPE не укажете URL към съответния W3C стандарт:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
Вие задействате режима Strict, започвайки своята страница с DOCTYPE, който включва и съответния URL към W3C:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
Браузърите базирани на Gecko (Mozilla, Netscape 6 и Konqueror) следват примера на IE5/Mac (както прави и IE6 beta). С всички тези браузъри, можете да използвате DOCTYPE, за да симулирате по избор или пълна съвместимост със стандартите, или поведението на старите, по-малко съвместими със стандартите браузъри.
Издуване до краен предел
Сега разбирате защо първият ми опит да копирам стария дизайн на ALA беше оседлан със скролбаровете. Прибавете padding-а и margin-ите към процентите, които използвах. 75% плюс 25% прави 100%. Но още 10% padding и 10 пиксела за DIV секцията със съдържанието и освен това още 25 пиксела за DIV секцията с менюто. Чудо е, че въобще проработи.
Как щях да се справя точността на цифрите и правилата? Не можех да напиша точно това в моята таблица със стилове:
{width: 75% и моля игнорирай PADDING}
Ако използвах абсолютни дължини, просто щях да посоча точните дължини и страницата щеше да е широка толкова, колкото ми трябваше. Но резултатът щеше да е една статична, наподобяваща печатна страница, която щеше да е прекалено широка за едни и прекалено тясна за други. Аз щях да създам гъвкава форма. Ако бях започнал да експериментирам с моите цифри, никога нямаше да ги нагодя. Ясно беше, че е невъзможо да се месят процентите и padding-ите по този начин без да се получат безумните ширини от сорта на 103% или пък 104.25%. Те щяха да са различни за всеки монитор, но винаги щяха да са пограшни.
В този момент Анонимните Донори А и Б решиха проблема, просто защото мислеха извън кутията.
Гъвкави и енергични
Вместо да смята, че ALA трябва да е жълтеникава страница пресечена от стоящото отдясно меню, Анонимният Донор А реши, че ALA трябва да е зеленикава страница пресечена от секцията със съдържанието, която естествено щеше да е в лявата страна. Точно тук той се възползва от слабо известния CSS атрибут "float" (бел.пр. "нося се, плувам"), за да накара съдържанието да "се носи" из желаната ширина:
#content {
float: left;
width: 67%;
padding: 45px 10% 100px 15%;
margin: 0 15px 0 0;
border-right: 2px dotted black;
border-bottom: 2px dotted black;
}
Забележете, че gif изображението, което използвах преди беше заменено от CSS атрибута border (2px dotted black). Отбележете освен това и факта, че процентите намаляха от 75% на 67%.
Всъщност, ние решихме, че идеалната дължина беше дори по-тясна от това. На монитори с разширения под 800 х 600, меню, което е само 25% ще е недостатъчно широко. В резултат елементите на менюто щяха да се преместят в края на страницата (screenshot). Оказа се, че идеалната ширина за секцията със съдържанието е 52%. Запомнете, че това са 52% без padding и margins. Може би вече ви се иска да се напиете и да се върнете след изветсно време, за да опитате отново.
Уместни въпроси
- Защо този проблем не се появи още в стария, базиран на таблици формат на ALA? Защото базираните на таблици оформления са едно немърливо начало. При оформлението на страници с таблици, ако менюто е прекалено широко, браузерът просто наглася пропорциите. Браузърите съвместими с CSS няма да се държат така само, за да спестят собствената ви глупост.
- Защо ако идеалната ширина всъщност е 52%, секцията със съдържанието е 67%? Просто: 67% е фалшива величина използвана, за да се заблуди IE5/Win и да го накара да показва ширината повече или по-малко коректно.
Запомнете, че IE5/Win разбира box модела погрешно като не отчита padding и margin в общата широчина. 67% изглежда приблизително така, както след прибавянето на padding и margin към 52%.
В този параграф описвам нещо, за което се сетихме чак след 14 часа труд. Ако искате, подишайте малко лепило и прочетете това отново, когато излезнете от интензивното.
Да запазиш точността
От това, което казах до тук, бихте могли да си помислите, че аз и моите анонимни спътници, нагласяме новия CSS външен вид така, че да работи най-добре с не толкова съвместимия със стандартите (но по-широко използван) IE5/Win.
Анонимният Донор А използва CSS-2 декларацията, за да определи правилната ширина:
body>#content {
width: 52%;
padding: 35px 5% 100px 10%;
}
Ако body># ви изглежда като печатна грешка, не сте прави.
Това е CSS-2 selector. IE5/Mac, Netscape 6 и Opera 5 разбират синтаксиса
на CSS-2. IE5/Windows - не и затова го пропуска. IE5/Win следва правилото,
което разбира: фалшивата ширина от 67%. По-съвместимите браузъри следват
онова CSS правило, което е по-конкретно. Какво значи това питате вие?
Правилото за по-голямата конкретност
Една обща Style Sheet обявява, че целият текст в <body>
на страницата трябва да бъде 1em Arial. Но е заявено, че един параграф трябва
да бъде .8em Verdana. Вие сте оформили този параграф директно и затова той
е оформен по начин, по-който вие сте му указали, а не както е зададено
за <body>.
Ако направите някой специален параграф class - да речем "legalese"
- и заявите, че "legalese" винаги e 10px висок, то резултатът
от по-голямата конкретност на <p class="legalese"> ще
бъде отпечатването на текст с височина 10 пиксела.
По-конкретното правило винаги надделява над по-общото.
В налудничавия свят на CSS, DIV секцията със съдържанието, която е част
от <body>, се счита за по-конкретна отколкото DIV секция
със съдържанието сама по себе си, макар всъщност те да са едно и също нещо.
Ако IE5/Win можеше да разбере синтаксиса на CSS-2, щеше да работи като останалите
браузъри и този трик нямаше да проработи.
Примамка за браузъри версия 4.0
И така вече направихме своята гъвкава форма чрез малко и чист CSS. Форма, която ще се изобрази правилно във всеки що-годе съвместим със стандартите браузър, но прекалено сложна за един браузър версия 4.0.
Ето на това място идваше време за инициативта на WaSP за Ъпгрейд на браузърите. А освен това Анонимните Донори А и Б имаха брилиантната идея да внушат на потребителите с по-стари браузъри желанието да минат на по-нови версии. За съжаление iframes не се поддържа в по-късните версии на XHTML и затова заменихме iframes с OBJECT тагове.
За съжаление текстът между невидимите OBJECT тагове се появяваше в съвместими със стандартите (но ограничени по възможности) браузъри и устройства като Lynx и Palm Pilot™. Така, че ние добавихме JavaScript към OBJECT таговете, за да скрием тяхното съдържание от подобни браузъри и устройства.
За нещастие, добавянето на JavaScript към OBJECT таговете, караше IE5+/Win да не показва и TITLE на страниците, а освен това да дава фалшиви съобщения за проблеми със сигурността в някои случаи, в зависимост от настройките на сигурността на потребителя.
По-късно Анонимните Донори А и Б измайсториха няколко заобиколни (но абсолютно
съвместими със стандартите) трика, които работеха с всеки браузър. Но
на този етап се бяхме предали. Сега ние заграждахме нашето съобщение за
инициативата с простия <P> таг и използвахме следния CSS код,
за да го скрием:
<p class="ahem">
<big>
This site will
work and look better in a browser that supports <a
href="http://www.webstandards.org/upgrade/" target="ala" title="The Web
Standards Project's BROWSER UPGRADE initiative.">web standards</a>, but
it is accessible to any browser or Internet
device.
</big>
</p> Как и защо това работи е обяснено на страницата със съвети на WaSP.
В защита на невинните
Трябваше да вземем още едно решение: дали да позволим на хората, използващи браузъри версия 4.0, да видят ужасния начин, по който изглеждат страниците без Style Sheet. Ние решихме да ги предпазим от това.
Има много начини да се постигне това и сред тях са JavaScript или пък server-side технологиите. Ние решихме да използваме HTML. Вместо да направим възката към таблицата със стиловете по обичайния начин ...
<link rel="stylesheet" href="/css/style.css" type="text/css" media="screen">
... ние го направихме така:
<style type="text/css" media="all"> @import "/nucss.css"; </style>
Браузърите версия 5.0+ разбират този метод, а версия 4.0 - не. Деца, пробвайте това вкъщи.
Използвайки @import метода с двойни кавички, вие предпазвате 4.0 браузърите от самите тях и имате свободата да използвате CSS по начина, по-който винаги е трябвало да се използва. Това е друг начин да се каже, че най-накрая имате свободата да използвате стандартите както трябва, а не да ги подминавате и заобикаляте още от самото начало.
А за хората, които правят уеб сайтове, това си е направо революция.
ОПАА!
По-късно разбрахме, че IE4.5/Macintosh разбира @import метода за връзка към Style Sheet. Невероятно е, но той разбира правилно и box модела. Но не разбира CSS-2 selector-ите.
И така IE4.5/Mac показва декларацията за "content" както е написано, но според CSS-1 спецификацията. За съжаление "content" декларацията, както може би си спомняте, беше написана с фалшивите величини, за да заблуди IE5.5/Windows. Ето защо IE4.5 се справя перфектно с задачата да покаже грешната декларация и затова оформлението в този браузър не е съвсем гладко.
А сега и последният удар. След като дизайнът на ALA беше променен, се появи и Ie6 beta за Windows. Също както и IE5/Mac, той поддържа промяната на режима на работа чрез DOCTYPE декларацията. Също като IE5/Mac, Opera 5 и барузърите базирани на Gecko, той разбира правилно CSS box модела. Но за разлика от тези браузъри (и точно като IE4.5/Mac), не разпознава CSS-2 selector-ите.
Затова, също като IE4.5/Mac, IE6 beta се справя перфектно с задачата да покаже грашната декларация. Браузерът е "прав", но оформлението е грешно.
За щастие успяхме да решим този проблем в стотния брой на ALA, където се използва по-проста Style Sheet и един DIV селектор, който обгръща всички части и ги държи заедно във всеки CSS-съвместим браузър. Вижте Забележките към брой No. 100 за повече информация.
На 7 април ние променихме формата и на брой номер 99 (включително и статията, която прочетохте в момента) така, че да е съгласувана с новата Style Sheet на ALA и за да се избегнат проблемите с IE6 beta и IE4.5/Mac. И докато се занимавахме с това, подновихме и текста на статията. Защо? Защото ви обичаме.
Един странен разговор
В първата седмица на Април, уеб дизайнерите, които използват CSS, експертите, които са помагали при създаването на W3C CSS препоръките и създателите на стадартни браузъри, участваха в една неформална дискусия за това кои са най-добрите начини за създаване на дизайн с помощта на CSS и как да се компенсират различията между браузърите.
Голяма част от нея беше обобщена от участвалия в дискусията Ерик Костело, а много от нас решиха да използват един наичн за прецакване на CSS box модела създаден от Тантек Чилик, един от главните разработчици на IE5/Mac и CSS-3. Изглежда по-страшно отколкото е всъщност.
CSS техниките използвани в ALA от стотния брой насам се основават на различен подход. Те работят добре в IE6 beta, IE5.5/Win, IE5/Mac, Mozilla, Konqueror, Netscape 6 и Opera 5.
Завръщането на блудния син
Заменянето на HTML таблиците с валиден CSS е добре за сърфистите и дизайнерите, но и въобще за стабилността и растежа на медията. Статията, която прочетохте току що, колкото и да изглежда безкрайна, едва докосва повърхността на проблема. Откакто тя беше написана за пръв път, се появиха няколко добри ресурса:
- BlueRobot CSS Layout Reservoir и мини-уроците за центрирането в CSS #1 и #2
- Glish CSS Layout Techniques
- Великолепните оформления от Оуен Бригс в страницата му Little Boxes, и and the Урокът за Box, който е насочен към дефектите в различните браузъри.
Пътешествието предстои
Отделянето на оформлението от съдържанието днес е в ALA, но утре или в други ден ще бъде навсякъде. Без да изглежда революционно, трудно, опасно или не user-friendly, то ще бъде начина, по който функционира медията. Така, в края на краищата, трябваше да работи мрежата от самото начало.
Тези, които мислят за мрежата предимно от гледна точка на графичния дизайн, ще трябва да разширят мирогледа си, но няма да загубят своя талант или своя възглед. Те ще получат огромен контрол и гъвкавост.
Може би вие ще се присъедините към нас, докато се опитваме да избутаме камъка нагоре по хълма, малко по-бързо отколкото това става обикновено. Може би ще се отпуснете и ще изчакате да видите как ще се развие цялата тази работа. Но независимо дали изберете ролята на активисти или не участвате въобще, сега е един добър момент да започнете да учите как тези стандарти работят всъщност и каква мощ могат да дадат на вашите сайтове.
Дори ако решите да запазите своите CSS и другите опити със стандартите offline или да ги споделите само с подбрана публика, времето за експерименти и обучение е сега. Защото много, много скоро цялата мрежа ще работи по този начин. А вие ще искате да бъдете част от нея, защото със сигурност това е един по-лесен, по-малко досаден и по-мощен начин да се създават уеб сайтове.
Разбира се, избирайки да не учите CSS и другите стандарти в мрежата, трябва да знаете, че Макдоналдс имат великолепна програма за обучение на мениджъри.
Ще се видим на барикадите, а останалите са на миля по пътя нататък.
Информация за статията
Статия в категория Код
Ключови думи: стандарти, css, markup, validation, практика
Източник: From Web Hacks to Web Standards: A Designer's Journey
A List Apart, http://www.alistapart.com
Подобни статии
Търсене
Все още не можете да намерите онова, което търсите? Защо не пробвате с това малко поленце отдолу (подсказки: въвеждайте повече думи; пишете на кирилица; използвайте по-конкретни понятия.)