Дима Паутов

К сожалению, при расчёте размеров псевдоэлемента ::selection учитывается зашитое в шрифт соотношение высоты линии к размеру шрифта.

Вы можете менять line-height сколько душе угодно, но для этого псевдоэлемента ничего не изменится. Доступны лишь правила color, background-color, в большинстве современных браузеров text-shadow.

Видимо, пока нет единого мнения относительно выделенного фрагмента, ибо даже в спецификации раздел 7.3 оставлен пустым

This section intentionally left blank. (This section previously defined a ::selection pseudo-element.)

В моду вошли повальная неграмотность и нежелание читать спецификации.
Какие на экранах могут быть pt? Неужели неочевидна разница между абсолютными (читай физическими) и абстрактными единицами?

Всегда использую px, был опыт с em, но не реализовал надежд.

Каких ещё надежд?
Почему нужно задавать в em, а не px?

Сейчас все чаще стали дизайны в pt приходить.

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

А вот типа веб-дизайнеры смогли. Ну и вот результат — шрифт в вебе, оказывается, в pt. Потрясающе. Это ничего, что pt (inch, pc, cm, mm) используются для печати?

Складывается впечатление, что pt из-за разнообразия экранов становится более правильным выбором.

Глупость. Без комментариев.

Т.е если что-то серьезное, то лучше использовать em.

Почему нужно задавать в em, а не px?

Так-же про % не забывайте.

А есть отличие от em?

Воспользуйтесь slice
jsfiddle.net/wx3x4c8j

Код строчки свойства выше 831 чем у свойства на 707 строчки по этому переписывает

В спецификации есть пример с применением section внутри article. И нигде не сказано, что section выше по приоритету.

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

Однако, в той же спецификации сказано, что внутри article не может быть main, что логично, ведь article по сути — смысловые единицы. А вот у section такого ограничения нет, и рамки применения такого элемента широки. Возможно, вы сделали вывод на основании этого? Если так, то напрасно — будучи вложенным в article, section будет подчиняться правилам для контента article (не содержать main), и не более того.

А в остальном внутри обоих элементов допускается flow content.

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

С точки зрения производительности труда - объединение классов для элемента и возникновение множественного дублирования стилей увеличивают издержки на поддержку. Для решения проблем с дублированием можно применить препроцессоры стилей.

С точки зрения здравого смысла следует соблюдать баланс. Скажем скрытие элементов удобно делать через добавление/удаление класса с элемента. В этом случае класс будет иметь только одно css свойство, но зато будет очень удобно скрывать элементы из JS например. С другой стороны, наличие таких вещей как классы хелперы (pull-left/pull-right/clearfix), которые можно в любой момент применить к элементу и не менять стили это удобно, но становится сложнее поддерживать верстку, это сказывается на производительности и т.д. В этом ключе стоит это все заключать в более специфичные классы для конкретных элементов. Хотя тут есть масса случаев когда можно и так жить.

Можно выносить какие-то общие вещи в базовый класс и добавлять специфичные стили по мере необходимости при помощи дополнительных стилей. Например в случае с кнопками удобно иметь класс .btn и несколько классов определяющих их размер и цвет, типа .btn-small, .btn-large, .btn-orange и т.д. Но в любом случае вы должны руководствоваться здравым смыслом.

Ну и да, используйте препроцессоры стилей. И да, никогда не используйте инлайн-стили для верстки.