SelenIT

Навскидку — на информационных сайтах минималистичного дизайна, заточенных под максимальную доступность контента в любых погодных условиях, хоть в IE6 (который всё не хочет вымирать в Китае, Корее и Индии. Где важнее аккуратность дизайна, а IE6 поддерживается по остаточному принципу — там, имхо, пиксели рулят однозначно. Насчет точности — спорно. Как раз IE7 и ниже (про 8-й сходу не скажу, проверять надо) эти самые тысячные доли игнорят. А вот сотые доли процентов (т.е. десятитысячные em-а), если ничего не путаю, там прокатывали. К тому же при выводе на экран дробные em-ы в любом случае округляются до целых пикселей (только Сафари умудряется отображать разницу за счет антиалиасинга), причем иногда "через раз" (отчего часть строк может оказаться высотой, скажем, 20px, а часть — 21px, рвется вертикальный ритм...). Для принт-версий как раз часто советуют абсолютные единицы (сантиметры/миллиметры/пункты). Но сам с ними редко сталкиваюсь, поэтому своей позиции пока не выработал. Главная сила em-ов — в возможности делать размеры блоков (включая отступы, радиусы многострадальных круголков с тенями и т.п.) соразмерными тексту. Последнее время подумываю над парадоксальным вариантом — шрифты в пикселях (с возможностью подгонять их под размер окна через @media), а именно отступы и украшательства в em-ах . Глубокой вложенности (бич пересчета em-ов в пиксели при наследовании при таком подходе заведомо не будет, графика для таких украшательств сейчас практически не нужна, зато дизайн всегда будет выглядеть цельно и органично. Вот только подходящего для этого макета что-то никак под руку не попадает...

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

Насколько я понимаю, сейчас \r практически не нужен, это пережиток эпохи механических устройств вывода а-ля телетайп. Но по историческим причинам на *nix-системах в качестве символа новой строки закрепился \n, а в виндах — комбинация \r\n. А в классической макоси была вообще одна \r (хорошо хоть эта зверушка вымерла). В браузерах, по-моему, тоже этот разнобой присутствует...

А в чем такая уж проблема фон на линк положить?

Насколько помню, именно так (а в IE еще и традиционный \r перед ним — по крайней мере, раньше было). Кстати, может, чем мучиться с перекидкой из блока в блок и прочим, не проще ли будет задать целевому блоку contenteditable и позволить юзеру писать сразу туда? А то и простейшим готовым wysiwyg-редактором воспользоваться...

Возможно, пригодится http://tanalin.com/articles/css-block-order/ (см. тж. комменты)

В базе и не должны. Экранирование нужно именно для строки запроса, чтобы данные не мешались с управляющими элементами. Идеально (местами аж слишком) тема разжевана здесь (на примере MySQL, но в других СУБД принцип тот же).

Моя задумка была в том, чтобы автоматом, на уровне одного лишь CSS, перегнать адрес картинки из атрибута src в url() фона. Предварительно превратив картинку в по сути обычный пустой блочный элемент с помощью content:'' (и display:block с указанием размеров). Причем только для Оперы, т.к. content для любого элемента (не псевдо-) понимает только она. Но авторы CSS привычно обломали весь кайф... Пардон... можно чуть пояснить, что значит "стили, выставленные для атрибута"? Вообще, насколько я в курсе, attr() умеет читать только атрибуты указанного элемента (и использовать в его же псевдоэлементах), поэтому content:attr(href) для div:after закономерно не работает по причине отсутствия атрибута href у div... или я чего-то важного не понимаю?

Из попадавшихся мне и притом практичных — например, вывод href ссылок в версии для печати: @media print { a:after { content: ' (' attr(href) ') '; } }

Да нет, он-то (attr в смысле) как раз старый... но нарочно его урезали, гады: Т.е. тупо вывести можно, а использовать — фиг. Почему-то CSS мне всё меньше и меньше нравится...

А почему всё-таки не работает url(attr(src))? Буду благодарен за любую наводку!

Так мой пример как раз на неоднородном фоне работает вроде, только с другими ограничениями... разве нет?

Ну какая из меня тяжелая артилерия... Вот максимум, на что меня хватило. Очевидные минусы — требуется задание размеров в CSS и повторное указание пути к картинке там же (фокус с background: url(attr(src)); у меня почему-то не удался). Зато на неоднородном фоне работает К тому же, ЕМНИП, где-то видел слухи, что content для любого элемента собираются из CSS3 убрать и в Опере, соотв-но, прикрыть. Одна надежда, что к тому моменту и исходный баг пофиксят... Но буду рад подтверждениям, что это мне лишь показалось

Типовое решение — "слоеный пирог". Нижний слой — единая подложка с дефолтным состоянием, верхний слой — прозрачная картинка с размеченной на ней <map> кликабельных областей, между ними — абсолютно позиционированные подсвеченные фрагменты. По умолчанию они все скрыты, по наведению на соотв. <area> показываются (можно с красивой анимацией прозрачности. Есть варианты подсветки на canvas, но пока, имхо, это скорее из серии "смотрите, как я еще могу", картинками проще и практичнее.

Вроде таблицы/ячейки не могут лишь быть точкой отсчета для позиционирования (что порой реально бесит, а так абсолютному потомку без разницы, что в его предках числится таблица — он всё равно позиционируется от ближайшего позиционированного предка (или от body, как повезет). Поэтому проблем быть не должно, если только не потребуется позиционировать весь список (тогда нужна дополнительная обертка). Единственный нюанс — ширина, display:table по умолчанию не растягивается на доступное пространство, так что может понадобиться еще width:100% (а при наличии бордеров/паддингов — box-sizing: border-box c нужными префиксами вдобавок). Если ошибаюсь — прошу меня поправить.

1. Да, так. Судя по всему, баг вебкита (достаточно давний). 2. Судя по всему, аналогично . Багом бага убиваем. Возможно, при display:table движок воспринимает строку блоков внутри как "что-то вроде table-cell", в каких-то FF до 3.6, если я ничего не путаю, был похожий баг. 3. Похоже, нет. Letter-spacing, как выясняется, по большому счету тут вообще не при делах. за межсловные (и, соответственно, межэлементные) пробелы отвечает word-spacing, но он, увы, не фурычит в вебкитах (см. п. 1). Во всём остальном, включая старые IE, похоже, работает. А для вебкитов есть два выхода — либо (inline-)table для контейнера (плюс 100% ширины, если надо), либо этот самый letter-spacing (впридачу к word-spacing-у)... В общем, резюмируя: word-spacing: -.25em работает во всех браузерах (с подавляющим большинством шрифтов) для display:inline и во всех, кроме вебкитов — для display:inline-block (но есть лазейки, как вебкитов "укротить").

Хм. Судя по спеке CSS 2.1, похоже, работает эта оговорка: Похоже, что браузеры "более-менее договорились" не сжимать буквы теснее, чем вплотную. Надо поэкспериментировать, если все актуальные браузеры в этом едины, то можно считать letter-spacing:-1em полностью унивесальной убиралкой межсловных пробелов для любых разумных шрифтов, и пользоваться этим (несмотря на отсутствие формальных гарантий этого в стандарте). Огромное спасибо за наблюдение! В CSS3 для letter-spacing есть еще многообещающий вариант — проценты от стандартной ширины пробела, по идее, -100% даст нужный эффект. Но вряд ли это пригодится в ближайшем будущем Упд.: Ага, договорились, как же. Вебкитные преспокойненько плющат буквы в соответствии с написанным (задние "съедают" передних). Попутно выяснил, что Опере-бяке letter-spacing'а не хватает — ей непременно word-spacing подавай. А word-spacing, в этом примере, прекрасно работает и для вебкитных... но, увы, не для инлайн-блоков . Правда, какое-никакое лекарство от этой беды (извратноватое, но всё же) тоже нагуглилось по-быстрому. Display:table для контейнера, ну надо же... нет, определенно и без IE6 не станет вёрстка скучным занятием, ох, не станет! Упд. 2: Вроде, вот так более-менее кроссбраузерно. Но как-то сс... боязно Упд. 3: И опять мимо — IE7, оказывается, тоже сплющивает... Похоже, лучше "минус четверти em-а" легкого решения и не найти.

Число "подозрительно смахивает" на 215-1 — максимальное двухбайтное целое со знаком. На ограничения FAT32 вроде непохоже (судя по официальной доке и ответам здесь), может, где-то при генерации имени файла как раз отрицательные числа или недопустимые в именах символы вылезли?

Ясно. Тоже логично — в первом случае, с точки зрения xml-веллформности, вложенность нарушена, а во втором нет. А вот для HTML-парсера и то, и другое — незакрытые теги...

В вебкитных word-spacing не пашет (который был бы логичнее), а letter-spacing вроде справляется (по моим экспериментам, как минимум под виндой). Минус четверть кегля — при разумных значениях этого самого кегля, с учетом округления, выходит довольно универсально, из популярных шрифтов не подходит разве что для Верданы (насколько "моя память не спит с другим"). Но в целом согласен — все эти отрицательные отступы, скукоживания интервалов и т.п. — костыли, а решение одно — физически убрать межтеговые пробелы из кода...

Как вариант, letter-spacing:-.25em для контейнера, как раз схлопнет стандартные пробелы в большинстве шрифтов. А вообще ради одного места — имхо, не катастрофа и вручную пробел между </li><li> по-честному убрать...

/тоже решил прекратить неконструктивный диалог, на который повелся было

Сорри, фразу я понял так, что вы проверяли подобный код FF-овским аддоном в режиме W3C-валидатора, и он отметил это как ошибку. Вот я и подумал, что, вероятно, теперь там по дефолту включена галка "учитывать тип" или что-то в этом роде. Потому что, когда я последний раз пользовался аддоном, эта проблема в нем была, как и в онлайновом валидаторе сейчас. А вот в режиме Tidy такие ошибки и раньше легко ловились...

Только что проверил в онлайновом валидаторе: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>111</title> <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" /> </head> <body> <!-- АГА!!! --><div/> </body> </html> результат — "This document was successfully checked as...". Что, формально, справедливо (XHTML — это XML, а там <div></div> и <div/> — одно и то же), но в реальной жизни (при отдаче существующим браузерам в виде text/html, как обычно и бывает) не утешает. Буду благодарен за ссылку на методику валидации, при которой это ловится...

Есть прием, когда соприкасающиеся границы (правая у левого блока и левая у правого, соотв-но) делаются визуально одинаковыми и накладываются друг на друга (с помощью чего-то типа margin-right: -1px для одной из колонок). Тогда визуально получается одна граница, тянущаяся по высоте самой высокой колонки, независимо от того, которая из них окажется таковой.