авторавторБез серьёзной оговорки, что высота плавающего блока при этом должна быть постоянной, ваше утверждение ошибочно, о чём я и пытаюсь до вас донести.Ничего ошибочного здесь нет, задать несколько постоянных размеров: одинарный, двойной, тройной.. По сетке. Выбираете подходящий размер заранее. Можно его вычислять на сервере.

С практической точки зрения такая методика по-прежнему является неприемлемой и ненадёжной, на практике не применимой. Нельзя полагаться на определённые/вычисленные/заданные значения высоты блока, содержащего текст:

1 . Размер шрифта может меняться на уровне браузера как по инициативе пользователя, так и по инициативе самого браузера (мобильные устройства при наличии/отсутствии определённых правил в CSS)
2 . Ваш серверный код будет зависеть от используемых стилей. Такая архитектура проекта является некорректной.

авторавторРазмещение плавающего блока после основного контента - это не попытка обмана поисковых систем.Именно попытка обмана, если вы пытаетесь показать этот блок наверху. Блок размещается внизу, вы хотите показать его наверху.
Не наверху, а сбоку. Сбоку от основного контента.

Аналогичный пример не обмана поисковых систем: когда формируется таблица и содержимое последней ячейки таблицы на уровне HTML располагается после содержимого первых ячеек, а на экране отображается на одном с ними уровне или даже уровнем выше (когда первые ячейки имеют атрибут rowspan и вертикально выравниваются по центру или по низу)

авторавторБолее того, информация, размещаемая в боковых колонках, у поисковых машин всегда ассоциируется с второстепенным характером данных и размещение её после основных данных на уровне HTML-кода только подтвердит корректность интерпретации поисковой машиной семантики тех или иных блоков данных на странице.
Ну так поместите блок вверху, коли так.
> ...блок не размещается наверху, поскольку имеет второстепенный характер и семантически должен следовать после основных данных.
> ... последовательность отображения контента на экране в целом совпадает с его последовательностью в HTML-коде. Поисковые машины, которые не анализируют стили и не выполняют скриптов, предполагают именно такое соответствие ... и при определении семантики данных ориентируются преимущественно на этот порядок

авторЯ не могу назвать диалог конструктивным, если вы сами себе противоречите. ...логики в ваших рассуждениях не просматривается ни при каком желании.К вопросу о конструктивности: какие именно утвержения, на ваш взгляд, друг другу противоречат ? И какие утверждения, по-вашему, не имеют логики ?
Если какие-либо из моих доводов вам не совсем понятны, готов пояснить более подробно.

авторавтор 1 . Размер шрифта может меняться на уровне браузера как по инициативе пользователя, так и по инициативе самого браузера (мобильные устройства при наличии/отсутствии определённых правил в CSS)Разный размер шрифта точно также задаётся на уровне media queries, сегодня страницы масштабируются браузером не путём изменения шрифтов. Нажмите Ctrl и покрутите колёсиком мышки в браузере. Аргумент приятнутый за уши и не корректный в целом.
1.1 Не знаю, какие media queries вы относите к размеру шрифта (если "viewport", то это не размер шрифта), но выглядит странным ваше утверждение о возможности учёта с помощью медиа-запросов размера шрифта, номинальная величина которого при масштабировании в окне браузера не меняется

1.2 . Независимо от того, каким образом браузер выполняет масштабирование шрифтов и отрендеренного изображения, вы никакими медиа-запросами не сможете учесть число строк, занимаемое блоком. Очевидно, что при увеличении/уменьшении размера текста число строк, им занимаемое, а следовательно, и высота плавающего блока, в общем случае также меняется.

Отсюда делаем вывод, что " без серьёзной оговорки, что высота плавающего блока при этом должна быть постоянной, ваше утверждение ошибочно... "

авторавтор 2 . Ваш серверный код будет зависеть от используемых стилей. Такая архитектура проекта является некорректной.Во-первых, серверный код вообще-то выдаёт эти самые стили, он их собирает, обрабатывает, минимизирует и оптимизирует. Во-вторых, задача и клиентской части и серверной части совместно решать поставленные задачи. Почему вы называете архитектуру, которая используется так или иначе, некорректной?

Ещё раз вернёмся к вашему утверждению: " Ничего ошибочного здесь нет, задать несколько постоянных размеров: одинарный, двойной, тройной.. По сетке. Выбираете подходящий размер заранее. Можно его вычислять на сервере "

Подходящий размер выбрать на сервере мы сможем только тогда, когда будет известен размер шрифта, явно или неявно прописанный в стилях. Т.е. если мы захотим изменить размер шрифта в стилях, то мы должны будем изменить ту часть кода серверной части, которая формирует (вычисляет) высоту плавающего блока. И далее уже эта часть серверного кода сформирует стили для высоты плавающего блока. Получаем цепочку " CSS - серверный код - CSS ". Одно из звеньев (первое или второе) здесь явно лишнее и не укладывается в сколь-нибудь приемлемую архитектуру проекта.

Если же вы предлагаете прописывать размер шрифта на уровне серверных скриптов либо серверными скриптами анализировать размер шрифта, явно или неявно прописанный в стилях, и на его основе дополнять стили вычисленной высотой плавающего блока, то такая логика/архитектура - ещё страшнее...

авторПочитайте про понятие потока в HTML. Плавающий элемент, который обтекается всегда находится выше содержания. Как вы собираетесь "обтекать" элемент, которого ещё нет?
...
Если вы что-то "обтекаете", значит размер обтекаемого элемента должен быть известен. Он может быть известен только в одном случае: если он идёт впереди. Браузер не должен из-за ваших странных и нелогичных пожеланий "метнуться" вниз и рассчитать блок, который он будет обтекать, потому что он не может его рассчитать, пока не будет отрендерены элементы выше в потоке
Преамбула
Плавающий элемент находится выше обтекающего контента только на уровне HTML-кода. Без анализа стилей он является таким же неплавающим контентом, что и основной контент (напомню, что согласно сабжевой задаче, плавающий элемент не является <aside>, <figure> и пр.). И более того, является более значимым, нежели основной контент (без анализа стилей), поскольку располагается перед оным. Поэтому, в контексте сабжевой задачи под плавающим блоком следует понимать тот, который визуально расположен сбоку от основного контента (на что и было указано при постановке сабжевой задачи). Для поисковых машин нет принципиальной разницы, "подлезает" основной контент под этот самый "плавающий" или нет. Гораздо важнее то, что он располагается сбоку. Ну а сбоку могут располагаться не только блоки с [float], но и абсолютно позиционированные блоки, и контент в ячейках таблиц и пр. и пр.

Суть. Посему, размещение такого блока на уровне HTML после основного контента НЕ является обманом поисковых систем (как бы вы ни пытались уйти в сторону, я вынужден вернуть вас к вашему утверждению). Иначе получится, что если на уровне стилей мы ему зададим [float: left] - это будет обман поисковых систем, а если зададим [position: absolute; top: 0; left: 0], то обманом не будет. Очевидно, что это ересь.

авторСколько можно уже? Моё решение, принципиально, нарушает принципы работы с потоком HTML, и не надо ждать от таких решений чудес.
Задание скриптами стиля [position: absolute] " нарушает принципы работы с потоком HTML " ???
Стили определяют способ визуального представления контента на странице. Состав этого контента и его семантику определяет HTML-код (также в незначительной степени на семантику могут влиять и стили - зависит от алгоритмов поисковых машин). Исходное размещение содержимого "плавающего" блока после основного контента - это реализация корректной семантики контента. Размещение скриптами этого блока сбоку от основного контента - реализация представления . Не нужно мешать всё в кучу !

авторавторК вопросу о конструктивности: какие именно утвержения, на ваш взгляд, друг другу противоречат ? И какие утверждения, по-вашему, не имеют логики ?Вы знаете о том, что поисковики могут определять важность контента по его визуальному представлению, но в тоже время не считаете, что вы пытаетесь его обмануть, поместив наверх блок, который находится внизу в потоке. Не "сбоку", как вы выражаетесь, а именно наверх. Нет такого понятия "сбоку" в поток. Поток это элемент идёт друг за другом. Поисковики строят такую же цепочку.
Как я показал выше, контент, визуально размещаемый сбоку от основного контента (не зависимо от того, реализовано ли "подлезание" основного контента под "плавающий" или нет - на семантику это не влияет), на уровне HTML не обязательно должен следовать после или перед основным контентом и не обязательно должен иметь [float]. Расположение на уровне HTML-кода определяется в первую очередь семантикой контента и во вторую очередь удобством визуальной компоновки (т.к. гибкость CSS-стилей не идеальна). Соответственно, размещение блока сбоку от основного контента не обязательно должно реализовываться через механизм плавающих блоков , и наоборот, использование [float] для требуемого представления не определяет семантику этого блока.

P.S . Надеюсь, мне удалось развеять ваши сомнения по поводу логичности и непротиворечивости моих доводов.

авторРазный размер шрифта точно также задаётся на уровне media queries
Ну тогда почитайте про MQ :)
Либо назовите MQ, отвечающие за размер шрифта, либо открыто признайте, что ошиблись, утверждая, что " если вёрстка не резиновая, а адаптивная, как это сейчас модно делать, то решается чисто на стилях, без скриптов, на media queries "

авторавтор 1.2 . Независимо от того, каким образом браузер выполняет масштабирование шрифтов и отрендеренного изображения, вы никакими медиа-запросами не сможете учесть число строк, занимаемое блоком. Очевидно, что при увеличении/уменьшении размера текста число строк, им занимаемое, а следовательно, и высота плавающего блока, в общем случае также меняется.Я и не собирался учитывать число строк медиа-запросами. Я предлагал определить размер блока такой, чтобы он вместил в себя требуемый текст
Невозможно определить высоту блока, достаточную для вмещения некоторого текста, не зная шрифта и числа строк, занимаемое текстом. Число строк меняется в зависимости от объёма текста, ширины и свойств блока, браузерного шрифта по умолчанию, шрифта, задаваемого на уровне стилей, а также от масштаба отображения. Ну а задать высоту с запасом или "на глаз", принимая в расчёт все эти влияния, НЕВОЗМОЖНО. Либо часть текста не поместится в блок, либо в нижней части блока будет пустое пространство, либо вёрстка вообще "слетит" (в зависимости от реализации). Иными словами, предлагать задавать блокам, содержащим произвольный текст, высоту "на глаз" - это одна из худших практик вёрстки (если таковая вообще существует), которая ни в коем случае не может рассматриваться в качестве решения практических задач.

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

Что касается мерцания, то зачем " с помощью тех же скриптов убрать эффект "мерцания" , если это самое мерцание является следствием действий, выполняемых скриптами ? Не лучше ли изначально генерировать такой HTML-код и выполнять скриптами такие действия, которые не приводят к мерцанию ?

авторавторПодходящий размер выбрать на сервере мы сможем только тогда, когда будет известен размер шрифта, явно или неявно прописанный в стилях. Т.е. если мы захотим изменить размер шрифта в стилях, то мы должны будем изменить ту часть кода серверной части, которая формирует (вычисляет) высоту плавающего блока. И далее уже эта часть серверного кода сформирует стили для высоты плавающего блока. Получаем цепочку "CSS - серверный код - CSS". Одно из звеньев (первое или второе) здесь явно лишнее и не укладывается в сколь-нибудь приемлемую архитектуру проекта.Всё верно. Если бы у вас был хоть какой-то боевой опыт вёрстки, вы бы знали, что очень часто стили и текст верстаются совместно... вы уже сами себя раком поставили не только задачей, но и условиями...
Совместно верстаются стили и HTML-код. Тексты извлекаются из БД. Что касается серверного кода, то в адекватных проектах:
а) CSS-значения, прописанные в стилях, не дублируются в серверных скриптах (в данном случае - шрифт, высота строки)
б) серверные скрипты не занимаются парсингом CSS-стилей (в данном случае - извлечением из CSS шрифта, высоты строки и свойств плавающего блока).
Это к вопросу о " раком поставить "

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

Скрипты вас не устраивают. Жёсткая вёрстка по сетке это у вас «плохая архитектура». Что делать будете? Может поменяете профессию?
Вы предложили вариант на скриптах. Я озвучил его недостатки, ограничивающие его реализацию в реальных проектах. Что касается скриптов, то я не против, но при использовании скриптов HTML-вариант должен быть приемлемым (в частности, не должны отсутствовать части основного контента и не должно быть перекрытий/наездов), а по семантике он не должен уступать уровню отображения . И первое, и второе, в частности, в той или иной степени важны для SEO.

Что касается сетки, то вы предлагаете "задавать по сетке" высоту, а не ширину. Ну а высоту блока, содержащего произвольный текст, по сетке не задают . По поводу архитектуры: " CSS-значения, прописанные в стилях, не дублируются в серверных скриптах " и " серверные скрипты не занимаются парсингом CSS-стилей ". Если для вас это ахинея, то вероятно стоит посочувствовать вашим проектам.

авторОпять двадцать пять. Нет никакого «сбоку». И не надо рассказывать как работают поисковые машины, это не более чем ваши чудные домыслы и догадки. Весь SEO называют «чёрной магией» не в шутку, это так и есть, при абсолютном незнании вопроса, начинают рассказывать как оно есть с умным лицом. Ну не серьёзно это.

Да и пофиг даже. Я вам два решения дал, не идеальных во всех отношениях, но вполне рабочих и приемлимых. Объяснил, почему чисто на стилях расположить плавающий блок ниже обтекающего контента разместить нельзя, это не я придумал, как работает движок браузера известно, это не ваши домыслы насчёт поисковиков, это железные правила, описанные в спецификациях.

Нет никакого «сбоку», элементы в HTML идут друг за другом и вложены друг в друга. Флоат заставляет содержимое следующего блока обтекать элемент слева или справа. При чём блок как занимал всё пространство по горизонтали, так и продолжает занимать. Никакого «сбоку» не существует. Не изобретайте пожалуйста.

Ещё раз: на уровне HTML-кода нет понятия "плавающий элемент" . А на уровне представления есть. Так же, как есть понятие "сбоку", "снизу", "сверху". Причём "сборку" блок можно расположить не только с помощью [float], но также и другими способами. И выбор способа расположения блока "сбоку" никоим образом не определяет его семантику. Семантику определяет HTML-код

Соответственно, ваши попытки доказать, что:
а) если на уровне представления блок располагается "сбоку", то на уровне HTML-кода этот блок должен располагаться вверху
б) если на уровне представления блок располагается "сбоку", но на уровне HTML-кода этот блок расположен внизу, то это попытка обмана поисковых систем
Оба эти утверждения являются ошибочными .

авторРазмещение блока ДЛЯ ПОИСКОВИКОВ внизу, а ДЛЯ ЛЮДЕЙ вверху — это самый настоящий обман. Если вы не дружите с логикой, у меня с ней всё в порядке.

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

Для классических поисковиков (уровень HTML) это означает, что содержимое блока имеет второстепенный характер по сравнению с вышерасположенным контентом (то, что выше - важнее). Для людей (уровень представления) это означает то же самое: размещённый сбоку столбец данных имеет второстепенный характер по отношению к основному тексту/контенту. Пользователи при просмотре страниц сайта в HTML-код не лезут, а глядят на экран браузера (понаблюдайте на досуге). И видят этот блок не наверху, не внизу, а СБОКУ от основного контента и воспринимают его как менее важные данные по отношению к основному контенту.

Ну а коли интепретация этого блока идентична и для поисковых систем (уровень HTML-кода), и для людей (уровень представления), то те поисковые системы, которые анализируют стили и выполняют скрипты, ни коим образом не смогут усмотреть в этом попытку обмана.

---
P.S . Судя по переходу на личности, вы, наконец, поняли логичность и непротиворечивость моих доводов. И ведь на самом деле, представленная логика доводов вполне себе однозначна и понятна. Другое дело, что тот или иной разработчик может не соглашаться с необходимостью придерживаться тех или иных правил и норм, но я и не должен заниматься убеждением. Моя лишь задача - представить эти доводы и аргументировать их. Оттого, что вы не хотите (в силу принципов, воспитания или иных причин) их придерживаться, не говорит о том, что они нелогичны и противоречивы. Это разные вещи.

hVostt Cyrax_02 1.1 Не знаю, какие media queries вы относите к размеру шрифта (если "viewport", то это не размер шрифта), но выглядит странным ваше утверждение о возможности учёта с помощью медиа-запросов размера шрифта, номинальная величина которого при масштабировании в окне браузера не меняетсяНу тогда почитайте про MQ

@media (min-width: 1024px) {
* { font-size: 14px; }
}
@media (min-width: 400px) {
* { font-size: 12px; }
}

Вы привели пример медиа-запросов, учитывающих горизонтальное разрешение устройства, а не используемый шрифт. Всё-таки, придётся признаться...

Если же вы имели ввиду непосредственное задание конкретного размера шрифта в зависимости от горизонтального разрешения, то даже если сделать допущение, что известен объём текста , грош цена усилиям, поскольку при масштабировании даже при неизменном номинальном размере шрифта и пропорциональном визуальном увеличении высоты "плавающего" блока меняется число строк . Более того, число строк неизвестно даже изначально , при отсутствии масштабирования, поскольку ширина "плавающего" блока при адаптивной вёрстке тоже меняется. Ну а число строк, о чём я уже неоднократно говорил, вы никакими медиа-запросами и никакими правилами не сможете ни учесть, ни задать. Отсюда делаем вывод, что решить сабжевую задачу чисто на стилях невозможно.

авторОтсюда я теперь отчётливо понимаю, что ни в HTML, ни в стилях вы не бум-бум. За сим, отправляю вас читать буквари и не отнимать у людей время.Ну вот так... если приглядеться к вашим медиа-запросам...
Тот факт, что вместо <html> , <body> или .left вы используете * , уже о чём-то говорит. Это к вопросу о "школоло".

авторК вопросу о SEO. Я не знаю, что вы там курите, но мы знаем, что в основе поискового продвижения лежит качественный контент, а не вот это школоло с позициями блоков, которое ушлыми сеошниками впаривается далёким от веба людям с большими развесистыми ушами.Помимо собственно контента на результат существенное влияние также оказывает куча других факторов, включая и поведенческие, и контекст, и семантику. Не все роботы, не во всех случаях и не всегда в полном объёме анализируют стили и выполняют скрипты. Поэтому, важно соблюдать семантику уже на уровне HTML-кода.

Более того, при наличии в "плавающем" блоке/столбце N-го количества внутренних ссылок расположение этого блока в HTML-коде перед основным контентом может привести к тому, что из-за ограниченных квот на индексацию те страницы, на которые указывают ссылки в основном контенте, будут индексироваться и обновляться в поисковой выдаче не в полном объёме либо с опозданием по сравнению со страницами, на которые указывают ссылки из "плавающего" столбца.

авторавторCyrax_02! не спорь с hVostt, у него есть "специально нанятый верстальщик", который всё делает, а hVostt только тут щёки раздувает.Слышь, тебя тут с твои экспертным мнением не звали, ты бы тоже буквари почитал, прежде чем куда-то влазить, позорище форумное.
Если в ответ на конструктивные аргументы "топырить" пальцы, переходить на личности и оскорблять участников форума, против себя вы будете настраивать всё форумное сообщество. Так бывает. Не нужно обижаться. Со временем придёт понимание себя и окружающего мира. Всегда мы узнаём что-то новое и это новое нужно принимать, а не отталкивать...

hVosttCyrax_02Вы привели пример медиа-запросов, учитывающих горизонтальное разрешение устройства, а не используемый шрифт. Всё-таки, придётся признаться... "Не знаю, какие media queries вы относите к размеру шрифта"
Не юлите.Коли разбирать процитированное вами предложение, то нужно также прочитать и вторую его часть:
..., но выглядит странным ваше утверждение о возможности учёта с помощью медиа-запросов размера шрифта ...

авторCyrax_02Если же вы имели ввиду непосредственное задание конкретного размера шрифта в зависимости от горизонтального разрешения, то даже если сделать допущение, что известен объём текста , грош цена усилиям, поскольку при масштабировании даже при неизменном номинальном размере шрифта и пропорциональном визуальном увеличении высоты "плавающего" блока меняется число строк .Высота блока задана фиксирована, ширина фиксирована, шрифт и размеры фиксированы. Всё подогнано под разные разрешения с помощью MQ. Объясните мне, недалёкому невежде, с какого перепуга число строк будет меняться?
Если предположить, что объём текста заранее известен и постоянен, что медиа-запросами мы будем подгонять ширину и высоту блока под каждое горизонтальное разрешение, что масштабирование во всех браузерах/клиентах будет выполняться по единым алгоритмам, что базовый шрифт будет задан в абсолютных единицах, - в этом случае число строк в разных браузерах также будет меняться. Как минимум, из-за различных механизмов пиксельного рендеринга. К примеру, в браузерах Webkit при рендеринге выполняется округление величин в меньшую сторону (дробная часть отбрасывается), в браузерах Gecko , Trident , EdgeHTML реализован пропорциональный рендеринг. В итоге в одном браузере часть строк, близких по ширине к внутренней ширине блока, будут переноситься, в других - нет. Также могут возникнуть проблемы и с предсказуемостью высоты строк в разных браузерах при наличии в них элементов с [inline-block]. Строчный контекст форматирования - это вам не блочный контекст . Там всё гораздо сложнее и гораздо менее предсказуемо.

авторавторТот факт, что вместо <html>, <body> или .left вы используете *, уже о чём-то говорит. Это к вопросу о "школоло".О чём говорит? Давайте раскрывайте тему.
Если вам неизвестны особенности и последствия использования селектора *, создайте отдельную тему. По результатам вам станет ясно, о чём говорит ваш пример в контексте сабжевого обсуждения. Думается, что эта тема уже сто раз изъезжена.

авторCyrax_02Помимо собственно контента на результат существенное влияние также оказывает куча других факторов, включая и поведенческие, и контекст, и семантику. Не все роботы, не во всех случаях и не всегда в полном объёме анализируют стили и выполняют скрипты. Поэтому, важно соблюдать семантику уже на уровне HTML-кода.

Более того, при наличии в "плавающем" блоке/столбце N-го количества внутренних ссылок расположение этого блока в HTML-коде перед основным контентом может привести к тому, что из-за ограниченных квот на индексацию те страницы, на которые указывают ссылки в основном контенте, будут индексироваться и обновляться в поисковой выдаче не в полном объёме либо с опозданием по сравнению со страницами, на которые указывают ссылки из "плавающего" столбца.
Семантика? Отлично. Представим, я вам заказал оптимизацию SEO. Дорого, очень дорого. Дал вам кучу времени. И вот вы показываете результат. А я прошу объяснить, почему вместо того, чтобы поместить плавающий блок там, где ему и положено быть, вы нагородили какую-то фигню из стилей и/или скриптов. Как будете доказывать заказчику, что вот этот шаг реально необходим и стоит ваших затрат на поиск решения, только без вашей демагогии , которая никому неинтересна. Покажите пруфы от поисковиков, или цифры. Что можно посчупать и проверить.

И насколько сильный ущерб от помещения плавающего блока там, где ему положено быть (вверху)? Как оценить? Есть критерии оценки какие-то? А если поместить внизу, как оценить что и насколько улучшилось?
Во-первых, кто сказал, что позиционировать второстепенные данные нужно именно с помощью [float] ?
Во-вторых, кто сказал, что блок с второстепенными данными должен располагаться перед основным контентом ? Любой заказчик, так же, как и любой здравомыслящий человек, понимает, что сначала идут основные данные, затем второстепенные. Соответственно, никаких вопросов у заказчика не возникнет, если уж так волноваться, что заказчик полезет в свёрстанный HTML-код и будет у исполнителей чего-то выпытывать.

Во-третьих, затратность той или иной оптимизации или решения (не обязательно SEO), а также методика и тактика доказывания кому бы то ни было чего бы то ни было никоим образом не определяет логичность или эффективность этой самой оптимизации или решения. Соответственно, ваш пример абсолютно не в тему. Не нужно пытаться доказывать логичность/нелогичность доводов тем, что заказчик Петя задал исполнителю Васе какой-то вопрос. Я не украинский политик, и такой лабудой не занимаюсь.

Если хотите доказать/показать, что семантика , квота на индексацию и расположение второстепенных данных с внутренними ссылками перед основными данными - пустой звук, приведите контраргументы. Конструктивные контраргументы, а не что-то вроде " для вас это тёмный лес, вы на это не способны ".

авторТак бывает, что человек нет-нет, да и соврёт. Это я про васВероятно, привести примеры вам не позволяет воспитание. А может быть, это секретная информация, не подлежащая раскрытию ? Какой ужас !

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

авторавторВысота блока задана фиксирована, ширина фиксирована, шрифт и размеры фиксированы. Всё подогнано под разные разрешения с помощью MQ.
Объясните мне, недалёкому невежде , с какого перепуга число строк будет меняться?Если предположить, что объём текста заранее известен и постоянен, что медиа-запросами мы будем подгонять ширину и высоту блока под каждое горизонтальное разрешение, что масштабирование во всех браузерах/клиентах будет выполняться по единым алгоритмам, что базовый шрифт будет задан в абсолютных единицах, - в этом случае число строк в разных браузерах также будет меняться.

К примеру, в браузерах Webkit при рендеринге выполняется округление величин в меньшую сторону (дробная часть отбрасывается), в браузерах Gecko, Trident, EdgeHTML реализован пропорциональный рендеринг. В итоге в одном браузере часть строк, близких по ширине к внутренней ширине блока, будут переноситься, в других - нет. Также могут возникнуть проблемы и с предсказуемостью высоты строк в разных браузерах при наличии в них элементов с [inline-block]. Строчный контекст форматирования - это вам не блочный контекст. Там всё гораздо сложнее и гораздо менее предсказуемо.авторИ что? В чём проблема? Меню, кнопки, заголовки, таблицы, рекламные блоки и прочие элементы верстаются с учётом этого знания, чтобы оно всё влазило в заданные границы и ничего не разъезжалось. Возвращайтесь пожалуйста в реальность, и не фантазируйте.Проблема в том, что вы просили объяснить, почему число строк будет меняться. Объяснил я недалёкому невежде ? Объяснил.

По поводу " меню, кнопок, заголовков, таблиц, рекламных блоков и прочих элементов ". Какие задачи вы рассматриваете ? Реальные или гипотетические в вакууме ? Если реальные, то ваша реальность сдулась ещё в первых топиках обсуждения, когда вы сделали допущение, что высота "плавающего" блока постоянна либо постоянен объём текста (а высоту блока можно заранее вычислить для каждого учитываемого горизонтального разрешения). В условиях сабжевой задачи прямо написано, что высота блока произвольная (заранее неизвестна). Аналогично обстоит и с реальными проектами, где "плавающие" блоки содержат текст. Резюмировать здесь можно вашими же словами: " возвращайтесь пожалуйста в реальность, и не фантазируйте ".

авторВерстальщик проверяет результаты своей работы в нескольких распространённых браузерах. Проблем в кроссбраузерной вёрстке на порядки больше, чем вы описали. Однако все они с успехом много лет решаются, и только вы говорите так, как будто вчера слезли с деревьев.Вы меня спросили, почему число строк будет меняться. Я объяснил. Про то, что это главная проблема верстальщиков, вроде как, никто не говорил.
И снова вашими же словами: " в волшебном мире пони... " жили-были...

авторКогда человеку нечего ответить на заданный вопрос по существу, он начинает размазываться по кафелю. Не знаете и не знаете. Тогда попрошу в следующий раз промолчать, прежде чем выдавать глубокомысленные утверждения.
Когда вы спрашиваете про универсальный селектор *, невольно возникает вопрос о вашем уровне познаний в вёрстке. Если же вы хотите поспорить с общепринятыми и обоснованными рекомендациями по его использованию/неиспользованию, ну уж очень хочется - создавайте новую тему. Таковы правила форума. Ещё раз повторюсь, что эта тема уже 100500 раз обсосана и изъезжена.

авторВо-первых, во-вторых, в-третьих.. Я просил у вас очередную порцию демагогии? А попросил показать цифры, метрики и показатели, которые можно проверить, пруфы от первоисточника. Значит у вас ничего этого нет.
Информацию о квотах на индексацию , об учёте поисковыми машинами семантики , поведенческих факторов и прочих критериев ранжирования (помимо голого контента), а также примеры их влияния на ранжирование - эту информацию вы можете почитать на сайтах поисковых систем в разделе "Для разработчиков", а также в смежных по семантике разделах. Самостоятельно найдёте ? Или нужна помощь ? Это риторический вопрос (немудрено предугадать, что таки попросите)


hVostt Вы меня обвинили, что я перешёл на личности. Это враньё.Коли вы настаиваете на примерах... Первое попавшееся на глаза (кстати, когда наш hVostt'атый это писал, он вероятно не знал, что в проектах с адекватной архитектурой тексты извлекаются из БД, а серверные скрипты не занимаются парсингом собственных же CSS-стилей):hVostt Всё верно. Если бы у вас был хоть какой-то боевой опыт вёрстки, вы бы знали, что очень часто стили и текст верстаются совместно. Но в вашем волшебном мире пони, всё должно волшебным образом сложиться благодаря волшебным свойствам стилей, так как надо при любых условиях. И не надо пожалуйста фантазировать на тему «приемлимой архитектуры проекта», вы уже сами себя раком поставили не только задачей, но и условиями. Адекватный архитектор никогда такого не допустит. НИ-КО-ГДА. Он будет искать разумные компромиссы, потому что профессионал в курсе, что мы не живём в идеальном мире розовых пони, в котором вы пребываете.Далее:hVosttСлышь, тебя тут с твои экспертным мнением не звали, ты бы тоже буквари почитал, прежде чем куда-то влазить, позорище форумное. Ну и далее куча примеров в том же духе.

P.S . Этого уже достаточно, чтобы у сообщества сложилось адекватное впечатление о товарище hVostt .

Сдулся наш хвостатый. По всем фронтам
Верно вадя подметил:
авторCyrax_02! не спорь с hVostt, у него есть "специально нанятый верстальщик", который всё делает, а hVostt только тут щёки раздувает.

авторСдулся наш хвостатый. По всем фронтам
Верно вадя подметил:вадяCyrax_02! не спорь с hVostt, у него есть "специально нанятый верстальщик", который всё делает, а hVostt только тут щёки раздувает.
И не только здесь, но и в соседних ветках:
http://www.sql.ru/forum/1274276/css-kak-vyrovnyat-shirinu-bloka-po-vyshestoyashhemu
hVostt Нет.hVostt Абсолютно ничего странного нет. Почитайте основы HTML.hVosttИменно! Поэтому нет.А решение оказалось простым - <caption>
Мораль: прежде чем "раздувать щёки" и флудить, иногда бывает полезным подумать