- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 4 Nov 2015 16:27:18 -0800
- To: Florian Rivoal <florian@rivoal.net>
- 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>
On Wed, Nov 4, 2015 at 4:14 PM, Florian Rivoal <florian@rivoal.net> wrote: >> On 05 Nov 2015, at 09:03, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Wed, Nov 4, 2015 at 3:35 PM, Florian Rivoal <florian@rivoal.net> wrote: >>>> On 05 Nov 2015, at 04:02, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>>> fantasai and I discussed this a bit today after reading Brad's email, >>>> and concluded that we did want to stick with just "start" and "end". >>>> Details: >>>> >>>> For today's simple 1-axis floats, "start" and "end" are unambiguous >>>> and simple, and consistent with text-align/etc. >>>> >>>> In the future when we have 2-axis floats (as in the Page Floats >>>> module), 'float' can become a 2-value property, consistent with the >>>> proposals for background-position and scroll-snap-align. If you >>>> specify one value, it will duplicate to the second value (as normal >>>> for CSS). The default float-reference (inline) will only pay >>>> attention to the inline-axis value, so the extraneous block-axis value >>>> is ignored (similar to how scroll-snap-align only pays attention to >>>> the relevant axis). For the 2d float references (column, region, >>>> page), saying "float: start" will just put you in the start/start >>>> corner, which seems fine. >>> >>> For the moment, page floats are not 2D, they are 2x1D. As in, they can be >>> floating either in the inline direction or in the block direction, but not >>> both, so your proposal wouldn't quite work. float-reference, as currently >>> specified, does not solve this. It does for float-reference:inline, as you >>> described, but not for the other values, since the current behavior allows >>> either block or inline, and your syntax would also allow for 2D floating. >> >> 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*. >>> We can solve this with more values on float-reference or more properties, >>> but I don't really want to conclude on start/end vs inline-start/inline-end >>> as values to the float property before we answer that question. >>> >>> Quick proposal in that direction: >>> >>> float-axis: auto | inline | block | both >>> float-reference: bfc | page | column | region >>> >>> auto would compute to inline for bfc, and to block for for the other values. >> >> No need for this. Just let float takes 1 or 2 values, with the >> 1-value duplicating to fill the missing one. Then the float-reference >> dictates whether the float cares only about inline, or about both, >> similar to scroll-snap. >> >> (scroll-snap-type is more explicit about axises, because they're >> independently valuable. Floats, at least currently, dont' do that - >> the two types of floats imply either "inline" or "both" axises.) > > No, they don't. At least not as currently specified. Not saying we > shouldn't extend to support "both" later (we should), but so far > we don't have it. Right, I'm saying they need to do so *now*. ~TJ
Received on Thursday, 5 November 2015 00:28:12 UTC