Art is like masturbation.

Design is like sex.

 
Принципи за чист изходен код

Красивият (x)HTML е в основата на красивия сайт. Когато водя лекции за CSS, винаги започвам с това, че чистият и надежден CSS може да съществува само тогава, когато има добра основа – (x)HTML. Едно дърво е толкова здраво, колкото корените му са здраво вкоренени в почвата, нали? Предимствата на чистия и семантичен (x)HTML са толкова много..., но толкова (реализирани, потребителски и корпоративни) ПРОДУКТИ (сайтове, портали и др.) страдат от лошо написан (x)HTML.
По просто казано – хигиенни навици (няма да изпадам в детайли).

Нека да разгледаме примерен лошо написан (x)HTML – да дискутираме недостатъците и проблемите му. Имайте предвид, че аз не съм "страшния съд" и не мога да съдя, а давам само съвети за съдържанието, дизайна, кода и т.н.. Ето и пример за лошо написан xHTML. Както и пример за същия (x)HTML, но написан подобаващо по стандартите и правилата.

(никак не е лоша идеята да разгледате двата примера преди да обособим правилата)

Ако ще правите нещо, то по-добре е това да е правилно "направено" нещо! Няма нужда от ожесточена дискусия за това дали да се използва HTML 4.01 или XHTML 1.0 и двете предлагат "строга" / Strict версия така, че нашият код да бъде чист, "хубав" и образцов (любима дума).

Твоят код не използва таблици за цялостния шаблон/темплейт, твоят код използва тага < h > , за да укаже заглавие и ти знаеш, че за списъци се използват: < ul > и < ol >? - Това е чудесно!!! Не е нужно да използваш Transitional DOCTYPE.

 

В самото начало на head секцията непосредствено след title трябва да се дефинира чар-сет-а на документа. В практиката си без изключения използвам UTF-8, като причините за това са доста (най-важната, е че никога не съм имал проблеми при местене на съдържание от един сървър на друг, благодарение на utf8). Дебати и симпозиуми на тази тема сме водили достатъчно много, за да ме разубеждава някой. Препоръчвам и на ВАС да използвате UTF-8 (и не пестете ресурси ;) – обикновено само с това се оправдават подражателите на другите енкодинги).

енкофинг в хтмл

Когато се говори за енкодинг, не трябва да се подмине и темата за специалните символи, които се използват доста често. Използвайте кодирания вид на символите!

( &amp; - &copy; и т.н. )

 

Подредбата на самия код не влияе (абсолютно) по никакъв начин на неговото интерпретиране/показване от браузърите, но уви влияе на нервите ми!
Стандартно, когато започнете нов елемент, го позиционирате един таб-за предпочитане навътре (кой не е бил в първи клас?) от предходния или няколко отстояния (space) – вече са доста и редакторите, които това го правят сами вместо вас, но не винаги редакторът хваща началото и края на даден елемент (машината не е по-съвършена от "human"-a).

 

Избягвайте inline стилове и скриптове. Това оптимизира освен генерирания код и трафика на потребителя, а и веднъж зареден файл в кеш-а на браузера при следващи зареждания не се тегли отново. А когато се отнася до JavaScript и е неизбежно да бъде inline, то при възможност нека е в края на <body> непосредствено преди </body> В примерния код:

инлайн цсс в хтмл

Случва се в "движение" да се използва inline css за някой елемент, но това са редки и "екстремни" ситуации.

В една от статиите си за (x)HTML и неговата семантика съвсем ясно поставих въпроса с последователността на елементите и разбираемостта относно неговото (на тага) значение. В този ред на мисли, често се срещат смущаващи разума подредби на елементи... например:

хтмл грешен

Повечето браузери ще интерпретират конкретния пример, като нещо "нормално" и ще се вижда перфектно, нооооо технически това е като да смените местата на глагола и подлога. Идеята да построявате думичките, както на ВАС ви харесва не е никак добра.

H3 е блок елемент, а таг-а A e Inline – правилото гласи, че блоковите елементи съдържат ВЪВ себе си inline, а не обратното!

ДИВ-изма е често срещано явление, дори се е превърнало в модно течение, в което няма абсолютно нищо лошо :)

Моля, имайте мярка! Много често поставяме елементи, които практически са ненужни – бъдете пестеливи откъм елементи. Ето и пример:

div елемент

В този пример ясно се вижда, че БЛОК елемента е <ul> не е необходимо да се натоварва с още един такъв - просто се губи смисъл, а и освен това вероятността да се "оплеска" кода в ралзичните браузери е доста по-голяма!

 

Нормално ли е да имате променлива "nababaiagashortitesacherveni" тогава, когато мятате камъни в полянките на програмистите? Абсолютно не – най-малкото НЕ е професионално.

В същия ред на мисли класове от типа на "onovasharenotogore" никак не са подходящи. Няма да се впускам в обяснения, че е желателно имената на обекти да бъдат описателни, за да може в последствие и друг човек бързо и лесно да се ориентира в кода. Също така в по-лека форма на "изкривяване" на имена също не е препоръчително, например:

как да именуваме класовете и ид-тата в хтмл

Хей, вие използвате само главни букви във вашето меню? Перфетно, а как постигате този ефект? Така ли:

големи букви в хтмл

CSS мощен "инструмент", който се занимава с оформянето/стилизирането и цялата визуална рамка. Безсмислено е да "донагласяте" чрез криворазбрани "техники", вземете контрола върху графичната композиция "ваши" ръце, чрез CSS :) Добрите дизайнери знаят, че CSS не е като Photoshop, но с времето подобряват уменията си (CSS) или стават "Флаш-ъри" :))))))))

ЗАЩО? Какво би накарало някого да използва id или class за body? Да, това е много (както казват) powerful, защото всеки пиксел от страницата е inline за body и по този начин можете да таргетирате достa по-пълноценно различните обекти? Някой иска да е джедай?

Въпрос на гледна точка, така или иначе аз не виждам (а съм използвал техниката) полза.

До каква степен държите на себе си, като уеб-разработчик? Мислите, че работите професионално? Имате много проекти, идеи, реализации? Мислили ли сте някога какво точно се случва след 6-12-24 месеца, като сте приключили с една задача? Случвало ли се е да зареждате дори от любопитство да проверите..?

Всъщност, няма никакво значение как сте отговорили на въпросите... НЕ е най-важният и основен фактор валидатора, но той винаги е прав – също, като клиентът :)

валидиране на сайтове

Да, клиентът никак не го вълнува валидатора (в повечето случаи), но лично при мен ЗЕЛЕНАТА светлина от валидатора е една малка победа, ежедневна, желана и истинска!

 

Предполага (разума), че блок с ид/клас HEADER се намира в началото на страницата и е блок, който е "глава" на страницата, нали? Тогава според вас къде се намира container, leftsidebar или защо не footer?

Да, ваша работа си е кое как ще се казва и къде ще се намира. Няма да бъде за мен изненада footer да е първият елемент във вашия код.

Но е невъзможно основите на вашата къща да са на мястото на покрива, нали? Дори и ако много ви се иска, няма да стане ;))) Футуризмът не е в начина на писане, а в начина на мислене!

Да, поредните съвети, поредни нечий мисли...

Когато се започне от нула, всичко това изглежда много по-лесно и реално. Когато се опитвате да преправите/ъпдейтнете, вече съществуваща страница по правилата – определено е много по-трудно. Или може да имате толкова много статични страници, че дори да е трудно да помислите откъде ще започнете. ОК! Най-важното е, че можете да се научите как да пишете чист xHTML и да се придържате към него.

Следващия път, когато пише xHTML, било то малко парче в огромния океан, или подхващате нов проект от самото му начало, просто дайте най-доброто от себе си!

Лекции и Статии
 
Аз видях, погледни през моите очи
 фотогалерия на кристалин чавдаров  пейзажи от цяла българия  Снимки на българската природа - планини, море, забележителности. Фотогалерия и фотобанка.  фотография, пейзажи, снимки, сток, България, природа, забележителности, изкуство, тракове, пътешествия, истории, разкази, услуги  снимки от сватби, сватбен фотограф, сватбено заснемане, сватбена фотография  Информация относно фотозаснемането на вашата сватба от сватбен фотограф
Чурилик
Себеизлеяния
"Аз мога - тук и сега"