W3C home > Mailing lists > Public > www-style@w3.org > November 2015

Re: [css-logical-properties] the 'inline-{start,end}' values for 'float' and 'clear'

From: Florian Rivoal <florian@rivoal.net>
Date: Thu, 5 Nov 2015 09:46:11 +0900
Cc: Jonathan Kew <jfkthame@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, Koji Ishii <kojiishi@gmail.com>, "www-style@w3.org" <www-style@w3.org>, Rossen Atanassov <ratan@microsoft.com>, "Elika J. Etemad" <fantasai@inkedblade.net>
Message-Id: <C5905EE2-BDCF-4865-9D2C-EB9461805E58@rivoal.net>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
> On 05 Nov 2015, at 09:27, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> This is the wrong thing.  Current floats are definitely 1d - they only
>>> float in the inline axis (or get pushed along the block axis, but
>>> that's irrelevant to specifying their desired position).  Page floats
>>> and similar, though, are definitely 2d. You can't specify just one
>>> axis.  If you float to the top, you need to know whether to go left or
>>> right when you're not the full width.
>> I suggest you have a look at the page-float spec. Currently you can
>> specify float:top, but not float: top left. Of course the spec
>> needs to say what happens when you don't take the full width (and it
>> does), but that's not the same as saying that the author needs to
>> be able to position arbitrarily in 2d.
> I know. That's precisely the thing I'm saying is wrong.
>> There are use cases for full 2d positioning, but so far, that had
>> been pushed to level 2.
> It's not a corner case.  All the *examples* have full-width elements
> being floated up or down, but that's irrelevant; in practice, a lot of
> top/bottom floats will be shrinkwrapped or otherwise sized to
> something other than 100%. Horizontal positioning is a requirement
> *now*.

Ok, I get your point now. Saying "page floats are[...]" when
you meant "page floats need to be [...]" confused me.

I am not at all disagreeing on the usefulness of 2d floats, but:

- We need to consider what the increased complexity will do
  to willingness to implement. I'd much rather have a simple
  (and extensible) definition of page floats with multiple
  implementations than a rich definition with only one

- I am not comfortable with deciding on the syntax of page floats
  before we decide on the semantics. We've had semantics in a spec
  for a while, and I am arguing for syntax based on these semantics.
  If we want different semantics, let's have that discussion.

  "full 2d" floats are a complicated matter, and I am far from sure
  a background-position inspired syntax will cut it.

Received on Thursday, 5 November 2015 00:46:40 UTC

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