Каскадные Таблицы Стилей → Препроцессинг CSS на клиенте
Представьте, что вы пишете блогохостинг и хотите позволить авторам блогов менять свой дизайн. Картиночки там вставлять, цвета менять, пропорции регулировать… Представили? Если хорошо представили, то уже поняли, что без констант и формул в CSS тут не обойтись.
При блуждании по блогам не хотелось бы грузить все стили заново, что неизбежно при серверном вычислении значений, а хотелось бы грузить лишь минимальную разницу — так называемый скин.
Итого, нам нужно грузить в дополнение к данным страницы: скин с константами и стили с формулами. Только две клиентские технологии позволяют сделать это: JS и XSLT. Однако первую очень любят отключать, а вторую отключать просто нет смысла. Поэтому вынесем CSS в XSLT контейнер, а заодно и не забудем про технологию XHTML-инклудов.
При блуждании по блогам не хотелось бы грузить все стили заново, что неизбежно при серверном вычислении значений, а хотелось бы грузить лишь минимальную разницу — так называемый скин.
Итого, нам нужно грузить в дополнение к данным страницы: скин с константами и стили с формулами. Только две клиентские технологии позволяют сделать это: JS и XSLT. Однако первую очень любят отключать, а вторую отключать просто нет смысла. Поэтому вынесем CSS в XSLT контейнер, а заодно и не забудем про технологию XHTML-инклудов.
Клиентская оптимизация → Правильное REST кэширование
Пусть мы хотим написать свой хабрахабр с блекджеком и прочими прелестями. Страница статьи у нас стостоит из 3 объёмных блоков:
1. собственно текст статьи. меняется очень редко.
2. дерево комментариев. меняется относительно часто, но со временем всё реже и реже.
3. прямой эфир. небольшой, но меняется очень часто.
Допустим, что страница с этой статьёй доступна по адресу ?article:right.cache
Но внутрь неё мы не будем помещать никакого контента, а вынесем его в отдельные ресурсы, как это обычно делается со скриптами и стилями. Внутри ?article:right.cache будет лишь индекс подключаемых ресурсов с версиями.
?article:right.cache/content/version:123
?article:right.cache/comments/time:2010-12-01
?live/time:2010-12-01
?style:article/version:666
?script:article/version:333
Указание версии позволяет задать для ресурсов жёсткое кэширование. А для индексного файла, наоборот, зададим необходимость проверять при каждом запросе изменился ли он.
Такая организация гарантирует нам, что при появлении новых комментариев не придётся грузить статью заново. И наоборот, при изменении статьи не надо будет перегружать всё дерево комментариев. А уж про то, что из-за часто меняющегося прямого эфира нам не надо по новой грузить весь контент, и заикаться не стоит ;-)
Важно, чтобы поисковики видели ссылки на ресурсы и могли их проиндексировать. Однако, из поиска люди будут приходить на конкретный ресурс и даже на конкретную его версию. Соответственно, ресурс должен определять загружен ли он по прямой ссылке и если это так, то после загрузки клиентскими средствами редиректить на индекс. Если актуальная версия ресурса не изменилась, то он потом будет взят из кэша. Если же изменилась — будет загружена новая версия. Не такая уж страшная беда, на самом деле ;-)
Реализации с использованием фреймов и аякса довольно банальны, так что воспользуемся хтмл-инклудами.
1. собственно текст статьи. меняется очень редко.
2. дерево комментариев. меняется относительно часто, но со временем всё реже и реже.
3. прямой эфир. небольшой, но меняется очень часто.
Допустим, что страница с этой статьёй доступна по адресу ?article:right.cache
Но внутрь неё мы не будем помещать никакого контента, а вынесем его в отдельные ресурсы, как это обычно делается со скриптами и стилями. Внутри ?article:right.cache будет лишь индекс подключаемых ресурсов с версиями.
?article:right.cache/content/version:123
?article:right.cache/comments/time:2010-12-01
?live/time:2010-12-01
?style:article/version:666
?script:article/version:333
Указание версии позволяет задать для ресурсов жёсткое кэширование. А для индексного файла, наоборот, зададим необходимость проверять при каждом запросе изменился ли он.
Такая организация гарантирует нам, что при появлении новых комментариев не придётся грузить статью заново. И наоборот, при изменении статьи не надо будет перегружать всё дерево комментариев. А уж про то, что из-за часто меняющегося прямого эфира нам не надо по новой грузить весь контент, и заикаться не стоит ;-)
Важно, чтобы поисковики видели ссылки на ресурсы и могли их проиндексировать. Однако, из поиска люди будут приходить на конкретный ресурс и даже на конкретную его версию. Соответственно, ресурс должен определять загружен ли он по прямой ссылке и если это так, то после загрузки клиентскими средствами редиректить на индекс. Если актуальная версия ресурса не изменилась, то он потом будет взят из кэша. Если же изменилась — будет загружена новая версия. Не такая уж страшная беда, на самом деле ;-)
Реализации с использованием фреймов и аякса довольно банальны, так что воспользуемся хтмл-инклудами.
XSLT → Кроссбраузерные HTML инклуды \(^_^)/
Пусть у нас есть простенький хтмльчик index1.htm
Как известно, хтмл поддерживает инклуды только через iframe/object, но с ними не очень удобно работать из яваскрипта.
Можно, конечно, прописать в каждую подключаемую страницу скрипт типа такого
Он переносит своё содержимое в родительский документ и удаляет фрейм. Но в случае отключённоо яваскрипта мы получим окошко ифрейма не подстраивающееся под размер содержимого.
<!DOCTYPE html>
<html>
<head>
<title>Xbrowser HTML includes</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
</head>
<body>
<h1>First file</h1>
</body>
</html>Как известно, хтмл поддерживает инклуды только через iframe/object, но с ними не очень удобно работать из яваскрипта.
Можно, конечно, прописать в каждую подключаемую страницу скрипт типа такого
new function(){
var frame= window.frameElement
if( !frame ) return
var parent= frame.parentNode
var body= document.getElementsByTagName( 'body' )[0]
var child;
while( child= body.firstChild ) parent.insertBefore( child, frame )
parent.removeChild( frame )
}Он переносит своё содержимое в родительский документ и удаляет фрейм. Но в случае отключённоо яваскрипта мы получим окошко ифрейма не подстраивающееся под размер содержимого.
Веб-разработка → Непонимание разметки. Комикс про XHTML 2 и HTML5
С выходом HTML 5 и анонсом W3С о прекращении разработки XHTML 2 в конце 2009 года начались активные дебаты по поводу будущей «правильной разметки». XHTML 1.0, XHTML 2, HTML 4, HTML 5 и XHTML 5 — за всем этим тяжело уследить.
Теперь, когда XHTML 2 перестал маячить на горизонте, какой синтаксис выбрать? Остаться на XHTML 1.0, или двинуться вперед на HTML 5? А может, вернуться к старому доброму HTML 4? Этот комикс немного все проясняет.
Персональные блоги → XHTML 2 против HTML 5
Вернемся в прошлое на десять с небольшим лет, в 18 декабря 1997. Internet Explorer 4 был выпущен 3 месяца назад, The Mozilla Foundation еще не сформирована и до выхода Firefox еще далеко. Здесь нет XMLHttpRequest, нет даже XML. В этот день, больше десятилетия назад, HTML 4.0 был опубликован как рекомендация W3C.
Он и стал базой, на основе которой были разработаны современные web-стандарты. Конечно, были и усовершенствования. В 2000 году как официальная рекомендация был принят XHTML 1.0, а CSS 2 был реализован большинством производителей браузеров. Но основа Web – костяк, на котором построен каждый сайт, от простых визиток до комплексных приложений – по существу осталась неизменной.
По крайней мере, до сегодняшнего дня. После долгого затишья, кажется, уклад вещей в W3C меняется – в разработке находятся две конкурирующие спецификации, призванные заменить устаревшие стандарты HTML 4.x и XHTML 1.x. Обе инициативы работают под эгидой W3C (пусть так было и не всегда) и обе, по моему мнению, значительно превосходят текущую подборку языков web-разметки. Это HTML 5 и XHTML 2.0. И если вы читаете эту статью, скорее всего, в течение нескольких следующих лет вам придется работать с одной (или обеими) из них.
Он и стал базой, на основе которой были разработаны современные web-стандарты. Конечно, были и усовершенствования. В 2000 году как официальная рекомендация был принят XHTML 1.0, а CSS 2 был реализован большинством производителей браузеров. Но основа Web – костяк, на котором построен каждый сайт, от простых визиток до комплексных приложений – по существу осталась неизменной.
По крайней мере, до сегодняшнего дня. После долгого затишья, кажется, уклад вещей в W3C меняется – в разработке находятся две конкурирующие спецификации, призванные заменить устаревшие стандарты HTML 4.x и XHTML 1.x. Обе инициативы работают под эгидой W3C (пусть так было и не всегда) и обе, по моему мнению, значительно превосходят текущую подборку языков web-разметки. Это HTML 5 и XHTML 2.0. И если вы читаете эту статью, скорее всего, в течение нескольких следующих лет вам придется работать с одной (или обеими) из них.
Веб-разработка → Иван Сагалаев поздравляет всех вебстандартистов с 1ым апреля.
Со слов самого Ивана, он, наверное, самый известный человек в рунете, довольно холодно относящийся к пользе XHTML, и DTD-валидации. Однако, при этом остается очень авторитетным ИТ-специалистом. И вот сегодня утром, я обнаруживаю у него в блоге запись со следующим заголовком:«XHTML 2».