Re: [css-page-floats] Mostly editorial comments

Hey,

glad to have run into you last week!

On Tue, Aug 18, 2015 at 8:29 PM, liam <liam@w3.org> wrote:

> I think most or all of these comments are editorial, so i didn't split
> them up into multiple messages.
>
>
> Section 5, Deferring Floats, starts out with the assertion,
> [[
> A page float can be deferred to another fragmentation container than where
> the float anchor is placed.
> ]]
>
> Does this mean that an implementation has the flexibility to defer floats,
> or that users can control whether floats are deferred/
>
> I think from the following paragraph it means the latter, but then why is
> the first paragraph there?
>

fixed

>
> Suggest removing the first paragraph.
>
> "This new property is instroduced" should name the property, e.g.
> "The float-defer property controls what happens when floats are deferred:"
>
> The description of a negative integer value could possibly be clearer :-)
> I _think_ it's trying to say that negative values count backwards from the
> last framentainer, with -1 being the last one, -2 being the next-to-last,
> and so on. It also needs to say what happens if N is less than -(total
> number of fragmentainers + 1)



fixed


> and also what happens if the fragmentainer referred to is earlier in the
> document -- e.g. we're formatting the third fragmentainer and we get to a
> request to put a float in the 2nd fragmentainer.
>

As far as I can see, it shouldn't be a problem to go back and add more page
floats to a previous page/column/region, but that is because so far we are
not doing reordering of the float stack (see below).



>
> In 7,
>
> "This property pushes a float in opposite direction of the where it has
> been floated with float."
> should be (i think)
> "This property pushes a float in the direction opposite to which it has
> been floated with float."i
>

fixed


> but opposite could mean, up instead of down, or it could mean horizontally
> instead of vertically. The examples suggest the first of those meanings is
> intended (e.g. float: left; moves a block horizontally and potentially to
> the left, so we can only move it to the right. I don't understand how this
> would work if we move something in two directions at 0nce with float, as in
> some of the multi-column examples)
>

so far we do not allow two dimensional floats, which is why this hasn't
been an issue yet.


>
> "This property can only influence a page float along an axis it has been
> floated." probably means
> "This property can only influence a page float along an axis along which
> has been floated."
> As written it's not a grammatical sentence I think, or at least I can't
> parse it.
>

I feel there is an "it" missing in the fixed version, otherwise fixed.


>
> Example 20:
> suppose contining-block-width is 300px and pull-quote-width is 100px.
> Then 50% is (300 - 100)px is 200px and moving the block by this much will
> not in fact center it. Or is the percentage applied twice/
> What happens if there are two or more adjacent blocks floated and pushed
> by a percentage??
>

Good question. Should the percentage be "percentage of the remaining space
after subtracting the space used by this and previous page floats? I am
wondering whether it is a good idea to allow percentages for the
float-defer value at all.


>
> 8 stacking order
> We need to be able to override the float stacking order.
> See attachment 1 "pagefloat01.png" -- the left-hand situation isn't
> acceptable in general.
>

I can see how this can be useful, but so far we have gotten around it by
specifying that it is a assumed that a page float fill the entire
width/height by default in the direction it is not floated (so width=100%
for top/bottom floats and height=100% for right/left floats).

Are there any particular algorithms you would refer to that decide when
stacking order should be changed automatically? Or do you have suggestions
on how this should be specifiable manually?

The situation you outline in pagefloat01.png would therefore mainly happen
if b is a page float and a and c are column floats. If that were the case,
b would be layouted first, so it would be placed on the top and the other
two then in the remaining part of the column below.


>
> Spanning of floats: Maybe this is specified elsewhere? See pagefloat02.png
> (attached) for examples of floated figures that (1) span two columns of
> text - not necessarily all columns if there are more than two - and (2) in
> the 2nd case, disrupt the flow of text, indicated with numerals in the grey
> boxes indicating text flow sequence.
>
>
Column spanning should have been moved to a new version of the multicol
spec: https://drafts.csswg.org/css-multicol/


Thanks for the extensive feedback!

-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org