Статьи

Рівномірний вирівнювання блоків по ширині - CSS-LIVE

  1. Як це працює?
  2. Наша задача
  3. Варіант 1
  4. Варіант 2
  5. Варіант 3 - text-align: justify
  6. Варіант 4 - Позбавлення від Додатковий елемента
  7. резюме
  8. Всі варіанти воєдино
  9. Оновлено 08.10.2014

У завданнях верстки періодично виникають моменти, коли з'являється необхідність вирівняти який-небудь список по ширині екрану. При цьому пункти цього списку повинні вирівнюватися поступово, притискаючись своїми крайніми елементами до кордонів контейнера, а відстань між ними має бути однаковим.
Щоб було зрозуміліше, про що йде мова, наведу пару зображень.

На малюнках видно, що при різному дозволі екрану пункти все одно продовжують вирівнюватися по ширині, приєднуючись до бічних стінок і роблячи відступи між собою - рівнозначними.
У цій статті я хочу докладніше розібрати різні варіанти вирішення даного завдання, а також розглянути всі погані і хороші сторони цих методів.

Як це працює?

Перед тим, як розглядати кожне рішення окремо, давайте трохи заглибимося в тонкощі механізму і поміркуємо, як він працює.
По суті ми повинні отримати те, що робить 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; }

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; }

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;}

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. Варіант з псевдо-елементом (Работающее рішення)

Оновлено 08.10.2014

Варіант 5 - використовуємо нові технології

5. Варіант з використанням флексбоксов і поступовим поліпшенням

Див. Окрему статтю

PS Це теж может буті цікаво:

Як це працює?
Як це працює?
Звичайно ж можна було б поставити мінімальну ширину контейнера і такого б не сталося, але хіба можна вважати цю дію відмовкою або рішенням?
Чому я сказав "Майже що"?
У чому ж справа?
Як бути?
Але, а цілому, наш метод працює ідеально, так що можна підводити підсумки і йти далі, адже нам же мало одного рішення, нам же потрібно більше і краще, чи не так?
Чому б не замінити таким псевдоелементи наш зайвий допоміжний блок?
Чому ж це відбувається?
Так, але тоді виникає питання: "Якщо є і можливість і сила, яка може її виконати, то чому ж тоді нічого не відбувається?

Новости