Проблема — безусловно, никто и не спорит. Но homm-овское «не имеет ничего общего с реальным миром» — очевидное трололо, поскольку вполне себе применяется же. Ну да не я тебе (вам) это должен рассказывать :3
Существуют частные решения, самый тупой вариант — это line-height в px и считать (на сервере, например) высоту строки или margin изображению. Или можно масштабировать изображения в CSS в удобной метрике (так иногда делают в т.ч. в @media-правилах для мелких экранов, видел пару раз). Или сделать обтекание текстом, например, если формат подразумевает. Нужно смотреть.
В случае же с line-height в безразмерных единицах — я не уверен, что решение в принципе существует (костыли на js, но это не решение, это именно костыли).
P.S. а блог кто будет вести? На RSS-фиде уже мох растет, с северной стороны :3
Мы живем в каких-то разных мирах. В том реальном мире, из которого я пишу это сообщение, понятие вертикального ритма в типографике появилось задолго до компьютерных сетей, а проблема с выставлением высоты изображения, кратной высоте строки, решается довольно просто.
Да, уточню на всякий случай (возможно, это не бросается в глаза) — в вашем примере #dimensionless h1 попадает в вертикальный ритм только при условии, что размер шрифта заголовка делится на базовый размер шрифта.
Да. Как я и писал выше, #em h1 унаследовал вычисленное значение (1.2em относительно базового размера шрифта) у контейнера. Спасибо, что подтвердили примером мой комментарий, мне было лень.
Это очень зависит от остальной верстки. Если дизайнер нарисовал блок попиксельно и очень дорожит этим, ничего не остается, кроме как задать размер шрифта в px.
Обычно я задаю базовый размер (body font-size) в pt, производные в процентах и/или pt, line-height и отступы для вертикального ритма в em.
По факту можно хоть в попугаях считать, главное делать это правильно и консистентно.
Многие люди, и я вхожу в их число, готовы платить (и платят) за экономию своего времени, удобство и качество предоставления услуг. Именно поэтому магазин видеоигр Steam пользуется бешеной популярностью: они дают пользователю возможность купить то, что он хочет, тогда, когда он хочет, и играть на любом компьютере без надоедливой защиты от копирования и ввода бесконечных серийников к каждой программе.
Steam «выстрелил», потому что он проще и удобнее, чем торренты, и мне не стыдно за мою коллекцию игрушек.
Так где же этот прекрасный видеомагазин мечты, в котором я смогу купить показываемый прямо сейчас онгоинг, указать, что звуковая дорожка должна быть на японском, титры на английском, и в два клика настроить скачивание уже вышедших и всех новых (по мере их появления) серий ко мне на компьютер? А нет его.
И речь, заметьте, не идет о завышенной стоимости — такой услуги в природе вообще нет. А торренты почему-то предоставляют именно эту самую штуку, которую я описал выше (ну, разве что новые серии нужно самому находить).
Не лучше ли использовать именно Markdown? Добавить в него поддержку тегов для видео и других нестандартных элементов несложно. Выигрыш относительно велосипедостроения в том, что
Markdown применяют различные сайты в интернете помимо вашего проекта, какой-то части редакторского состава он будет уже знаком по Stack Overflow и Github, что заметно сокращает процесс обучения;
(следует из п. 1) оператор, которому не нужно запоминать новую разметку для каждого сайта, на который он пишет пост или комментарий, реже ошибается;
реализация Markdown существует для многих языков программирования, и когда следующую версию сайта будет решено разрабатывать на Python или Ruby, не придется плясать с народными музыкальными инструментами вокруг существующего контента;
Отложенное освобождение ресурсов хорошее. panic и recover как-то удивительно сделали, я не совсем понимаю преимущества относительно работающей во многих языках идиомы try / catch.
Относительно проблематики monkey patching-а — мне тоже кажется, что это очень непрозрачно. Пришел в проект новый разработчик, смотрит на contrib.auth.models.User, а у него first_name нету. Мне бы не пришло в голову искать причину этому в manage.py.
Существуют частные решения, самый тупой вариант — это line-height в px и считать (на сервере, например) высоту строки или margin изображению. Или можно масштабировать изображения в CSS в удобной метрике (так иногда делают в т.ч. в @media-правилах для мелких экранов, видел пару раз). Или сделать обтекание текстом, например, если формат подразумевает. Нужно смотреть.
В случае же с line-height в безразмерных единицах — я не уверен, что решение в принципе существует (костыли на js, но это не решение, это именно костыли).
P.S. а блог кто будет вести? На RSS-фиде уже мох растет, с северной стороны :3
Как я уже писал выше, совершенно неважно, как задавать величину — нужно, чтобы верстальщик понимал, почему он так делает и что получится в результате.
Обычно я задаю базовый размер (body font-size) в pt, производные в процентах и/или pt, line-height и отступы для вертикального ритма в em.
По факту можно хоть в попугаях считать, главное делать это правильно и консистентно.
Многие люди, и я вхожу в их число, готовы платить (и платят) за экономию своего времени, удобство и качество предоставления услуг. Именно поэтому магазин видеоигр Steam пользуется бешеной популярностью: они дают пользователю возможность купить то, что он хочет, тогда, когда он хочет, и играть на любом компьютере без надоедливой защиты от копирования и ввода бесконечных серийников к каждой программе.
Steam «выстрелил», потому что он проще и удобнее, чем торренты, и мне не стыдно за мою коллекцию игрушек.
Так где же этот прекрасный видеомагазин мечты, в котором я смогу купить показываемый прямо сейчас онгоинг, указать, что звуковая дорожка должна быть на японском, титры на английском, и в два клика настроить скачивание уже вышедших и всех новых (по мере их появления) серий ко мне на компьютер? А нет его.
И речь, заметьте, не идет о завышенной стоимости — такой услуги в природе вообще нет. А торренты почему-то предоставляют именно эту самую штуку, которую я описал выше (ну, разве что новые серии нужно самому находить).
Если бы еще девочки в HR-отделе знали, что такое QR-код.