waldeh

Обо всем этом прекрасно рассказано в спецификации CSS 2 от 1998 года.
Подобным «статьям» место в видеоуроках «Как стать верстальщиком за 7 дней», а не на хабре.

На видео не весь доклад, а только половина. Интересующая часть в запись не вошла, видимо. В любом случае, спасибо за ссылку.

Да ладно вам, на такие конференции приезжают за ценной информацией, а не за халявными айпэдами.

Конференция — однозначно на очень высоком уровне.
Однако, задавал один или два вопроса в твиттер. И комрад мой задавал. И не получили мы ответов. Всё же, видимо, процессы, связанные с вопросами в твиттер, подкачали.

Негибкость конфига заключается в необходимости привязки к конкретным классам (id не используем). Это не тот уровень абстракции, который хотелось бы достичь. В моём понимании, если мы ставим задачу тестировать «картинку», то не должны завязываться на коде. Мне кажется более правильным подход в установке уровней (как направляющие в фотошопе), нежели метрики конкретных элементов (сегодня элемент такой, завтра другой).
Возможно, я что-то недопонимаю или толкую неверно. Но я не хотел бы спорить на сей счёт, пока изучаю возможность применения селениума для данной проблемы, иначе у нас получится разговор слепого с глухим )

Спасибо за совет. Селениум упустили из виду… Сейчас изучаем применимость к решению наших конкретных задач. Пока останавливает негибкость конфига. Мой гипотетический метод абстрагирован от разметки, что нас и привлекает.

Решение с маркерами более отказоустойчивое: классы могут заменяться JS сценариями. Кроме того, перед выкладкой, как показала практика нашего проекта, удалять комментарии вполне безопасно. Удалять же регуляркой классы я бы не стал, как потенциально багоопасный момент (вырезания лишнего), который мы не контролируем. Да, я понимаю, что можно написать правильную регулярку, но тут в самом методе модержится погрешность.
Что касается необходимости вычисления ширины (маркеры — суть определение высоты, только в неявном виде), теоретически это может быть полезно. На практике, надо проверять.

Извините, что вопросом на вопрос, но в нём и содержится ответ:
А вы пробовали решить поставленную задачу с помощью winrunner и других продуктов тестирования GUI?

*Для реальных проектов не всегда годится.

Это значит лишь, что ваша работа не подразумевает идентичного отображения во всех популярных браузерах, видимо, потому что ваш клиент не требует этого. Но клиенты бывают разные, и, скажем, приходит к вам мобильный оператор, и слушать он не будет ничего о gracefull degradation. На что имеет полное право. И как профессионал, вы обязаны удовлетворить его требования.
Я сам с удовольствием использую техники и методы, которые возможны с помощью CSS3, когда задача позволяет такое решение.
Что касается конкретно всех этих вкусностей, было бы неплохо просто описать, какие есть варианты решения задачи для ие7-8, тогда метод можно считать целостным.

Так и представляю, приходит верстальщик с менеджером к клиенту, и говорит: «Такие-то браузеры мы поддерживать не будем, потому что они старые». Извините, господа, это смешно. Заговнокодить по-быстрому на фрилансе 10 страниц — это одно, а когда вы работаете над проектом, которым пользуется миллион человек и столько же он приносит прибыли — все эти техники стоят по рублю за пучок. И если в таком случае разработчик говорит, что он этого делать не будет — он не профессионал, и гнать его нужно в шею. Если ты специалист — будь добр, сделай то, что от тебя требуют в наилучшем виде, чтобы качественно решить поставленную задачу.

Согласен, но только если речь идёт о своём хоумпейдже для кота. Для реальных проектов не годится. И что есть мелочь?..

Там, где живёт и работает автор, Opera — это мобильный браузер ).

К сожалению, пока есть ИЕ7-8, все эти замечательные красоты остаются лишь демонстрацией возможностей css3.

Нет. Например, когда в массиве текста вы выделяете опорные слова. Тогда при беглом просмотре страницы взгляд читателя цепляется за эти слова, что очень удобно, чтобы понять о чём текст. Но при этом, в контексте эти слова могут не иметь повышенной значимости. Лиды, опять же…
Примеров применения масса, нужно только разобраться ;)

Значит плохо слушали ). Яркий пример вредных советов в действии — Tinymce (под кнопочками b и i). Что уж говорить о простых смертных

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

Во-первых, смотрим доктайп Яндекса <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
А ещё на главной яндекса для раскладки используются таблицы. Потому что яндекс поддерживает ie5.x, а следовательно техники и методы они выбирают для наилучшего решения поставленной задачи.

Извините за казус выше.
Что касается элемента , в использовании старых элементов, на мой взгляд, есть определённый профит: разработчикам не нужно осваивать новые элементы, равно как и пользовательским агентам, что очень хорошо сочетается с идеей обратной совместимости.

Не совсем. В спецификации HTML 4.01 они рассматриваются как "font style elements". Следовательно, о явной семантике речи не идёт.
Что касается элемента , в использовании старых элементов, на мой взгляд, есть определённый профит: разработчикам не нужно осваивать новые элементы, равно как и пользовательским агентам, что очень хорошо сочетается с идеей обратной совместимости.