s0rr0w

Потому что исследование проводил дилетант.

Тьфу ты, точки забыл. .submit+.clear { display none; clear: none; } Идиотские clear.

Идиот какой-то верстку делал. Клинический причем. Пробуй такую конструкцию submit+clear { display none; clear: none; }

Доктайп строгий поставить.

Ищи по форуму или в гугле ключевые слова conditional comments

Пробуйте target="_tab"

На этом форуме неоднократно подымалась тема центрирования контента по вертикали. Используйте поиск. Тему закрываю.

Аналогично но проще. Куда проще вставить две скобки и имя переменной, чем горидить обвязку пхп. Читабельность смарти-темплейтов на порядок выше. Данный пример решается на пхп дополнительным циклом, вместо capture. Человеческие ресурсы не безграничны. Один человек не сможет никогда сделать больше, чем два, три и более. Почему никто не пишет серверные веб-приложения на ассемблере? Нельзя подходить к смарти как к задаче тупой вставки переменных в шаблон. Это логическая прослойка. В ее необходимости вы удостоверитесь, когда будете разрабатывать большие проекты в команде.

Они оба могут писать на смарти, но один заведует пхп, второй хтмл. Их зона ответственности лежит в смарти. Программеру не обязательно знать все тонкости HTML, а кодеру- досконально пхп и структуру системы. А смысл было придумывать языки высокого уровня, если все то же можно написать на ассемблере? Или вообще в машинных кодах? Смарти - более высокоуровневый язык. Его изучить кодеру проще, чем вникать во все тонкости пхп. Если у нас пришли такие данные, то мы показываем вот этот блок. Если другие данные, то вот этот блок. Если данных нет вовсе, то надо показать третье. Таблицу с данным раскрасить с учетом типов данных, причем прогруппировать их в отдельные блоки, причем неактивные данные предварительно свернуть. Так понятнее?

Легко {capture name="ids" assign="ids"}{/capture} {capture name="cData" assign="cData"} {foreach from=$data item="item"} <tr><th>{$data.title}</th><td>{$data.name}</td></tr> {capture name="ids" assign="ids"} {$ids} {$data.id}, {/capture} {/foreach} {/capture} {if $cData|strip != ""} <table> <tbody> {$cData} </tbody> </table> <input type="hidden" name="ids" value="{$ids}"> {else} Нет данных {/if}

Открою вам страшную тайну, зона ответственности лежит между кодером и программером. Дизайнеры должны дизайнить, а не HTML стряпать. В коде модификатора. В папке smarty/plugins/ Смарти это не тупая вставка переменных в шаблон. Это темплейты с логикой. Кто-то скажет, что логика должна быть вынесена на уровень выше, а я скажу, что ее целесообразнее использовать именно в шаблоне, а на php переложить функцию подготовки первичных данных. В системах с использованием смарти код распределяется таким образом: php : выбрать данные, передать их в шаблон smarty : на основании данных построить нужный HTML, причем логика отображения HTML будет находиться в смарти

Когда ты работаешь над кодом один, то тебе пофиг какой инструмент выбрать для того, чтобы выполнить задачу. Но когда работает больше чем 1, то smarty - отличный способ разграничить зоны ответственности. Второй момент. Смарти в чистом виде выглядит действительно невзрачно, но стоит немного его доработать, как работа с ним начинает приносить удовольствие. Например, есть задача показать в таблице список клиентов. Допустим, каждый клиент описывается следующим массивом ( для упрощения записи использую JS) { id: 43, company_type: "ООО", name: "Роги и копыта", type: 3, access: 1 } Эти данные в чистом виде берутся из базы. Как видим, type и access - идентификаторы, а не текстовые значения. Допустим, type=1 это демо клиенты, type=2 это коммерческие клиенты, а type=3 партнеры access: 1 это уровень доступа к системе. Для демо-клиентов уровень доступа всегда один - нулевой. Для коммерческих клиентов всегда 1=обычный доступ. А для партнеров 1 это обычный доступ, 2 - специальная партнерская схема. Нам нужно отобразить человеческие текстовки на основании таблицы этих параметров, чтобы было понятно людям. Демо-доступ Коммерческий доступ Партнерский доступ Расширенный партнерский доступ Для этого мы создадим модификатор access_type, который будет модифицировать type и выводить нужную нам текстовку. {$type|access_type:$access} В итоге нам в любом месте, где нужно будет выводить информацию о доступе, будет достаточно применять модификатор. В нашем проекте используется более 20 кастомных функций и модификаторов, которые серьезно облегчают жизнь.

Может и возможно, но желания копаться в вашем коде, откровенно, нет.

Залейте данный блок фоном.

Пользователь без ваших подсказок сам решит, что ему наиболее удобное.

Сначала надо выучить HTML, потом CSS, потом уже заниматься порезкой PSD.

table-layout: fixed

Потому что margin collapsing

Понты ни к чему. Если что-то легче делать таблицей, то надо делать таблицей и не париться.

Мыслишь стандартно. display: table:cell превратит твой код в таблицу визуально. Для IE сделаешь кондишинал комментс

1. Таблица 2. Отказаться от списка и сделать через inline-block с центрированием контента Приехать в офис компании с мачете и отрубить пару пальцев у архитектора программы. Я забиваю на оплошности браузеров. Никто не заметит отсутствие пары пикселей.

Мой первый коммерческий сайт тоже давно сдох вместе с компанией... Первый хомяк сдох вместе с очередным обновлением GeoCities еще году в 2000м...

CSS арифметика простая 50% от auto = auto/2 = screen width/2 100% от 50% = screen width/2 http://www.w3.org/TR/CSS21/syndata.html#percentage-units Проценты могут быть дробными Че, правда что-ли? Мдааа, проверил, реально Опера тупая и игнорирует спецификацию в данном вопросе. Зато проходят на 100% тест acid 3.

Ну да А если у тебя нет постраничного вывода, то грузи просто данные, без обертки.

Стоит его использовать, когда в этом есть потребность.