…Въпреки че синтаксисът на HTML е относително лесен за научаване,…има все още много елементи, атрибути и…други концепции, които ще трябва да научите и да ги следите.…Въпреки че този курс има за цел да въведе ви запознаете с най-важните неща в HTML, той...наистина не е предназначен да ви научи на всеки един елемент и атрибут, който е наличен....Така че имайки предвид това, искам да ви дам няколко онлайн ресурса за HTML,...които наистина могат да ви помогнат като започвате да изучавате HTML и...може да ви послужи като ценна справка по-късно, докато създавате свои собствени страници....Сега ще започнем със самите спецификации....

И това е нещо, два документа, които определено трябва да сте маркирали.…И така, това е W3Cs версията на HTML5.…Можете да видите, че имат най-нова версия за издател.…Можете да отидете да видите черновата на редактора,…ако искам да видя какво идва надолу, по тръбата.…И това е доста голямо.…Ако превъртя надолу, можешвижте, че тук е само съдържанието.…И дори няма да превъртя всичките.…

Автоматично превъртане на препис

актуализиран

Освободен

HTML е езикът за програмиране, който захранва мрежата. И като всеки език, след като го овладеете, можете да започнете да създавате свое собствено съдържание, независимо дали това са прости уебсайтове или сложни уеб приложения. Този курс предоставя задълбочен поглед върху най-важното: синтаксиса на HTML и най-добрите практики за старши автор Джеймс Уилямсън прави преглед на структурата на типичен HTML документ и показва как да разделяте страниците и да форматирате съдържанието си с HTML. Освен това научете как да създавате връзки и списъци и разберете как HTML работи с CSS и JavaScript за създаване на богат , ангажиране на потребителския опит.

Темите включват:

• Защо HTML е важен?
• Разглеждане на HTML документ
• форматиране на съдържание
• Показване на изображения
• Използване на nav, article и div елементи
• Връзки към страници и съдържание за изтегляне
• Създаване на списъци
• Контролиране на стила (шрифтове, цветове и други)
• Писане на основни скриптове

: Винаги съм искал да разбера това, но значението му беше толкова малко, че винаги имаше причина да не го направя :)

И вие се чудехте: URL - какво е това?

Винаги се сблъсквам с това, но все още не исках да разбера каква е разликата между термините URI, URL, URN и тогава изведнъж публикация (за съжаление вече е потънала в забрава), реших - ще прочети го сам и кажи на другите, въпреки че, както беше споменато по-горе, нищо няма да се промени от това, но понякога обичам да пиша, така че прочетете разумния преводач:

Обръщали ли сте някога внимание на адресната лента в браузъра си? Какво е това? URI, URL или URN? Много от нас не правят разлика между URI, URL, URN, а някои от нас дори не са чували за термините URI и URN, всички просто използват термина URL. Нека се опитаме да разберем това заедно.

Обяснение на съкращенията

URI - Единен идентификатор на ресурс (унифициран идентификаторресурс)
URL - Унифициран локатор на ресурси (унифициран търсач на местоположениересурс)
URN - Унифицирано име на ресурс (унифицирано имересурс)

Внимание, тук истината е в малките неща, но засега нищо не е ясно, някаква каша. Да отидем по-нататък.

Определение

URI: Показва името и адреса на ресурс в мрежата. Обикновено се разделя на URL и URN, така че URL и URN са компонентите на URI.
URL: Адресът на някакъв ресурс в мрежата. URL адресът определя местоположението на ресурса и начина за достъп до него.
URN: Името на някакъв ресурс в мрежата. Смисълът на URN е, че той дефинира само името на конкретен елемент, който може да бъде намерен на множество конкретни места.

Няма нищо по-хубаво от конкретния пример

URI = http://site/2009/09/uri-url-urn.html
URL = http://сайт
URL=/2009/09/uri-url-urn.html

Обобщаване

URI е концепцията за абстрактен идентификатор, докато URL и URN са конкретни реализации на адреси и имена.
Надявам се всичко да е ясно на всички. Бъди умен!

Възприятието на всеки от нас е индивидуално, затова - спорете и прочетете дискусиите в коментарите към статията, има много интересни неща.

По правило много уебмастъри качват своите сайтове на хоста веднага след създаването им. В същото време те се фокусират най-вече върху коректността на смисъла на текстовото съдържание, отколкото върху коректността на вътрешния код на страниците.

Валидиране на сайта

Но има и други фактори, които могат и оказват влияние върху позицията на сайта. И те включват, наред с други неща, технически фактори. Е, валидирането на сайта също спада към техническите. И така, какво е това?

Ако с прости думи, тогава валидирането на сайта е проверка на кода на сайта за техническо съответствие и грешки. Е, например, забравихте да използвате затварящия таг - /html. В най-новия HTML5 визуално нищо няма да се промени. Това обаче е грешка в кода.

При писане на код са възможни и други грешки. И отново, модерен езикхипер маркирането ще издържи много. Например „забравяне“ на затварящия таг /head. Отново, няма да видите разликата. Но тя е))

Всъщност, когато пишете уебсайт, може да има доста грешки. И още по-лошо, някои от тези грешки може да се показват и визуално. Е, може би блоковете ще плават, може би подравняване или може би нещо друго. Потенциални грешки, хиляди. И не всички са фрапантни.

Каква е опасността?

Е, изглежда, добре, какво лошо има в това? Да, трябва да се каже, че често такива грешки не се виждат. Или по-скоро невидим за хората. Но страниците на нашия сайт могат да бъдат посещавани не само от хора, но и от паяци за търсене, които напълно сканират сайта. И всяка грешка, която открият в сайта, те предават на сървърите на търсачки като Yandex или Google.

И търсачките, от своя страна, виждайки, че сайтът има много грешки в кода, може да заключат, че сайтът е лош. И това означава, че няма да го вдигнат в търсенето. Е, това вече ще означава, че сбогом посетители от търсенето.

Да, трябва да се признае, че известно песимизиране на сайта поради грешки при валидиране е доста рядко. Но това е напълно възможно, което означава, че трябва да се работи върху валидирането. И какво трябва да се направи за това? Разбира се, първата стъпка е да откриете грешките.

Но тъй като ръчно това е много времеемък и ненадежден бизнес, тогава за търсене на грешки те използват специални услуги, така наречените „Валидатори“.

Услуга за валидиране на маркиране на валидатора.

Тази услуга проверява коректността на HTML и XHTML кодовете, които са в основата на повечето страници при създаването на почти всеки сайт и определят вътрешната му структура. Тази услуга за валидиране може да бъде достъпна, като следвате връзката http://validator.w3.org

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

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

Точно оттам трябва да започнете.

Всъщност проверката на валидността на сайт е изключително проста, като целия ни смъртен свят: в адресния прозорец на услугата трябва да напишете адреса на сайта, т.е. неговия URL адрес и след това щракнете върху „Проверка“. След такова просто действие валидаторът ще „пухне“ за няколко секунди и ще издаде следното:

Това означава, че няма грешки в кода на страницата и можете да сте абсолютно спокойни.

Но може да има и такава нежелана опция:

Това вече е по-лошо и означава, че има някои грешки във вътрешния код на страницата, която се проверява. Това обаче изобщо не е фатално: просто трябва да превъртите страницата по-долу и всички грешки, открити по време на процеса на проверка, ще бъдат написани подробно там.

В допълнение, валидаторът не само ще изведе откритите грешки, но и ще покаже точно на кой ред от вътрешния код се намират тези грешки. Така че няма да се налага да ги търсите дълго време. Тук, без да преувеличаваме нищо, можем твърдо да кажем, че този валидор работи перфектно.

Но това не е всичко: валидаторът не само показва местоположението на откритата грешка в кода, но също така дава доста пълни препоръки как да се отстранят тези грешки. Разбира се, за това не е нужно да сте мързеливи и внимателно да прочетете всичко написано.

Като кратко и обобщено заключение можем да кажем следното:

1. тази услуга за валидиране работи чудесно и може да провери сайта много бързо.
2. Е, малко, но много приятно допълнение: валидирането на сайта е безплатно.
3. Сега можем да преминем към следващата стъпка: това е проверка на CSS кода.

Услуга за валидиране на CSS

Като цяло това е втората функция на горната услуга, но тя е „заточена“ не за проверка на HTML и XHTML код, а специално за проверка на коректността на кода css стилразположен на външната маса. А за да стигнете до страницата на услугата, трябва да следвате връзката http://jigsaw.w3.org/css-validator.

Между другото, тук си струва да отбележим нещо приятно: проверката на тази услуга е абсолютно безплатна. Така че не вадете пари от портфейла си - оставете ги да лежат до подходящия момент. Нека обаче да преминем към методологията на работа по тази втора услуга.

Като цяло цялата работа по валидатора на CSS е абсолютно идентична с проверката за чистота на кода. Следователно не е необходимо да предоставяте отделно изображение на адресната лента на валидатора. Малко по-надолу ще разгледаме накратко реда на самата проверка и това е всичко.

За това трябва да адресна лентанапишете URL CSS таблици, например "http://my site/style.css" и след това натиснете бутона с руски надпис "Проверка". Съответно, този валидатор също ще „пухне“ за няколко секунди и ще даде желания резултат:

Това означава, че CSS таблицата е написана правилно и в нея не са открити грешки.

И тук има и приятна изненада: ако превъртите страницата малко по-надолу, там ще бъде написан оптимизираният код за вашата CSS таблица, от който ще бъдат премахнати всички ненужни надписи и всички кодови тагове ще бъдат подредени в последователност който отговаря на оптималните работни изисквания на всички търсачки. Всичко, което остава, е да копирате този перфектен примерен код и да го поставите в CSS таблицата.

Напълно възможно е да се случи нещо подобно:

Това означава, че са открити някои грешки в CSS кода, но изобщо не трябва да се страхувате от това. Точно под тази червена линия валидаторът ще ви каже точно кой етикет е неправилно изписан. Остава само да намерите тези тагове в листа със стилове и да направите необходимите корекции.

И разбира се, след това качете коригирания лист със стилове на хоста и, ако има зелена линия, можете щастливо да копирате стиловия код на оптимизираната CSS таблица. Съвсем ясно е, че тогава е най-добре да се промени стар кодкъм нов и оптимизиран.

Кратко обобщение.

Двете най-основни и задължителни проверки за валидиране на уебсайтове бяха обсъдени по-горе. Без тези проверки не трябва дори да отваряте индексиране за търсачки в robots.txt В противен случай сайтът може да бъде игнориран за индексиране търсачкии ще се считат за дефектни с подходящи санкции.

За да не се случи това, трябва да отделите само няколко минути, за да сте абсолютно спокойни и напълно уверени в техническото състояние на вашия сайт и всички негови страници. Разбира се, необходимо е да се направят и допълнителни проверки на връзките и анкорите, видимостта на сайта мобилни устройстваи параметри на други кодове. Само тогава сайтът може да се счита за готов за пълноценното си функциониране и за успешна и бърза промоцияв ТОП.

Бих искал да кажа предварително, че всички други проверки са толкова бързи и прости, колкото и тези, обсъдени по-горе - просто трябва внимателно да прочетете процедурата за работа с валидатора.

Добавен на 19.04.2018

Често срещани грешки във валидността при валидиране на HTML код

Реших да актуализирам статията. HTML грешкикодове, които често се срещат в сайтовете. Във всеки случай имах много от тях)). Валидаторът подчертава грешките в жълто.

1) Грешка: Препратката към символ не е завършена с точка и запетая.

Грешка: символът не е прекъснат от точка и запетая - съответно трябва да се добави.

2) Предупреждение: Разделът няма заглавие. Обмислете използването на елементи h2-h6, за да добавите идентифициращи заглавия към всички секции.

Предупреждение: Този раздел няма заглавие. Обмислете използването на елементи h2-h6, за да добавите идентифициращи заглавия към всички секции. Тук всичко е ясно, трябва да добавите поне един субтитър. Това дори не е грешка, а препоръка.

3) Грешка: Елементът noindex не е разрешен като дете на елемент p в този контекст.

Грешка: noindex елемент не е разрешен като дъщерен елемент p елемент в този контекст. (Потискане на допълнителни грешки от това поддърво.)
Решението е просто, трябва да коментирате етикета noindex, изгледът ще изглежда така:

4) Грешка: Централният елемент е остарял.

Грешка: тагът "center" е остарял - трябва да бъде заменен, ако говорим за img, тогава можете да използвате атрибута align. Ако нещо друго е центрирано, заменете го с div.

5) Елемент img трябва да има атрибут alt, освен при определени

Грешка: Елементът img трябва да има атрибут alt - тук всичко е ясно, трябва да добавите атрибут alt, дори и да е празен, грешката ще изчезне.

6) Атрибутът width на елемента td е остарял. Вместо това използвайте CSS.

Грешка: Атрибутът „width“ на елемент „td“ е отхвърлен

7) Атрибутът type не е необходим за ресурси на javascript

Грешка: Атрибутът type не е необходим за ресурси на javascript. Решението е просто да премахнете всичко ненужно и да оставите само етикета „script“.

8) Атрибутът align на елемента img е остарял.

Грешка: Атрибутът align на елемента img е отхвърлен. Направете divs за подравняване на изображението.

Класът ResourceBundle.Control има набор от външни методи, които се извикват от метода ResourceBundle.getBundle() при търсене и зареждане на пакети. След като създадете своя контролен клас, можете да промените поведението на зареждане и кеширане по подразбиране.

В този случай трябва да създадете имплементация на два метода на класа Control: getFormats() и newBundle(). Методът getFormats() отговаря за поддържането XML формат, а newBundle() работи с пакет от ресурси. Базовият контролен клас има помощни методи за преобразуване на имена на базов набор в действителни имена на ресурси.

Тази реализация на класа ResourceBundle.Control включва подклас на XMLResourceBundle. Този подклас се използва за зареждане на данни от XML файли използването им в метода ResourceBundle.

Следното е описание на класа Control и изпълнение на метода ResourceBundle:

импортиране на java.io.*;
импортиране на java.net.*;
импортиране на java.util.*;

Публичен клас XMLResourceBundleControl разширява ResourceBundle.Control(
частен статичен низ XML = "xml";

Публичен списък getFormats(String baseName) (
върнете Collections.singletonList(XML) ;
}

Public ResourceBundle newBundle( BaseName на низ, Локален локал,
Формат на низ, ClassLoader loader,булево презареждане)
хвърля IllegalAccessException, InstantiationException, IOException{
if ((baseName == null ) || (locale == null ) || (format == null )
|| (loader == null )) (
хвърля ново NullPointerException();
}
ResourceBundle bundle = null;
ако (format.equals(XML))(
String bundleName = toBundleName(базово име, локал) ;
String resourceName = toResourceName(име на пакет, формат) ;
URL адрес= loader.getResource(име на ресурс) ;
if (url != null) (
URLConnection връзка = url.openConnection() ;
if (connection != null) (
ако (презареди) (
връзка.setUseCaches(false) ;
}
InputStream поток = връзка.getInputStream() ;
if (stream != null ) (
BufferedInputStream bis = нов BufferedInputStream(
поток);
пакет = нов XMLResourceBundle(bis);
bis.close();
}
}
}
}
пакет за връщане;
}

Частният статичен клас XMLResourceBundle разширява ResourceBundle(
подпори на частни имоти;

XMLResourceBundle(InputStream поток) хвърля IOException(
подпори = нови свойства();
props.loadFromXML(поток);
}

Защитен обект handleGetObject (ключ за низ) (
връщане props.getProperty(ключ);
}

Публично изброяване getKeys()(
Задайте handleKeys = props.stringPropertyNames() ;
връща колекции изброяване (handleKeys);
}
}

Public static void main(String args) (
("Тест2",
нов XMLResourceBundleControl()) ;
низ= bundle.getString("Помощен ключ");
System.out.println ("HelpKey: " + низ) ;
}
}

Това изпълнение включва триредова тестова програма:

Пакет ResourceBundle = ResourceBundle.getBundle("Тест2", нов XMLResourceBundleControl()) ;
Низ низ = bundle.getString("Помощен ключ");
System.out.println ("HelpKey: " + низ) ;

Най-интересен тук е първият ред. Трябва да предадете своя контрол на метода getBundle(). След това можете да използвате комплекта както във всеки друг случай.

Следва примерен XML файл Test2.xml:

http://java.sun.com/dtd/properties.dtd" > Добре Отказ Помогне да не

Резултатът от изпълнението на програмата XMLResourceBundleControl ще бъде:

> java XMLResourceBundleControl HelpKey: Помощ

Горната реализация не използва методите getTimeToLive() и needsReload():

публично дълго getTimeToLive( BaseName на низ, локал на локал)

публични булеви нуждиReload( BaseName на низ,
локал,
формат на низ,
зареждане на класове,
пакет от ресурси,
дълго време за зареждане)

Методът getTimeToLive() връща продължителността на живота за пакети с ресурси, създадени с ResourceBundle.Control. Наборите ресурси се кешират, за да се ускори процеса на презареждане. Така при презареждане на набор, той ще бъде в кеша. Положителната стойност на времето за живот ще зададе в милисекунди колко време ще остане наборът в кеша без повторно потвърждаване. Стойността по подразбиране, върната от метода getTimeToLive(), е TTL_NO_EXPIRATION_CONTROL, която деактивира проверката за изтичане на кеша. Ако не искате да кеширате набора, тогава върнете TTL_DONT_CACHE. Ако върнатата стойност е 0, тогава пакетът се кешира, но се проверява при всяко извикване на метода getBundle(). За да изчистите кеша, извикайте статичния метод clearCache() на класа ResourceBundle. Има незадължителен аргумент ClassLoader, който ви позволява да изчистите кеш паметта, създадена от конкретен товарач.

Методът needsReload() определя дали кешираният набор трябва да бъде презареден. Стойност true означава, че наборът трябва да бъде презареден, а false, че не е необходимо да се презарежда. Можете да контролирате дали набор от ресурси трябва да бъде презареден чрез претоварване на метода needsReload(). Например, ако искате наборът от ресурси винаги да се презарежда, методът needsReload() винаги трябва да връща true. В този случай методът getTimeToLive() винаги трябва да връща стойността 0. В противен случай наборът ще се запази по-дълго от очакваното.

За получаване Допълнителна информацияЗа информация относно подобренията в процесите на интернационализация на Mustang можете да се обърнете към Джон Оконър, блог на разработчика на софтуер на Sun на