s0rr0w

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

Что Опера, что ИЕ, показывают отсебятину. The effect of 'position:relative' on table-row-group, table-header-group, table-footer-group, table-row, table-column-group, table-column, table-cell, and table-caption elements is undefined

Написание готовых скриптов для лосей в JS - 100$ в час.

ИЕ не поймет. А так, можно

Хах.. тема такая, что за несколько статей не расскажешь. Большие проекты верстаются следующим образом. 1. Ищем закономерности. Есть куча похожих блоков, стилей, и так далее. Выделяем их в отдельные логические структуры. 2. Составляем логику построения CSS и HTML-кода. Если в одном месте можно описать дизайн, например двумя блоками <div class="someBlock"> <div class="someBox"> Some content </div> </div> а во втором достаточно одного <div class="otherBlock"> Other content </div> То все равно лучше добавлять еще одну пустую структуру, чтобы была идентичность кода. <div class="otherBlock"> <div class="otherBox"> Other content </div> </div> Как видно, я использую логическую вложенность block>box и повторяю ее. Если в блоке несколько боксов, так и делаем <div class="otherBlock"> <div class="otherBox"> Other content1 </div> <div class="otherBox"> Other content2 </div> </div> Если у блока есть заголовок, то лучше перенести логику внутрь бокса, разделив все на уровни <div class="myBlock"> <div class="myBox"> <h4 class="myBoxHeader"> My box header </h4> <div class="myBoxContent"> My box content </div> </div> </div> Такую структуру легко понимать, легко программировать, легко описывать в CSS Далее, модификаторы. Лучше 5 модификаторов, чем 5 различных видов блоков. <div class="myBlock newsBlock"> <div class="myBox"> <ul class="myList newsList"> <li>News Item</li> </ul> </div> </div> Если убрать модификатор newsList, а надеяться только на newsBlock, то в итоге можно напороться на проблемы со специфичностью и тоннами непонятного CSS А так у нас есть конкретный список, конкретный модификатор списка, и если этот список куда-то перенести, то он останется все тем же списком. Есть еще одна тактика, которая тоже дает выигрыш. Это тактика первого использования. Например, у вас есть список новостей. Но очень похожий список - список статей. Можно делать список новостей базовым, а список статей - модификатором. Что это дает? Это дает точное указание, откуда растут ноги у списка статей, и что он основывается на списке новостей, но только с видоизменениями. И если меняется базис (список новостей), то всегда понятно, какой блок нужно проверить дополнительно, чтобы не поломать ничего. Этот вариант проще всего выискивать при помощи того же grep. Модификаторы лучше всего делать уникальными. Если у вас красным цветом выделяется важная новость, сообщение об ошибке или еще что-то, то лучше всего сделать три, пять, десять модификаторов, чтобы потом не думать, почему у вас на сообщении об ошибке стоит class="important", а не class="error". Это все очень сильно сбивает с толку при модификации кода, особенно через месяца три после сдачи. 3. Повторная модификация кода (рефакторинг). Если у вас что-то получилось лучше и логичнее, чем в предыдущие разы, то лучше все старые участки кода переделать, а не оставлять зоопарк из десятков различных подходов и способов. Это никак не поможет разобраться в коде в будущем, и никак не облегчит поиск ошибок. А ошибки имеют свойство накапливаться и вылазить боком в самый неподходящий момент. 4. Не бояться длинных и понятных имен классов. Пока, думаю, хватит.

Поместите руль в контейнер с белым листом. Руль абсолютно спозиционируйте. При помощи margin-top: -y; margin-left: -x; сделайте отрицательное смещение. И перестаньте up'ать, если возможность есть ответить, то вам обязательно ответят.

Интернет большой. В нем все есть.

a:visited {color: perple;} Знаю цвет purple, а perple - нет И ul.navbar a гораздо сильнее a:hover, поэтому поведение нормальных браузеров гораздо понятнее, чем отсебятина у IE

Карта ссылок не может привязываться к конкретному кадру.

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

По поводу форм. А зачем ее нужно генерировать при помощи JS, если ее можно генерировать на стороне сервера? На странице генерируется одна огромная форма, и включается/выключается ее контент по мере заполнения. Это же интранет, размер страницы почти не играет роли. Если вы сделали так, что страница генерируется, а потом еще и аяксом что-то дозапрашивается, значит вы сделали идеологически неправильно. Любую задачу можно видоизменить так, что ее большая часть будет переложена на ту или иную технологию. Простой пример. Есть раздел статистики, например. В нем есть несколько блоков: календарь, типы статистических отчетов, контент отчета. Календарь и контент отчета делается перезагружаемым, потому что есть начало и конец работы пользователя, а значит и нужно показывать на календаре его период работы. Нам нужно три различных контентных страницы - статическая заготовка для страницы статистики, календарь и отчет. Если перенести на сторону клиента вставку календаря и контента сразу, то зачем вообще разделять эту страницу на три части? Ведь такой способ ничем не отличается от простой статической генерации страницы, ajax лишь усложняет понимание самой технологии сборки, и в будущем будет тяжелее разбираться. Если загружать статику, потом делать динамические запросы в нужные контейнеры, то это будет намного выгоднее, так как легче будет модифицировать код и будет меньше всяких функций. Приведу пример. function loadCalendar( options ) { // загрузка календаря в контейнер calendarContainer } function loadStatReport( filter ) { // загрузка отчета в контейнер statReportContainer } И если в коде мне нужно будет перезагрузить календарь, то достаточно будет вызвать функцию loadCalendar, и нужное действие будет выполнено, независимо от того, в каком месте вызывалась функция. Загрузилась статическая страница отчетов, вызвали две функции, и дальше пользователь будет сам управлять дальнейшим функционалом и запрашивать данные при помощи двух функций. А программист будет точно знать, что есть всего две функции, при помощи чего генерируется контент.

Не вижу особо плюсов в данном способе вообще. Почему? Все очень просто. Давайте разберем не способы вставки контента, а сам факт вставки контента. У меня возникает резонный вопрос, зачем контент добавлять при помощи JS, если это может сделать тот же php? В пхп в тысячи раз больше вариантов работы с текстом, и почти все из них гораздо удобнее, чем работа на уровне JS. Хорошо, мы придумали задачу, которая требует вставки кода именно через JS. Тогда возникает второй резонный вопрос, а почему бы нам не сделать эту вставку уже после того, как вся страница загружена? Почему вставку нужно делать незамедлительно при загрузке страницы? Чтобы избавиться от идентификаторов? Ну так страница совершенно без идентификаторов тоже не решение. Гораздо проще, быстрее и дешевле использовать идентификатор, чем городить огород из скриптов поиска нужных контейнеров для контента. Идентификатор позволит повторно сделать запрос, эмулятор document.write - нет. Однако есть варианты, когда идентификаторы зло - например для контейнеров перечисляемых данных. Но это уже не относится к данному коду. Так что этот способ носит чисто академический интерес, реальное же применение его весьма сомнительно.

Бан.

Матчасть не пробовали учить? Книжки умные читать? Иначе вы замучаете тут всех на форуме вопросами из детского сада.

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

1. Разбить на две ячейки 2. Выровнять по верху следующей ячейки, абсолютно спозиционировать и переместить при помощи отрицательного марджина наверх 3. Выравнивать контент по низу, верхние блоки спозиционировать абсолютно 4. Использовать JS 5. Забить на это, так как это противоречит сути HTML

Это похоже на VBScript? echo и Echo - два разных слова

Монитору поставить 24 или 32 битный цвет, а не 16.

png24

В FF пока да. Пока не будет ясно, баг это или фича.

Очередной баг в спеке, или в понимании спеки. Как известно, margin collapsing бывает только у блоков. Но таблицы к ним не относятся. Однако таблица все равно генерирует анонимный блок, который и будет выступать тем блоком, с которым будет коллапсировать марджин. Однако на марджин у таблицы не распространяется действие коллапсирования, поэтому анонимный блок не будет коллапсировать с таблицей, а значит и не будет коллапсировать с другими блоками. Получается, что FF может правильно рендерить, остальные - нет.

Это не ошибка, а предупреждение.

О, это ж другое дело. Фольга подошла как раз. #cv-d-l и #cv-d-r абсолютно спозиционированы и перекрывают ваш текст. Решение 1. Лучше всего переверстать это по-другому 2. Указанным элементам z-index: 0, #content поставить position: relative; z-index: 1. Аналогично сделать с футером.

Вот скажите, сколько вы сайтов вы перешерстили в качестве поиска решения? Какие решения вам показались понятными? Какие проблемы вы видите с данными решениями?

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