В последно време много се дразня на хората, които си мислят, че изграждането на един сайт е супер проста и лесна работа. Също и от техническа гледна точка един сайт (или даже уеб приложение) е в пъти по-прост от едно десктоп приложение. Затова реших да драсна няколко реда, за някои от важните неща, за който трябва да се мисли в един сайт от frontend страната.
Като начало – html
За създаването на един сайт, трябва html. По принцип html е просто нещо, но и той като php-то е “измамно лесен”. За една добра html структура какво трябва да се гледа?
Първо дали е семантична – всеки html си има някакво значение. Това значение трябва да се ползва. Въпреки че, понякога това е много трудно. Примерно тага за списък <ul> трябва да се използва всеки път, когато има меню или списък от каквото и да е естество. За всяка форма към всеки елемент трябва да има <label> със съответния “for” атрибут, оказващ за кои елемент е този label. И т.н.
След това идва и seo-то. Много е важно html да е построен така, че една търсеща машина (google например) много лесно да може да се ориентира в самия сайт какво има. От една страна това е свързано със семантиката на html. Примерно е важно заглавието на страницата да е със <h1>, да има коректни meta тагове (по възможност различни за всяка страница), всяка връзка, ако няма текст, да има поне title атрибут. Както и всяка картинка. Също така е важно и реда на връзките в html къде ще са, за google колкото по-нагоре е връзката толкова по-голям приоритет има. Затова примерно в даден сайт в кода текста на страницата може да е преди менюто, но визуално менюто да е от ляво, а текста от дясно.
Картинки
Всеки сайт трябва да има картинки, нали така? Обаче и тук има няколко особености. Като за начало е важно да се разграничат два вида картинки – едните са част от дизайна на сайта, а другите са част от неговото съдържание. Тези, които са част от дизайна са примерно фона на сайта, различни орнаменти и други подобни. А тези които са част от съдържанието са примерно снимки на продукт, ако това е каталожен сайт или снимка от новина, ако в сайта има новини.
При добре свършена работа <img> тага се ползва само за снимки от съдържанието. Като всяка една от тях трябва да има алтернативен текст в alt пропъртито. Докато другите картинки, част от дизайна, се слагат като фон чрез css (за него по-долу).
Много важна е оптимизацията на снимките. Като за начало е почти задължително вече всички картинки от дизайна да се обединяват в sprite. Т.е. да се обединят в една снимка и тя да се прилага. Вече, в зависимост от дизайна, може да се ползват и няколко sprite-а. Така от една страна е по-лесно да се организира сайта (колкото и странно да се струва това на пръв поглед). От друга, сайтът се зарежда по-бързо, защото трябва да се изтегли само една снимка, а не примерно 10-20.
Също така е важно всяка снимка (особено sprite) да мине през нещо като SmushIt, за да и се намали размера, като и се изчистят ненужни мета данни.
Друга важна подробност е, че ако по дизайн някоя връзка, примерно от менюто, трябва да е картинка (например, защото там се ползва някой изчанчен шрифт с antialiasing), тя трябва да се сложи като фон. А текста, който е написан в нея, да се сложи и като title атрибут на връзката и да се сложи като текст в самата връзка (и да се скрие с css).
Cascading Style Sheets или за по-кратко css
Стиловете трябва да са отделени в css файл, за предпочитане само в един за по-лесно зареждане. Не е препоръчително ползването на <style> тага или inline стилове (style=”").
Ако се ползват стилове предназначени само за IE, не трябва да се ползват с хакове, а да са отделени във файлове според версията на IE чрез conditional comments. Например <!–[if lte IE 6]> <link rel=”stylesheet” type=”text/css” href=”stylesheets/IE6fix.css” /> <![endif]–> ще зареди файл важащ само за версии на IE до 6 включително. Стиловете трябва да се организират поне според структурата на html-а (header, content, sidebar, footer…) и по значението им (за текст, форми, заглавия…).
Не лоша идея е да се използва css reset.
Хубаво е пропъртитата да са подредени по азбучен ред и задължително да се ползват shorthand. Например padding-top: 5px; padding-right: 15px; padding-bottom: 12px; padding-left: 10px може да се изпише padding: 5px 15px 12px 10px. Имената на class и id трябва да са смислени, указващи частта от html, за която са предназначени (header, footer, nav_main, nav_categories). Ползването на дълги селектори като #header .menu .home li a се отразява зле на IE, а и по принцип е затормозяващо.
Ползването на нови селектори като box-shadow не е невъзможно, тъй като те имат поддръжка или алтернатива в повечето браузъри, включително IE, което намалява значително ползването на изображения. За намаляване и оптимизиране на css кода могат да се ползват css компресори, но такива, които не ползват нестандартни вредящи похвати, като да заменят strong с b. Освен това може да се приложи компресия gzip.
Приложна магия – JavaScript
JavaScript е един от най-неразбраните програмни езици в света. Поради различни причини, за които, ако трябва да пиша, ще ми трябват поне 1-2 поста още. Но въпреки това е един от любимите ми езици. 
Надявам се да не се налага да казвам че всичкия JavaScript трябва да е unobtrusive.
За JavaScript си имам едно правило – всичко в сайта трябва да работи без javascript. Тук идеята е следната. Ако примерно имаме галерия със снимки – една голяма и малки тъмбнейли – при натискане на даден тъмбнейл се сменя голямата снимка. Обаче ако няма javascript, какво правим? Много просто – всяка снимка при натискане да се отваря в нов прозорец, за да може потребителя така или иначе да я види. А ако има javascript просто ще спрем отварянето и ще я покажем с хубав ефект.
Естествено, има неща, които без javascript не работят. Тук правя следното – просто ги крия, т.е. при зареждане на страницата са маркирани като невидими и след като се зареди javascript-а ги показвам.
Само тук искам да отбележа, че става дума за най-нормален сайт, който трябва да бъде достъпен отвсякъде и понякога без JavaScript просто няма накъде.
Браузъри
Yahoo имат един списък с браузъри – http://developer.yahoo.com/yui/articles/gbs/. Дефакто в A-Grade (и IE6) браузърите се налага сайта да работи. За IE6 може и да не работи толкова добре. Все пак, който ползва IE6 (и като цялата IE фамилия де), си е свикнал да не вижда хубави работи…
Скорост
Една от новите ми любими теми.
Като за начало има 2 инструмента, с които може да се замери скоростта на сайта по различни показатели (става дума само за html/css/js/assets часта) – YSlow и Google Page Speed.
Някои от най-важните неща са:
- css най-отгоре и в един файл
- javascript най-отдолу и в един файл
- компресиране на всичко, което се праща от сървъра (тук има и малко работа по server-side)
- expire headers
- по-малко DOM (html) елементи
- по-прости css селектори
Една нова дума взе да се появява из различни презентации и постове при темата за Скорост и това е – Progressive HTML Rendering.
Идеята там е, че за потребителя страницата се “построява” пред очите му и така се създава усещането за скорост. За това много помага JavaScript да е възможно най-долу. Защото когато браузърът стигне <script> таг, забравя всичко останало. Затова много хора се насочват към това с малко javascript да зареждат останалия javascript, защото така не се блокира нишката на браузъра.
Заключение
И това е само една малка част от нещата, които се правят само по обвивката на един сайт. По принцип за всяка точка тук може да се пишат серии от постове. Да не говорим колко много развитие и промени има по темата.
Естествено. винаги може някой да си хване един dreamweaver и да си нареди 2-3 картинки и да каже, че има сайт. То и аз така съм почнал. Но в един момент това си е професия със своите тънкости и особености. Даже и името и е много яко - Frontend Engineering.
п.п. Само да вметна, че аз се водя web developer в Pixel Depo и основно работя по нещата, които стоят под frontend-a и JavaScript-a .
January 19th, 2010 at 1:15 am
Да, много добре казано! Много хора си мислят ,че като научат да използват Dreamweaver и са факири в web пространството.
January 19th, 2010 at 11:14 am
съгласен, какво друго да ти кажа?
но ние тези неща си ги знаем.
инче в статията си заложил основно на best practices, вместо да огромния брой на инструментите и целевите платформи – 5 браусъра по 3 операциони системи + поне 10 мобилни умни телефони … абе въобще абсолютна лудница :Д
иначе преди година писах нещо подобно и аз, но говорих за целия пакет – фронт енд, бакенд, архитектура и т.н. http://weboholic.de/what-is-being-a-web-developer.html
January 19th, 2010 at 11:24 am
Сега като се замисля за сигурността не съм писал, но там нещата са много дълбоки и мътни (за някои хора) а и аз исках само на за frontend страна да се съсредоточа.
Плюс че за мен web developer и frontend engineer са 2 различни професии, който може и да си покриват част от работата и функциите имат и доста различни неща на които трябва да се фокусират.
January 19th, 2010 at 1:07 pm
За писането на CSS си прав, но с маааалки уточнения:
1) Абсолютно задължително е хаковете за ИЕ 6 / 7 да НЕ стоят в отделен файл. Проклетите браузъри имат пуснати смао 2 / 4 конекции и това още повече се забавят. Хаковете стоят в същия фаил, непосредствено под пропъртито, което хакваш с представка _ или * респективно. Ако ползваш -moz, -webkit и прочее представки, CSS така или иначе е невалиден. Приеми, че _ и * са представки за ИЕ, нещо като -ms, но специално за 6 и 7;
2) Да кажеш, че е добре да подреждаш стиловете по азбучен ред, е като да кажеш “добре е да подреждаш класовете в азбучен ред” — невярно. Много по-добра идея е да групираш пропъртита по предназначение. Само се запитай къде стоят font- и text- респективно;
3) За предпочитане са тирета (-) вместо подчертавки (_) в имената на класовете по ред прични.
4) Кратките селектори са утопия, която не съществува, освен в контекста на минималистичните сайтове. Важи и за кратките стилови блокове;
5) Колко е голям DOM / колко са вложени нещата зависи от самата страница, нейното приложение и целева група (демек браузър, с който отварят). Като ти дойдат Ройтерс и ти кажат “Ние имам един продукт, за който сме платили Х милиона пауна и той използва ядро ИЕ 5.5, така че сайта трябва да работи на него”, ще слагаш не само допълнителни wrap-ъри, ами и таблици;
6) За компресиране на CSS е достатъчно да се махнат всички ненужни коментари, интервали, табове и нови редова. Останлото идва от gzip / deflate;
Та така.
Виж прав си, че като видят клиентите Dreamweaver и вече си мислт “бахти колко е лесно” или “тез само ме мотат” и други мисли пръкнати из дълбините на съзнанието им…
January 19th, 2010 at 1:22 pm
По принцип css пиша до толкова колкото се налага в предвид, че не правя дизайна.
Само за тирета (-) вместо подчертавки (_), си е въпрос на вкус, но от друга страна, Rails ( с който все повече работя използва подчертавки (_), а и от JavaScript страна ми изглеждат доста добре.
Иначе си напълно прав, че винаги си зависи от конкретния сайт и от изискванията на клиента
п.п. Добре че повечето хора вече тотално са забравили M$ Frontpage
January 19th, 2010 at 6:20 pm
Съвсем бегло си засегнал от всичко по малко, но пък си посочил полезни неща – постът ми хареса. Хем към колегите, хем към потенциалните клиенти, хем описателен към настоящите такива какво всъщност се прави и защо не всичко е просто нарисувано с Frontpage.
Аз така и не можах да обясня на няколко employer-а, че ‘backend’ не е скатаване на работно време и не всичко, което се пише, се вижда директно на екрана. Много порочна практика е мисленето, че сайтовете се ‘рисуват’, а нещата стават ‘от само себе си’…
January 19th, 2010 at 7:24 pm
В езиците за програмиране не можеш да използваш тирета (-) за име на променлива / фунцкиа (кв’ото и да е) по простата причина, че се приема за математически знак
В CSS обаче, такива хави нема и заради това можеш. Допълнително, при положение, че свойствата (properties) са с тирета, някак си ми идва по-естествено и аз да ползвам тирета.
Но си е въпрос на вкус
@Марио, човек ако знеш колко съм го зяпал монитора, ама с часове и кур не става от само себе си. Най-лесно клиентите разбират, че нещата не стават от само себе си, като им се направи аналогия с пари. Въобще парите са един много хубав пример / аналогия за всичко
Аз имах точно обратния проблем пък — че фронт-а не е скатавка.
January 19th, 2010 at 9:43 pm
@Марио благодаря
@Иван за (-) преди време наистина ги предпочитах, и в контекста на css стоят по-добре. Но напоследък (_) по лесно се мапват в html/javacript контекста. Но това е малко като дали скобата трябва да е същия или на долния ред. Важното да е се избере единия вариант и да се работи с него (докато е полезен разбира се) за да не стават мазаници
January 19th, 2010 at 10:04 pm
“Ааа, така ли? Аз пък си мислех, че хоп и готово.” цитат от учудването на клиент след обяснението как и за колко време ще му бъде направен сайта…
Жалко, че тия, които искат сайтове, но с намаление, защото има криза и в същото време карат чисто нови джипове, няма да прочетат този пост.
Може би трябва в магазина да искам намаление на сиренето… криза е все пак…
January 19th, 2010 at 11:24 pm
Няма да коментирам. Само ще предам един разговор, който проведох преди години с човек който работеше като ……
Аз: Какво работиш сега?
Той: Ами програмист съм.
Аз: На кой език програмираш?
Той: Как на кой? На Word.
Аз: ?!? А, значи знаеш Visual Basic!
Той: Какво е това Visual Basic?
Тук приключих разговора с мисълта че “всички от всичко разбират” че просто ако го продължа ще изглеждам не само неук но и прост.
Одобрявам статията. Трупай опит и в писането на такива неща. След години съм сигурен че ще ти потрябва този опит.
January 20th, 2010 at 10:59 am
@Иван, не съм съгласен с коментара ти относно CSS.
Когато стиловете за IE са в отделен файл, поставен в условен коментар, файлът се тегли само от IE, за остналите браузъри е просто коментар и не се отразява на зареждането на страницата. Допълнителната заявка за изтегляне на файла тежи само на IE. Освен това съвременните браузъри могат да отварят повече едновременни връзки – по подразбиране Firefox е ограничен на 6 към един хост.
Друга причина да предпочитам отделните файлове за IE, е че по-лесно да направиш съвсем различни стилове за IE. Не се налага да пишеш всяко нещо по два пъти (щото не става да сложиш хаковете са IE6 и IE7 заедно) и е по-ясно защо тези стилове са там.
Относно смачкването на CSS – най-добре е да ползваш някой инструмент за това. Аз предпочитам YUICompressor. А, и като говорим за намаляване на обема на файла, стигаме и до кратките декларации на свойства. Ясно е, че
padding: 1px 2px 3px 4px;
е доста по-малко от
padding-top: 1px;
padding-right: 2px;
padding-bottom: 3px;
padding-left:4px;
А според мен е и доста по-ясно.
January 21st, 2010 at 3:02 am
@Гозно, виж ако зависи от мен — * html {display: none;} — обаче не зависи, затова го търпя.
Хаковете за ИЕ за доволно малки, даже бих казал пренебрежително малки и не всяко нещо се пише по два пъти. Обикновено е едно нещо min-height: 0; _zoom: 1; и рядко друго нещо такова. Предвид, че deflate търси повторения теглото, което се добавя е малко.
Защо му е на човек да прави различни стилове за ИЕ не мога да разбера, но за целта на спора ще приема, че му трябва. В такъв случай съм съгласен, че условните коментари биха свършили работа. Само че аз би го решил със снифене за accept хедър, а не с условни коменари. Много по-елегантно и не се генерира излишен HTML.
За компресиите… Нека само за секунда се замислим — при положение, че сам си пиша ситловете, дали ще ми се случи да има дълга форма вместо къса, освен ако не е умишлено? Не. Този тип компресори за хора, които нямат изградени навици.
Допълнително, ако видя някой компресор да ми направи кратка форма на font просто минавам и го бия през ръцете. Защо? Защото кратката форма нулира line-height и я връща към подразбиращата за браузъра т.е. между 1.3 и 1.4 мисля.
Което ме връща в изходна позиция (предвид, че имам навици при писане на ЦСС) — когато се прави заявка към ЦСС и сървъра е в release режим, чисти интервалите и прочее гадове и по-добра компресия няма.
За малко да забравя.. точно защото deflate търси повторения, има много голямо значение как ще си подредиш стиловете. При малък фаил от (примерно 100-на ред т.е. около 10-20 правила) кирията беше около половин кило(байт). При по-големи файлове разликата отива към кило и нещо две. Ето на това му казвам аз компресиране
Междудругото, за писане на ЦСС можем си чешем езиците мноооого дълго време. Ти само дай тон за песен.
@Радослав — тая сесия много бързо изтича.
January 21st, 2010 at 2:34 pm
Защо може да трябва различен стил за IE – за да направиш box-shadow с картинка вместо със CSS, да замениш PNG със GIF, ако не става да е 8 битово PNG-то, за да нямаш дълги filter: редове … Или просто за да предложиш наистина основно описание на нещата за IE6 и да не се занимаваш с глупости (ако дизайнера не поиска да те убие за това).
Аз предпочитам да го правя с условни коментари.
Относно мачкането на CSS – не вярвам да си пишеш файловете на един ред без нито един интервал. Също не намирам за удобно преди да кача нещо на сървъра, ръчно да минавам да трия интервали и нови редове. По-лесно е това да става с един шел скрипт или като част от build-прцедура заедно с мачкането на JavaScript.
За кратката форма на font – мдаа, и на мен не би ми харесало да отнесе line-height. Не съм забелязал yuicompressor да чупи височината на реда, ще тествам специално.
А, бях забравил и за JavaScript в края на документа. В повечето съвременни браузъри изтеглянето на скриптове не блокира зареждането на останалите елементи от страницата, но се изпълняват в последователността, в която са в документа. За това вече не е толкова важно да се поставят на края на документа, аз лично си ги слагам в head. Проблем са естествено inline скриптовете, особено, ако правят document.write(;<script…, тогава става страшно!
January 21st, 2010 at 5:14 pm
Ама аз не пиша нищо на един ред — аз използвам супер много коментари и нови редове. Системата ми е 4:2:1 в зависимост колко си приличат / подхождат ситловете заедно
Нали ти казвам, че всичко зависи от setting на сървъра. Ако е release, се прави едно махане на интервали.
Самия regex е ултра прост и е сигурно 20 реда с коментарите.
Важи същото и за скриптовете, макар аз самия да предпочитам да са впълния си вид, че ако ми се налага да дебъгвам нещо на live сайт си е ебало майка.
Междудругото съм върл привържаник на твоята теза, че с паралелните връзи (parallel connections) вече не е задължително всичкото скрипт да стои най накрая. Би било добре, но не е задължително. Най-малкото един Bootstap ще ми се наложи да набухам в хеда.
Пък за дизайнерите и filter — само в екстремни случаи и то вероятно автоматизирано с JS
Поне дотам се пораснали във фирмата, че да убеждаваме клиентите в превъзходството на пълноцветното PNG пред GIF.
January 24th, 2010 at 2:28 pm
За javascript който да е най-долу си има и други плюсове освен че не блокира браузъра ( което го прави ) няма нужда се слагат onload / dom:load (или ready в jquery и други), защото в момента в който се стига до този код DOM дървото е завършено.
Също така за групирането в един файл ползвам в Rails проектите sprockets / http://getsprockets.org/ / което много ми помага при менажирането на js кода. За PHP проектите ползвам това http://gist.github.com/212303
Специално за зареждане на javascript Стоян Стефанов има много добър пост http://www.phpied.com/javascript-loading-strategies/ ( част от серията му постове преди Коледа )
April 29th, 2010 at 12:36 am
Всъщност, от чисто техническа гледна точка сайтът е по-лесен от desktop приложението (като прескочим момента, че двете не са особено сравними
). Вярно е, че правенето на сайт не е детска играчка (имам твърде много наблюдения върху направени абсолютни глупости), но може да се стори така на някой, който е писал големи desktop приложения с “прекрасните” api-та на microsoft или с да речем Xlib (въпреки че на някой писал с Xlib вероятно и чистенето на ориз с боксови ръкавици ще му е лесно).
Нищо ново няма по света де, едно време същото се казваше за desktop приложенията – “аз си мислех, че е много лесно”
April 30th, 2010 at 3:28 pm
Не казвам кое е по-лесно кое не
Като цяло според мен е до лична нагласа познавам хора, който правят страхотни desktop неща, но за web просто не им се занимава. Аз съм обратното.
Това което исках да посоча в статия че и изграждането на един сайт само от frontend страна не е толкова лесно. Да не говорим ако трябва да RIA тип приложение.
June 4th, 2010 at 3:42 pm
Понеже днес поех нещо ново и се сещам за още неща. По подразбиране да се разбира и да се знае софтуер за колаборация, ако сте 1+ човека (тракове, SVN-и и т.н.), умения по Linux, разговорни SSH и т.н.
June 4th, 2010 at 3:46 pm
Тук вече навлизаме във software craftsmanship, което също е една много добра тема. За source контрол, методи за разработка, за deployment стратегии, тестване и други.
Но за нещастие това са неща, които остават скрити за нормалния клиент, който просто иска добър краен продукт.