По време на нашите безплатни ИТ курсове всички от лекторите ни наблягат както на добрите практики, така и на лошите. Често споменаваме „това не е правилно, не го правете“. Разбира се, физически времето не ни позволява да подплатим всичко с реални примери. Затова показваме първо добрите практики и ако остане време – лошите. Поради тази причина решихме, че е нужно да направим малко по-подробно обяснение и в тази статия ще ви запознаем с няколко от лошите практики в писането на HTML.
Красив HTML = красив уеб сайт. Когато се учим да пишем красив CSS код, всъщност трябва да знаем, че това е невъзможно без да имаме и красив HTML код. Предимството на изчистения семантичен HTML са много, а все още много уеб сайтове страдат от лошо написан HTML.
Нека разгледаме няколко принципа за писане на по-красив HTML код. Имайте предвид, че не отразяваме никакви промени в дизайна на сайта, а само в структурата и подредбата на HTML кода му.
Ако ще го правим, нека го правим правилно! Използвайте HTML5 DOCTYPE. Няма нужда да коментираме, че използването на HTML5 DOCTYPE не ни ограничава в това да пишем в XHTML формат.
Не забравяйте да поставите meta таг за charset преди всичко останало в head на страницата. Колкото и интелигентни да са днешните браузъри, не биха определели сами encoding-а на страницата, която трябва да визуализират.
Нека започнем с това, че за да подредите правилно кода си, не трябва да използвате интервали. Използвайте TAB за да „избутвате“ кода навътре и направите правилно „вдлъбване“. Табулацията няма значение за крайния резултат от кода ни, но има много голям ефект върху четенето му. Улеснете себе си и всички останали като подредите кода си правилно!
Въпреки, че не е задължително, използването на коментари е силно препоръчително. Все пак не трябва да се прекалява с тях. Най-важно е да обозначите различните части от документа, като ги обградите в коментари за начало и край. При по-специфични функционалности е допустимо кратко описание и/или обяснение на подаваните параметри към метода (за JS).
Никой не харесва файлове с много дълъг код. Не пишете CSS и JS вътре в документа си. Не само защото не е прегледно, а и защото може да се използва само в един документ. Използвайки външен CSS или JS файл означава, че ще може да го използвате в колкото си желаете други документи. Така ще улесните работата си и ще пишете по-малко код.
Нека да кажем, че заглавието на сайта ни „My First Website“ е в <h1> таг. До тук добре, така и трябва да бъде. Обаче, искате това заглавие да бъде линк към началната страница. Обграждате <h1> тага с <a> таг и готово. Да, ама не! Това е голяма грешка. Повечето браузъри ще се справят с този код и ще го визуализират правилно. Въпреки това, написали сме грешен код! Тагът за линк <a> е inline елемент, а таговете за заглавие <h*> са block елементи. Block елементите не трябва да бъдат в inline елементи!
Нямам си и на идея кой е измислил термина „divitis“, но това е много важно! Терминът ни насочва към избягване използването на твърде много div контейнери, за да структурираме страницата си. В началото се учим да обграждаме съдържанието в div, за да го таргетираме чрез CSS и стилизираме. Това води до твърде много div контейнери, заради което кодът ни става претрупан и трудно четлив. Когато можете, не използвайте div!
За пример имаме div, който обгражда nav. Двата елемента са block елементи и обграждането на nav с div в случая е напълно излишно. Каквото можем да направим с div контейнера, това можем и с nav.
Ресурси: https://csscreator.com/divitis
Нека вземем за пример ситуацията по-горе с неномерирания списък използван за навигация. Да кажем, че този ul има id=”bigBarNavigation”. Частта с “navigation” има смисъл понеже това си е навигация, но частта с “big” и “bar” обяснява дизайна, но не и съдържанието. Сега може и да има смисъл понеже менюто е на една линия и е голямо. Но в бъдеще това може да бъде променено и тогава няма да бъде смислено. Ще се наложи да се смени id-то на всякъде, което ще отнеме време и може да доведе до други проблеми. За да именуваме правилно навигацията си, може да използваме следните имена: „mainNav“, “subNav”, “sidebar”, “footerNav”, “metaData” и т.н. – неща, които описват съдържанието.
Ресурси: https://www.sitepoint.com/how-to-compose-html-id-and-class-names-like-a-rockstar/
Дизайнът на нашето меню изисква текста в линковете да бъде само с главни букви (all caps). Затова сме решили просто да напишем текста само с главни букви директно в HTML документа ни. До тук добре. Получихме каквото желаем, но това е напълно грешно! За целта може да напишете текста в правилната му форма, като например „Home“ или “About us” и да използвате CSS, за да направите текста само с главни букви – text-transform: uppercase. Уповавайки се на предното твърдение, също трябва да имаме в предвид, че не трябва да използваме <h*> тагове просто за да направим текста ни по-голям. Тези тагове обозначават заглавията из страницата. Ако желаете по-голям шрифт и този текст не е заглавие, използвайте CSS.
Ресурси: http://learn.shayhowe.com/html-css/working-with-typography/
Всички сме хора и всички грешим. Много често в бързината пропускаме създадени грешки от типа на объркан символ, пропуснат или забравен затварящ таг. Това е нормално, но не позволявайте да наруши структурата или по-зле – да наруши дизайна на страницата. Понякога няма никаква причина да валидираме изходния код. Но само да видим зеления текст за напълно валиден изходен код би ни накарало да се почувстваме по-добре и по-сигурни.
Ресурс: https://validator.w3.org/
Старайте се логически да подреждате DOM структурата на уеб сайта. В над 99.99% от случаите това е възможно и не би трябвало дизайнът да попречи на структурата (в противен случай, най-вероятно нещо с дизайна не е наред). Всичко е възможно, спазвайте логическата подредба на секциите в сайта. За пример имаме aside, който е позициониран след footer-а на страницата. Но това е напълно грешно! Footer-а на страницата трябва да бъде последното нещо в нея. Ако позиционирате нещо след него само заради самия дизайн, то тогава вие грешите.
Ресурси: https://css-tricks.com/snippets/html/html5-page-structure/
Покрихме по-голяма част от често допусканите грешки в писането на HTML, но всичко не свършва дотук. Нужно е сами да изградите навици и да се стараете в писането на изчистен, правилно структуриран и подреден код. Разбира се, много по-лесно е да напишем красив код, когато започнем от началото и само ние пишем по него. Няма нужда да коментираме, че всеки програмист си има свой стил на писане, свои лични похвати и т.н. Научете добрите начини и ако се налага, поправяйте грешките на колегите си. Никой не е безгрешен. Дори и най-добрите.