Тэги как кирпичи всякого документа основанного на XML должны выбираться с большим прагматизмом, что-бы потом не удалять ненужные (т.н. deprecated) и не тормозить внесение новых (sound, video). В свете того что я сам этой темой пристально занимаюсь решая что нужно оставить в WYSIWYG-редакторе и что добавить, а так-же меня интересует типографика и семантика, то читая Никиту решил тоже поштудировать эту тему.
a — мало кто помнит почему самый популярный тэг ссылки использует такое название да ещё и параметр href. Ещё меньше пишущих статьи используют этот тэг по прямому назначению, а именно в качестве якоря к участку документа, определённому параметром name. С переходом на динамическое содержание при помощи ajax, якорь получил новую жизнь, поскольку в URL после # можно прописать адресс открытого письма (см. gmail), но мало кто это замечает.
address — единого мнения нет, то-ли это физический почтовый адресс, то-ли это часть описания документа с email-ом.
abbr — отличный тэг для сокращений. Используя параметр title как в картинках, при наведении курсором появится полное название
ins и del — очень часто статьи в блогах и ЖЖ меняются, при этом люди пишут что-то типа «upd. вопрос разрешился», тогда как логичней использовать для этого соответсвующие тэги. Само собой когда статья имеет историю изменений типа wiki, то система должна быть посложней.
sub и sup — эти тэги находят как правило те кто хочет оформить простейшую математику или химию. Впрочем степени, атомарные и изотопные индексы не единственная функция. Если вы когда-либо писали дипломную работу то наверняка столкнулись с научным оформлением ссылок на источники, а сноски с использованием sup вкупе с anchor активно используются взамен неподдерживаемого тэга fn.
tfoot, thead, th, caption — всё это тэги, расширяющие обычную таблицу. Очень часто разработчики усложняют себе жизнь добавляя лишние классы, div-элементы и тп.
label — используется в формах как текстовое описание поля и если связан через параметр for
с элементом, то при нажатии активирует элемент. Очень полезен с
галочками и автоподсказками. В последнее время становится популярным.
fieldset и legend — элемент группирования элементов форм и соответсвенно заголовок к этой группе. Из-за ограниченний браузеров и разного отображения разработчики отказываются в сторону искуственных и универсальны div-элементов. Но упомянуть я немогу.
code, var — нужные разве что программистам. Вместо них как правило используют pre и em, что помоему не очень семантично.
base — помоему самый ценный тэг для CMS, поскольку один раз установив для документа абсолютный путь, все остальные объекты (изображения, ссылки) можно указывать относительно. Это уменьшает как работу с темплейтами у программиста, так и уменьшает код.
Будьте бдительны, неосторожная игра с элементами которые вам могут показаться "семантически подходящими" на самом деле могут быть либо мало поддерживаемыми браузерами, либо deprecated со стороны W3C в соответсвующем XHTML/HTML5 стандарте. Например menu, listing, comment, sidebar
SVG (scalable vector graphics) это векторный формат графики подобно EPS, анимации и интерактива с пользователем, разрабатываемый в W3C. Внутри файл не бинарный а обычный XML, описывающий объекты, их эффекты и поведение.
Векторная графика в общем нужна при изменении размера изображения без потери качества, например в полиграфии. В web я это вижу в резиновых сайтах, где размеры блоков установлены в %, размер шрифтов в em, а лого - в SVG. Пересели на более хороший монитор - всё изменилось пропорционально. Практические примеры - иконки, графики, карты, логотипы, интерфейсы. Ниже я привожу пример такого Pie-chart'а.
Интеграция
HTML - Inline
Поскольку SVG по сути XML, то его можно сразу inline-стилем описывать в XHTML-структуре. Однако как я уже убедился, XHTML1.1 doctype подразумевает что MIME документа уже не text-plain. А "ослик" IE6 не понимает XHTML в принципе, с другой стороны Firefox использует два парсера, и если MIME не application/xhtml+xml, то inline SVG не будет распознан. Это палка с двумя концами - IE и FF.
С Active Directory мне недавно пришлось столкнуться на практике в большой компании. LDAP это протокол по которому можно читать с 389 порта ldap сервера иерархические данные, а также изменять и фильтровать их. Используются эти данные как некий аналог регистра Windows, только для публичных целей. Обычно AD используется в больших корпорациях что-бы хранить личную информацию сотней сотрудников, сгруппированных по департаментам и регионам.
Адрессация
При работе с LDAP (я буду использовать этот термин, хотя это всё равно что говорить HTTP вместо Apache Server) можно заметить сначала полный хаос - какие-то сокращения, завёрнутые в одно иерархическое дерево, по которому ещё можно и поиск делать странный. На самом деле - дерево строится без всяких ID'шников, по именам папок. А сокращения это:
DN (Distinguished Name). Полное местонахождение от корня, типа URL - уникален и состоит из родителей. RDN (Relative Distinguished Name). Фактически - имя, просто без родителей, должно быть под своим родителем уникально вроде как.
Стандартное web-приложение работает минимум на двух машинами - браузере клиента и web-сервере с базой данных. Естественно что системное время на машинах может быть разным. Приложения которые безразличны к тому какое время у клиента очень распространены. Типичный пример где такие проблемы замечаются это форумы и социальные сети, что уж говорить о финансовых операциях.
Время на сервере (реальное)
Очевидно, что сохранять клиентское время в базу бессмысленно, потому что клиент может поменять временной пояс, или другие люди со своим часовым поясом могут запросить те же данные.
Можно попробовать до внесения данных установить на сервере часовой пояс клиента - в mysql это можно: SET time_zone='+00:00'
Человеко-понятный URL нужен. Так наглядней видеть где вы находитесь. Реализовать ЧПУ можно несколькими способами.
(Apache) mod_rewrite
В зависимости от архитектуры web-системы, загрузка отдельных модулей происходит как правило если не напрямую через GET запрос, то хотя-бы косвенно. Косвенно это когда создаётся страница, а потом специально для неё создаётся путь, сохраняется в БД, изменяем и красив.
Преобразование разных параметров в папки по-моему самое нужное. Включаем mod_rewrite, создаём или дописываем .htaccess что-бы работало всё так:
