wildhind

а можно ли посмотреть на то, что уже сделано?

Несколько фоновых рисунков задаются через запятую. Читать здесь. Только не забывать о том, что в некоторых устаревших браузерах это работать не будет. А по второму вопросу… Там всё очень сильно плохо. Например, зачем для боди абсолют задан? Надо вёрстку в порядок привести, чтобы можно было исправить.

разобраться с margin-top — речь о том, что вы применяете к div.imag свойство margin-top: 9px и ожидаете, что картинка сдвинется на 9px вниз, а она не сдвигается? Это нормальное поведение. Маргин выходит за рамки родительского элемента, поскольку внутри #footer перед .imag других элементов нет, и отталкаваться ему не от чего. В вашем случае можно для #footer задать overflow: hidden, тогда #footer за свои пределы никого просто так отпускать не будет, а .imag своим маргином отталкиваться будет уже от верхней границы #footer.

ой. Беда есть, да. для #footer ширина не задана, соответственно, его ширина будет равна ширине страницы, каковой бы она ни оказалась. Зависит от ширины окна браузера. А картинка с номером телефона спозиционирована относительно левого края #footer: left: 140px; position: relative; Вот она и остаётся на расстоянии 140px от левого края окна браузера, как бы широко это окно ни было раскрыто. Чтобы картинка расположилась строго под левой колонкой (а такова была задумка?), надо либо задать для div.imag такую же ширину, как для div.wrapper, и при этом вычистить весь этот мусор с позиционированием, и не забыть убрать text-align: center; либо спозиционировать блок с картинкой по центру (left: 50%), а затем маргином подвинуть влево (margin-left: -500px).

а ещё лучше — ссылку на страницу.

Тогда остаётся вам посочувствовать.

а сам текст в чём набран? а сервер что в заголовках отдаёт? а не выбрана ли какая-нибудь ересь в настройках браузера?

http://htmlbook.ru/css/word-wrap

А вот на этот вопрос ответить уже будет возможно лишь после того, как вы правильно сформулируете свою проблему.

Так ведь это задача в первую очередь для дизайнеров.

Привести кодировку в соответствие здравому смыслу.

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

замечательно решили вопрос с вертикальным центрированием. Однако если уж #wrapper { display: table-cell; }, то и вести оно себя будет как ячейка таблицы. А как единственной ячейке таблицы шириной 1000px вести себя в таблице шириной 100%? Не знаете? Вот и файрфокс не знает. И Хром не знает. И ладно бы это ещё в самом деле была таблица, так ведь нет, это всё блочные элементы, но в css такое! Браузеры путаются и с ума сходят, а с ума сходят — вот и путаются. Кстати, зачем вообще для #wrapper задана ширина? его ведь задача только по вертикали центровать. А центровать по горизонтали обучен #centered. И ему задана и ширина и margin: auto — всё как положено. Уберите ширину у #wrapper. Не нужна она там. И всё заработает стабильнее.

нет, дурак так не сможет. Молодцы авторы.

не получается ещё чуть сильнее поднажми!

ну ещё overflow: hidden правому блоку — и будет вам счастье. А вообще, jsfiddle.net гораздо удобнее и понятнее, чем куски кода и куски скриншотов.

если блоку с ценой задать float, то соседний блок автоматом его обтечёт и займёт оставшееся место.

да, можно. Читать здесь.

Над самими картинками работать. При горизонтальном выравнивании по центру они должны дать нужный эффект.

Забить. Ну или почитать msdn. -ms-filter:"progid:DXImageTransform.Microsoft.Alpha(Opacity=0)";

Если нужно древних ослов поддерживать, то тоже есть решение: filter:progid:DXImageTransform.Microsoft.Alpha()

да

Этот функционал не планируется в рамках данного проекта.

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

Сервис ориентирован на довольно узкую целевую аудиторию и узкое применение. Обзоры сайтов, системы помощи и прочее сюда не входит. Сервис ориентирован на дизайнеров, преимущественно на веб-дизайнеров. Известен факт, что заказчик получает более чёткое представление о дизайне разрабатываемого сайта, если дизайнер демонстрирует не голый макет, а обёрнутый в окно браузера. Как бы ближе к действительности получается. В окне браузера — уже не абстрактная картинка, при взгляде на которую возникают нездоровые фантазии вроде «а добавьте здесь красненького, а тут пусть вертится», а действительно макет сайта. Заказчик видит его уже как бы в действии, как он будет выглядеть в браузере, и принятие решения насчёт развития дизайна переходит в более конструктивное русло. Поэтому многие дизайнеры давно используют этот приём для получения более качественного результата. Сервис разработан изначально для своих дизайнеров с учётом в первую очередь их пожеланий. А они таковы: — одновременная загрузка и одновременная обработка нескольких изображений; — выбор браузеров и устройств; — нормализация размеров итоговых картинок; — возможность повторной обработки уже загруженного набора; — возможность дать ссылку на итоговый набор картинок; — конфиденциальность (невозможность подбора адреса существующих сетов); — автоматическое удаление с сервера устаревших сетов. Свои дизайнеры довольны, сервис экономит им тучу времени, выполняя за них ненужную рутинную работу. В большинстве случаев работа с сервисом сводится к тому, чтобы выделить в файндере несколько файлов, перетащить их пером в окошко GetCover, кликнуть «готово», кликнуть «получить ссылку», кинуть эту ссылку в окошко скайпа заказчику. Раньше та же операция занимала до двух часов работы. Особенно это тормозило на завершающих этапах разработки дизайна, когда согласовывались уже мелочи. Недавно сервис переехал в интернет для публичного использования. Естественно, интересны отзывы пользователей сервиса, в том числе потенциальных. Уже мы услышали много интересного, уже сейчас в работе некоторые изменения, в том числе и инициированные конструктивной критикой посетителей форума htmlbook. Есть уже кое-какие изменения, которые пока тестируются на локальной версии, но в публичную часть не выложены. Опросы показали забавную тенденцию: высокооплачиваемые дизайнеры в основном довольны сервисом, настрония у них варьируются от умеренно положительного до щенячьего восторга. Низкооплачиваемые дизайнеры ворчат: «это ж для кого такой сервис? кто не может своими руками то же самое сделать в фотошопе?». А программисты в 80% случаев вообще не понимают, что это, для кого, зачем, и что с этим делать И начинаются фантазии насчёт скриншотов и прочего не имеющего отношения к основной затее. Сегодня определены шаги дальнейшего развития сервиса. Пока нет реализации, не могу говорить о том, каковы они будут, но направлены они будут на дальнейшее развитие удобства взаимодействия дизайнера с заказчиком. Да, смотрел уже с выбором. Сегодня пригляделся и меня начали терзать смутные сомнения, что это именно iPad 2, толостовата рамка немного Спасибо. Передам эти сомнения дизайнеру. Пусть проверит.