Как вы уже наверное знаете, мы стремимся создать, действительно, профессиональное сообщество. Сообщество веб-разработчиков, которое разговаривает на языках HTML, CSS и JS. 
Но, к сожалению, наших физических возможностей не хватает на то, чтобы часто пополнять сайт интересным материалом, поэтому мы вынуждены попросить помощи у сообщества. Если у кого-то из вас вдруг возникнет желание быть причастным к великому делу и внести свой вклад в его развитие, то мы бы были безумно этому рады. В частности нам нужны переводчики. Люди, хорошо владеющие английским языком, желающие помогать сообществу и развиваться в этом направлении.

Все ваши предложения пишите на почту: psywalker09@gmail.com

На рисунках видно, что при разном разрешении экрана, пункты всё равно продолжают выравниваться по ширине, примыкая к боковым стенкам и делая отступы между собой – равнозначными.
В этой статье я хочу подробнее разобрать разные варианты решения данной задачи, а также рассмотреть все плохие и хорошие стороны этих методов.

Как это работает?

Перед тем, как рассматривать каждое решение в отдельности, давайте немного углубимся в тонкости механизма и поразмыслим, как он работает.
По сути мы должны получить то, что делает text-align: justify с текстом. Так как поведение наших блоков уж очень напоминает результат выравнивания слов в строке с помощью именно этого свойства. Немного углубившись в процесс работы text-align: justify, мы можем наблюдать следующий алгоритм.

Этап первый
Сначала в строке текста ищутся минимальные, неразрывные "кирпичики". Это могут быть отдельные слова в тексте, картинки, инлайн-блоки, инлайн-таблицы и т.д. В общем всё то, что в случае необходимости перенесется на новую строку как единое целое.

Цифрой 1 на картинке отмечены обычные инлайн-боксы, т.е. попросту текст или инлайн элементы, такие, например, как < span> или <em>.
Под цифрой 2 у нас находится элемент строчно-блочного уровня, т.е inline-block. Как можно заменить, алгоритм отступов внутри него рассчитывается заново. Причина в том, что внутри себя inline-block генерирует свой собственный контекст форматирования. Что нельзя сказать об обычном inline элементе, внутри которого межсловное расстояние распределялось бы, по общему, внешнему алгоритму.
Цифрой 3 отмечена обычная картинка. Так же, как и остальные, она является строчным, целым элементом.
Для нашей строки все эти вещи представляют из себя отдельные сущности, неразделимые слова, единые целые. А расстояния между ними как раз и регулируется нашим механизмом, под названием text-align: justify
*Последняя же строка не попадает в поле зрения justify, так как он работает только для целиком заполненных строк, а в последней строке пробелы всегда остаются своего обычного размера.

Этап второй
Вторым этапом алгоритм высчитывает ширины всех наших "кирпичей" в строке, складывает их, а полученный результат отнимает от общей ширины самой строки.

Отсюда можно сделать вывод, что сейчас мы имеем общую сумму всех пробельных зон в строке, которая равна 116px.

Этап третий – завершающий
Третьим и последним этапом алгоритма будет деление полученной цифры (в данном случае 116) на количество пробелов в строке (в нашей строке их 7). Из полученного результата (16.571) вычитается ширина одного пробела и уже это значение добавляется к каждому из них. Что в итоге даёт равномерное распределение отступов во всей строке.

Итог
Как мы можем видеть, алгоритм работы text-align: justify не так уж и сложен на самом деле, всё вроде бы понятно и логично. Я уверен, что каждый из нас, решая подобную задачу, высчитывал бы результат, по точно такому же сценарию. Сложность заключается только в том, чтобы написать хорошее, красивое, а главное качественное решение, затратив при этом минимум материала. Ведь существует много подводных камней, в виде последней (не попадающей под алгоритм) строки, которую нужно прятать, или каким либо образом выравнивать точно так же, как и все остальные. Ну и естественно нельзя забывать об интерпретации кода, таких браузеров, как Opera, IE6-7, которые любят преподносить неожиданные сюрпризы.

Наша задача

Наша задача состоит в том, чтобы построить решение на базе этого алгоритма. Применить, симулировать, заменить, сделать всё что угодно, главное в итоге получить то, что мы хотим. А именно – равномерно выровненные элементы в строке, боковые из которых прижаты к своим границам. Ну и конечно же расстояния (пробелы) между этих элементов должны быть абсолютно одинаковыми при любой ширине контейнера.

Вариант 1

Самое первое, что пришло мне на ум, это взять список из пяти пунктов, сделать 4 из них обтекаемыми, а у последнего отменить float и растянуть на всю оставшуюся ширину. Чтобы было понятнее, о чём идёт речь, привожу код.
Структура будет таковой

<ul>
	<li class="left">
		<div class="content"></div>
	</li>
	<li class="left">
		<div class="content"></div>
	</li>
	<li class="right">
		<div class="content"></div>
	</li>
	<li class="right">
		<div class="content"></div>
	</li>
	<li class="center">
		<div class="content"></div>
	</li>
</ul>

А CSS таким

ul {
	font: 14px Verdana, Geneva, sans-serif;
	overflow: hidden;
}
	ul li {

	}
	ul li.left {
		width: 20%;
		float: left;
	}
	ul li.right {
		width: 20%;
		float: right;
		text-align: right;
	}
	ul li.center {
		text-align: center;
	}
	ul li .content {
		background: #E76D13;
		width: 98px;
		height: 98px;
		display: inline-block;
		text-align: left;
		border: 1px solid #000;

		/* эмуляция inline-block для IE6-7*/
		//display : inline;
		//zoom : 1;
	}

Что мы собственно сделали? А сделали мы следующее. Два левых и два правых пункта мы раскидали по разным сторонам с помощью float : left и float : right соответственно, при этом назначив им по 20% ширины каждому, что в сумме дало 80% от всей ширины контейнера. Последний пункт, я решил не делать обтекаемым, так как его содержимое само по себе занимает всё оставшиеся пространство после float-блоков.
Соответственно для такого решения пришлось пожертвовать разметкой, а точнее дополнительными классами + внутренними контейнерами для контента. Как вы могли заметить, каждый из этих контейнеров я сделал строчно-блочным, повесив на них display : inline-block, благодаря чему мой контент смог выравниваться в любую сторону с помощью text-align у родителя. Эти "жертвы" с большой натяжкой можно было бы отнести к хорошему решению, если бы не некоторые, весомые "но".
Во-первых, как видно из скриншотов, равномерные отступы имеют только боковые пункты, а между средним и остальными есть явная разница. И чем больше ширина контейнера, тем заметнее это становится.
Во-вторых, ради эксперимента, я назначил второму пункту ширину, равную 200px.

И второй элемент сразу же оказался под третьим. Конечно же можно было бы поставить минимальную ширину контейнеру и такого бы не произошло, но разве можно считать это действие отговоркой или решением? Конечно же нет! Я хочу, чтобы наши пункты могли иметь любую ширину и при этом чтобы наш алгоритм идеально работал.
Ну и в-третьих, все эти дополнительные обёртки, классы, рассчитывание кол-ва элементов, их ширины, а так же и ширины контейнера ставят абсолютную точку на этот варианте, заставляя нас идти дальше, в поисках настоящего решения.
Выкладываю этот вариант на всеобщий суд и перехожу к следующему способу.
Вариант с разносторонним выравниванием

Вариант 2

Второй вариант напоминает первый, но только отчасти. Дело в том, что в нём мы выравниваем по левому краю только один, левый блок, а остальные находятся уже в своём, собственном контейнере. Но перейдём от слов к делу.

<ul>
	<li class="one">
		<div class="content">1</div>
	</li>
	<li class="two">
		<ul>
			<li>
				<div class="content">2</div>
			</li>
			<li>
				<div class="content">3</div>
			</li>
			<li>
				<div class="content">4</div>
			</li>
			<li>
				<div class="content">5</div>
			</li>
		</ul>
	</li>
</ul>

ul {
	font: 14px Verdana, Geneva, sans-serif;
	overflow: hidden;
}
	ul li.one {
		float: left;
	}
	ul li.two {
		overflow : hidden;
		float : none;
	}
	ul li.two li {
		width: 25%;
		text-align: right;
		float: left;

		/* Лекарство для IE6-7*/
		//width: 24.9%;
	}

	ul li .content {
		background: #E76D13;
		width: 98px;
		height: 98px;
		display: inline-block;
		text-align: left;
		border: 1px solid #000;

		/* эмуляция inline-block для IE6-7*/
		//display : inline;
		//zoom : 1;
	}

Если вы скажите, что в данной ситуации мы по сути имеем две разных колонки, то будете абсолютно правы. Ведь наша структура поделена на две части, левая из которых представляет из себя контейнер с одним блоком, а правая соответственно содержит в себе все остальные. Выглядит это примерно так:

Левая колонка прижата к левому краю и содержит в себе самый первый, одиночный блок. Это нужно для того, чтобы правая часть прижималась вплотную с правой стороны и растягивалась на всё оставшееся место. Растяжка правой части происходит благодаря overflow : hidden, который создаёт свой контекст форматирования, т.е. по сути свой собственный, независимый контейнер. Для всех дочерних элементов этого контейнера его ширина составляет 100% и поэтому блоки внутри него мы растягиваем в соответствии с этим правилом. Четыре блока имеют ширину 25%, что в сумме даёт 100. На изображении можно увидеть, как расположены эти блоки. Видно, что строчно-блочные элементы с контентом, внутри них, выровнены по правому краю с помощью text-align : right, благодаря чему самый правый блок прижат к своей боковой стенке, так же как и левый.

Благодаря таким "жертвам" с двумя колонками, мы получили отличный результат, и как видно из первых рисунков, при разных разрешениях, расстояние отступов между блоками остаётся абсолютно одинаковым. Это происходит за счёт равнозначных блоков в правой части. Ширина каждого из них составляет 25%, а элемента внутри них – 100px. Что и даёт равные отступы слева от каждого "кирпичика" в отдельности.
На данный момент можно смело заявить, что при фиксированной ширине блоков у нас получилось именно то, что мы хотели.

Но всё же интересно узнать, что будет, если мы поменяем ширину сначала у первого, а потом и у любого блока из правой части. Давайте для начала поставим левому… ну допустим 150px.

ul li.one .content { width: 150px;}

Всё здорово! Пока работает всё та же идея с правым, самостоятельным контейнером. А теперь перенесём нашу ширину на первый блок в правой части.

Эх, а вот этот эксперимент потерпел неудачу. Правый отступ у самого левого блока оказался меньше, чем все остальные. Всё легко объясняется тем, что контент первого элемента в правой части, стал больше на 50px, а так как он выровнен по правой стороне, то ширина визуально прибавилась к его левой части и соответственно стала отличаться от ширины соседних блоков. Ну и естественно поменялся отступ, который стал меньше ровно на 50px.

Из всего этого можно сделать вывод, что данный метод явно лучше, чем его предшественник и то, что он имеет право на жизнь. Единственный его недостаток связан с тем, что мы не может задать разную ширину блокам, и должны придерживаться одинаковой. Так что, если у вас есть список, в котором все пункты имеют равную ширину, то вы вполне можете применять этот подход. Конечно же, нужно понимать, что без двухколоночной структуры тут не обойтись + нужна обязательная минимальная ширина у контейнера (min-width), иначе при маленькой ширине экрана блоки будут наезжать друг на друга.
* Кстати, у себя в примере, в правом контейнере я использовал четыре блока по 25%, и их общая сумма составила 100%. Поэтому нужно помнить, что если блоков будет, ну скажем 6, то ширина каждого из них, будет равна 16.666, что говорит о дробных процентах, которые, например, не поддерживаются в браузере Opera.
Соответственно результат в этом случае будет немного не тем, чем вам хотелось бы.

Вариант с двумя колонками

Вариант 3 – text-align: justify

Стоит отметить, что до этого момента, ни в одном примере, мы ни разу не воспользовались text-align: justify, даже не смотря на то, что именно на основе его алгоритма и строятся все наши решения. Я предлагаю нарушить эту традицию и, наконец, пустить уже в дело этого зверя.

В первой части статьи мы выяснили, что text-align: justify влияет на все строки, кроме последней, а значит нужно построить наш список с учётом этого поведения, добавив в конец меню дополнительный, вспомогательный элемент.

<ul>
	<li>1</li>
	<li>2</li>
	<li>3</li>
	<li>4</li>
	<li>5</li>
	<li class="helper"></li>
</ul>

ul {
	font: 14px Verdana, Geneva, sans-serif;
	text-align: justify;
}

	ul li  {
		background: #E76D13;
		width: 98px;
		height: 98px;
		display: inline-block;
		text-align: left;
		border: 1px solid #000;

		/* эмуляция inline-block для IE6-7*/
		//display : inline;
		//zoom : 1;
	}
	ul li.helper {
		width: 100%;
		height: 0;
		visibility: hidden;
	}

Из кода ясно, что мы создали список с пятью основными и одним элементом – помощником. text-align: justify на главном элементе-родителе (ul), заставляет своих потомков подчиняться своему алгоритму. Ведь, как известно, это свойство работает с текстом, а так как наши строчно-блочные (display: inline-block) пункты, по сути и являются неразрывными словами в строке, то это поведение вполне закономерно. Кстати, стоит учесть, что text-align: justify наследуемое свойство, поэтому text-align: left на ближайших потомках – необходимая мера. Этим самым мы как бы возвращаем выравнивание содержимого наших блоков в прежнее состояние.
В первой части статьи я упоминал, что наш алгоритм не распространяется на последнюю строку, а работает со всеми строками кроме неё. Поэтому я добавил в конец ещё один элемент, пустышку, и растянул его на 100% по ширине, тем самым заставив его растянуться на самую последнюю строчку в списке. С помощью нехитрых приёмов (height: 0, visibility: hidden) я, можно сказать, почти что спрятал его. Почему я сказа "Почти что"? Об этом чуть позже, для начала давайте взглянем на то, что у нас вышло.

Первое, что бросается в глаза, это то, что при разной ширине наш алгоритм работает так, как и должен. При пунктах с одинаковой шириной расстояние между ними сохраняется одинаковым, что не может не радовать. Но всё таки интересно узнать, будет ли всё так же хорошо при разной ширине блоков. Назначим паре пунктам классы и проверим это.

<ul>
	<li class="first">1</li>
	<li>2</li>
	<li class="third">3</li>
	<li>4</li>
	<li>5</li>
	<li class="helper"></li>
</ul>

Добавим для них свои правила.

.first { width: 150px;}
.third { width: 200px;}

Проверяем.

Я специально увеличил ширину экрана, чтобы при маленькой ширине блоки не перескакивали на другую строку, как обычные слова в тексте. Но, если посмотреть на результаты алгоритма, то он работает! Пробелы между элементами остаются равнозначными, даже не смотря на то, что у двоих из них, мы увеличили ширину.
Т.е. можно с лёгкостью заявлять, что этот метод, с дополнительным элементом в конце – даёт отличный результат и, если ограничить экран по ширине, то его применение на практике нас не разочарует.
Так, ну а теперь, пожалуй, настало время подлить ложку дёгтя.
Во-первых, как вы могли заметить, во всех примерах я перечислял все браузеры, кроме IE6-7.
Во-вторых, опять же, как вы, наверное могли видеть на рисунках, внизу нашей строки, где дополнительный элемент, есть большие, непонятные отступы.
Давайте разбираться по порядку.

Первая проблема – это проблема IE6-7. Не приводя скриншоты, скажу сразу, что наш метод там не работает. Пункты в этих браузерах прижаты друг к другу вплотную и не растягиваются в строке. Дело в том, что парсер IE6-7 полностью игнорирует закрывающие теги у элементов <li>. А нет тегов – значит нет пробелов между ними, и, следовательно text-align: justify пропускает нашу строку, состоящую по сути из одних "строчно-блочных" слов, прижатых друг к другу.

За решением данной проблемы мы отправляемся на самую высокую гору… на MSDN. Мда… найти что либо на этом сайте, представляет большую трудность. Но, всё же повозившись, некоторое время, решение было найдено! text-justify: newspaper – свойство для увеличения или уменьшения интервалов между буквами и между словами. MSDN заявляет, что эта вещь "Самая навороченная форма выравнивания для латинского алфавита", а вот в этой статье ещё есть и дополнение, что для арабских текстов это свойство вытягивает и сами буквы.
Отлично, нам как раз нужно что нибудь на подобии. Давайте-ка проверим их слова на деле.

ul {
	font: 14px Verdana, Geneva, sans-serif;
	text-align: justify;

	/* Лекарство для IE6-7*/
	text-justify: newspaper;
}

	ul li  {
		background: #E76D13;
		width: 98px;
		height: 98px;
		display: inline-block;
		text-align: left;
		border: 1px solid #000;

		/* эмуляция inline-block для IE6-7*/
		//display : inline;
		//zoom : 1;
	}
	ul li.helper {
		width: 100%;
		height: 0;
		visibility: hidden;
	}
	.first { width: 150px;}
	.third { width: 200px;}

А вот и результат.

Победа! IE6-7 были побеждены их же оружием. Здорово. Теперь во всех браузерах, начиная с IE6, наш способ работает идеально. Выходит, что MSDN не подвели и их слова подтвердились на деле. Так что text-align: justify выручил нас, поэтому берём его на заметку и переходим к решению второй проблемы.

Вторая проблема связана с непонятным отступом между низом списка и нашей строкой с элементами. В чём же дело? А дело в том, что всё вполне закономерно и этими странными отступами являются ни кто иные, как межстрочный интервал (line-height) и размер шрифта (font-size), которые априори присутствуют у строк и букв в тексте. Наши элементы – блочные только внутри, а строчные снаружи, поэтому они и попадают под эти правила.
Как быть? А легко! Мы можем повесить на контейнер обнуление этих стилей, а уже у потомков восстановить их в прежнее состояние. Пробуем.

ul {
	font: 14px Verdana, Geneva, sans-serif;
	text-align: justify;

	/* Обнуляем для родителя*/
	line-height: 0;
	font-size: 1px; /* 1px для Opera */

	/* Лекарство для IE6-7*/
	text-justify: newspaper;
}

	ul li  {
		background: #E76D13;
		width: 98px;
		height: 98px;
		display: inline-block;
		text-align: left;
		border: 1px solid #000;

		/* Востанавливаем у потомков, кроме последнего*/
		line-height: normal;
		font-size: 14px;

		/* Без него в Opera будет отступ под элементами */
		vertical-align: top;

		/* эмуляция inline-block для IE6-7*/
		//display : inline;
		//zoom : 1;
	}
	ul li.helper {
		width: 100%;
		height: 0px;
		visibility: hidden;
		overflow: hidden;
	}
	.first { width: 150px;}
	.third { width: 200px;}

Результат.

До обнуления

После обнуления

Отлично! Всё получилось. Обнуление стилей у главного контейнера помогло нам. Единственное, что теперь стоит помнить, это то, что в связи с обнулением размера шрифта мы не сможем задать нашим пунктам шрифт в таких единицах длины, как em, а так же % для <body> не принесут желаемого результата. Но, а целом, наш метод работает идеально, так что можно подводить итоги и идти дальше, ведь нам же мало одного решения, нам же нужно больше и лучше, не правда ли?

Подводя промежуточные итоги, скажу, что данный подход пока что лидер среди присутствующих до сей поры решений, и что, я лично, не вижу в нём ни одного изъяна, правда, кроме… Кроме дополнительного элемента в конце строки, плюс, как мне кажется, неактуальные проблемы с % и em. Но, эти натянутые минусы, никак не могут быть причиной отказа от представленного варианта. Так что смотрим результат и идём дальше.
Вариант дополнительным элементом

Вариант 4 – Избавление от дополнительного элемента

В предыдущем варианте для нашей цели мы использовали дополнительный элемент, ставя его в конец списка. С одной стороны, конечно же, этот маневр принес свои плоды, но с другой… но с другой стороны создал некие неудобства. Например, при динамическом добавлении пунктов, вспомогательный блок будет только мешать, да и потом этот "хвост" портит нашу структуру, засоряя её. В этом варианте, я предлагаю избавиться от него, не испортив при этом решение.
В CSS2.1 уже давно есть такие вещи, как псевдоэлементы. Это такие абстрактные сущности, которые могут быть сгенерированы каким нибудь элементом и вставлены в его начало или конец. Почему бы не заменить таким псевдоэлементом наш лишний вспомогательный блок? Давайте попробуем…

<ul>
	<li>1</li>
	<li>2</li>
	<li>3</li>
	<li>4</li>
	<li>5</li>
</ul>

ul {
	font: 14px Verdana, Geneva, sans-serif;
	text-align: justify;

	/* Обнуляем для родителя*/
	line-height: 0;
	font-size: 1px; /* 1px для Opera */

	/* Лекарство для IE6-7*/
	text-justify: newspaper;
	zoom:1;
}
	ul:after {
			width: 100%;
			height: 0;
			visibility: hidden;
			overflow: hidden;
			content: '';
			display: inline-block;

	}
		ul li  {
			background: #E76D13;
			width: 98px;
			height: 98px;
			display: inline-block;
			text-align: left;
			border: 1px solid #000;

			/* Востанавливаем у потомков, кроме последнего*/
			line-height: normal;
			font-size: 14px;

			/* Без него в Opera будет отступ под элементами */
			vertical-align: top;

			/* эмуляция inline-block для IE6-7*/
			//display : inline;
			//zoom : 1;
		}

В данной ситуации мы воспользовались псевдоэлементом :after, который сгенерировали в конце нашего списка. Выставив ему те же значения, что и бывшему, вспомогательному блоку, мы, по сути сделали тоже самое, но не залезая в разметку. Т.е. создали такой же, пустой, но полезный элемент. И вот результаты.

Здорово! Трюк с псевдоэлементом сработал. Теперь наша разметка чистая, аккуратная и без лишнего "мусора". Нам удалось избавиться от дополнительного элемента, полностью заменив его сгенерированным.
Но, как обычно, не обошлось без IE6-7 приключений. К сожалению, в браузерах IE6-7 нет поддержки :after и :before. А если нет поддержки, следовательно и нет никаких вспомогательных блоков, а значит и растягивать попросту нечего. Поэтому картина в этих браузерах такова.

Как видно из скриншота, IE6-7 полностью игнорирует пробелы между блоков, прижимая их вплотную друг к другу. Даже не смотря на то, что мы уже задействовали тяжёлую артиллерию в виде text-justify: newspaper. Почему же это происходит? Давайте выясним.
Оказывается всё дело в том, что text-justify: newspaper лишь даёт возможность растягивать наши буквы (inline-block), но не команду. Проще говоря, он рассказывает строке, как бы он хотел, чтобы она была растянута, а text-align: justify является растягивающей силой. Т.е. text-align: justify отвечает за растяжение строки, а text-justify: newspaper лишь уточняет, как именно это растяжение будет происходить.
Да, но тогда возникает вопрос: "Если есть и возможность и сила, которая может её исполнить, то почему же тогда ничего не происходит?". Ответ кроется в самом свойстве text-align: justify. Если вы помните, в обсуждении его алгоритма я упомянул о том, что он не распространяется на последнюю строку в тексте. А так как мы убрали вспомогательный элемент в конце списка, то соответственно наша строка (пускай даже она одна) с блоками – стала уже последней, и следовательно алгоритм отказался с ней работать.

Как же быть? Есть ли выход?
К счастью мир не без добрых людей, и один такой добрый человек направил меня на верный путь. Оказывается решение было у меня под носом. text-align-last – свойство, которое включает алгоритм text-align: justify в самой последней строке текста, если к ней применён этот самый text-align: justify. Проще говоря, когда мы применяем к тексту обычный text-align: justify, то, видя это, text-align-last указывает первому на то, что он поступает плохо и что ему придётся теперь работать и в последней строчке тоже.
Самое интересное, что это свойство считается ориентированным именно на Internet Explorer, в котором он нам как раз и нужен). В общем пора переходить к делу.

ul {
	font: 14px Verdana, Geneva, sans-serif;
	text-align: justify;

	/* Обнуляем для родителя*/
	line-height: 0;
	font-size: 1px; /* 1px для Opera */

	/* Лекарство для IE6-7*/
	text-justify: newspaper;
	zoom:1;

	/* Включаем в работу последнюю строку*/
	text-align-last: justify;
}
	ul:after {
			width: 100%;
			height: 0px;
			visibility: hidden;
			overflow: hidden;
			content: '';
			display: inline-block;

	}
		ul li  {
			background: #E76D13;
			width: 98px;
			height: 98px;
			display: inline-block;
			text-align: left;
			border: 1px solid #000;

			/* Востанавливаем у потомков, кроме последнего*/
			line-height: normal;
			font-size: 14px;

			/* Без него в Opera будет отступ под элементами */
			vertical-align: top;

			/* эмуляция inline-block для IE6-7*/
			//display : inline;
			//zoom : 1;
		}

Да! У нас получилось. text-align-last: justify сделал то, что от него требовалось, и сделал это на 5 баллов. Алгоритм включился в работу, в нашей последней и единственной строке. Так что празднуем победу и подводим итоги этого способа.

Ну что ж, я доволен. Доволен тем, что нам удалось найти действительно достойное решение. Причём не просто найти, а разобраться во всём и довести его до абсолютной кроссбраузерности, затратив минимум кода и не засоряя разметки. На лицо одни плюсы, а что же с минусами? Как по мне, так их попросту – нет. По сравнению с предыдущим вариантом, в этом мы только улучшили результаты. Разве что…

Единственное, что теперь стоит помнить, это то, что в связи с обнулением размера шрифта мы не сможем задать нашим пунктам шрифт в таких единицах длины, как em, а так же % для <body> не принесут желаемого результата.

Но, опять же, эти "минусы" с большой натяжкой можно назвать таковыми. Их неактуальность говорить о том, что про них можно практически забыть, если это не принципиально.
Так что в целом решение отличное, надёжное и действительно качественное.
Вариант с псевдо-элементом

Резюме

В этой статье мы рассматривали не только методы, которые могут помочь нам в равномерном выравнивании блоков по ширине, но и так же очень подробно разобрали механизмы работы всех свойств и деталей, участвующих в процессе. Всё это важно для понимания вещей, с которыми мы имеем дело. Поэтому я настоятельно рекомендую перечитать статью, и не один раз.
Я безумно рад, что нам удалось добиться своей цели и найти достойное и качественное решения.

Все варианты воедино

1. Вариант с разносторонним выравниванием (К сожалению неработающее решение. Надеюсь, что в комментариях кто нибудь натолкнёт на верный путь)
2. Вариант с двумя колонками (Работающее решение, но только с фиксированными по ширине блоками)
3. Вариант дополнительным элементом (Работающее решение)
4. Вариант с псевдо-элементом (Работающее решение)

Для тех, кто не особо понимает в чём суть, поясняем, что в модулях на данный момент существует как минимум три совершенно разных черновика CSS3 для будущих механизмов раскладки, со множеством спорных моментов в каждом, вдобавок конфликтующих между собой. В черновиках по этому поводу творится некая неразбериха, неопределённость, из-за которой может показаться, что разработчики сами пока ещё не знают, что хотят получить в итоге. И вот из двух таких модулей: раскладки сеткой (в котором структура макета описывается сеткой, отдаленно похожей на табличную, предложен Микрософтом) и раскладки по шаблону (синтаксис которого напоминает ASCII-арт, а автором является Берт Бос — один из двух создателей CSS вообще), возможно, получится единый модуль (хотя пока трудно сказать, на что такой "гибрид" будет похож). И есть шанс, что разработчики браузеров наконец придут к консенсусу и реализуют его.

В общем, неразбериха в лейаутных модулях, о которых так давно мечтали вебмастера, вот-вот пройдет свой максимум и начнет уменьшаться, постепенно выруливая на финишную прямую. По крайней мере, есть основания надеяться на это. Хотя нельзя и исключить, что Элика просто пошутила;)

Пожалуйста, ознакомьтесь с описанием уровня членского взноса для стартапов, чтобы узнать подробности и больше информации об условиях, дающих право на него. Пожалуйста, свяжитесь с membership@w3.org если у вас есть какие-либо вопросы.

Прежде чем приводить конкретные примеры, давайте посмотрим на уровень web’а сегодня и то, куда он движется. За последние годы дизайн сайтов обозначил новую тенденцию в развитии техники универсального дизайна (Responsive Website Design). И это к лучшему. По существу, универсальный дизайн обеспечивает переход от использования полюбившихся нам фиксированных по ширине страниц, к вёрстке плавающих форм с интеллектуальным перемещением их содержимого. Добавьте к этому продуманную стратегию содержимого и мобильный подход, и мы уже начинаем предлагать универсальный опыт адаптации под множество устройств и браузеров, удовлетворяя потребности конечного пользователя.

Когда мы смотрим на многочисленные устройства, предполагающие выход в интернет, приходит осознание того, что универсальный дизайн – это лучшее, что можно предложить современному пользователю интернета. Использование горизонтальной прокрутки, панорамирования и масштабирования окна браузера имеет место быть, как часть дополнительного интерфейса, но принуждение пользователей к выполнению данных действий для навигации по сайту, быстро становится утомительным занятием. Подгонка сайта под размеры окна просмотра основана не только в вёрстке, но и в разрешении. В этой статье я покажу, почему SVG прекрасно дополнит будущие интернет разработки.

ЗНАКОМЬТЕСЬ, SVG

В действительности, масштабируемая векторная графика, для представления в интернете, предлагает техники, зависящие от разрешения. SVG это формат векторной графики, который использует XML для определения основных свойств, таких как пути, формы, цвета и шрифты, а также применения более продвинутых функций, как например градиентов, фильтров, написания скриптов и анимации. Создав файл один раз его можно использовать в любом месте, в любом масштабе и при любой разрешающей способности.

Рассмотрим область применения: пользовательский интерфейс, иконки навигации, иллюстрации в векторном стиле, паттерны и повторяющийся фон. Для всего этого, масштабируемая графика является наилучшим решением с визуальной точки зрения, но ограничение разрешения картинок по-прежнему является нормой. В примере, приведённом ниже, мы покажем, как в целом расширить техники разработки и воспользоваться преимуществами SVG.

Рассмотрим спрайты CSS

Всем нам хорошо знакомы методы использования CSS спрайтов (если вам не знакомы данные техники, можете быстро глянуть статью Свена Леннартца. А также ознакомиться с доводами «за и против» Луиза Лазариса). Ниже, мы продемонстрируем с какой лёгкостью SVG способен заменять обыкновенные растровые изображения. Если данный пример не для вас, мы уверены, вы сможете представить целый ряд подобных ситуаций с аналогичным использованием SVG

Векторные иконки играют большую роль при разработке пользовательского интерфейса. Картинки весьма ясно отражают свою значимость, в то время как их текстовой эквивалент может быть вполне двусмысленным. При разработке пользовательского интерфейса, свободное пространство на вес золота и компактная иконка может быть весьма кстати.

Я попробовал на этом примере:

Я попробовал на этом примере:

Я буду первым, кто отметит, что этот комплект иконок не достоин дизайнерских наград, но его вполне достаточно для этой статьи. Давайте взглянем на HTML:

<div class="actions">
	<a class="a-share" href="#">Share</a>
	<a class="a-print" href="#">Print</a>
	<a class="a-tag" href="#">Tag</a>
	<a class="a-delete" href="#">Delete</a>
</div>

Я выдержал код в минимальном стиле, но на практике, вы захотите создать тоже самое при помощи маркированного списка. И, вполне вероятно, вы замените знаки решётки на URL адреса (даже если функциональность будет обеспечиваться при помощи JavaScript, иметь запасной вариант всегда приятно).
Посмотрим на CSS:

.actions {
   display: block;
   overflow: auto;
}

.actions a {
   background-image: url('sprite.png');
   background-repeat: no-repeat;
   background-color: #ccc;
   border-radius: 5px;
   display: block;
   float: left;
   color: #444;
   font-size: 16px;
   font-weight: bold;
   line-height: 20px;
   text-decoration: none;
   text-shadow: 0 -1px 2px #fff;
   padding: 10px 20px 10px 40px;
   margin-right: 5px;
}

.a-share  { background-position: 10px 0; }
.a-print  { background-position: 10px -40px; }
.a-tag    { background-position: 10px -80px; }
.a-delete { background-position: 10px -120px; }

Обратите внимание на фиксированные размеры в пикселях и фон .png, который, как вы можете видеть ниже, оформлен по всем правилам Photoshop:

Данная реализация CSS спрайтов является основой, но уже не годится по сегодняшним стандартам! И как мы можем это улучшить? Во-первых, давайте рассмотрим следующие вопросы:

1. Мы растрировали изображение на очень ранней стадии. Даже в полном размере, местами, имеется размытость.
2. Если мы приблизим, размытие усилится, т.к. процесс ререндеринга невозможен из-за отсутствия данного изображения в больших размерах.
3. У всего фиксированный размер, что не хорошо, как для универсального дизайна, так и для удобства, учитывая игнорирование стандартного размера шрифта самого браузера.

Как вы, наверное, уже догадались, мы покажем вам, как SVG справляется со всеми из перечисленных проблем. Но для начала рассмотрим каждую из проблем более детально, чтобы понять суть проблемы в целом.

1. РАСТЕРИЗАЦИЯ

Устройства, на подобии современных смартфонов, имеют очень большую плотность пикселей. Так, некоторые из них превышают 300 пикселей на дюйм (PPI), что практически на грани возможностей человеческого глаза различать столь мелкие детали. Пиксель не имеет эквивалента в реальном мире до тех пор, пока он не окажется на экране фиксированного размера (скажем, диагональю 3,5 дюйма) и фиксированного разрешения (скажем, 640 x 960 пикселей). При таком раскладе, текст, с размером шрифта в 16 пикселей, будет невероятно мелким для его прочтения. По этой причине, устройства просто не могут перевести единицу CSS пикселя в единицу пикселя самого устройства, вместо этого они удваиваются. Таким образом, шрифт, размером 16 пикселей, фактически преобразуется в шрифт, размером 32 пикселя, после своего отображения.

То же самое происходит и с картинками, однако, они уже растрированы, так что от удвоения пикселей нет абсолютно никакой пользы. В нашем примере, каждая иконка была растрирована в 25 x 25 пикселей (полный спрайт получился 30 x 160 пикселей), поэтому они не смогут воспользоваться преимуществом удвоения пикселей. Одно из решений заключается в использовании CSS запросов по определению соотношений пикселей. Эта возможность уже реализована в WebKit- и браузерах на движке Gecko.

Для улучшения нашего примера, мы может добавить в CSS следующее:

@media only screen and (-webkit-min-device-pixel-ratio: 2)  {
   .actions a {
      background-image: url('sprite@2x.png');
      background-size: 30px 160px;
   }
}

Альтернативное фоновое изображение, указанное в коде выше, сохранено в размере 60 x 320 пикселей (т.е. в два раза больше от первоначального размера). Свойство background-size сообщает CSS о том, что спрайт меньше. Отметим, что теперь у устройства есть дополнительные данные для подгрузки при отображении лучшего изображения (если есть такая возможность).

Это решение не плохое, но оно не решает проблемы, с которыми мы столкнулись в пунктах 2 и 3. Это также требует от нас создания увеличенных копий изображений, что доставляет немало хлопот и увеличивает нагрузку на пропускную способность. Для невекторных изображений, таких как фотографии в формате .jpg, мы не можем сделать чего-то большего.

2. УВЕЛИЧЕНИЕ

В своём первоначальном размере, наши растрированные иконки выглядели приемлемо, по крайней мере на экранах с низкой плотностью пикселей. Однако, при увеличении веб-страницы, эти мелкие элементы пользовательского интерфейсы молниеносно ухудшатся.

Первое, что делает пользователь испытывающий дискомфорт при просмотре мелкой страницы сайта – это увеличение. Подобные сайты весьма распространены. В действительности, нет «идеального» размера, в силу ухудшения зрения, неизбежно приходящего к нам с возрастом. Во-вторых, стремительное развитие устройств с сенсорным экраном сделало нормой необходимость постоянного увеличения фиксированных страниц (это большая часть интернет проектов на сегодня), созданных для больших экранов.

Наша задача – разрабатывать сайты, сводя к минимуму необходимость пользователей осуществлять дополнительные телодвижения для комфортного просмотра интересующих их страниц. Вот для чего необходим универсальный дизайн. Просто нет возможности обеспечить растрированные изображения для каждого уровня приближения (в теории – это бесконечность). Решением является масштабируемая графика. Мы применим её в нашем примере, но для начала несколько слов о фиксированных размерах.

3. ФИКСИРОВАННЫЕ РАЗМЕРЫ

Представление элементов страницы в фиксированных размерах не только провоцирует множество пользователей к увеличению, но и отключает одну из полезных возможностей браузера. Пользователь может задать предпочтительный для него размер шрифта (стандартный используемый размер 16 пикселей). Задавая все размеры в пикселях, мы перекрываем эти настройки. Размер элементов, который зависит от стандартных значений, куда более предпочтителен. Если текст больше, то и всё остальное подстраивается под него. По существу, это имитирует эффект увеличения, только происходит это без каких-либо манипуляций при каждом посещении. Этан Маркотт написал достойную статью на тему относительных размеров шрифта.

Давайте повторно реализуем пример с нашим спрайтом и применим решения для трёх существующих проблем.

МАСШТАБИРУЕМАЯ РЕАЛИЗАЦИЯ

И снова HTML код. Здесь мы ничего изменять не будем.

<div class="actions">
	<a class="a-share" href="#">Share</a>
	<a class="a-print" href="#">Print</a>
	<a class="a-tag" href="#">Tag</a>
	<a class="a-delete" href="#">Delete</a>
</div>

Обновим CSS и сотворим в нём немного магии:

body { font-size: 100%; }

.actions {
   display: block;
   overflow: auto;
}

.actions a {
   font-size: 1em;
   line-height: 1.25em;
   padding: 0.625em 1.25em 0.625em 2.5em;
   margin-right: 0.3125em;
   border-radius: 0.3125em;
   background-image: url('sprite.svg');
   -webkit-background-size: 1.875em 10em;
   -o-background-size: 1.875em 10em;
   -moz-background-size: 1.875em 10em;
   background-size: 1.875em 10em;
   /* styles carried over from the original implementation */
   background-repeat: no-repeat;
   background-color: #ccc;
   color: #444;
   display: block;
   float: left;
   text-decoration: none;
   text-shadow: 0 -1px 2px #fff;
}

.actions-em .a-share { background-position: 0.625em 0; }
.actions-em .a-print { background-position: 0.625em -2.5em;  }
.actions-em .a-tag { background-position: 0.625em -5.0em;  }
.actions-em .a-delete { background-position: 0.625em -7.5em;  }

В эту версию мы внесли следующие изменения:

• - background-image теперь использует .svg файл
• - Все размеры основаны на стандартных 16-ти пикселях, или 1 em. Если стандарт для пользователя больше или меньше, всё будет изменено взаимосвязано. (Если вы помножите каждый размер в em на 16, вы получите число пикселей, которое использовалось в первоначальном примере с фиксированными размерами).
• - Обратите внимание на background-size. Выставляя размер в em, мы говорим браузеру масштабировать спрайт в зависимости от всего другого. Вы заметили, что 1.875 * 10 em помноженное на 16 равно 30 x 160 – размер в пикселях, в котором мы представлен наш спрайт.
• - background-position каждой иконки спрайта также заданы в относительных единицах.

Теперь, используя SVG и относительные размеры, мы решили три большие проблемы, описанные выше. Масштабируемая графика может быть растрирована в зависимости от потребностей для отличного отображения на любом разрешении и при любом увеличении. А используя относительные размеры, мы можем продолжить развитие универсального дизайна, сводя к минимуму потребность пользователей в увеличении. Мы также учитываем размеры шрифта браузера и адаптируем наш дизайн соответствующим образом.

На самом деле сначала я создал SVG спрайт, а лишь потом при его помощи и PNG версию. (Я импортировал SVG в Photoshop, прежде чем экспортировал его в качестве PNG – экспорт PNG через Illustrator имел плохую растеризацию). Ниже приведён заголовок моего SVG файла, размер тот же (30 x 160 пикселей).

<svg enable-background="new 0 0 30 160" height="160px" id="Layer_1" space="preserve" version="1.1" viewbox="0 0 30 160" width="30px" x="0px" xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" y="0px">
</svg>

В открытом SVG теге вы можете видеть, что атрибуты ширины и высоты заданы в пикселях (width=”30px” height=”160px”, сгенерировано Illustrator’ом). Это заставляет выполнять рендер в Firefox’е раньше, чем график масштабируется в соответствии с em размерами background-size. Webkit-браузеры, вроде, масштабируют SVG превосходно. Я заметил, что в SVG файле можно проставить единицы этих двух атрибутов в em для решения проблемы с Firefox.

<svg enable-background="new 0 0 30 160" height="160em" id="Layer_1" space="preserve" version="1.1" viewbox="0 0 30 160" width="30em" x="0px" xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" y="0px">
</svg>

Я не знаю, какой из браузеров выполняет масштабирование правильнее, нам лишь необходимо позаботиться о кроссбраузерной совместимости. В Mozilla MDN есть замечательная и углублённая статья «Масштабирование фоновых изображений SVG», которая рассматривает множество практических примеров. Более подробно, читайте статью Алекса Уокера «Прощание с градиентами CSS3».

Вот детальный скриншот, демонстрирующий SVG спрайт:

Спрайт масштабируется превосходно (чего, к сожалению, нельзя сказать о моём текстовом shadow эффекте).

Лучше один раз увидеть, чем сто раз услышать. Я подготовил live demo, где продемонстрированы масштабируемые спрайты в действии, с обозначением техники сверху каждого примера.

Поддержа со стороны Браузеров

В начале статьи я заметил, что SVG недостаточно распространён. Хочется верить, что причина была в плохой поддержке со стороны браузеров. Но сейчас всё по-другому! Расцвет SVG происходил последние несколько лет, в связи с пониманием эффективности его использования.

По данным сайта Когда я смогу пользоваться?, поддержка SVG выглядит следующим образом (я объединил поддержку для свойств background-image (CSS) и img source (HTML) – как наиболее важных):

• Internet Explorer 9+
• Firefox 4+
• Chrome 4+
• Safari 4+
• Opera 9.5+

Поддержка мобильных браузеров также весьма развита по всем направлениям. Если есть рабочий вариант для старых браузеров, тогда SVG будет очень эффективным решением.

В соответствии с некоторыми дополнениями к веб-стандартам, мы спокойно может реализовывать их, зная, что старые браузеры просто проигнорируют их и, что они даже не требуются. Мы называем это «progressive enchancement»: чем лучше браузер, тем лучше реализация. SVG – это немного другое, ведь он в большинстве случаев просто заменяет изображения в элементах CSS и HTML. Форматы изображений, будь-то SVG, PNG, JPG или GIF, они либо поддерживаются, либо нет. Здесь мы не можем просто следовать практике прогрессивного улучшения, т.к. изображения, которые невозможно отобразить, неприемлемы для реализации

ОПРЕДЕЛЯЕМ БРАУЗЕР ПОЛЬЗОВАТЕЛЯ ИЛИ ПОДДЕРЖКУ САМОЙ ВОЗМОЖНОСТИ

Мы можем сделать предположение и сказать, что беспокоиться следует только о пользователях Internet Explorer с 6-ой по 8-ую версию. В этом случае техника условных комментариев для IE позволяет применить в CSS второй background-image в одном из поддерживающихся форматах, таких как PNG, вместо используемого по умолчанию SVG.

Определение браузера пользователя всегда было опасной игрой. В то время как Internet Explorer является основным отступником, мы не можем утверждать, что он единственный.

Безопасный и настоятельно рекомендуемый способ заключается в определении поддержки SVG и использовании данной возможности, только в случае её поддержки. Я предлагаю использовать Modernizr, когда вам необходимо определить ряд функций. В случае обнаружения, Modernizr применяет класс SVG к вашему корневому html элементу (к которому можно добавить SVG в качестве background-image). Но всё немного сложнее, если вы используете SVG в качестве источника для изображения в HTML. Придётся дописать JavaScript, чтобы найти и заменить все источники разом, на случай, если поддержка была подтверждена.

Проблема этого метода в том, что браузер будет загружать запасные изображения до того, как поддержка SVG будет установлена – единственным исключением являются условные комментарии для IE. Пользователи могут также заметить моргание при перестроении содержимого, когда источник будет изменён. Это не будет долго продолжаться, но, по меньшей мере, на сегодня, эти проблемы могут быть достаточными, чтобы остановить вас от использования SVG.

ВЕС ФАЙЛА

В нашем примере вес SVG файла составил 2445 байт. Версия PNG весит всего 1064 байт (версия PNG 60 x 320 для удвоенных пикселей весит 1932 байта). На первый взгляд, векторное изображение проигрывает во всём, но при больших размерах, растровые изображения значительно набирают в весе.

Ещё SVG файлы удобны для чтения, благодаря использованию XML формата. Как правило, они содержат весьма ограниченный набор символов, что способствует их существенному GZip – сжатию при передаче по HTTP. Фактически, это значит что скачиваемый размер файла в разы меньше исходного, до 30% и, возможно, больше. Растровые изображения, такие как PNG и JPG уже изначально сжаты по-максимуму.

ПРОИЗВОДИТЕЛЬНОСТЬ

Интересным вопросом остаётся производительность отображения SVG, особенно на мобильных устройствах, чьи аппаратные возможности ограничены. Растровые изображения могут отображаться попиксельно после декомпрессии и декодирования. Векторная графика нуждается в растрировании к определённому разрешению каждый раз при её просмотре.

В качестве платформы для анимированной векторной графики SVG при последовательном испытании оказался медленнее Canvas, но нас интересует основное отображение, а не тысячи манипуляций в секунду, но если и это возможно, тогда простое отображение не должно быть проблемой. Более напряжёнными остаются такие возможности SVG, как маски и фильтр – эффекты. Они не нужны для большинства практических целей (таких как наш пример), но, при необходимости их использования, наилучшим путём оценки производительности остаётся тестирование. Множество интернет разработок поддерживается только в теории, а на практике результаты далеки от совершенства.

Альтернативные Методы

Надеюсь, вы согласитесь с тем, что SVG является крайне полезным, но не идеальным решением проблем, связанных с разрешением. В конечном счёте, задумка в том, чтобы избежать масштабирования растровых изображений. Ниже ещё ряд идей, над которыми можно поразмыслить.

CSS3

Вы уже возможно начали комбинировать такие свойства CSS3, как linear-gradient, text-shadow и box-shadow с целью создания совокупных стилей. Веб разработчик Лиа Веру курирует CSS3 галерею образцов, которые демонстрируют впечатляющий потенциал одних только градиентов.

В своей статье «Мобильный Интернет в Высоком Разрешении», Бред Бирдсалл демонстрирует технику сохранения pixel-perfect для высокого разрешения, при помощи использования свойства pixel-ratio.

Кроме того, есть чистые CSS «иконки», которые Фарук Атеш справедливо считает «безумием» – естественно это так, если вы создаёте логотип при помощи CSS! Вы можете возразить, сославшись на небольшое количество полезных техник, таких как CSS треугольники, описанные Крисом Койером.

ВЕБ ШРИФТЫ

Шрифты с графическими маркерами (dingbat) и символы Unicode – вот две интересные альтернативы векторных иконок, как с семантической точки зрения, так и со стороны их доступности. Джон Хикс описал, пожалуй, лучшее об их использовании. SVG выглядит подходящим решением для иконок и имеет высокий потенциал касательно высокого разрешения. Мы, в ближайшем будущем, будем уделять этому повышенное внимание.

ЗАГЛЯДЫВАЯ В БУДУЩЕЕ

Как вы заметили, использование SVG весьма доступно, а поддержка со стороны браузеров и производительность в будущем будут только улучшаться. Из этой статьи важно понять необходимость создания веб-сайтов, которые будут настолько независимы от разрешения, насколько это возможно.

Принимая во внимание «one web» философию и широкий спектр устройств можно сделать вывод об отсутствии единого случая для всех пользователей. Чем больше мы можем сделать для познания новых устройств – тем лучше. Универсальный дизайн сайта способен удовлетворить большинство потребностей и дать ряд преимуществ. Использование векторной графики может быть не столь очевидным плюсом, но даже это незначительное улучшение даёт большую разницу.

Уже сегодня множество пользователей могут насладиться масштабируемой графикой… или, возможно, так неправильно думать. Большинство пользователей не скажет: «Вау! Слава вектору». Боюсь, они даже не примут это во внимание (и не оценят затраченных на это усилий). И это хорошо. Каждый раз, когда мы улучшаем что-то для пользователей, мы не нуждаемся в посвящении этому песен с танцами. Оправдывайте ожидания пользователей в визуальной эстетике и со временем они сами научаться замечать «низкопробные» сайты. Если этого не сделаете вы, это сделают другие.

Оригинал

Минздрав Интернета предупреждает: каждый раз, когда вы называете проприетарную фичу словом «CSS3», в мире умирает котенок. Любая -webkit-фича, не входящая в спецификации (хотя бы в редакторский черновик) — не CSS3 ни разу. Да, их часто выдают за него, но они вообще даже не часть CSS. Различать эти вещи — не пустое педантство. Это важно, потому что эта путаница мотивирует некоторых производителей браузеров (с таким, кхе-кхе, яблочком на лого…) идти в обход процесса стандартизации, реализовывать в WebKit свою отсебятину, а потом подавать ее вебмастерам как невиданную вкусность. Новые блестящие игрушки ослепляют нас, и мы сами начинаем превозносить их, усиливая эхо рекламного шума.

Гоняясь за новыми побрякушками, мы часто забываем, сколько людей боролись всё прошлое десятилетие за то, чтобы мы могли писать код без ветвлений и хаков и рассчитывать, что он заработает везде. Если вы «в теме» дольше пары-тройки лет, вы наверняка помните, что так было не всегда. Причина удобства нынешней веб-разработки — веб-стандарты, итог тяжко давшейся нам победы в браузерных войнах.

Удивительно, но веб-стандарты существовали и в эпоху браузерных войн. W3C основан в 1994 году. Однако вебмастерам было не до них, всем хотелось «потрогать» проприетарные расширения. В итоге браузеры тоже особо не заморачивались веб-стандартами. Ничего не напоминает? Сегодняшние проприетарные фичи ничуть не лучше ActiveX и IE-шных фильтров. Разница лишь в лучшем пиаре, и то потому, что мы не еще столкнулись с последствиями. Хотите верьте, хотите нет, но тогдашние фичи тоже принимались с восторгом в те дни.

Да, иногда у браузеров получается что-то стоящее, что со временем становится стандартом (XMLHttpRequest, Drag and Drop API, contentEditable, веб-шрифты — так, навскидку). Но ничто не препятствует им вводить новинки, соблюдая стандартную процедуру. Ничто не мешает им, придумав что-то клёвое, предложить это соответствующей рабочей группе W3C, заодно улучшив его благодаря коллективной обратной связи, прежде чем пускать в реализацию. Поступил бы так Microsoft с Drag & Drop API — не был бы он таким геморроем в использовании.

Проприетарные фичи, не прошедшие процедуры стандартизации, обычно страдают конструктивными дефектами, даже когда идея в целом хорошая. Например, CSS-градиенты — блестящая задумка, но -webkit-gradient() был многобуквенным ужасом, так и подбивающим ошибиться в нем. Веб-шрифты — великолепная идея, но вот обязательность наличия .eot-файла — нет. Процедура стандартизации не только способствует переносимости, она еще и помогает лучше спроектировать каждую фичу, благодаря большему разнообразию мнений.

Так что же это за позорные фичи? По части CSS наиболее популярны:

• -webkit-box-reflect
• -webkit-text-stroke
• -webkit-mask
• -webkit-background-clip: text;
• -webkit-text-size-adjust
• -webkit-tap-highlight-color
• -webkit-text-fill-color

Не каждая фича с префиксом — проприетарщина. Некоторые из них — лишь экспериментальные реализации фич, входящих в черновики спецификаций. Что подводит нас к следующему вопросу.

«Как узнать, проприетарна ли та или иная фича?»

Способ, который помогает мне — поискать в Гугле название фичи (в кавычках), добавив к поисковому запросу site:w3.org, чтобы искать только в пределах домена w3.org. Два примера:

• “box-shadow” site:w3.org
• “box-reflect” site:w3.org

Как видите, один из первых результатов для первой фичи — спецификация W3C. Результаты для второй — одни лишь обсуждения в списках рассылки, что говорит о том, что спецификации для нее пока нет.

«Чем я могу помочь?»

Простейшее «правило буравчика» — избегать проприетарных фич вообще. Не пользуйтесь ими, не пропагандируйте их и — главное — не полагайтесь исключительно на них. Хотя я понимаю, что порой это легче сказать, чем сделать. Если вы не можете совсем выкинуть проприетарщину из своей жизни, вот несколько советов, которым, я уверена, вы последовать сможете:

• Убедитесь, что используете эти фичи в соответствии с принципом прогрессивного улучшения, что конструкция может прекрасно работать и без них.
• Не рекламируйте их, или, если вы вынуждены это делать, не забывайте объяснять, что эти фичи — проприетарные, и что это значит.
• Если вам приходится использовать их в своем коде, добавьте комментарий об этом. Хватит чего-нибудь вроде /* Warning: Нестандартно! */. Многие начинающие фронтенд-кодеры учатся на примерах исходников реальных сайтов. Даже если вы не читаете лекций и не пишете туториалов, вы можете косвенно учить людей каждой строчкой своего кода.
• Отзовите статьи, лекции, примеры и т.п., пропагандирующие эти фичи без каких-либо предупреждений, или где используется только один префикс одного производителя (что тоже весьма серьезная проблема). А еще лучше — сами исправьте их, если возможно.

«Как я могу помочь стандартизации фичи?»

Если вы испытываете потребность в проприетарной фиче слишком часто, примите участие в стандартизации чего-то подобного. Я рекомендую следующую последовательность действий, большая часть которых подойдет для любых новых предложений вообще:

Шаг 1. Изучите стандартные альтернативы

Прежде всего, изучите стандартные альтернативы. Они могут хуже (или вообще никак) поддерживаться браузерами, но вы хотя бы будете знать, за что бороться. Вы даже можете добавить их как «фоллбэк», не загораживая дорогу другим производителям, если вдруг они эту фичу уже реализуют.

Вы можете даже помочь ускорить реализацию, сообщив о соотв. баге в браузерах, которые ее не поддерживают. Не забудьте сначала поискать среди существующих багов. Если баг уже числится в списке, вы всё еще можете подчеркнуть его важность для вас, написав комментарий (будьте вежливы!). Браузеры учитывают запросы вебмастеров, устанавливая приоритеты для фич — что из них реализовать раньше. Покажите им, что та или иная фича для вас значима.

Шаг 2. Проверьте, не была ли эта фича уже кем-то предложена

W3C обсуждает, какие фичи добавлять и как «отполировать» их до совершенства, в своих списках рассылки. У каждой рабочей группы (WG, сокр. от «Working Group») есть свой, иногда даже несколько, чтобы рабочие группы могли сообща разрабатывать фичи, затрагивающие несколько технологий сразу. Например, CSS WG пользуется списком www-style, а SVG WG — списком www-svg. Однако для фич, затрагивающих как CSS, так и SVG, есть список public-fx.

Прежде чем писать в любую из этих рассылок, пожалуйста, поищите прошлые обсуждения вопроса. Каждая минута, которую тратит член рабочей группы, отвечая на дубликаты предложений — это еще одна зря потерянная минута для разработки веб-стандартов. Для поиска по архивам вы снова можете воспользоваться мощью Гугла. Наберите ключевые слова как обычно и просто добавьте в конец запроса site:lists.w3.org.

Если вы видите, что фичу уже предлагали, но обсуждение застопорилось без какого-либо результата, вы можете ответить (один раз!), чтобы снова поднять его. Пожалуйста, постарайтесь не выказывать в переписке своего нетерпения или раздражения. Читайте обсуждение дальше, обдумывая, что бы такого добавить, чтобы оно не оказалось уже расписано другими.

Шаг 3. Предложите фичу

Постарайтесь приложить как можно больше относящихся к делу данных.

Вот некоторые типы сведений, которые вы можете включить:

• Примеры использования, для которых фича была бы полезна. Это очень важно. Ни одна рабочая группа не хочет стандартизировать фичи, которые будут использоваться лишь в редких исключениях. Полезный прием для сбора таких примеров — погуглить проприетарную фичу и посмотреть, для чего люди ее используют.
• Ваш опыт использования фичи. Что вам нравится, что вы хотели бы изменить в ее работе, как можно сделать ее универсальнее и т.д.

Также, решите, для какой спецификации она подойдет. Список спецификаций CSS можно найти здесь. Затем добавьте в начало названия вашей темы ID этой спецификации в квадратных скобках. Например, если тема относится к модулю величин и единиц, добавьте в начало названия «[css3-values]» (ID каждой спецификации можно найти в ее URL). Это обеспечит легкость нахождения вашей темы редакторами, и такие метки помогают каждому следить за разработкой интересующей его спеки.

Еще надо иметь в виду, что новые фичи не добавляются в спецификации, которые достигли статуса кандидата в рекомендации (или вот-вот его достигнут). Конечно, это относится и к последующим стадиям, напр. предложенной рекомендации и рекомендации. Например, если у вас предложение ввести новый селектор, адресуйте его не модулю селекторов 3-го уровня (ID: css3-selectors), которые уже имеют статус рекомендации, а селекторам 4-го уровня.

Если хотите узнать больше о том, как работает процесс стандартизации, прочитайте замечательный цикл статей fantasai «Внутри рабочей группы CSS».

«Это всё так сложно и скучно!»

То же самое можно сказать о раздельном сборе мусора для повторной переработки в противовес выбрасыванию всего кучей в один бак. Конечно, это сложнее, чем просто пользоваться проприетарными фичами «абы работало». Но в долгосрочной перспективе это в интересах каждого из нас, включая вас самих — завтрашних.

Огромное спасибо Дэвиду Стори, Сильвену Галино и Эрику Мейеру за их отклик.

Translated with the permission of A List Apart Magazine and the author[s].

А это — страница,
Которая в кеше на диске хранится,
И служит исходником каждой вещицы
В DOMе, который построил браузер.

Вот стили,
Которые быстро себя применили
Ко всем элементам разметки страницы,
Которая в кеше на диске хранится,
И служит исходником каждой вещицы
В DOMе, который построил браузер.

Вот область просмотра,
В которой рисуются рендером бодро
(С учетом всех стилей,
Что к элементам себя применили)
Все эти вещицы
(Которым исходником служит страница,
Которая в кеше на диске хранится)
В DOMе, который построил браузер.

Вот корневой элемент.
Он заполняет в момент
Всю область просмотра,
В которой рисуются рендером бодро,
С учетом всех стилей,
Что к элементам себя применили,
Все эти вещицы
(Которым исходником служит страница,
Которая в кеше на диске хранится)
В DOMе, который построил браузер.

А это — начальный блочный контекст
Который заведует выдачей мест
Под всё, что хранит корневой элемент,
Который заполнил в начальный момент
Всю область просмотра,
В которой рисуются рендером бодро,
С учетом всех стилей,
Что к элементам себя применили,
Все эти вещицы
(Которым исходником служит страница,
Которая в кеше на диске хранится)
В DOMе, который построил браузер.

Вот блоки,
Что идут друг за дружкой в потоке,
Упираясь контейнеру margin-ом в боки,
Образуя тот блочный контекст ,
Который заведует выдачей мест
Под всё, что хранит корневой элемент,
Который заполнил в начальный момент
Всю область просмотра,
В которой рисуются рендером бодро,
С учетом всех стилей,
Что к элементам себя применили,
Все эти вещицы
(Которым исходником служит страница,
Которая в кеше на диске хранится)
В DOMе, который построил браузер.

А это вот — строки,
Которыми будут заполнены блоки,
Что идут друг за дружкой в потоке,
Упираясь контейнеру margin-ом в боки
(если только в самих в них не вложены блоки,
что тоже пойдут друг за дружкой в потоке),
Образуя тот блочный контекст ,
Который заведует выдачей мест
Под всё, что хранит корневой элемент,
Который заполнил в начальный момент
Всю область просмотра,
В которой рисуются рендером бодро,
С учетом всех стилей,
Что к элементам себя применили,
Все эти вещицы
(Которым исходником служит страница,
Которая в кеше на диске хранится)
В DOMе, который построил браузер.

Конфиденциальность

Эта сборка Wahoo добавляет поддержку технологии Do Not Track, которая разрешает браузерам пользователей запрещать их отслеживание в интернете. По умолчанию эта функция отключена, но мы можем её активировать, включив следующие опции в настройках Opera: "Preferences > Advanced > Security > Ask websites not to track me"

Нужно помнить, что это будет работать только когда сайт акцептует запрос. Некоторые сайты уже сейчас делают это. И эффект DNT будет оценен, чтобы убедиться, что эта технология является жизнеспособным решением в долгосрочной перспективе.

SSL производительность

Эта сборка так же включает в себя первый раунд оптимизации для быстрой обработки SSL (CORE-41667):

• TCP оптимизация по исключению задержек прохождения сигнала
• Улучшен сеанс согласования (session negotiation) для экономии на времени ожидания
• Улучшена обработка соединения, что улучшает HTTP и HTTPS соединения
• Более быстрое закрытие соединений, что разрешает новые подключения на ранней стадии
• Распараллеливание OCSP/CRL использует в два раза меньше времени на проверку отмены операции
• Strict transport security повышает безопасность, а так же будет повышать и скорость, если серверы начнут использовать эту фишку

К примеру, первая загрузка сайта skandiabanken.no была уменьшена более, чем на 1 секунду. В последующие 10 загрузок время открытия уменьшилось почти вдвое.

XHR

В CORE-41784 мы доделали поддержку прогресса событий в XMLHttpRequest, для закачки, загрузки и настройки обновлений. Это улучшит закачку (upload) на сервисах Google (никаких Flash-загрузчиков на YouTube и Gmail).

Еще

Есть множество других улучшений, включая исправления в ядре, почте и темизации.

Просмотрите список изменений для более точной информации:

Осторожно! Это версия для разработчиков. В ней присутствуют все последние изменения, но так же и серьезные известные проблемы.

Скачать:

Windows Mac Linux\Free BSD

Полный список исправлений и изменений:

Desktop

• DSK-351582 Сбой при написании в адресной строке после удаления закладки
• DSK-337608 Сбой при выходе после установки расширения Speed ​​Dial
• DSK-355413 Одиночная вкладка показывается как набор вкладок
• DSK-340411 Зависание при копировании длинной строки в адресное поле
• DSK-349889 Отправка данных предупреждения системы безопасности блокирует страницу с двумя диалоговыми окнами с предупреждениями, из которых только одно может быть закрыто
• DSK-298032 Поиск по странице (CTRL-F) учитывает последний искомый текст

Почта

• DSK-267965 Поддержка Yahoo IMAP
• DSK-320233 Ответ на HTML-письмо должен быть представлен как HTML даже если по умолчанию стоит plain-text
• DSK-350402 Сбои при откреплении последнего сообщения в "Pinned" режиме
• DSK-355394 Сбой при закрытии окна почты
• DSK-355494 Заголовок письма прижат к правому краю, вместо левого
• DSK-353909 Сбой при выборе письма
• DSK-350332 Неверное количество непрочитанных писем
• DSK-352390 Невозможно настроить отображение загруженных заголовков
• DSK-350584 Пропажа содержимого текстового поля Быстрого Ответа при переключении сообщений
• DSK-353193 Колесо прокрутки и стрелки не проматывают сообщение
• DSK-353996 Опция 'No Images' не работает при переключении на другое сообщение
• DSK-354567 Сброс 'time period' опции просмотра почты при обновлении с pre-12 версии
• DSK-355473 Не запоминает последнее выделенное сообщение после перезапуска
• DSK-356611 Не прокручивает textarea до самого низа
• DSK-348448 Предварительный просмотр письма для печати должен использовать всю высоту окна почты
• DSK-347227 Прикрепление/открепление в списке не перерисовывается в сообщении сразу
• DSK-350960 Счетчик обновления акаунта на панели разделов почты не всегда исчезает
• DSK-356032 Не показывается диалоговое окно при выходе

Темизация

• DSK-340152 Выбранный эскиз в диалоговом окне при добавления в SD находится в "невыбранном" состоянии
• DSK-340136 Вкладки меняют свою ширину при наведении
• DSK-352081 Нечитабельные сочетания цветов в выбранных opera:config элементах
• DSK-347908 Двойные счетчики прогресса в режиме visual tab
• DSK-340936 Анимация счетчика загрузки страницы перезапускается при наведении
• DSK-346438 Подсказка Opera Turbo повторяется несколько раз
• DSK-260734 Загрузка неизвестного размера отображает неверный заголовок вкладки
• DSK-349657 Непредусмотренный цвет фона за счетчиками сообщений
• DSK-351800 Счетчик загрузки страницы в визуальных вкладках не анимируется
• DSK-355062 Неправильная кнопка на странице предупреждения о мошенничестве
• DSK-355042 Градиент фона не достаточно широкий когда вкладки находятся сбоку
• DSK-351508 Очистка отступов адресного и поискового полей
• DSK-353058 Удалена оберточная панель вокруг кнопок Назад/Вперед в адресной строке
• DSK-351152 Синяя полоса в верхней части интегрированной вкладки/заголовка
• DSK-350701 Амперсанды в главном меню WinXP в теме Zune
• DSK-352610 Сломанная полоса панели переключения
• DSK-349069 Контекстное меню панели задач не работает в XP с установленной темой
• DSK-353449 Шрифт строки меню контролируется "browser toolbars" вместо "browser menus"
• DSK-347984 Установка старого шаблона после темы применяет оба
• DSK-350481 Шаблон Аero меню не работает при аппаратном ускорении
• DSK-351752 Фоновые картинки не выстраиваются между элементами экрана
• DSK-354933 Выделение неправильным цветом в выпадающем адресном поле
• DSK-356643 [*nix] тема не растягивается при развернутом состоянии
• DSK-353770 Подсказка отладки шаблона должна быть показана только при зажатии CTRL

Ядро

• Исправлено множество сбоев
• Множественные исправления Dragonfly
• CORE-41308 Не разрешает встраивание iframe'ов в родительский документ с iframe src="#" (приводит к зависанию)
• CORE-41844 Сбой при огромном поле ввода
• CORE-41835 if(top.document) не должен работать кроссдоменно
• CORE-41647 'list-style-type: none' влияет на CSS градиенты, но не на другие изображения
• CORE-41669 xx-small font size отличается от других браузеров
• CORE-31179 Обрезается динамическое добавление тени
• CORE-41708 Поддержка HTMLInputElement.width и HTMLInputElement.height
• CORE-41793 Внутреннее ES имя класса для key event object должен быть KeyboardEvent
• CORE-34674 about:blank недостаточно пуст
• CORE-42174 Сбой в webgl демо на codeflow.org
• CORE-36742 Cookies, добавленные с помощью AddCookie, не отображаются в JS (document.cookie)
• CORE-41643 Вырезать и Вставить текст не вставляет вырезанный текст (FramesDocument::CutTextToClipboard неверный код для помещение в буфер)
• CORE-42357 Внешние скрипты не сохраняются в MHTML
• CORE-42361 XML парсинг не работает при сохранении XHTML документа с изображениями
• CORE-42359 Элементы в тегах OBJECT не сохраняются при сохранении с изображениями
• CORE-42296 Добавление color:black к UA стилизации для чтобы сделать его более читаемым при заданном желтым цветом текста по умолчанию
• CORE-42450 Некорректный .oex файл приводит к зависанию Opera
• CORE-42570 Нельзя залогиниться в Opera Link используя non-ASCII пароль
• CORE-42214 Opera виснет после отправки формы, измененной с помощью JS
• CORE-28773 non-BMP символ в URL некорректно отображается в строке состояния
• CORE-42281 :not(.a).b и :not(#a)#b не совпадают, когда должны
• CORE-20881 выделения текста в редактированном документе обрабатывает суррогатную пару (surrogate pair) как два символа
• CORE-42217 Неправильная обработка box-shadow
• CORE-25919 Конвертирование hex в unicode не срабатывает в режимах почты compose/designmode
• CORE-12300 Opera дает сбой при отсутствии файла english.lng
• CORE-5664 line-height: 0 предотвращает выделение текста
• CORE-40886 minhaseconomias.com.br не загружается после логина (Unicode проблема)
• CORE-13929 Если после !important не следует точка с запятой, не сработает не только следующее свойство, но и все правило тоже
• CORE-40509 Изображение с процентным значением высоты не меняет ширину, чтобы заполнить своего родителя
• CORE-39361 text-indent служит оберткой для вложенных флоат-элементов и элементов с левым отступом
• CORE-38020 STF поток содержащий инлайн-блок с левым отступом и флоат-элемент становится слишком узким в почти стандартном режиме
• CORE-42663 css white-space свойства со значениями, отличными от 'nowrap' не обрабатываются в MultilineEdit
• CORE-42614 Баг с линейным градиентом
• CORE-42396 Уменьшен расход памяти при Bidi расчете
• CORE-42537 Unicode space like символы не должны конвертироваться в ПРОБЕЛ (U+0020) в заголовке документа
• CORE-39103 Незначительный прирост производительности JS
• CORE-42736 Удалено игнорирование атрибута 'transform' элемента после animateTransform
• CORE-42671 Элемент остается в активном состоянии после двойного клика
• CORE-42776 animateTransform + svg фильтр не размещаются корректно
• CORE-40065 В Event.prototype должны быть константы AT_TARGET, BUBBLING_PHASE, CAPTURING_PHASE, …
• CORE-42038 postMessage отдает структуру://host вместо ноля для файловой схемы, у которой нет scheme/host/port кортежа
• CORE-42784 EventSource не срабатывает в виджетах в связи с проверкой CORS
• CORE-41319 Не срабатывает клик по определенных частях колонки
• CORE-42822 Работает, пока оператор с исполняемым регулярным выражением, который был создан во время компиляции, не прекращает пошагово матчить
• CORE-42909 Игнорируется стиль тегов SVG, встроенных в HTML5
• CORE-42848 Поддерево с символьной информацией (текст или комментарии) вставляется в элемент дважды и вызывает проблемы производительности
• CORE-42866 Фикс для Unicode имен прикрепленных файлов в почте приводит к повреждению файлов в некоторых клиентах
• CORE-8987 Изменения настроек не сохраняются незамедлительно
• CORE-42910 document.lastModified должен возвращать текущее время, если нет данных
• CORE-42574 Обход DOM, работающий cloneNode и установка innerHTML массово нагружают CPU
• CORE-37862 FileReader API – последнее "progress" событие иногда срабатывает после "load" и "loaded" событий
• CORE-43012 Срабатывает отключение параметра по умолчанию для SSL
• CORE-42812 Сокращенный border-radius не может быть удален с помощью removeProperty()
• CORE-33296 Opera не читает zip архивы созданные с помощью bsdtar или zip64
• CORE-43050 Когда инпут с данными спрятан, и позже его значение убирается и появляется снова, старое значение восстанавливается
• CORE-43010 currentColor обрабатывается как значение invert свойства outline-color

Оригинал