Внимание! Данная запись отмечена как устаревшая и/или потерявшая актуальность! Возможно автор уже передумал и теперь придерживается другой точки зрения, нежели изложенная в тексте ниже.

Верстка с помощью Grid

Дневник / Вёрстка сайтов: CSS, HTML, LESSПросмотров: 21787 (236)

После обсуждения предыдущей статьи «Концепция: верстка HTML-страниц ячейками» я немного переосмыслил свои же идеи. Спасибо всем, кто принял участие в обсуждении и на сей раз я готов предложить дальнейшее развитие концепции и готовый практический вариант.

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

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


Эпизод 1

Итак, начнем с рабочего процесса создания сайта. Клиент заказывает сайт. Обычно в первую очередь идет работа дизайнера. Именно он думает об оформлении всех графических элементов. Грамотные дизайнеры постоянно держат в голове тот факт, что конечный результат это не файл в фотошопе, а HTML-страничка, которая имеет свои ограничения. Например неизвестный объем текста в различных блоках. Или то, что вывод информации осущствляется прямоугольниками. Те же дизайнеры, которые имеют опыт типографской верстки (условно назовем их так) могут думать возможностями своих программ. Например сложное обтекание текстом, колонки с перетеканием, «фонарики» и т.д. Во многих случаях такой дизайн если и реализуется на HTML, то с большим трудом. Откройте для примера какой-нибудь глянцевый журнал и вы увидите пример типографской верстки.

Вторым участником процесса будет верстальщик. Ему предстоит «нарезать» дизайн под HTML и прописать нужные CSS-стили. Верстальщик помимо всего прочего должен обеспечить не просто визуальное соответствие, но и одинаковое отображение в разных браузерах (хотя бы до разумных пределов). И тут, помимо сложностей и хитростей верстки, есть масса подводных камней. Например заказчик настаивает на том, чтобы сайт корректно работал в IE6. Стоит ли говорить о том, что этот браузер совсем старый и не соответсвует многим web-стандартам? Таким образом верстальщик вынужден идти на дополнительные сложности. Например очень часто используют вложенные DIV-блоки, только ради корректного отображения в браузерах IE. Что же касается CSS-стилей, то помимо т.н. хаков появляется лес плохо очевидных правил. Конечно же это сильно усложняет код и вообще работа со стилями во многом тянет на шаманство.

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

После верстальщика, готовый HTML попадает в руки программиста, в задачу которого входит «натянуть» шаблон на CMS. Для программиста главная головная боль - это разбить HTML на части, которые подключает система, а также согласовать CSS-стили верстальщика со стилями и HTML-кодом, который генерирует CMS. На самом деле это довольно сложная задача и порой случается так, что программист вынужден возвращать шаблон верстальщику, чтобы тот его поправил. Иной раз случается и так, что утвержденный клиентом дизайн (и уже сверстанный верстальщиком), невозможно выполнить в рамках CMS. То есть CMS генерирует такой HTML-код, который очень далек от сделанного верстальщиком. И тут либо уговаривать клиента подстроиться под «движок», либо что-то менять в системе.

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

В этом случае от программиста требуется довольно-таки неплохие знания прежде всего верстки. У меня, например, нередки ситуации, когда глядя на предоставленный шаблон, я принимаю решение полностью его переписать. Причин может быть масса: от заголовков H3, вместо H1 (который генерирует система), до совершенно безобразного или очень путанного HTML и CSS-кода. То есть это как раз случай, когда проще и быстрей сделать с нуля, чем разбираться и переделывать существующее.


Эпизод 2

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

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

Самым простым примером такой сетки, могут служит т.н. направляющие в редакторах. Например инструмент Slice в фотошопе выполняет примерно такую же роль. В CorelDraw можно выставить сетку в виде точек, а самим направляющим задать произвольный угол наклона. Или скажем, «прилипание» к объектам, тоже является своего рода модульной сеткой. В типографских программах, например PageMaker (и аналогичных) модульная сетка может задаваться в виде колонок, у которых задаются отступы, шаблоны «master page», фреймы, которые могут иметь свой набор колонок и даже обтравочный контур (в TIFF) по которому происходит обтекание текстом.

Наверное этих примеров достаточно и он демонстрирует, что дизайнер совершенно не обделён возможностью строить произвольную модульную сетку. Грамотный дизайнер, как я уже отметил выше, держит в голове, что конечный вариант - это прямоугольники, поэтому графические элементы могут располагаться только в виде простой прямоугольной модульной сетки. Стоит дизайнеру, сместить какой-то элемент в одном из парных блоков выше «top-линии» и это уже гарантирует верстальщику дополнительную головную боль. Это конечно же не означает, что такой дизайн плох. Нет, просто затраты на верстку в таком случае несколько больше, чем, если бы дизайнер придерживался модульной сетки попроще.

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


Эпизод 3

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

Но верстальщики бывают разные. Те кто помоложе, да порезвее делают «буквально» - вот блок - он должен располагаться там-то и там. Задаем отступы, размеры - вуаля! - все на месте. Такая работа не имеет системного подхода, потому что для следующего сайта ему опять придется все делать с нуля. Такой верстальщик должен иметь в своем арсенале сто и один способ заставить отображаться капризный блок в четко заданном месте.

Верстальщики поумнее понимают, что так не годится и делают какой-то свой набор правил и подходов. Часто у верстальщика есть своя коллекция заготовок на все случаи жизни - он берет наиболее близкую заготовку и начинает работу уже с ней. Аналогично происходит и структуризация наборов CSS-стилей. Тут вариации самые разные: от простого reset.css до использования css-фреймворков.

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

И вот тут наступает черед самых умных верстальщиков. Они-то знают, что сверстать сайт проще в два этапа - вначале выстроить (сымитировать) модульную сетку, а уже потом заниматься кастомизацией каждой ячейки.

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

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

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

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


Эпизод 4

Любой программист ленив. Это залог того, что он будет изобретать и придумывать способы уменьшить свои тело, -мозгодвижения. Я тоже в меру ленив, поэтому решил, что модульную сетку должна делать программа. В HTML, как ни крути, всё прямоугольное и построчное. Поэтому модульная сетка может быть только в виде строк и ячеек. Грубо говоря - блоки или таблица (как сложная группировка блоков).

На практике это будет выглядеть так: верстальщик будет следовать тем же правилам, что и программист. То есть у них будет единая модульная сетка. Эта сетка будет задаваться в виде ячеек: строка, столбец. Программа (PHP-скрипт) будет сама решать какой именно генерировать HTML-код, чтобы это было оптимально с разных точек зрения. Для верстальщика задача будет состоять в том, чтобы выстроить модульную сетку и получить готовый HTML-каркас для дальнейшей верстки (по сути - остальное работа со стилями). А поскольку генерацию кода мы поручили программе, то построение сетки будет проходить весело и легко, почти как при визуальном моделировании.

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


Эпизод 5

Уже вижу возмущенный взгляд - опять таблицы! На сей раз нет. Функции построения модульной сетки (GRID) будут умными и сами смогут решить, где выводить таблицу TABLE, а где достаточно обычного блока DIV.

Основные правила таковы:

  • Если в сетке одна ячейка, то это одиночный DIV.
  • Если в сетке один столбец, то это вложенные DIV.
  • Если в сетке более одного столбца, то это TABLE.
Что же касается алгоритма анализа, то в принципе для противников таблиц, можно предусмотреть генерацию HTML на основе блоков, имитирующих таблицы. Например берется CSS-фреймворк и строится функция, генерирующая блоки согласно его API.

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

Делаем мы это из соображений облегчить вывод информации браузерами и немного упростить результирующий HTML-код.


Эпизод 6

Перед тем, как приступить к практической части, я просто обязан рассказать как происходит вывод данных в шаблонах MaxSite CMS. Конечно же предложенный скрипт спокойно подойдет под любую другую систему или простенький php-шаблонизатор. Но, поскольку я не готов упускать случая попиарить свою MaxSite CMS, то и решение соответствующее.

В MaxSite CMS (Покупайте наших слонов!) шаблон должен иметь файл index.php. В нем находится т.н. диспетчер типов. В нем определяется какие данные следует выводить. Например home - главная, page - одиночная страница и т.п. Подключается (обычным require) файл типа (type). Этот файл может быть как свой, так и дефолтный.

В самом type-файле вначале подключается файл main-start.php, потом выводятся данные, и в конце подключается main-end.php.

То есть наш шаблон должен быть разбит на две части: main-start.php и main-end.php. Между ними система выводит нужные данные, например текст страницы.

Таким образом наши GRID-функции должны работать именно в этих двух файлах.


Эпизод 7

Основных GRID-функций три:

  • grid_start() - указание размеров и названия сетки
  • grid_r_c() - опции ячейки
  • grid_end() - вывод сетки

grid_start('название сетки', строк, столбцов);

- Каждая сетка должна иметь своё уникальное название. Именно оно задается в первом параметре. При генерации HTML-кода это название используется для указания id контейнера (DIV или TABLE).

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

grid_r_c('название сетки', строка, столбец, array(опции));

- Для задания опций ячейки следует указать название сетки, к которой она принадлежит, и её координаты. Последний параметр - массив опций. Опции следует задавать именно через массив, потому что опций может быть много и в будущем могут появиться новые.

- Опции задаются в виде «Ключ => Значение». Например 'file'=>'main-menu.php'. Ниже привожу список реализованных опций и их описание.

  • text - текст для ячейки. Можно задать произвольный HTML. Существует предопределенный текст «_null», который позволяет для таблиц не генерировать ячейку TD. Используется для построения сложных таблиц с colspan или rowspan.
  • func - функция ячейки. Результат функции будет выведен в ячейке. Есть несколько предопределенных имен функций. «ob_start» - включает буферизацию вывода. Нужно например для вывода вложенных блоков или для вывода результата type-файла. «ob_end» - вывод буфера в ячейку. «ob_clean» - очистка буфера без его вывода. Используется для генерации голого HTML-каркаса или при отладке.
  • file - файл, который будет выведен в ячейке. Должен располагаться в каталоге шаблона.
  • id - id ячейки.
  • class - класс ячейки.
  • attr - атрибуты ячейки, например style.
  • colspan - количество столбцов которое занимает ячейка (только для таблиц). Полный аналог COLSPAN для TD.
  • rowspan - количество строк которое занимает ячейка (только для таблиц). Полный аналог ROWSPAN для TD.

grid_end('название сетки');

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

Для отладки сетки можно использовать функцию grid_show_struct(). Она выводит в виде массива текущую структуру всех сеток. Годится для программистов.

Для верстальщиков может понадобиться сгенерировать HTML-каркас без содержимого ячеек. В этом случае перед построением сетки нужно определить константу «GRID_ONLY».

define('GRID_ONLY', true);

После генерации кода (F5, в общем-то) получить каркас можно скопировав исходный код страницы (Ctrl+U).

Для того, чтобы не выводить содержимое type-файла, нужно очистить буфер. В файле main-end.php указываем функцию «ob_clean» (вместо «ob_end»):

grid_r_c('main', 1, 2, array('func'=>'ob_clean'));

Для возврата в нормальный режим, закоментируйте или удалите константу «GRID_ONLY».


Эпизод 8

При построении сетки не обязательно указывать каждый параметр (ну кроме функции, текста или файла), программа автоматически создает нужные классы и id. То есть задумка такая, чтобы был один простой алгоритм именования. В текущем виде он реализуется так.

  • Название сетки выставляется как id контейнера.
  • Для вложенных элементов генерируются классы: «сетка-строка сетка», «колонка строка-колонка сетка-строка-колонка».

Например для кода:

grid_start('myblock', 1, 2);
        
    # row1
    grid_r_c('myblock', 1, 1, array(
            'text'=>'первая ячейка',
            ));
        
    grid_r_c('myblock', 1, 2, array(
            'text'=>'вторая ячейка',
            ));
        
grid_end('myblock');

Будет сгенерирован такой HTML-код:

<table id="myblock">
    <col>
    <col>
    <tr class="row1 myblock-row1">
        <td class="col1 row1-col1 myblock-row1-col1">первая ячейка</td>
        <td class="col2 row1-col2 myblock-row1-col2">вторая ячейка</td>
    </tr>
</table>

Если же необходимо явно задать класс или id, то он определяется в параметрах.

grid_start('myblock', 1, 2);
    
    # row1
    grid_r_c('myblock', 1, 1, array(
            'text'=>'первая ячейка',
            'class'=>'logo',
            ));
    
    grid_r_c('myblock', 1, 2, array(
            'text'=>'вторая ячейка',
            'id'=>'myfind',
            ));
        
grid_end('myblock');

Получим:

<table id="myblock">
    <col>
    <col>
    <tr class="row1 myblock-row1">
        <td class="col1 row1-col1 myblock-row1-col1 logo">первая ячейка</td>
        <td id="myfind" class="col2 row1-col2 myblock-row1-col2">вторая ячейка</td>
    </tr>
</table>

Таким образом верстальщик может использовать автоматические классы для построения модульной сетки, а для ячеек с содержимым - явно указать id или нужный класс.

Обращаю ваше внимание на тэги «col». Они необходимы при построении сложных таблиц и указывают браузеру количество колонок в таблице. Если этого не делать, то при использовании colspan может возникнуть ситуация неверного построения таблицы. Скажем вы задали три ячейки, одна из них объединена с другой, поэтому указывается два TD, хотя должно быть три.

При использовании опции «colspan» следует вывести объединяемую ячейку из отображения/генерации. Для этого в её параметре «text» следует указать «_null». Вот пример объединенной ячейки.

grid_start('test', 2, 4);
        
    # row1
    grid_r_c('test', 1, 1, array(
                'text'=>'11',
                ));
        
    grid_r_c('test', 1, 2, array(
                'text'=>'12',
                ));
        
        grid_r_c('test', 1, 3, array(
                'text'=>'13',
                ));
                
    grid_r_c('test', 1, 4, array(
                'text'=>'14',
                ));
            
            
    #row2
    grid_r_c('test', 2, 1, array(
                'text'=>'21',
                ));
        
    grid_r_c('test', 2, 2, array(
                'text'=>'22',
                'colspan'=>2,
                ));
        
    grid_r_c('test', 2, 3, array(
                'text'=>'_null',
                ));
                
    grid_r_c('test', 2, 4, array(
                'text'=>'24',
                ));    
grid_end('test');

Результат:

При генерации DIV используются теже самые правила, что и для таблиц. Естественно, что параметры colspan и rowspan игнорируются. Для одиночного блока (одна ячейка) задается только id, класс и атрибуты. Для вложенных DIV создаются классы «строка сетка-строка». Колонка, не задается, посколько это лишено смысла - она всегда одна.  


Эпизод 9

Для использования GRID-функций, следует вначале скачать файл grid.php 11 (переименуйте расширение).

Подключить его можно к любому шаблону перед началом использования, например в файле index.php:

require_once(getinfo('template_dir') . 'grid.php');

Если у вас другая CMS, то подключение аналогично, только указываете свой путь. В файле следует удалить первую строчку, а также заменить функцию отладки pr() на что-то похожее, вроде print_r(). В остальном разницы нет.


Эпизод 10

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

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

grid_start('myheader', 1, 2);
    
    # row1
    grid_r_c('myheader', 1, 1, array(
            'func'=>'myheader_logo',
            ));
            
    grid_r_c('myheader', 1, 2, array(
            'func'=>'myheader_name',
            ));
            
    function myheader_logo()
    {
        if (!is_type('home')) echo '<a href="' . getinfo('siteurl') . '">';
        
        echo '<img src="' . getinfo('stylesheet_url') . 'images/header.jpg" '
            . 'width="200" height="100" alt="' . getinfo('name_site') . '" '
            . 'title="' . getinfo('name_site') . '">';
    
        if (!is_type('home')) echo '</a>';
    }
    
    
    function myheader_name()
    {
        echo '
            <h1>' . getinfo('name_site') . '</h1>
            <h2><span>' . getinfo('description_site') . '</span></h2>
            ';
    }    
        
        
grid_end('myheader');

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

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

Следует отметить, что при задании ячейки учитывается приоритет. Высший приоритет имеет «text», потом «func» и в конце «file». То есть, когда вам вдруг понадобится перестроить сетку, но уже будут прописаны функции или файлы, то для отладки достаточно указать «text». После отладки эту строчку можно закоментировать.

В некоторых случаях может потребоваться подключить какой-то большой и сложный блок. В этом случае удобней вынести его в отдельный файл и подключать с помощью «file». Сам файл должен располагаться в каталоге шаблона.

Например можно задать файл для отображения MainMenu:

// main-menu.php
<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
if (!mso_hook_present('main_menu')) { ?>
    <div id="MainMenu">
        <div id="tab">
            <ul>
                <?php
                    $def_menu = t('/ | Главная_NR_about | О сайте_NR_comments | Комментарии_NR_contact | Контакты_NR_sitemap | Архив_NR_feed | RSS', 'templates');
                    if ( $menu = mso_get_option('top_menu', 'templates', $def_menu) ) 
                        echo mso_menu_build($menu, 'selected', true);
                ?>
            </ul>
        </div><!-- div id="tab" -->
    </div><!-- div id="MainMenu" -->
    <?php } 
    else mso_hook('main_menu'); 
?>

Это стандартный блок горизонтального многоуровневого меню для шаблонов MaxSite CMS. Подключаем так:

grid_r_c('header', 2, 1, array('file'=>'main-menu.php'));

Использование функций и файлов позволяет задавать сложные блоки, а с помощью плагинов «Модули» или «Ушки» задавать содержимое блоков прямо из админ-панели. Комбинирование всех этих подходов позволяет делать полностью настраиваемые сайты.


Итог

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

Приятного сайтостроения!


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

Комментариев: 3 RSS

1Романыч28-10-2009 16:09

Респект за статью!

Замеченный недостаток: куча ошибок в тексте.

2UmFal02-01-2010 08:23

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

За любой холивар о том, что «таблицы - вчерашний век» и подобный бред, сразу забаню навечно.

Рискнуwink Если не прикрутить дивовую вёрстку, хотя бы как опцию, пользоваться разработчики вряд ли станут. Про то, что таблицы вчерашний век... Это не так, но большинство шаблонов используют именно дивы, а сайт как ни крути должен быть свёрстан единообразно. Смешивать не надо.

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

Благодарю за статью! С праздником!

3Андрей13-01-2010 15:18

До 6 эпизода все понятно.

А дальше инфа вроде как для верстальщика, но мне она не совсем понятна.

p.s. WP шаблоны и ежи сними - это что-то, вернее нечто. Неделю как знаком с WP, саму концепцию уловил не до конца еще. А вот ваша понятна, но технически я просто в нокауте.

Оставьте комментарий!

Комментарий будет опубликован после проверки. Вы соглашаетесь с правилами сайта.

(обязательно)

О сайте

Здесь вы получите самую полную информацию о создании сайтов на MaxSite CMS.

Рейтинг@Mail.ru