Я вот разрабатываю достаточно сложные интерфейсы, а теги footer, article, aside и т.п. можно эффективно использовать, разве что, при верстке блога или новостного сайта.
Мне не очень понятно какую семантическую нагрузку несет, например, тег <footer>. Для меня это позиция на странице, а семантика в моём понимании не имеет ничего общего с позиционированием.
Про «модные css3 фишки» я в курсе (border-radius к ним бы точно не относил), но вот селекторы… как по мне это экономия на спичках. Особенно на мобильных сайтах, там DOM как правило небольшой.
Подобные статьи летают из блога в блог, но существуют тесты которые подтверждают пользу от такой оптимизации для современных браузеров? Речь не об искусственных тестах на абсурдно сложном DOM и тысяче селекторов по атрибуту.
На практике разницу в скорости будет нереально обнаружить. Что бы отловить разницу нужно будет создать тестовый случай с большим и сложным DOM, а также с огромным количеством сложных селекторов.
Кстати, мне не удалось найти примеров таких тестов для более-менее свежих браузеров, единственный который я нашел 2008-го года.
То ничего страшного не произойдёт. В теории рендер будет медленнее, но на практике, заметно это станет только при огромном количество таких селекторов.
Допустим высота дочернего элемента 100px, а верхнее поле 80%.
Имеем уравнение x=0.8x+100
Получаем x=500.
Высота родителя 500px, дочернего элемента 100px, padding-top 400px.
Кто-то знает почему?
На stackoverflow только догадки stackoverflow.com/questions/11003911/why-are-margin-padding-percentages-in-css-always-calculated-against-width
<footer>. Для меня это позиция на странице, а семантика в моём понимании не имеет ничего общего с позиционированием.Кстати, мне не удалось найти примеров таких тестов для более-менее свежих браузеров, единственный который я нашел 2008-го года.
То ничего страшного не произойдёт. В теории рендер будет медленнее, но на практике, заметно это станет только при огромном количество таких селекторов.