[CSSWG] Minutes Tokyo F2F Fri 2017-04-21 Part II: Page Floats Redesign [css-page-floats]

   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

Floats breakout


   - RESOLVED: Rejigger the spec to use the 1d top/floats.
   - Florian gave a brief summary of issue 1236 (inline alignment of
       block-end floats- https://github.com/w3c/csswg-drafts/issues/1236)
       and 1235 (auto width of block-start/end floats-
       https://github.com/w3c/csswg-drafts/issues/1235) in hopes of
       getting more attention on the topics.
   - RESOLVED: We will use values of clear to have in-flow and floated
               content clear other page floats. No placement based clear.
   - RESOLVED: Add issue to figure out what happens in a non
               paginated context.
   - RESOLVED: Use 'float: top bottom' as a way to have something
               float to the top or bottom based on proximity and
   - RESOLVED: 1D page floats shortens the content area of the
               fragmentation, therefore backgrounds and borders of
               the fragmented content do not extend through the float
   - RESOLVED: Add start and end keywords always qualify with
               block- and inline- prefixes: block-start/block-end/


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split part of the morning of the 20 April on two
       tracks: Floats and Color/SVG.

Floats breakout
Scribe: eae


1D vs 2D Floats

   Florian: The page floats spec was initiated by us because we
            thought we'd need it. We did need it and we've been using
            it in projects.
   Florian: The spec was intended to be a simple subset and with some
            implementation experience the trade off between
            implementation ease and ease of use might not be the
            right one.
   Florian: A deeper rewrite has been proposed.
   Florian: Basically the current spec only allows one to float in
            one direction.
   Florian: top, bottom, left, right. Syntax is 1d, implementation is
            2d. Float top is top left, bottom is bottom right.
   Florian: This was intended as a gentler introduction with the
            intention to eventually expose both axis.
   Florian: But float: top and float: top left are different things and
            we probably want (leaving aside L1 vs L2) one dimensional
            page floats to be one dimensional. So that float: top is
            float: top and not float: top left.
   Florian: What we found most useful is fully 1d float. You can sort
            of get there with 2d floats masquerading as 1d floats but
            it is hard.
   Florian: Should we move away from the model where 2D floats are
            pretending to be 1D floats?
   Florian: We think we have a fairly good grasp on how 2D floats
            should behave.
   Florian: We would prefer to define 1D and 2D page floats to be
            different things.
   Florian: We could then go into details about how clearance works

   astearns: When you're talking about the sort of 2d floats where
             you have a float: top not confusing the full width. Does
             content flow around it?
   Florian: Depends on the exclusion and wrap.
   iank: Float center and nothing can wrap around it?
   Florian: Regular block layout?
   Florian: If it is a block it will consume full width. If an image
            it won't be stretched.
   iank: This means it'll be pulled up to the root of the formating
   Florian: Depends on the type of float.
   iank: That is a little bit.

   fremy: The main difference between what you described and what is
          in the spec is that bottom floats that also go to the line
          end (right for English) they go to the beginning of the
          line instead. Text wraps around it?
   Florian: That is not the only difference.
   Florian: First intuition was bottom right over bottom left.
            Arbitrary but impl easier for left.
   [Florian draws a page with a float in the lower right corner on
       the whiteboard. On the next page the remainder of the box is
       at the top of the page. Border and background goes behind
       float. That is in the 2D-ish model. Not so much for 1D floats.]
   Florian: There are use cases for 2D floats. Absolutely. There are
            probably ones for 2D floats that consume the full width.

   iank: Some implementation feedback. I think most architectures (at
         least ours) the float top at the very least will cause us to
         go into multi-pass layout which we would not want to get
   iank: The current floats work okay as they do not cause elements
         to shift beyond the current line. This proposal has floats
         where an arbitrary float in a page can cause all elements to
   astearns: That is true. 2D floats means that don't just shift but
             triggers relayout.
   astearns: 1D floats would not.
   iank: They still could due to fragmentation.
   iank: With parallel floats it would be even worse.

   johanneswilm: I agree that 1D floats - used in most places. The
                 question about relayouting, would it help if we said
                 that the float would always defer to the next page/
                 column? There have been ideas around policies around
                 placement where one has them be deferred.
   iank: That may work without multipass.
   Florian: Might work, not sure if good enough.

   astearns: Always deferred, what about the case where there is no
             next page/column? Not in a fragmentation context?
   Florian: What does it do if in no fragmentation context? Different
            question we should address separately.
   Florian: Would be simplification but might push it too far and not
            be good enough for authors.

   fremy: For sure 1D floats are much better than 2D ones, closer
          match to what authors are implementing. Not sure if you
          need to do any layout if you have a top float as we don't
          change the width of the page. Assume we can apply overflow.
          Push float top to next page. Think that would solve the
   Florian: Could you be more specific?
   fremy: Shift everything down or if not possible push to next page.
   Florian: Very big page with a lot of content, say 30 pages of
            text, is that enough space?
   fremy: Don't layout anything that comes after the float. When you
          encounter the float you decide if there is enough space
          below and then shift down if you can, or if there is not
          then push it to next page.
   iank: If you have additional floats in parallel flows is an issue
         but would work if nothing has fragmented.
   Florian: This is something I'd be happy to leave to a quality of
            implementation. It would be okay to push to next page.
            Would not be happy with the spec mandated it. It should
            be allowed for implementors to do the high-quality multi
            pass layout.
   Florian: Not intended for building UIs with pixel perfect results.
            Allowing both sounds reasonable to me.

   johanneswilm: How about having a policy and only have browser
                 implement the lower level where they do the simple
                 thing that doesn't require multi-pass layout while
                 publishing apps could allow for the multi-pass
   Florian: I think we're saying the same thing. Yay.
   johanneswilm: I think the difference is that you'd have a way to
                 specify which one you want to use. Browsers would
                 only have one, other tools could have other ways of
                 doing it.
   Florian: Not one of five complex ways in this case.
   johanneswilm: If you look at HÃ¥kon's alternative spec, he has a
                 number of suggestions including one where floats
                 disappear after last page, another one where they
                 are deferred.
   Florian: For level-1 we could spec it without mandating a specific
            implementation and then in later versions we could allow
            the authors to specify behavior with the known limitation
            that browsers may never implement it.
   iank: The float: top bottom as proposed at the moment can't have
         text or other content flow around it.

   astearns: This proposal is a bit like shorting the flow height
             like normal floats shorten the line box width.
   Florian: If we agree on this it would make the first two issues on
            the agenda invalid.
   Florian: I don't think we can resolve on spec prose but if we
            could resolve on basic idea that would be great.
   <astearns> proposal: rejigger the spec to use the 1d top/floats

   RESOLVED: Rejigger the spec to use the 1d top/floats.

Inline Alignment of block-end Floats
   <kawakubo> https://github.com/w3c/csswg-drafts/issues/1236

   iank: I don't think that we would have any interest in
         implementing this.
   Florian: We do not expect browsers to jump on this. We want to
            make a model where if one day your priorities shift we
            want to make sure it can be implemented without violating
            design principles.
   Florian: For books but also applicable to multicol.
   myles: Use cases? is this for books?
   myles: How important is this particular feature?
   Florian: Very. Things like newspapers or scientific article would
            use this. As would magazine layout. Very common for print

   tantek: I think the distinction between print and browsers is
           getting less and less important. Things that are paginated
           are going to be in the browser. The assumption that the
           two are separate is no longer valid. The web is taking
           over a lot of print.
   Florian: Big gray zone.
   myles: We're all in agreement here.

   johanneswilm: The point that we need to make the spec is that
                 before vivliostyle that had implementations but not
                 compat. We want to end that. The other point is that
                 this could be provided for browsers using js and
                 polyfills without the browsers themselves having to
                 add support for it.

Auto Width of block-start/end Floats
   <kawakubo> https://github.com/w3c/csswg-drafts/issues/1235

   Florian: Next up. What do we do about 2D floats. What about left
            and right?
   Florian: For left page floats you don't want to chunk it from the
            page. I don't think that is typical.
   Florian: Use case for page float to the left could be when you
            have a multicol and you want to float not in the column
            but things like side notes (intruding or not).
   Florian: Not symmetrical with the bottom line.
   <skk> Our ebook product is using multi-col to create page in
         browser. As a side-effect, it's difficult to have column in
   iank: Goes through formating contexts? That is concerning from an
         impl. point of view.
   iank: Page float inside multicol, would bubble up to the page and
         then intrude into multicol? That is scary as we have no way
         of intruding into it. We have nothing like it today.
   fantasai: abs pos plus exclusion.
   Florian: Don't want to deep dive. Wanted to mention.

   tantek: Do you have a place where you collect examples?
   Florian: Have some private ones, not sure we can share. Much under
   astearns: We have a number of similar examples for exclusions.
   <kawakubo> This is an example of page top (inline-start) float
              with vertical text: 
   <rachelandrew> I have some random bits and examples here
   iank: Exclusions are only for things before the muticol?
   Florian: Not here, bubbles out.
   iank: Would trigger multi-pass layout which is bad.

   Florian: Not the highest priority, lets move on to 2D page floats.
   johanneswilm: Sidebars are probably not floats, if they are then
                 we need work differently, they have some behavior
                 where basically they have to shift up if their
                 contents don't fit on the page, or fragment. They
                 seem to work differently than top and bottom floats.
   Florian: Agreement that they are different and complicated, will
            deal with some other time.

2D Floats

   Florian: If we have a 2D float it goes there (draws float in lower
            right corner), if you have another one if there is enough
            space it goes to the left (draws it to the left of the
            previous float). If there is not it would go above it.
   Florian: Controlling this behavior is what clear is for.
   Florian: Clear: all means that the top edge must be below the
            bottom edge of any previous float. If you can do that do
            it. If not it goes to the next page.
   Florian: Fits with how existing floats work. If if fits place it
            there, if not push down.
   Florian: Want to talk about clear as it'll help us reason about
            both 1D and 2D floats.
   Florian: If it was tall enough not to fit it would be pushed to
            the next page/column/whatever.

   Florian: This is different from current definition of clear.
            Current definition is not about pushing things down,
            current one is about limiting floats of the same type.
   astearns: Sounds more like a float handling policy than a clear
   Florian: In the current spec clearing an in-flow content will not
            interact with page floats.
   Florian: With clear as currently defined in page float spec it
            cannot apply to in-flow content. If we go back to a
            definition of clear that shifts content down we can have
            it apply to in-flow and that might be desirable.

   johanneswilm: If we only have 1D page floats that basically means
                 the clear values applies to page floats. Correct?
   Florian: Not quite. If you have a page with a bottom page float,
            then top float that has clear all. In that case clearing
            it would force document order pushing the top float to
            the next page.
   astearns: If you had a top float that had to go to the next
             fragment for sizing reasons and the content after had
             clear all the content would also go on the next page.

   myles: Where would an inline float go if combine with page floats?
   Florian: Not sure, haven't thought much about it.
   myles: Also, what if it is taller than a page? Chopped in two and
          placed on different pages?
   astearns: Pushed to the next container, if it is the only page
             float it will fragment. Regular left and right floats
             also fragment so nothing special there.


   fremy: I gave this some thought and I think it makes a lot of
          sense to use clear as you (Florian) suggested. One thing
          you might want is a way to do float top or bottom. You
          would be floated to the top but if there is a clear you
          might want to be on the same page and then float to the
   Florian: Fully agree. Next topic I wanted to go into.
   proposal: We will use values of clear to have content and float
             clear other floats. Placement based clear.

   RESOLVED: We will use values of clear to have in-flow and floated
             content clear other page floats. No placement based clear.

   skk: This allows for the creation of pages?
   Florian: Defined in different spec.
   Florian: Use case for applying clear to in-flow content is the
            beginning of a new section, want to clear all floats from
            previous section regardless of whether they're top or

   Florian: We will likely need more clear keywords than 'all'. In our
            use cases 'all' is all we've needed but we can envision
            cases where you'd just want to clear specific ones.

Page Floats in Continuous Media

   fantasai: What happens in non-paged media?
   Florian: I don't know. Might not apply?
   Florian: Top probably makes sense?
   <astearns> bottom float with an infinite scroller
   fantasai: Much harder to figure out the reference. You might want
             to go to the bottom of the section. There are things you
             might want to do like have a 2D float at the top left of
             a section. No page reference. Could fall back on BFC for
   Florian: Given that we have a mechanism for picking a reference we
            could start by saying it doesn't apply and then change it
            to define a reference. Might be weird.
   myles: It's hard to gage what the best behavior is without a big
          corpus of examples. Think it is important and almost a
          prerequisites for discussions like this.
   iank: Would be nice if the spec had more details around more
         complex issues.
   Florian: Yes, spec is improved over the previous level but needs
            more work.

Snapping top/bottom

   Florian: Snapping top / bottom
   Florian: Very reasonable to say "float me to top or bottom,
            whichever is closer"
   Florian: Common to say float me left but if I'm within 3ems float
            me to the bottom instead
   Florian: Current spec has a mechanism that almost does what I said
            but doesn't do either.
   Florian: If I'm within 3ems of the bottom float me bottom, if I'm
            within 3ems of the top float me top. If neither don't
            float me. If both are true float down.
   fantasai: We have lh units which will get you closer to what you want.
   fantasai: Basing on actual line height creates cyclic dependency,
             and is rarely going to be different.

   Florian: We believe the float me top/bottom is a more important
            use case. Proposed syntax is float: top bottom. Means
            float me to either top or bottom depending on which is
   Florian: Different from floating to the left *and* top or bottom.
   johanneswilm: There was also the idea to have float: left right.
                 Are we talking about vertical text or is this for
                 horizontal text? In horizontal snapping left/right
                 seems less useful.
   Florian: Not meant to be writing mode discussion. Needs to be
            converted to logical.
   Florian: Not use-case driven for float: left right. float: top
            bottom was use case driven as was 2D.
   astearns: Let's not do left right now then and focus on top bottom
             where we have use cases.

   iank: Always in logical space?
   Florian: Tricky question. In vertical wiring mode still tend to
            flow start bottom.
   fremy: If you have float for multiple values, i.e. first try start
          then bottom. Not sure this is the best way to express that
          you have a preference and a fallback. I see float: top
          bottom as a way to prefer to float to the top and fallback
          on bottom. Float being a fallback list makes more sense,
          that way instead of going to the next page float to the
   astearns: Sounded like the proposed syntax for float to closest
             edge looks like a fallback. You would prefer a different
             value meaning either value.
   Florian: float: top bottom.
   astearns: Asking for a different value that doesn't look like a
   fremy: Ah, so top bottom as being different from it being a list.
   Florian: "top-bottom" or "top bottom" not important but the latter
            might be easier
   Florian: because doesn't require people to remember the order.

   myles: Thinking about how to implement this. Place first page
          float at the top and then relayout for the rest.
   myles: If you shift down then the other content may end up on
          another page.
   Florian: That is okay.
   astearns: Happens with left floats as well, anchor for left float
             can be on different line from the float.
   astearns: For the first level we'll only do one dimensional floats
             where text doesn't wrap around it. Pushed down.
   myles: Pushing anchor to next page may make the float fit on
          previous page. Could be cyclical.
   Florian: Not OK for anchor to be on same page if float is pushed
            to next.

   kawakubo: I want to float this element to top or bottom but if
             there is already another float at the top of the page
             then I want to place it at the bottom. Choose which way
             to float depending on the presence of another page float
             of the same direction.
   fantasai: Feature that was previous part of the clear property. We
             resolved to move that to a new property.
   astearns: If we have that property then it could be used in
             combination with float: top bottom

   fantasai: Closest possible spot I think.
   astearns: We can resolve on closest possible spot in cases where
             there are restrictions based on other properties.
   proposal: Use float: top bottom as a way to have something float
             to the top or bottom based on proximity and possibility

   RESOLVED: Use 'float: top bottom' as a way to have something float
             to the top or bottom based on proximity and possibility.

In-place Floats

   fantasai: What about in-place floats?
   fantasai: Similar to top and bottom floats that we are talking
             about. You have a page and layout some content and you
             have a box like and image that doesn't fit. You have to
             move it to the next page. Because we moved it there is a
             giant gap. Maybe I don't care for having this gap. The
             exact position of the float isn't super important but I
             don't want to gap. Move lines of text to fill the gap?
   astearns: Even if it is float left 100% content following the
             float can't be above the float.
   fantasai: You don't want to float more things, what if we had a
             value like float-inplace that acts like a top or bottom
             float that doesn't want to leave gaps. Allow text from
             below to fill gap.
   fremy: position sticky for floats?
   fantasai: No, instead of pushing everything to the next page in
             essentially becomes a float: top page float.
   Florian: Very useful features. Doesn't have to be in spec
   Florian: Ways to work around it and we can add it later.
   fantasai: Seems like a simple addition. One dimensional float.
   Florian: float:left *and* snap to top or bottom if within a
            certain threshold.
   Florian: ^ proposal for new topic
   * fremy thinks this looks like "float: none, top" (try none; but
           if cant without wrapping, use float top)
   Florian: A 1D float shortens the fragmentation, therefor
            background and borders of inflow content does not go
            behind the float.
   kawakubo: Page with two columns, if I place a page top float it
             takes the full width of both columns. Shortens the
             fragmentation. If there is column top float (only in
             left column) then one column is shortened but not the
             other one.
   fantasai: If it is a column float then the column is not shortened
             but the content of the column is.
   Florian: Column box is the same size but the area used of column
            content is shortened.
   Florian: I think we have enough feedback and ideas to go ahead and
            do a bunch of edits.
   proposal: 1D page floats shortens the content area of the
             fragmentation, therefore backgrounds and borders of the
             fragmented content do not extend through the float area

   RESOLVED: 1D page floats shortens the content area of the
             fragmentation, therefore backgrounds and borders of the
             fragmented content do not extend through the float area

float: end vs float: inline-end

   Florian: I think logical properties are blocked on page floats.
            float: end vs float: inline-end
   Florian: Are we sill blocked?
   fantasai: Seems to me that the main question is whether float
             would take two position keywords or would it be an
             unordered thing. That is the question.
   fantasai: For scroll-snap-align we have two keywords with a fixed
             order. Therefore no prefix needed.
   Florian: The distinction between 1D and 2D means start in one
            dimensions doesn't necessarily imply anything about the
            other direction.
   Florian: For 1D it can't be just start, it needs to be block-start

   johanneswilm: If I recall correctly, with a 2D float the stacking
                 direction would be different. Top-left vs left-top.
   johanneswilm: If we don't have 2D then it should be easy.
   Florian: I think with clear changes this goes away...
   Florian: Instead float start isn't a thing, we don't know the
            axis. Needs to be block-start or inline-start.
   fantasai: Sounds like we're going with block-start and
   proposal: Add start and end keywords and always qualify with block
             and inline prefixes. block-start/block-end/inline-start/

   RESOLVED: Add start and end keywords always qualify with block-
             and inline- prefixes: block-start/block-end/inline-start/

Received on Saturday, 27 May 2017 00:58:40 UTC