Имеется основной текст и плавающий блок. Всё бы хорошо, но имеются такие условия:

1 . По HTML-коду основной текст должен следовать перед плавающим блоком
2 . Основной текст должен обтекать плавающий блок сбоку и снизу (как если бы плавающий блок был размещён по HTML-коду перед основным текстом)

https://jsfiddle.net/jmuwdvxk/1/

P.S. Если кому интересно, часть первая - здесь .

Ширина плавающего блока фиксированная, высота - произвольная (заранее неизвестна)

Похоже, задача решения не имеет ?

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

И это я так решил

авторОткройте для себя прелести html5 и не страдайте фигнёйОдно другому не мешает. В условиях жёсткой конкуренции бывает целесообразным учёт и таких, казалось бы, малозначимых ньюансов. Что касается html5, то каким образом он здесь сможет помочь ? <figure> и <aside> семантически не соответствуют этому самому плавающему блоку-столбцу. Сам по себе <section> не укажет на второстепенный характер основных данных.

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

Не вариант. Поскольку:
1 . Пустые блоки, которые никогда не заполняются данными, - семантически некорректны
2 . В процессе загрузки и рендеринга основной контент страницы будет скакать туда-сюда (даже если на уровне стилей абсолютно позиционированный блок [left] разместить где-нибудь внизу)
3 . Скрипты на клиенте могут быть отключены либо могут не работать по тем или иным причинам

4 . В адаптивной вёрстке при изменении ширины экрана (например, поворот устройства на 90 градусов) меняется и ширина столбцов. В этом случае придётся скриптами дополнительно отслеживать изменение ширины/ориентации устройства и корректировать высоту блока (ширина корректируется медиа-запросами). А это дополнительная нагрузка на процессор.

автор2. Бред, ниче там не скачет.До начала выполнения скриптов основной текст отображается так, как будто плавающего блока нет. После выполнения скриптов выполняется перекомпоновка основного текста с учётом плавающего блока - слова текста опускаются вниз. Это и есть "скачет"

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

автор4. Я менял ширину, всё у меня ОкВ вашем примере при изменении ширины окна ширина столбцов не меняется. В адаптивной вёрстке, как правило, меняется. А при изменении ширины столбцов выполняется перекомпоновка их содержимого с изменением высоты блока-контейнера. Это ж очевидно.

авторЗадача выполнена, следующий! Порой, реализация практических задач требует и качества тоже...

авторПро нагрузку про процессор уже выдаёт в вас больное воспалённое воображение. А браузер типа под сложную вёрстку не давит на процессор?Одинаковые по сложности операции на уровне CSS выполняются на порядок быстрее, чем на уровне скриптов

авторЯ не стал заморачиваться, но если вёрстка не резиновая, а адаптивная, как это сейчас модно делать, то решается чисто на стилях, без скриптов, на media queries.В случае адаптивной вёрстки с использованием медиа-запросов задачу чисто на стилях по-прежнему не решить.
Как вы будете реализовывать обтекание блока, расположенного в HTML после основного контента, этим самым контентом ? Никак.

автор> В вашем примере при изменении ширины окна ширина столбцов не меняется. В адаптивной вёрстке, как правило, меняется. А при
> изменении ширины столбцов выполняется перекомпоновка их содержимого с изменением высоты блока-контейнера. Это ж очевидно.
Media queries и вперёд.В данном случае просто медиа-запросов здесь также будет недостаточно, поскольку верхняя позиция абсолютно позиционированного блока в общем случае не равна 0 или какому-либо постоянному значению. Если выше расположен блок, ширина которого меняется в зависимости от горизонтального разрешения экрана, то и верхняя позиция абсолютно позиционированного блока также будет меняться, и как я написал выше, потребуется скриптами отслеживать изменение ширины экрана и его ориентации для его "перепозиционирования".

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

2 . Содержимое зелёного блока относится к основному контенту (в т.ч. поэтому и не заключается в <aside>), хотя и имеет второстепенный характер. Соответственно, при отключенных или неработающих скриптах этот блок должен отображаться. Посему, " просто без плавающего блока " здесь не прокатит.

3 . Учитывая, что поисковые машины анализируют не только HTML-код, но также и стили, то в плане SEO при прочих равных условиях преимущества будет иметь тот сайт, на котором информация представлена в более полном и более удобном для пользователя виде (при отключенных скриптах). При этом скрипты выполняют не все поисковые машины и не во всех случаях. Это один из практических доводов не в пользу ваших убеждений.

авторКачество говорите? Есть огромное количество задач, которые тупо не решаются на стилях. Что теперь, застрелиться? До того, как появились закругления, в вёрстке очень много было говна, чтобы эти закругления эмулировать, и многие так делали. Хотите сказать, они делали некачественно?Если придерживаться хорошего тона программирования вёрстки, то при отключенных или неработающих скриптах контент должен быть представлен в приемлемом виде. Как в плане полноты контента, так и в плане удобства и корректности компоновки. Отсутствие скруглений - это приемлемый вариант. Но отсутствие или перекрытие части основного контента - это, очевидно, не приемлемый вариант.

авторавторЯ не стал заморачиваться, но если вёрстка не резиновая, а адаптивная, как это сейчас модно делать, то решается чисто на стилях, без скриптов, на media queries. > В случае адаптивной вёрстки с использованием медиа-запросов задачу чисто на стилях по-прежнему не решить.
> Как вы будете реализовывать обтекание блока, расположенного в HTML после основного контента, этим самым контентом ? Никак.

Решить. Тоже самое, что я делал в скриптах, только размеры плавающего блока вы задаёте изначально.

Ещё раз повторяю, задача решается для адаптивной (не резиновой) вёрстки, с использованием медиа запросов. Не идеально, но решается. Если вы просто не знаете как это сделать — вопрос другой.

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

Иными словами, что с медиа-запросами, что без них, что в "адаптивной", что в "резиновой" вёрстках (если использовать вашу терминологию), задача реализации обтекания чисто стилями не решается . Утверждениями, что решение якобы имеется, но мне оно неизвестно, вы лишь вводите читателей в заблуждение.

авторСерьёзно??? Анализируют стили??
Анализируют. Простейший пример: пишете текст с ключевыми фразами в начале страницы и стилями делаете им [display: none] либо скрываете их иным образом. Поисковые машины этот финт обязательно просекут. В лучшем случае (для вашего сайта) этот текст в поисковой выдаче будет отсутствовать, в худшем - рейтинг вашего сайта будет понижен.

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

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

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

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

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

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>
Мораль: прежде чем "раздувать щёки" и флудить, иногда бывает полезным подумать