> On Nov 6, 2015, at 12:33 AM, Johannes Wilm <johannes@fiduswriter.org> wrote: > > > >> On Fri, Nov 6, 2015 at 8:00 AM, Brad Kemper <brad.kemper@gmail.com> wrote: >> >> > On Nov 4, 2015, at 4:46 PM, Florian Rivoal <florian@rivoal.net> wrote: >> > >> > - 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. >> >> I think we should. I'm concerned that the current semantics may limit our choices of good 2D float semantics. > > The conclusion of my last two emails was that yes, we can have 2D light without having to write a lot of very complex placement logic, but their order will matter. > > "float: bottom left" means that the first priority is to float to the bottom. That first priority is used to determine what space in the given fragment is reserved for the page float in relation to other page floats. The second priority is "left". So it will be floated to the left most part of the area that has been reserved for it through means of the first priority floating. > > "float: left bottom" means the opposite. > > The results will differ once there are several floats within the same fragment. And if a 'float: left bottom' is followed by a 'float: bottom left', flowed by a 'float: left bottom', followed by a 'float: bottom left'? A stair step arrangement? This seems complicated and unnecessary to me, and breaks the normal expectations of horizontal coming first when two values represent two axes (X and Y, horizontal and vertical). And it is way too subtle to expect authors to easily figure out that this ordering is significant to float stacking. I expect top and bottom to indicate where the float is placed prior to any horizontal floating. don't see a great need to stack floats vertically, and then wrap text around all of them. If that's needed, then another property can be added, such as 'next-float: vertical'. But that needs a lot of thought, and I'm happy if that isn't added until later. > > So if we change it from: > > "float: inline-start block-end" > > to just > > "float: end start" > > then we have lost a vital piece of information. So I don't think that is a good idea. > > I agree with Tab that content should normally not overload fragments, but it is not uncommon to have more than one float in a fragment. And authors should be able to predict what happens then. > > -- > Johannes Wilm > Fidus Writer > http://www.fiduswriter.org
Received on Friday, 6 November 2015 10:07:04 UTC