The rel attribute of the link tag

<link href="main.css" rel="stylesheet">

This simple example provides the path to the stylesheet inside an href attribute, and a rel attribute with a value of stylesheet. The rel stands for „relationship“, and is one of the key features of the <link> element — the value denotes how the item being linked to is related to the containing document.

The ralationship with the document, това е ключовата дума. Демек, какво е – CSS, икона, JS…

In HTML, link types indicate the relationship between two documents, in which one links to the other using an < a >, < area >, < form >, or < link > element.

Литература:

https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-rel

Resource Description Framework (RDF)

Метаданни или мета информация – това са данни за данните, или информация за информацията.

На практика, компютрите са едни електронни сметалки, съхраняващи и обработващи информация по дадени алгоритми, зададени под формата на програми.

За да могат компютрите по-ефективно (в смисъл по-информативно) за нас потребителите, да обработват въпросната информация, те трябва по техен начин, да „знаят“ повече за нея. Тя, информацията, да е „по-разбираема“ за тях.

В какъв смисъл „по-разбираема“ и „да знаят“?

Цялата информация в Интернет е двоична (текст, изображения, звук, видео….). Което чисто семантично е напълно непонятно за компютъра, освен ако нямаме изкуствен интелект, защото пак да кажем, компютрите са просто едни електронни сметалки, които съхраняват информацията и могат да я обработват само по програмно зададен алгоритъм.

Идеята на Semantic Web най-просто казано е, да зададе повече информация за самата информация (мета информация), което от своя страна да помогне на компютъра и неговите програмно заложени алгоритми, да ни предоствят по-информативни услуги.

В какъв смисъл „по-информативна“?

В смисъл, че когато въпросните „електронни сметалки“ „знаят“ повече (мета инфо) за информацията, която съдържат, те ще могат да ни я предоставят по-близко до това, което всъщност търсим. Демек, ще бъдат по-информативни.

За създаване на разбираем от компютрите език, се използва форматът RDF (Resource Description Framework), който е на основа на синтаксиса на XML и използва идентификатори URI за обозначение на ресурсите.

RDF — това е система за описание на мрежовите ресурси, понятна за компютъра. Форматът RDF е предназначен за съхранение на метаданните. RDF не е предназначен за четене от човек.

Text-based web browser

text-based web browser is a web browser that renders only the text of web pages, and ignores most graphic content.

Under small bandwidth connections, usually, they render pages faster than graphical web browsers due to lowered bandwidth demands.

Additionally, the greater CSSJavaScript and typography functionality of graphical browsers require more CPU resources.

Практическата им полза е доста ограничена но могат да се употребяват например при различни компютърни рийдъри, или за люде със слабо зрение…

Един известен пример за text based web browser е например Lynx.

Progressive enhancement e идея, която позволява по-широкото използване на text-based web browsers. Защо? Защото идеята е една уебстраница, бидейки се състояща се от три основни елемента: мултимедия, CSS, JavaScript и разбира се текст, от нея да може да бъде използван например само текстът, демек – само най-ниското ниво от „пирамидата“, най-същественото.

Oт тази пирамида виждаме, че в основата на всяка уебстраница, демек – най-същественото, е самият текст.

След това идва CSS – визуалната част на даденият текст, което разбира се включва оформяне както на самият текст, така и на мултимедийните части на страницата. Но идеята е като цяло – форматиране на визуалната част.

И най-горе – функционалната част, JavaScript, която добавя интерактивност и програмируемост на поведението на уеб-браузърът, заредил дадената уебстраница.

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

Предишната подобна идея за организиране на уебстраници е т.н.  graceful degradation, при която уебстраницата се прави пригодна за най-новите страндарти и браузъри, НО с идеята да е използваема и от по-старите такива.

The strategy is an evolution of a previous web design strategy known as graceful degradation, wherein Web pages were designed for the latest browsers first, but then made to work well in older versions of browser software. Graceful degradation aims to allow a page to „degrade“ – to remain presentable and accessible even if certain technologies expected by the design are absent.

Демек, в единият случай мислим нещата от долу нагоре, а в другият – от горе надолу.

Литература:

https://en.wikipedia.org/wiki/Text-based_web_browser

https://en.wikipedia.org/wiki/Progressive_enhancement

https://en.wikipedia.org/wiki/Fault_tolerance

Lightweight markup language

Това са маркъп езици със силно опростен синтаксис, обикновено използвани за просто форматиране на текст, например като за документация…

Визуалната им функционалност се ограничава само до текстово форматиране като:

  • размер на шрифта;
  • удебеляване;
  • италик;
  • табулация, маргини…
  • и т.н… но все чисто текстов форматинг.

Общо взето lightweight markup language служат основно за чисто текстово форматиране, и с оглед основно за писане на текстова документация.

Също и да можеш кто погледнеш суровият текст, да можеш да прочетеш самият текст. „Lightweight markup languages are used in applications where it may be necessary to read the raw document as well as the final rendered output„.

DTD and Doctype

DTD или още Document Type Definition, е стандарт за дефиниране на това, какви валидни елементи и техните атрибути, даденият език за маркиране може да съдържа за да се счита за валиден.

With a DTD, independent groups of people can agree on a standard DTD for interchanging data.
Рабирам това така: можем да имаме custom DTD-та ако искаме да си зададем свой формат на валиден език за маркиране. Тоест, DTD не са нещо твърдо зададено като задължителен формат.

С помощта на DTD можем също да проверяваме дали даден документ, написан на език за маркиране, е валиден.

Пример за XML

DTD дефиницията на даден XML документ може да е или вградена в самият документ, или заредена от външен *.dtd файл.

Тук standalone=“yes“ ще рече, че даденият документ използва вграден DTD, а не извлича такъв от външен файл.

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE note [
	<!ELEMENT note    (to,from,heading,body)>
	<!ELEMENT to      (#PCDATA)>
	<!ELEMENT from    (#PCDATA)>
	<!ELEMENT heading (#PCDATA)>
	<!ELEMENT body    (#PCDATA)>
]>
<note>
	<to>Tove</to>
	<from>Jani</from>
	<heading>Reminder</heading>
	<body>Don't forget me this weekend!</body>
</note>

Ако искаме да отдели DTD дефиницията в отделен *.dtd файл, тогава:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE address SYSTEM "address.dtd">

За какво служи SYSTEM?

За да зададем т.н. Formal Public Identifier.

Със SYSTEM задаваме, че става дума не за предефиниран DTD, а за например наш, custom DTD файл. И посочваме кой е файлът.

Ако имаме PUBLIC вместо SYSTEM, тоагава ще имаме например:
<!DOCTYPE name PUBLIC „-//Beginning XML//DTD Address Example//EN“>
тогава казваме, че искаме да използваме публичен DTD и посочваме неговият Formal Public Identifier.

Елементи на DTD

Вижда се как DTD дефиницията за целият документ се свежда до следната схема:
<!DOCTYPE <коренен таг> [ декларации на отделните елементи ]>

Декларацията на отделният елемент –
<!ELEMENT <таг> (тип на тага)>

За декларация на атрибути към даден елемент използваме:
<!ATTLIST  <таг> <има на атрибут> <тип на атрибут> <стойност на атрибут>>

Примерно DTD:
<!ATTLIST  payment type CDATA „check“>

Примерен XML:
<payment type=“check“>

По-подробно за Formal Public Identifier

FPI се състои от 4 полета, разделени от // например:
-//W3C//DTD XHTML 1.0 Transitional//EN

поле 1 : Indicates whether the DTD is connected to a formal standard or not. If the DTD hasn’t been approved (for example, you’ve defined the DTD yourself), use a hypen (-). If the DTD has been approved by a nonstandards body, use a plus sign „+“. If the DTD has been approved by a formal standards body this field should be a reference to the standard itself.

поле 2 : Holds the name of the group (or person) responsible for the DTD. The above example is maintained by the W3C, so „W3C“ appears in the second field.

поле 3 : Indicates the type of document that is being described. This usually contains some form of unique identifier (such as a version number).

поле 4 : Specifies the language that the DTD uses. This is achieved by using the two letter identifier for the language (i.e. for english, use „EN“).

Интересно:

Каква е разликата между CDATA (Charcter data) и PCDATA (Parsed Character Data)?
Първото означава, че става дума за текст, който не бива парсиран от парсера и се използва за текст, който носи информация.
Второто е текст, който е част от самият език за маркиране, като тагове, атрибути и т.н…

Също, добър въпрос би бил, щом можем с PUBLIC да си задаваме DTD файл, това значи, че можем да си създаваме свои, custom DTD-та.

Литература:

https://www.quackit.com/xml/tutorial/dtd_fpi.cfm

The Open Graph protocol

Протокол, имащ идея да стандартизира начинът, по който дадена web страница да бъде споделяна в различните социални мрежи като Facecbook, така че да бъде т.н. „rich object in a social graph“.

Тоест, да предостави хем достатъчно, хем минимална информация за себе си, за да може например Facebook да знае ако ще и малко, но поне достатъчно, за да я включи успешно в своя т.н. „sociql graph“.

Как става това?

Просто като в секцията на web страницата се добавят определени тагове с 4 задължителни атрибута:
og:title – The title of your object as it should appear within the graph, e.g., „The Rock“.
og:type – The type of your object, e.g., „video.movie“. Depending on the type you specify, other properties may also be required.
og:image – An image URL which should represent your object within the graph.
og:url – The canonical URL of your object that will be used as its permanent ID in the graph, e.g., „https://www.imdb.com/title/tt0117500/“.

<html prefix="og: https://ogp.me/ns#">
<head>
<title>The Rock (1996)
<meta property="og:title" content="The Rock">
<meta property="og:type" content="video.movie">
<meta property="og:url" content="https://www.imdb.com/title/tt0117500/">
<meta property="og:image" content="https://ia.media-imdb.com/images/rock.jpg">
…
</head>
…
</html>

Има разбира се и незадължителни атрибути:
og:audio – A URL to an audio file to accompany this object.
og:description – A one to two sentence description of your object.
og:determiner – The word that appears before this object’s title in a sentence. An enum of (a, an, the, „“, auto). If auto is chosen, the consumer of your data should chose between „a“ or „an“. Default is „“ (blank).
og:locale – The locale these tags are marked up in. Of the format language_TERRITORY. Default is en_US.
og:locale:alternate – An array of other locales this page is available in.
og:site_name – If your object is part of a larger web site, the name which should be displayed for the overall site. e.g., „IMDb“.
og:video – A URL to a video file that complements this object.

Ето техният HTML пример:

<meta property="og:audio" content="https://example.com/bond/theme.mp3">
<meta property="og:description" content="Sean Connery found fame and fortune as the suave, sophisticated British agent, James Bond.">
<meta property="og:determiner" content="the">
<meta property="og:locale" content="en_GB">
<meta property="og:locale:alternate" content="fr_FR">
<meta property="og:locale:alternate" content="es_ES">
<meta property="og:site_name" content="IMDb">
<meta property="og:video" content="https://example.com/bond/trailer.swf">

Отделно, някои от атрибутите могат да имат допълнитела мета информация. Например за og:image можем да имаме:
og:image:url – Identical to og:image.
og:image:secure_url – An alternate url to use if the webpage requires HTTPS.
og:image:type – A MIME type for this image.
og:image:width – The number of pixels wide.
og:image:height – The number of pixels high.
og:image:alt – A description of what is in the image (not a caption). If the page specifies an og:image it should specify og:image:alt.

HTML пример:

<meta property="og:image" content="https://example.com/ogp.jpg">
<meta property="og:image:secure_url" content="https://secure.example.com/ogp.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="400">
<meta property="og:image:height" content="300">
<meta property="og:image:alt" content="A shiny red apple with a bite taken out">

Подобно и заз og:video, за og:audio…

Друго интересно е, че даден таг с дадено property може да има повече от една стойност.
Например:

<meta property="og:image" content="https://example.com/rock.jpg">
<meta property="og:image" content="https://example.com/rock2.jpg"> 

Литература:

https://ogp.me/

Separation of concerns in HTML and CSS

HTML трябва да е максимално концентриран върху семантиката на една страница – самата информация и смисъл.

За това как изглежда страницата имаме CSS.

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

Toва трябва да е добрия HTML код.

Затова не се препоръчва в HTML-а да няма нищо, свързано с външният изглед, дори и атрибути като width, height и т.н…

Що е polyfill и има ли то почва у нас?

Например за HTML, от polyfill имаме нужда, когато с помощта на JavaScript създаваме функционалност, която липсва в самият HTML.

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

Selectivizr например.

A polyfill is a piece of code (or plugin) that provides the technology that you, the developer, expect the browser to provide natively.

Възможно е и за други езици и технологии да има възможност за използване на такива „сурогати“.

XUL

XML диалект, с който могат да се пишат user interface скриптове, което го прави да е нещо като HTML но изполвайки XML.

… which is a cross-platform language for describing applications’ user interfaces… явно се използва за разработване само на интерфейси.

XUL provides the ability to create most elements found in modern graphical interfaces. Some elements that can be created are:

  • Input controls such as textboxes and checkboxes
  • Toolbars with buttons or other content
  • Menus on a menu bar or pop up menus
  • Tabbed dialogs
  • Trees for hierarchical or tabular information
  • Keyboard shortcuts

In Mozilla, XUL is handled in much the same way as HTML or other types of content are handled. When you type the URL of an HTML page into the browser’s address field, the browser locates the web site and downloads the content. The Mozilla rendering engine takes the content in the form of HTML source and transforms it into a document tree. The tree is then converted into a set of objects that can be displayed on the screen. Style sheets (CSS), images, and other technologies are used to control the presentation. XUL functions in much the same way.

https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL/Tutorial

https://www.xul.fr/tutorial/application.html

< meta viewport

Kaто зададеш width на body таг да е например 100%, добре, ама 100% от колко?

От т.н. viewport size, а колко да е този viewport size вече се задава с meta тага, демек, задаваш широчината на viewport size да е колкото е широчината на екранът на устройството.

Ако не зададеш широчината на viewport-a, брауза ще използва някаква дефолтна, която е например 980px

Защо според Joel Spolsky тагът

Според Joel Spolsky тагът
<meta http-equiv=“Content-Type“ content=“text/html; charset=……“>
трябва да е веднага след <head>, защото така браузърът ще спре да парсира HTML кода до там и ще започне отначало, използвайки зададеният енкодинг.

Демек, вече ще знае с какъв енкодинг да дисплейне дадената страница. Да не забравяме, че браузърът получава „купчина единици и нули“, как да знае точно от кой енкодинг са.

But that meta tag really has to be the very first thing in the <head> section because as soon as the web browser sees this tag it’s going to stop parsing the page and start over after reinterpreting the whole page using the encoding you specified.

Aко нито с HTTP хедър, нито с този HTML таг не е зададен енкодингът на страницата, браузърите имат свои механизми да разгадаят правилният енкодинг, но едва ли безгрешно. И едва ли бързо…

Е да, другият вариант е с HTTP тагът Content-Type:

Content-Type: text/html; charset=utf-8

Литература:

https://www.joelonsoftware.com/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type

HTML form enctype

application/x-www-form-urlencoded

Когато енктайпа е application/x-www-form-urlencoded – праща данните все едно са енкоднати с urlencode()

Демек „plamen“ ‘georgiev’ го праща като %22plamen%22+%27georgiev%27

Aко имаш file поле за ъплоуд на файл – качва само името на файла, пак енкоднато все едно с urlencode()

Eто примерно request body:
fldName=%22plamen%22+%27georgiev%27&fldFile=somefilename.jpg&fldSubmit=Kachvai

multipart/form-data

Когато енктайпа е multipart/form-data – праща данните по съвсем друг начин.

Content-Type: multipart/form-data; boundary=–––––––––265001916915724 (някакъв номер, различен за всеки отделен request)

и после разделя стойностите на отделните полета със:

––––––––––265001916915724
Content-Disposition: form-data; name=“fldName“

„plamen“ ‘georgiev’
––––––––––265001916915724
Content-Disposition: form-data; name=“fldFile“; filename=“20170916_101204.jpg“
Content-Type: image/jpeg

ÿØÿájYÿ*§(€%$ЕРge4$@Т23r2rqХСАТ€§%€%$СА&%€УÿájY… и т.н…. някаква двоична чудесия…

text/plain

Когато енктайпа е text/plain – праща данните подобно на application/x-www-form-urlencoded но не енкоднати. На качен файл с „file“ поле му качва само името.

fldName=“plamen“ ‘georgiev’
fldFile=somefilename.jpg
fldSubmit=Kachvai

Достигам до извод, че ако искаш да качваш файл – само multipart/form-data, иначе качва само името на файла. И мотодът да е POST.