1.2. HTML-элементы
HTML-элементы — основа языка HTML. Каждый HTML-документ состоит из дерева HTML-элементов и текста. Каждый HTML-элемент обозначается начальным (открывающим) и конечным (закрывающим) тегом. Открывающий и закрывающий теги содержат имя элемента.
Все HTML-элементы делятся на пять типов:
- пустые элементы — , ,
, , ,
,
, , , , , , , , ;
- элементы с неформатированным текстом — , ;
- элементы, выводящие неформатированный текст — , ;
- элементы из другого пространства имён — MathML и SVG;
- обычные элементы — все остальные элементы.
В таблице приведен полный список элементов, поддерживаемых HTML4 и HTML5. Экспериментальные и устаревшие элементы исключены. Элементы, добавленные в спецификацию HTML5, выделены бирюзовым цветом.
Полный список HTML-элементов
| Элемент | Описание | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Используется для добавления комментариев. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Объявляет тип документа и предоставляет основную информацию для браузера — его язык и версия. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Создаёт гипертекстовые ссылки. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Определяет текст как аббревиатуру или акроним. Поясняющий текст задаётся с помощью атрибута title . | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Задает контактные данные автора/владельца документа или статьи. Отображается в браузере курсивом. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Представляет собой гиперссылку с текстом, соответствующей определенной области на карте-изображении или активную область внутри карты-изображения. Всегда вложен внутрь элемента . | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Раздел контента, который образует независимую часть документа или сайта, например, статья в журнале, запись в блоге, комментарий. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Представляет контент страницы, который имеет косвенное отношение к основному контенту страницы/сайта. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Загружает звуковой контент на веб-страницу. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Задает полужирное начертание отрывка текста, не придавая акцент или важность выделенному. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Задает базовый адрес (URL), относительно которого вычисляются все относительные адреса. Это поможет избежать проблем при переносе страницы в другое место, так как все ссылки будут работать, как и прежде. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Изолирует отрывок текста, написанный на языке, в котором чтение текста происходит справа налево, от остального текста. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Отображает текст в направлении, указанном в атрибуте dir , переопределяя текущее направление написания текста. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Выделяет текст как цитату, применяется для описания больших цитат. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Представляет тело документа (содержимое, не относящееся к метаданным документа). | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Перенос текста на новую строку. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Создает интерактивную кнопку. Элемент может содержать текст или изображение. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Холст-контейнер для динамического отображения изображений, таких как простые изображения, диаграммы, графики и т.п. Для рисования используется скриптовый язык JavaScript. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Добавляет подпись к таблице. Вставляется сразу после открывающего тега
Таблица-шпаргалка с элементамиДля удобства пользования я сгруппировала HTML-элементы по тематическим разделам, добавив значения свойства display . Чтобы перейти к таблице, кликните по рисунку. как назвать контейнер?Вот у меня есть тип, который включает в себя массив (кусок памяти). В массиве каждый бит изображает число от 0 до Размер-1. И таким образом реализовано множество целых чисел. Тип мутабельный. Доступ не потокобезопасный. Диапазон чисел, к-рые могут храниться, фиксируется в момент создания. Отрицательные числа хранить нельзя. Задача на 5: как назвать такой контейнер? Если его назвать так, чтобы название отражало смысл, то получится что-то типа: А если название не отражает смысл, то оно проживёт до момента, когда появится немутабельное или с поддержкой параллельного доступа, или с изменяемым размером. У нас в лиспе никогда не было этих вот STL-ей и стандартных контейнеров от Явы. Да и в SQL тоже как-то мало разных контейнеров. Что делать-то, как назвать? Ну вы можете сказать, что Оберон плохой язык, потому что в нём нельзя сделать слова параметрами шаблона. Но речь не про то. Если слова разделить запятыми и засунуть в угловые скобки, сильно проще не станет. den73 ★★★★★ Первая реакция после шока — надо вводить какую-то номенкулатуру, типа марок сталей или кодов микросхем, кодировать аспекты контейнера буквами. 12Х18Н10Т, 1891ВМ4Я. den73 ★★★★★ Назови как в жабе BitSet, ибо если я прравильно понимаю, именно его ты и сделал. Shevchik
Квалификаторы типа const не завезли что-ли?
Местами завезли, но вопрос не в том. Мутабельный и иммутабельный контейнер вообще разные. den73 ★★★★★
Где-то что-то пошло не так…
Не совсем BitSet, поменьше функций в этом. Ну и я его не делаю, просто придумываю правильное название. Сейчас он называется Bitmap. А я обнаружил, что это название условное, т.к. не полностью выражает суть. И тут выяснилось, что у любого контейнера полное название будет ужасно длинным. И в библиотеках обычно названия строятся на основе каких-то условностей. den73 ★★★★★ IntSet — назначение же множество целых чисел, так? Begemoth ★★★★★ Или RemainderSet , т.к. это множество остатков от деления на N. Begemoth ★★★★★ Ответ на: удаленный комментарий Вопрос в том, какие операции на типе определены (его public API). Begemoth ★★★★★
Предназначение? Так то можно это дело и IntegerRangeMask назвать, и IntegerSet, и ещё по всякому. anonymous-angler ★☆ +1 за bitset, потому как это именно то чем такой тип является как структура данных (в STL так называется, по крайней мере), и он довольно generic. А что он уж там логически из себя представляет в конкретном месте программы лучше выражать через имена соответствующих переменных. bugfixer ★★★★ Эх, никто не понял проблему. Понятно, что это битовый вектор с т.з. реализации. Но это ещё и контейнер, а у него есть ряд аспектов: мутабельность, потокобезопасность, фиксированность размера. Я этот назову bitset (вообще кто не понял тег Яр, то я всё по-русски называю, так что это будет БитовыйВектор). А завтра я заведу второй контейнер, такой же, но потокобезопасный. А послезавтра — потокоопасный, но иммутабельный. И т.п. Т.е. всё равно быстро появятся типы-контейнеры с ужасно длинными именами. Получается, что короткие имена, которые мы иногда можем наблюдать, какой-нибудь std::Vector — это условности что ли? Или это, наоборот, базовый класс, у которого никакие аспекты не определены? Как плодить типы контейнеров, чтобы имена их не стали столь ужасны и в то же время, чтобы имена чётко обозначали суть дела? Вот в чём вопрос-то. den73 ★★★★★ Ответ на: комментарий от den73 30.12.20 21:47:06 MSK
Надо ли это всё отражать в именах — это вопрос к тому какие API типичны для классов в разрабатываемой системе. Т.е. если в основном от класса ожидается, что он мутабельный и непотокобезопасный, то такие указания надо опускать. Например, будет vector / immutable_vector (чтобы ни значило) / concurrent_vector. Для immutable подразумевается атомарность операций над объектами типа. Ну и неплохо привести бы список имеющихся / планируемых контейнеров, а то может всё вполне описывается в виде «база» (указание на смысл + гарантии по алгоритмической сложности) + «модификатор» (один в подавляющем большинстве случаев). Ещё как вариант можно использовать имена пакетов/пространства имён для различение вариантов контейнеров. Begemoth ★★★★★
А вот это надо хорошо постараться, чтобы сделать. Ну и необходимость «потокобезопасного» варианта для каждого контейнера — очень сомнительна. Операции над контейнером будут конечно атомарными, но код его использующий необязательно автоматически будет потокобезопасным (см. на API boost::sync_queue vs std::queue ).
Вот тут главный вопрос не в именах, а в том сколько контейнеров надо наплодить. Begemoth ★★★★★
Выделенное жирным — это важная информация, остальное — нет. Begemoth ★★★★★ Да, потокоопасный и мутабельный не бывает, но тут суть не в конкретных примерах, а вообще в большом количестве аспектов и их взаимодействии. Ещё несколько: персистентный, не выделяющий динамической памяти, пригодный для жёсткого реального времени, с оптимизированным хранением (уже не битовый вектор, а хеш-таблица, допустим). Да, пространства имён можно задействовать в какой-то степени. Ну и ещё есть особенность моей текущей деятельности — я не пишу код, а перевожу существующий. Поэтому я не знаю, сколько контейнеров впереди и нет оснований назвать тот, который мне первым попался, наиболее коротким именем. den73 ★★★★★ Ответ на: комментарий от den73 31.12.20 14:29:46 MSK
Тут стоит ориентировать на соотношение универсально/специализированного контейнера. В примере — явно специфическая вещь. Я бы следовал правилу — более универсальные средства имеют более короткие имена. Ты сам увидел, что сообщать всю информацию о типе в его имени — непрактично. Строить короткие имена на базе системы соглашений об именовании — это не прижилось (хоть и использовалось, например, в LAPACK). Можно и с другой стороны посмотреть — имена mapcar/reduce/filter не содержат информацию о том является ли их реализация tail recursive или нет (или там вообще цикл do), вычисляется ли результат сразу или отложено и т.д. Т.е. всё именование основывается на определённых условностях и выделении самой важной информации. Begemoth ★★★★★ А как там было в LAPACK, можно примерчик? Я бы не сказал, что оно вообще нигде не прижилось. Микросхемы вполне себе так обозначаются, да и ещё есть куча других подобных номенкулатур. В автозапчастях вообще едва ли ни числовые коды, типа ip-адресов — и живут ведь как-то.
Ну я и говорю, что фактически именование всегда условное. Единственное, на чём я в моей ситуации могу выехать — то, что это частный объект для модуля и он не экспортируется. Т.е. неважно, как он называется. Но если я хочу, чтобы в коде можно было нагрепать, где какой контейнер есть (а путь оберона — это не делать библиотеку контейнеров, а под каждый случай делать специализированный — хорошо это или нет — отдельная тема, но 40 Мб кода уже есть и решать это уже поздно), то мне нужна какая-то система именований, дружественная к поиску. Какой тег нельзя назвать контейнеромHTML предоставляет набор контейнерных тегов. Эти теги могут содержать неопределенный набор других тегов. и может быть непонятно, в чем разница между ними. Посмотрим, когда использовать каждый из них. articleТег статьи определяетвещьчто может быть независимым от другихвещина странице. Например, список сообщений в блоге на главной странице. Или список ссылок. Мы не ограничены списками: статья может быть основным элементом на странице. Внутри article тег у нас должен быть заголовок ( h1 — h6 ) и sectionПредставляет раздел документа. Каждый раздел имеет тег заголовка ( h1 — h6 ), то разделтело. Длинную статью полезно разбить на разныеразделы. Не следует использовать как общий контейнерный элемент. div создан для этого. div является общим элементом контейнера: Вы часто добавляете class или же id атрибут этого элемента, чтобы можно было стилизовать его с помощью CSS. Мы используем div в любом месте, где нам нужен контейнер, но существующие теги не подходят. Теги, относящиеся к страницеЭтот тег используется для создания разметки, определяющей навигацию по странице. Сюда мы обычно добавляем ul или же ol список: asideВ aside Тег используется для добавления части контента, относящейся к основному контенту. Например, поле, в которое можно добавить цитату. Или боковая панель. С помощью aside это сигнал о том, что вещи, которые он содержит, не являются частью регулярного потока раздела, в котором он живет. headerВ header Тег представляет часть страницы, которая является введением. Например, он может содержать один или несколько тегов заголовков ( h1 — h6 ), слоган статьи, изображение. В main тег представляет основную часть страницы: footerВ footer тег используется для определения нижнего колонтитула статьи или нижнего колонтитула страницы: Какой тег нельзя назвать контейнеромHTML (Hyper Text Markup Language) : язык гипертекстовой разметки, используется для создания интернет-страниц. Страница, написанная таким образом, представляет собой обычный текстовыи документ, в котором при помощи тегов определяются расположение и оформление текста, графики и др. Все теги пишутся в угловых скобках (< , >) Все теги делятся на 2 группы: — требующие закрывающего тега (контейнеры); Теги-контейнеры записываются так: Одиночные теги записывают так: Тег может иметь параметры. Параметры тега записываются после него, внутри его угловых скобок через пробел. Например, Ниже приведены основные html-теги и их применение. Обязательные теги— тег-контейнер, открывающий тег пишется в самом начале документа; закрывающий- в самом конце. Заключает в себе всё содержимое документа и сообщает компьютеру, что это действительно html-документ. — контейнер, заключает в себе голову html-документа, где пишутся специальные теги. Начинается сразу после , заканчивается между и . — контейнер внутри контейнера . — тело документа, где находится основное содержание. Контейнер должен распологаться между и |
