Добавлен: 28.06.2023
Просмотров: 39
Скачиваний: 3
|
* { margin: 0; padding: 0; box-sizing: border-box; } .small_box { font-size: 8pt; } body, html { width: 100%; height: 100%; } |
Не обязательно выбирать один из вариантов, можно комбинировать их в любом соотношении.
Стиль с элементом можно связать одним из трёх способов:
- По имени тега: теги пишутся как есть без дополнительных символов.
- По имени класса тега: у каждого тега можно задать атрибут class, по значению этого атрибута и можно связывать стиль с элементами. Это делается с помощью указания имени класса и установки знака «.» перед именем. Например, у тега <span class=’SomeClass’> text </span> имя класса равно SomeClass, значит в файле стилей к нему можно будет обратиться так: .SomeClass {}
- По имени уникального идентификатора конкретного элемента. Идентификатор указывается в атрибуте id любого тега на странице, а образение к нему происходит с подставлением перед идентификатором символа «#». К элементу <span id=’SomeClass’> text </span> стоит обращаться так: #SomeClass {}
Глава 6. Отличия HTML и XHTML
Если в основе HTML лежит стандарт SGML, то в основе XHTML заложен XML.
Функциональность у XHTML и HTML одинаковая, но отличается принцип построения документа и его обработки. Поскольку XHTML является расширением XML, то все требования к правильно сформированному (well-formed) XML документу сохраняются. Вот те самые дополнительные требования к разметке документа, если он должен соответствовать стандарту XHTML:
- Каждый тег XHTML должен быть закрыт. Если HTML позволял конструкции типа <br> или <hr>, то в XHTML они должны выглядеть только так: <br/><hr/>. Менее тривиальным является следующий вариант разметки, который устраивает HTML, но не является корректным с точки зрения XML: <b>bold<i>bold_and_italic</b>italic</i>. Правильным XHTML аналогом будет являться следующая разметка <b>bold<i>bold_and_italic</i></b><i>italic</i>. На основе приведенного примера, первое ограничение я бы дополнил формулировкой: XHTML не допускает частичного пересечения области действий тегов разметки. Если это обстоятельство и создает какие-то дополнительные сложности верстальщикам, то эти сложности с лихвой компенсируются контролем над ошибками со стороны сервисов XML. Причины всех этих ограничений проявятся дальше.
- XHTML не поддерживает сокращенной формы записи атрибутов. Это означает, что в XHTML нет сокращенной формы записи булевых атрибутов, а само значение атрибутов всегда должно быть в кавычках. Если в HTML следующий код считался корректным <input type=textbox readonly value='anytext'/>, то в XHTML приведенная конструкция должна выглядеть следующим образом: <input type='textbox' readonly='readonly' value='anytext'/>.
- Специальные символы в XHTML должны быть представлены в виде кодов. Это означает, например, что символы < и >, если они не являются частью разметки, должны в тексте обозначаться, как < и > соответственно. Если такой вариант не устраивает, например, если требуется в разметку добавить программный код (Java-script, VBScript), то для этих целей следует использовать раздел CDATA, содержимым которого может быть любая символьная информация, в том числе специальные символы разметки. Вот пример: <script type="text/javascript"><![CDATA[Код скрипта]]> </script>
- Все символы, используемые в именах тегов и атрибутов должны быть строчными. Вот это ограничение уже не является наследием XML, поскольку XML настаивает только на том, чтобы и открывающий и закрывающий теги были записаны одинаковым набором символов, в который могут входить как строчные, так и заглавные символы. Это ограничение, скорее, результат стремления избежать путаницы и оптимизировать скорость обработки документа. Кодировка символов в XHTML, как и в XML по умолчанию UTF-8.
- Корневой элемент в XHTML должен быть один. Другими словами это означает, что тег HTML должен присутствовать в XHTML всегда! Стандарт HTML не настаивал на присутствии тегов <HTML> и <BODY> – разметку можно было начинать с любого тега и корневого элемента могло не быть вообще.
Есть ещё несколько отличий, чуть менее очевидных, но точно так же исходящих из того, что XHTML является расширением XML, а HTML нет.
Обработчик HTML является, по сути, интерпретатором. Он обрабатывает документ последовательно, и именно это обстоятельство позволяет ему исправлять ошибки разметки. Многим известно, что документ HTML в памяти браузера представлен в виде объектной модели DOM. Именно DOM является основой DHTML (Dynamic HTML) – симбиоза HTML и JavaScript, который способен “оживлять” статичную разметку, обрабатывая события пользователя.
Код javascript и DOM способны одни фрагменты документа “на лету” заменять другими или существенно изменять стиль их отображения. Преобразования эти осуществляются на стороне клиента, благодаря чему перезагрузки страницы не требуется. Все выглядит красиво и динамично. Именно благодаря DOM стали возможны все выпадающие меню и списки на страницах браузера. Для корректного формирования объектной модели интерпретатору HTML жизненно необходимо исправлять ошибки верстальщиков, добавляя закрывающие теги, исправляя частичные пересечения области действия тегов разметки (пример выше) и т.п. Обработчик XML, в свою очередь, больше походит на компилятор: он обрабатывается сразу весь документ.
Если документ не является well-formed (например, нарушает стандарты xml), то обработчик (парсер) сообщает об ошибке и отменяет формирование DOM целиком.
Логично, что в случае XHTML происходит все то же самое. Для XML и его расширений действует правило: “Либо все, либо ничего”, в то время как парсер HTML не сообщает об ошибках, старается их исправлять и практически всегда производит, как минимум, частичную обработку HTML страницы. Может показаться, что такое поведение интерпретатора HTML более удобно, нежели парсера XHTML, однако есть нюансы.
Исправление HTML происходит на стороне клиента, т.е. интернет браузером. Различных браузеров достаточно много, не говоря уже о большом количестве версий каждого из них. Это обстоятельство не гарантирует вам, что во всех случаях ошибки будут исправлены одинаково и результат этого исправления вас устроит. Также можно утверждать, что на исправление ошибок тратится дополнительное время. Не стоит в этом полагаться на браузер.
На данный момент не все интернет браузеры поддерживают XHTML. Для того чтобы поэкспериментировать с этим новым стандартом локально, достаточно файлу с гипертекстом дать расширение .xhtml и открыть его в поддерживающем XHTML интернет браузере, например, в Opera. Если разметка не будет соответствовать well-formed XML, то браузер выведет сообщение об ошибке. Если у тега не будет определено пространство имен xmlns=http://www.w3.org/1999/xhtml, то вы увидите просто xml, а не обработанную страницу.
При разработке сайтов рекомендуется придерживаться правил XHTML, и проверять страницу на соответствие этому стандарту локально. А какой обработчик будет использован браузером пользователя не так важно, поскольку если страница соответствует синтаксису XHTML, то синтаксису HTML она соответствует точно. Принудительно использовать парсер XHTML можно заставить браузер в любой момент, настроив должным образом заголовки интернет страниц на сервере.
Глава 7. Инструменты для работы с HTML
Так как документы html являются текстовыми, для работы с ними подойдёт абсолютно любой текстовый редактор. Но ввиду специфику содержимого лучше выбирать редакторы, которые будут обеспечивать подсветку синтаксиса языка разметки. Это значительно упрощает работу в разы.
Рис 3. Пример html документа в редакторе без подсветки синтаксиса.
Рис 4. Пример html документа с подсветкой синтаксиса.
Среди таких редакторов можно выделить несколько наиболее популярных и удобных. От самых простых: notepad++ и sublime text, до серьёзных и коммерчески выгодных: WebStorm, PhpStorm, Visual Studio, Atom.io.
Так же для работы с html со всеми вышеупомянутыми редакторами применяется множество расширений и дополнительных инструментов, ускоряющих работу. Такие инструменты умеют автоматически заканчивать имена тегов, компилировать законченный документ из сокращённого синтаксиса, автоматически обновлять окно браузера для отображения внесённых в документ изменений «на лету» и многое другое.
Существует множество онлайн (работающих в окне браузера) редакторов, облегчающих работу фронтэнд разработчиков. Фронтэнд (англ. Frontend) разработчики – это специалисты, занимающиеся созданием клиентской части веб приложений, то есть как раз и работают с html, css и JavaScript.
Но не все работают с html файлами только в текстовом формате. Существуют редакторы, позволяющие менять именно визуальную составляющую документа, она так и называются: Визуальные редакторы.
Визуальные или же WYSIWYG редакторы позволяют редактировать именно внешнюю составляющую будущей веб страницы, а сам код разметки, таблиц каскадных стилей и javascript скриптов формируются программой в фоновом режиме. То есть при работе с ними разработчик апеллирует не текстом разметки, а графическими элементами, из которых состоит страница.
Самыми популярными WYSIWYG редакторами на рынке являются: Adobe Dreamweaver, Adobe Muse, KompoZer, Amaya и многие другие. Они очень удобны с той точки зрения, что разработчик сразу же видит результат. Нет необходимости писать сотни строк кода, подгонять стили, постоянно обновлять окно браузера. Всё происходит «на лету». Так же они ускоряют процесс создания прототипа будущей веб страницы либо позволяют создать веб документы, не обладая знаниями в области компьютерной вёрстки и программирования.
Визуальные редакторы делятся на несколько типов: предназначенные в первую очередь для вёрстки, такие как например Dreamweaver.
Рис 5. Пример окна визуального редактора Adobe Dreamweaver
Или же заточенные на создание прототипов и дизайна, например Adobe Muse.
Рис 6 Окно визуального редактора Adobe Muse.
Но если бы всё было так хорошо, никто бы не пользовался редакторами кода. Здесь так же есть свои минусы: визуальные редакторы ВЕБ страниц генерируют код разметки и стилей не опираясь на производительность, лаконичность, человеческий опыт и дальнейшую читабельность документов.
Код, полученный на выходе из таких инструментов в большинстве своём очень громоздкий, содержит множество лишних элементов, перегружен свойствами и слабо читаем, что усложняет его дальнейшую поддержку.
К таким редакторам стоит прибегать в одном из нескольких случаев:
- Дальнейшая поддержка документа не планируется. Необходимо создать «одноразовый» документ.
- Необходимо в короткие сроки разработать прототип для его демонстрации и затем уже переходу к разработке полноценного веб документа.
- Нет возможности привлечь к разработке квалифицированных специалистов
- Недостаточно знаний для создания страницы с нуля, но достаточно для оптимизации автоматически сгенерированного года.
Так как на сегодняшний день понятие HTML неразрывно связано с созданием веб страниц, к программам, без которых этот процесс не обходится, стоит так же отнести и графические редакторы. К HTML они относятся косвенно, однако, без них не происходит создание практически ни одного сайта, а также они имеют вспомогательный функционал, способный упростить настройку некоторых элементов на странице, к примеру, копированием уже готового CSS кода.
К самым известным из них относятся следующие программы: Adobe Photoshop, Adobe Illustrator и Coral Draw.
