W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-multicol] Breaks should be allowed to avoid floats

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 20 Dec 2013 14:13:52 -0800
Message-ID: <CAAWBYDA9LceTsn5Yi9bw8etmNu7aYkTEk5M=RaxtY518teX7MQ@mail.gmail.com>
To: Mike Sierra <letmespellitoutforyou@gmail.com>
Cc: www-style list <www-style@w3.org>
On Fri, Dec 20, 2013 at 6:54 AM, Mike Sierra
<letmespellitoutforyou@gmail.com> wrote:
> Attached is a screen shot of a web page (http://onforb.es/Ja4nUs) that shows a formatting problem I notice a lot.  The partly obscured video element represents the article's overall width.  A heading ("Previous fixes were failing") that's logically tied to the following block of body text does not visually align to it, because of sidebar content that gets floated to the left margin. The spec for "break"-related properties applies "avoid" to page, column, and now region breaks. In this situation, if the heading were defined as "avoid," I would hope that it would also apply to floats, and fall into the same visual block as the element that follows. I understand a web designer may avoid the problem by embedding the floating content elsewhere, but it strikes me as something that should be able to be automated.

I don't think this has anything to do with the 'break-*' properties.
This is a basic layout failure on the author's side, is all.  The
sidebar is placed after the heading but before the text, and thus when
floated, it floats below the heading but next to the text.  This is
standard, expected behavior, and we don't want to try and tweak it, as
doing so would more than likely break a whole bunch of pages.

The right answer is to either move the sidebar content around, or more
usefully, use one of the new layout methods such as Flexbox to make it
more robust.  Floating was a useful layout technique for many years,
but it is and has always been a dirty hack, and we have better ways to
do this kind of thing now.

Received on Friday, 20 December 2013 22:14:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:38 UTC