SelenIT

Если задать table-layout:fixed, то не надо. А в чем заморачивание, если главная проблема блоков — их взаимное расположение — таблицей уже решено?

Из спортивного интереса сделать можно — отдавать страницы как application/xhtml+xml (ну или text/xml на мегакрайний случай). Но незачем. А добавлять разметку ради отступов — вообще отвратительная практика. Еще бы двойной <br> добавили...

Спасибо, не надо Что не мешало этому изначально неправильному браузеру быть объективно лучшим и самым инновационным чуть ли не пять лет. Если бы W3C не отмораживали уши назло маме упрямствовали в своей противоестественной боксовой модели (при том, что на момент принятия CSS 1 во всех браузерах был реализован border-box!), бойкоте VML и т.п., еще неизвестно, каким был бы веб уже пару лет назад...

На Хабре опубликовали еще один забавный вариант решения. К сожалению, в половине современных браузеров не фурычит (и, видимо, не будет). Но в комментах есть несколько альтернативных идей для частных случаев.

1) "Идейно" да (применительно к шрифтам), на практике бывают различия при масштабировании (особенно в старых браузерах). 2) Подразумевается масштабирование страницы при включенной галке "Zoom text only" (в меню "View — Zoom") в FF либо "View — Text size" в IE. Для полностраничного зума все единицы равнозначны.

Боюсь, для современных браузеров — только менять ширину контейнера для разных диапазонов ширины окна через media queries. Рецепты Rikani не работают начиная уже с IE8 и FF3.

Неважно, каков сам элемент, важно, какова его модель контента. У абзаца модель контента — (%inline;)* — от 0 до бесконечности инлайновых элементов или простого текста (#PCDATA — отпарсенные символьные данные). Любой CSS применяется к уже отпарсенной DOM. И на саму DOM никак повлиять не может, может лишь изменить ее отображение. А исправление ошибок недопустимой, в плане модели контента, вложенности тегов происходит в процессе самого парсинга, гораздо раньше. Так что повлиять на модель контента CSS не может физически, даже если бы очень захотел.

Вот, набросал на скорую руку: http://jsfiddle.net/Ezav4/5/

Даты с некорректными параметрами автоматически переводятся в нормальные. Например, 32 декабря автоматом превращается в 1 января следующего года, ну а 0-е число любого месяца — соотв-но, в последнее число предыдущего. Кроме прочего, этим можно пользоваться для валидации даты, не заводя массива констант: если дату распарсить, подставить части в new Date() и перевести в оригинальный формат, для правильной даты результат должен совпасть с оригиналом, а если не совпал — значит, дата недопустимая.

Это условность подсчета. Я считаю так: 12 полных месяцев (с марта '12 по февраль '13) + 1 марта '13 (конечная дата у меня идет включительно, т.к. между соседними днями разница 1 день) + 28 и 29 февраля '12. Вот три дня и набегает...

При клике по ссылке страница перегружается, выделение теряется. А на второй странице ссылки ведут на внутренние якоря, поэтому выделение остается.

.mytable { border: #353535 solid 2px; border-collapse: collapse; width: 95%; margin: auto; } .mytable td { border: #fff solid 1px; padding: 0; } не решает? И всевозможные cellpadding="0" cellspacing="0" border="2" width="95%" align="center" — пора на свалку, стилями проще и красивее.

А вот мой вариант. Похоже, алгоритм был еще проще (и логичнее), чем я написал выше...

Может быть неочевидно, что "владельцем" и "пользователем" файлов выступают программы. Я сам через это прошел

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

До кучи, если растяжка на всю ширину не нужна — display:table

Пользователи вообще ни при чем, они общаются не с файлами, а с ответами сервера, связь между ними очень косвенная. С файлами работают процессы операционной системы (программы). Каждый процесс выполняется от имени определенного условного "пользователя". Например, если у вас право на запись в каталог сайта есть только у владельца каталога и этим владельцем является "пользователь" процесса Apache (что вполне достаточно для работы внешней части сайта и веб-админки), будьте готовы к тому, что вы не сможете ничего закачивать в него по FTP, т.к. у FTP-сервера "пользователь" другой.

Общая идея примерно такая (Y0, m0, d0 и Y1, m1, d1 — год, месяц и день начальной и конечной даты, соотв-но, конечная дата позже начальной): 1) Грубо прикидываем разницу лет: dY = Y1 - Y2 2) Если m0 > m1 или (m0 == m1 и d0 > d1), то уменьшаем dY на 1 год, увеличиваем m1 на 12; 3) Прикидываем разницу месяцев сверх разницы лет: dm = m1 - m2 4) Если d0 > d1, то уменьшаем dm на 1 месяц, увеличиваем d1 на число дней в месяце m0 (определяется как "0-й день следующего месяца"); 5) Определяем разницу дней сверх разницы лет и месяцев: dd = d1 - d0. 6) Общее кол-во месяцев между датами: dM = dm + dY * 12 7) Общее кол-во дней между датами: а вот тут, имхо, вполне можно взять разницу таймстемпов по UTC да поделить на 86.4 миллиона миллисекунд

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

Должен поддерживать, вообще-то. Нельзя ли уточнить задачу, желательно с минимальным примером?

Какой IE и какой доктайп? С нормальным доктайпом во всех IE от 7-го и выше должно работать без ухищрений.

По-моему не факт, учитывая, что активировать ссылку можно и с клавы. Хотя это и экзотика. У меня тоже

В XML — при условии, что парсить его будет XML-парсер — правильно. Во всех остальных случаях надо думать головой, а не валидатором. Сделайте тестовую страничку с парой-тройкой таких тегов, откройте в браузере, посмотрите итоговую DOM. Попробуйте объяснить результаты Плохо искали.

А по-моему, если выделять на сервере, то фоном или <img>-шками — ноль разницы. Фокус в том, что у нас не одно меню с "перемигивающимися" пунктами, а фактически несколько разных меню по числу разных страниц, которые, конечно, ничто не мешает оформлять по-разному. Если страницы генерятся серверным скриптом, то пусть генерятся сразу с нужным меню. А вот это зря, поисковики обидятся. Хотя бы alt-ы картинкам пропишите...

Хорошая формулировка задачи — половина решения. В вашем случае решение уже прозвучало: на каждой странице задавать текущему пункту особый класс. Удобнее всего делать это серверным скриптом.