W3C home > Mailing lists > Public > www-style@w3.org > April 2018

Re: [CSSWG] Minutes Berlin F2F Tue 2018-04-10 Part III: Spatial Navigation, Floats [css-overflow][css-floats] / single-spaced

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 27 Apr 2018 14:28:36 -0700
To: www-style@w3.org
Message-ID: <de4145c8-c4e1-bc70-9eab-eb2016cd1707@inkedblade.net>
=========================================
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.
=========================================


Spacial Navigation
------------------

   - Jihye showed a demonstration of how the spec has progressed so far:
       https://wicg.github.io/spatial-navigation/demo/blog/
   - Much of the current spec isn't about CSS, but it has raised questions about
       terminology and making it easier to refer to scrolling concepts.
   - It was suggested that all the definition of terms occur in CSS Overflow
       to make it easier to reference terms.
   - There's significant interest in having this spec assist accessibility
       concerns.
   - The group did not think that adding information about hit testing would
       be valuable.
   - Exposing a new Media Query that would give data on interaction media
       feature navigation raised concerns about possible fingerprinting.
       If there are strong use cases the group will reconsider.

   - RESOLVED: Add the definition of the border shape edge to Borders and
               Backgrounds L3 (Issue #2324: Missing box terminology).

CSS Floats
----------

   - Originally there were three proposals to address issue #2452
       (What happens when a bfc height grows such that it intersects
        with a lower-placed float that was not considered when choosing
        its width):
       1) Attempt all possibilities until one fits (what Firefox does)
       2) If it doesn't fit you try one more layout
       3) Put the BFC under the floats (what Edge does)
   - Option 3 is the most performant, but option 1 was what users would expect.
       Option 2 was a compromise, but since no one implements it currently there
       were objections to resolving on it.
   - The group agreed on Option 1 and will request more performance data from
       whomever implements so that they can re-open this if there is a
       significant performance issue.

   - RESOLVED: The working group preference is to specify BFC float avoidance
               behavior to match the guidelines of what is spec in 2.1 for
               inline layout float avoidance behavior.
   - RESOLVED: Start a CSS 3 Floats Module with dbaron and fremy as co-editors.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

Spatial Navigation
==================

   Demo link: https://wicg.github.io/spatial-navigation/demo/blog/
   Spec Link: https://wicg.github.io/spatial-navigation/
   jihye: spatial navigation is the ability to navigate between
          focusable elements.
   jihye: florian and I introduced this draft last year. Most browsers
          have not historically offered these features. Some browsers
          have allowed it using arrow keys. No browser now provides it
          by default. Some web apps provide using JS libraries.
   jihye: We thought to spec basic behavior and provide some overriding
          APIs of the default behavior.

   jihye: [shows spec]
   jihye: florian and I wrote the ED. It includes processing model which
          is basic browser behavior. We're writing overriding APIs and
          the CSS property.
   jihye: I also made a polyfill based on the spec. It's not complete,
          but supports main behavior

   florian: This is mostly not a CSS spec right now. From a CSS sense
            it's as if everything was auto. We need to say what happens
            when a user tries to do things when everything is auto and
            then we have some JS for changing auto.
   florian: We started with CSS properties but with limited data on what
            authors and users want. We thought it was better to get the
            basic APIs and then add additional CSS properties based on
            what people do with JS. This works without JS, but the JS
            overrides. The questions we have later is things the depend
            on layouts.

   jihye: [shows demo]
   jihye: In the page there are several focusable elements and you can
          navigate using arrow keys. You can do with tab, but you have
          to press more times. Web apps using inline layout, spatial
          nav is very useful.
   jihye: [shows a page with many examples of layout]
   jihye: There's many corner cases, including hover cases.
   florian: One of this thing we're interested in seeing is the long
            standing questions about re-ordered sequential navigation;
            we think they want spatial navigation. We're interested to
            see if people still want the re-ordered sequential after
            we've done this.
   tantek: There's always been an a11y desire to make sequential work
           without a spatial view.
   florian: This is a side note.

   Rossen: We've been implementing and shipping spatial nav on Xbox
           with Edge for a few releases. We've precieved it as a general
           UI nav, and for that reason we're allowing a generic UI for
           a11y and anything, including XBox controller or input based
           on Kinect motion or verbal commands, is just working.
           We don't have to deal with all modes of input and user input,
           that's mediated by a11y interface.
   Rossen: Also, from what tantek said, I've been in the APA WG and
           that's been their top gripe about flexbox and grid and
           everything else. I'm very interested in anything we'll do
           to help those efforts. If we're not solving this for a11y
           as well I think we're missing out.
   <tantek> agreed with Rossen
   florian: We have an open issue saying if you have use cases not
            solved by spatial nav for reordered sequential please tell
            us. We haven't heard, but maybe don't have the right eyes.
            I don't think there's anything incompatible, but I've heard
            conflicting requests about the sequential navigation, and
            some of them may be solved here.
   tantek: It's better to look through mintes for joint CSS WG and a11y
           meeting at TPAC 2017.
   florian: I did. There's multiple people saying conflicting things.
            I suspect that some of these conflicts would go away once
            we have spatnav.
   florian: But that's not what we wanted to talk about today.

Missing scroll-related anchoring terminology
--------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2322
           and https://github.com/w3c/csswg-drafts/issues/2323

   florian: For issues, one thing that became apparent is spatial
            navigation isn't easy. If the first focused button is
            several pages down you want to scroll until you get to
            it. When we tried to specify in relation to scrolling,
            we found it difficult to define in terms of CSS.
            There's some in overflow, some in scroll snap points,
            some in CSSOM view which defines APIs. These bits are
            not well integrated. The more procedural approach in
            CSSOM view doesn't talk about snap points.
   florian: We have two issues on the agenda. #2322 and #2323

   florian: It's the desire for a scrolling spec to exist. #2322
            we found a need to refer to a thing that can be scrolled.
   fantasai: Do you want something that can be scrolled by the user
   florian: Yes and that can be manually scrolled. It's not already
            scrolled all the way in. If it's all the way down it
            cannot. If it's the last mandatory scroll point you cannot.
            If a use wants to scroll in this direction, could they?
            We found a need to try and talk to that. You can describe
            this, but there's no single term.
   fantasai: What do you want the WG to do?
   florian: These two issues call for a scrolling spec that folds all
            the things in so that we don't have to talk about properties
            from many specs when talking about scrolling. What's the
            WG stategy to make scrolling easy to refer to?
   fantasai: Having terminology defined in Overfow makes sense if it's
             general. If it's API-based it should be in CSSOM.
   florian: This is anchoring terminology.
   fantasai: CSS Overflow

   florian: We needed a thing that can be manually scrolled in another
            direction, and the other is scrolling directionally by a
            UA-defined amount, taking into account all the other properties.
   fremy: Scroll a single user?
   florian: If you pressed the down arrow, find an anchoring term
   fantasai: Scroll in intended direction.
   <fantasai> https://www.w3.org/TR/css-scroll-snap-1/#scroll-types
   florian: There's the classification of things in Scroll Snap.
   fantasai: We can move that section to Overflow.
   Rossen: I think what fantasai said is CSS Overflow is where terminology
           should be. If it's not there point it out. In terms of additional
           features that live on those terminologies, we shouldn't have base
           definitions in css-snap-points.

   florian: So propose terms move to Overflow with notes to spec how they
            affect that term
   majidvp: Overscroll introduces scroll boundary and that's something you
            alluded that you needed so it makes sense to refactor.
   florian: I'll propose the relevent edits.
   Rossen: For issue #2322 do you need anything for the group?
   florian: No, I need to propose.

Questions from demo discussion
------------------------------

   myles: I wanted to ask for clarification on the xbox. Were you talking
          about logical vs visual ordering or talking about making the API
          work for a11y?
   Rossen: Mine was about that we've been asked many times to help a11y
           WG by defining how the flexbox reordering, or grid, plays nicely
           with a11y. a11y for all the providers today is still tree-based,
           and based on content order. If you reorder using flex order or
           you target visually different grid cells you are disconnecting
           visual order from content order.
   Rossen: This has been the #1 issue the a11y WG has been asking us to help
           them solve.
   Rossen: They have also been asking in addition for help with general
           spatial nav. Put aside flexbox and grid, if they have a canvas
           with a bunch of little things inside, how do the spatially
           navigate? Like with a map. Then going back to HTML/CSS how do
           you navigate over a document.
   Rossen: I sympathize with the effort. I hoped florian and jihye's work
           would help with both things. I hoped that they wouldn't reinevent
           the wheel with how it currently works. If this is something that
           can aid this.
   florian: Clarification. We're trying not to reinvent. Our model is closer
            to the one that exists in Chrome. It doesn't exist by default,
            but you can get it in a console command and it's similar to
            presto. I don't know the type of spat nav.
   iank: It's similar to presto when it was in opera.
   Rossen: myles does that answer?
   myles: Yes.

Missing box terminology
-----------------------
   github: https://github.com/w3c/csswg-drafts/issues/2324

   florian: css-backgrounds-3 says border-radius changes the border edge.
            If you link to “border edge” it doesn't say if it effects it.
            The spec that does talks about border edge but not the other
            various boxes. It makes it really awkward to refer to in other
            specs. If we can define the border edge in level 3
   TabAtkins: I like “shaped border edge” to refer to it.
   florian: And we can add all the things that can be shaped.
   TabAtkins: We wanted to refer to the things outside.
   florian: If it effects hit testing it should be there.
   iank: clip-path yes, but I don't believe share-outside affects it.
   florian: Editors will do it? I think it's border and backgrounds L3
   TabAtkins: Sure. Seems fine.
   astearns: Since it's just missing testing to go to rec....it's just a
             term. As long as you don't open hit testing against backgrounds
             and borders L3 I'll be happy.
   Rossen: proposal: Add the definition of the border shape edge to Borders
           and Backgrounds L3
   RESOLVED: Add the definition of the border shape edge to Borders and
             Backgrounds L3

Hit Testing
-----------
   github: https://github.com/WICG/spatial-navigation/issues/29#issuecomment-378153116

   florian: Is this an operation that we can use or is it hard to impl?
   florian: When you have dialogs or things popping over a page, you can't
            click on the things behind. Currently tabbed navigation can get
            behind, but spatial navigation is relatively new. It would be
            nice that if an item can't be clicked on also can't be navigated
            to. It could be possible to declare these things as inert, but
            if we didn't have to ask authors it would be good. Can we or is
            it hard to implement?
   tantek: It would require normative reference to “can you click on it”.
   florian: We haven't defined how hit testing works, so we don't have to
           depend on it.
   iank: If there's a 1px edge and you want to test exposed?
   florian: If it's barely visible then you made it visible.
   iank: This is asking for hit testing on an area and you have to determine
         the area?
   smfr: As you scroll and animations run you have to animate every frame.
         It's super hard.
   Rossen: Every implementation layers differently. We layer for perf.
           We layer things interdependently for painting and hit testing
           doesn't benefit on that. Mechanics of doing hit testing may
           suffer, but hit testing isn't highly demanding.

   Rossen: Thing to point out, though, I would encourage you to take a look
           at HTML AAM or ARIA AAM and see how they go about it. They define
           landmarks and all of the sites I've seen with pop ups they have
           a11y.
   florian: There are mechanisms to say obscure things aren't interactive.
            Given our thing doesn't have compat baggage, if it's necessary
            for authors to make them do it that's okay, but if it could be
            authors don't have to do anything it's a nicer experience.
   Rossen: You'd discourage authors to do what's recommended for a11y reasons.
   florian: I'm hearing hard to implement and possibly not desirable;
            don't do this.

   fremy: We have a JS-exposed function called msElementsFromRect where
          we return all elements that match the rectangle. Rectangles are
          easy but shapes and SVG things get harder. If you want to define
          this as there is an element for the entirety of the object.
          Can you click on some pixel is hard.
   Rossen: And then you get into the argument of where is the origin of
           the pixel.
   fremy: If you want to see if there is one object that completely covers
          another object that's easier.
   Rossen: And with this you don't get the order of the rects.
   florian: So rely on author actively disabling things.
   Rossen: Which they should do for a11y. I would continue encouraging
           people to support that a11y agenda. It should work for everyone.

   tantek: florian you said you saw contradicting items. most comprehensive
           write-up is from James Craig. I would reach out to him to ask for
           him to point you to latest thinking

Interaction media feature navigation: none | sequential | spatial
-----------------------------------------------------------------
   github: https://github.com/WICG/spatial-navigation/issues/41

   <jihye> https://github.com/w3c/csswg-drafts/pull/2494
   florian: We have a few media features that let you test input device
            to try and help author of page media-query their way into
            more convenient UI
   florian: We propose it would be useful for an author to know if user
            has sequential or spatial navigation available to them.
   florian: If you're on a thing that lacks a mouse but has spat nav,
            grid is fine. If you lack a mouse and spat nav you likely
            want visually linear. Having a ability to know if they
            match seems useful.
   florian: Web signage would be an example of having neither.
   florian: I made a PR, can we add that to MQ L5?

   fantasai: Reasonable to me. might want to distinguish 4-direction
             navigation and navigation that can go in any direction
             (e.g. joystick).
   florian: I'd suggest opening that as an issue on the feature.
   fantasai: Okay.

   Rossen: If you have a mobile device and are connected to a hub that
           gives you keyboard and mouse, what's the expectation?
   ...
   florian: It's also for authors to not be unreasonable. You can query
            ability to hover when there's a mouse. You could reorder
            the whole page at that time, but it would not be wise.

   smfr: I'm slightly opposed to a MQ that exposes a user setting
         because it's extra fingerprintting.
   Rossen: I also want to echo smfr concern about user fingerprinting.
           We're going through extreme efforts to not bleed anything
           into the user logic level that would ID users with disabilities.
   <tantek> Also want to echo concerns about fingerprinting
   florian: I think this is different where devices that provide this
            always and devices that allow it. If it's an opt-in
            functionality we can say you're allowed to opt-in.
   dbaron: I'm a little skeptical to the fingerprinting concerns because
           the site can tell what the user is using anyway. They'll get
           mouse events.
   smfr: True, if those events go to a frame doing detection. Detection
         without user input is more dangerous.
   fantasai: I would hope we'd get more browsers implementing spatial nav.

   myles: Would MQ enable when you press modifier.
   florian: The MQ would not be on when you press a key, it's on when
            you're in a browser where spatial navigation is enabled.
   myles: So every page gets this MQ when you update your browser the
          internet looks different... being a spatial nav enabled browser
          is different then saying optimize your site for spatial navigation.
   florian: I don't think it means prefer spatnav. It's like when hover is on.
            If I'm about to do a design that would look terrible without
            that feature, I should rethink when you don't have it available.
   florian: This isn't meant as a request for preferring design for spatial
            nav. Design for spatial nav is typically a typical design.
   myles: So if every major browser ships, what would a web author do with
          this MQ?
   florian: If you're on a device with no pointer but there is spatial nav
            it's reasonable to have the same main layout we see. If there's
            neither it's not so great. If you're on a TV with no tab key
            you might want to know.
   smfr: Are there any UA where tab is only form of nav? We should encourage
         people to write web content that works everywhere, not content
         that works with a mouse but is terrible with tab navigation.
         This feels a bit too far. And we shouldn't assume there's UAs with
         only terrible tab navigation. Those are bad UAs.
   smfr: I'd prefer not to have this.

   florian: Summarize the feedback as "hmm maybe, come back with stronger
            use cases"
   smfr: Yeah.
   Rossen: I'd say "hmm not really but if you come back with something
           stronger we'll reconsider"

   Rossen: Anything else for spatial nav?
   florian: Just a request for people to look at what we've done.
   <florian> https://wicg.github.io/spatial-navigation/
   Rossen: That's jihye and florian

CSS Floats
==========

Complex float shapes and bfc sizing
-----------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/2452

   The diagrams being discussed are funky things like placing a series of floats
   into configurations like the following, and then trying to flow content
   (lines or BFCs) into the remaining space in the container.

   +------------------------------------+
   |###                      ###########|
   |###                      ###########|
   |###                      ###########|
   |################         ###########|
   |################         ###########|
   |################                    |
   |################                    |
   |################                    |
   |############################        |
   |############################        |
   |##                                  |
   |##                                  |
   |##                                  |
   |                                    |
   |                                    |
   |                                    |
   |                                    |
   |....................................|

   fremy: [whiteboards]
   fremy: Issue is pretty simple
   fremy: When you have a float and another float later that has a different
          shape constraint. We try and size the BFC in the remaining space
          in the block. If your BFC is taller than the point where size
          constraint changes then you have to do something.
   fremy: In FF every time this happens, a new layout is drawn and we try to
          resize the BFC. It's repeated as many times as needed. It's an
          arbitrary number of relayouts.
   fremy: Chrome looks like some weird behavior where they tried to do it
          but it broke websites.
   fremy: We'd like to find something in the middle

   Rossen: We'll layout in the first available space and then slide the other
           block down until we find space. We're optimizing for not relayout
           so we avoid overlap
   astearns: But you're not using the width of the space.
   Rossen: We are. The BFC might become wider and shorter so you don't
           intersect. When I wrote this in like IE9, you do an intersection
           with all your geometry until you fit the space in your initial
           BFC and you use that.
   iank: Did you change recently?
   Rossen: Maybe but not so much
   fremy: We do first layout and move the box to the first place you fit.
   Rossen: We may not do relayout.

   dbaron: One problem with the description. While making something wider
           generally makes it shorter, sometimes it makes it taller.
           Like when you have an overflow:hidden and the image has a
           fixed width if you make it wider the image gets taller.
   dbaron: You can't assume that it's going to not overlap.
   dbaron: Other thing is these overlap cases happen on real websites,
           especially Wikipedia. Browsers that get this wrong have
           overlapping content in Wikipedia.
   dbaron: In wikipedia cases, FF has like 3 layouts.

   iank: We looked into this. We think our current implementation is a
         little funky. One thing we can do is you look for next available
         area that is unbounded and doesn't have a float blocking it off
         at the bottom.
   Rossen: You can have a zigzag of floats. If you want to start filling
           it with a zigzag you'd push the first BFC down in this case.
   iank: It will skip the zig zag. That's the best 2 pass.
   fremy: 2 pass option, first we try and use the size. If you overlap
          with another float you can try to get the smallest distance
          that you have in the future and try to layout in that narrow
          space. If that's more then the minimum space you do the usual.
   Rossen: What do you mean it'll work in 2 passes?
   fremy: If it doesn't work we do edge behavior, but if it does you find
          the smallest space in the future. You simplify the geometry and
          the remaining space is what you try to use.
   Rossen: Furthest left and furthest right can be disjointed.
   fremy: To get 2 passes. [missed]
   <iank> Here is a testcase I created a while ago...
          https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5370
   florian: So furthest left and right, not shortest distance.

   dbaron: There's one assumption about gecko you made that I think is
           wrong. I think you assumed we did a layout...let me check...
   dbaron: I think we're using intrinisic min-content width for checks
           and not doing layout.
   dbaron: We're doing a layout to determine the height.
   Rossen: That's the one we're talking about. The widths are created
            by the geometry.
   dbaron: I need to read the code...

   iank: One thing to point out is when you introduce margin collapsing
         if the BFC's margin affects position of floats.
   Rossen: If BFC positions after the floats it will have to be in content
           order. Only thing that could be effected is BFC position
   iank: Margins collapsing through in an empty div.
   Rossen: But they're already committed.
   iank: Not until you know the final margins.
   iank: You can have a margin that's further down in the doc that affects
         where the floats are positioned.
   Rossen: You'll have to show me the test case.
   Rune: top margin will collapse through?
   iank: Yes.

   Rossen: dbaron did you get this into your head?
   dbaron: Kinda. There are a set of positions you can reject without layout.
   Rossen: What does 2.1 spec suggest?

   astearns: From my recollection when defining shapes, FF has the right
             behavior where you slide things until it fits.
   Rossen: What do you mean by slide? In fremy picture, would you consider
           sliding?
   astearns: I recall line layout, not BFC.
   Rossen: Line layout is rigid.
   dbaron: Line layout has the same problem because the line can also get
           taller.
   astearns: And trying them at a lower position can change the width.

   Rossen: [draws]
   Rossen: Assuming this geometry is what you have to play with (large
           multi-tiered box) what do you mean by sliding?
   Rossen: Let's assume everything above is taken. First place you can
           position is here. Then you arrive and get to some kind of
           layout. Is sliding on the x axis? one of the geometries?
   dbaron: For both line layout and BFC you have 2 nested loops.
           If you fail to fit....the outer loop is over your y position
           and the inner is over your reduction in width.
   dbaron: If you try and place here and fail because it intersects
           below, you narrow your width to account for the intersection
           and try again. You go until you fit or you fail but there's
           no more floats.
   dbaron: That's the inner loop. Outer loop is we failed to find a
           width for this vertical position so then we move down to
           the next vertical position with more room.
   dbaron: In the simple case what we implement right now is looking
           for the next position where something changes.
   dbaron: Traditional floats it's not that bad, in shapes we should loop

   iank: On shapes we switched shape sizes and BFC, so shape-outside has
         no effect on a BFC.
   dbaron: I think you can exclude a decent amount of things.
   astearns: Changing what you're doing depending on regular float vs
             shape-outside, I don't think that makes that much sense.
             Everything you can do with shapes you can do with a
             sufficient number of floats.
   iank: We have use counters saying it's not used so we switched it off.
   astearns: I'm not that concerned with BFCs but everything we're
             discussing as a problem for BFCs is also a problem for
             placing first line of non-BFC content next to floats.
   iank: Slightly different.

   Rossen: In general what you describe makes sense. I hope there's a
           spec where we can define this. I failed to find anything
           when I implemented.
   astearns: Section 9.5.1
   dbaron: 2.1 defines itfor lines but not well for BFC is my memory.
   dbaron: All float rules in 2.1 are in terms on constraints and this
           is a case where constraints is a bad way of defining it.
   fremy: This is potentially a lot of layout.
   iank: In our new implementation of block layout we went with FF's
         behavior, going through each opportunity.
   Rossen: From user POV that's the better behavior.

   iank: I can describe the 2 pass method.
   iank: The 2 pass one is layout and the based on I think min-content
         you lay out in one of the areas.
   fremy: I proposed you first try the first position. Then you try
          the furthest right space. If it's bigger then the min-width
          you put the element there. That's what Edge is doing. I'm
          fairly confident that'll work almost all the time and then
          you don't have to layout again and again. As an author you
          don't expect this to be super expensive, but it can be.
   <rego> this non-BFC example has overlapping issues on Blink/WebKit
           http://jsbin.com/yebelixowu/1/edit?html,css,output
   florian: If I understand dbaron in the case without minimum, the
            extra part you compress. But if you have the minimum you
            have to do a re-layout.

   dbaron: Most expensive case is [whiteboards]
           a table and you're dealing with a shape that has a really
           rough uneven edge.
   dbaron: So you keep having to relayout.
   iank: This is why we switched this off for shapes.
   fremy: We only do this a few times and then give up and overflow
          the floats.
   fremy: What this would do is it would try to lay it out and if it
          doesn't work it would clear the table under the shape.
   [But not relayout in the larger space after clearing]
   astearns: I'm not sure the example of the narrowest place works
             for this example.
   dbaron: Depends on what the shape is.
   fremy: If the table fits it fits. If it's bigger it goes underneath.

   myIes: I think the point is it's valid, but not good.
   astearns: I see the appeal from an implementation side, but as an
             author I can't imagine wanting this... if an author wants
             the content as far up in the layout as possible so FF and
             half of Chrome is what I expect an author would want.
   astearns: If we have to have a strategy to avoid re-layouts, giving
             up and going past the float may be better.
   fremy: Chrome would like to remove this thing.
   iank: We've removed shapes. We added counters to shapes and barely
         saw usage. I believe shapes now only effect line-boxes.
   iank: As people add lots of floats, sure. Shapes is easy to go into
         every max-length.
   dbaron: I think saying shape-outside doesn't effect BFC is a
           reasonable compromise.
   astearns: We deferred to 2.1 in the spec.
   fremy: [missed]

   dbaron: I think wikipedia looks better with the algo.
   fremy: In most cases you do it in 3 which gets you same result.
   dbaron: It's reasonably common that the narrowest thing will be
           something narrow.
   astearns: Because we counter with shapes and BFCs is small, a
             different rule for BFC is fine. But I'd hate that to be
             a precedent for line layout.
   iank: That's easier because when you do the first pass you know
         the height.
   astearns: I don't mind as long as it doesn't apply to line layout.
   florian: Are you sure problem isn't for lines?
   dbaron: You don't change height of the line depending on it getting
           narrower. If you shrink the line it might get shorter,
           but it won't increase in height. If you shorten the line
           and it gets shorter in height, but it fits, you leave it.
   iank: Always works in 2 passes.
   Rossen: And for BFCs the narrower you make it, the longer it gets
           usually.
   dbaron: You can guarantee the shortening look is 2, the moving
           down can be more loops.

   fremy: 2 proposal. 1 to say BFC....
   Rossen: 1) Do all possible layouts which will optimize for the area.
   myles: 2) layout to widest. If it doesn't fix calculate some numbers
             and if it doesn't fix clear it.
   myles: 3) is always clear it.
   Rossen: We try and find space for the layout and then clear it.
   fremy: Reason we're here is we've found 3) is not good on Wikipedia.
   myles: 1 is what user wants. astearns pointed out option 3 may be
          better than option 2 for user.
   fremy: [missed]
   astearns: Option 1 will often find a > min place to put the BFC.
   fremy: Not as likely.
   dbaron: Depends on the floats.
   dbaron: If your floats are like this (smallest on top right) then
           you'll be fine on the top.
   Iank draws two stepped sets of floats, one of decreasing widths
        on the left, one of increasing widths on the right, leaving
        a stepped diagonal channel

   Rossen: Can I make a proposal? I'm not sure we'll be able to resolve
           without wasting more paper. Holding the whole group on this
           prob. not very helpful. Let's take this over lunch with the
           people interested.
   Rossen: So what we believe is best for user and impl and we'll come
           back after the break.
   dbaron: I think one resolution that solves part of the problem is
           the interaction with shapes and BFC. Prop: BFC flow around
           floats don't care about shape-outside.
   fremy: If you do shape-outside and you do a float BFC is wrong.
          If you do shape outside the entire element floats.
   florian: For FC it's rare enough it's okay.
   Rossen: Shapes with BFC is probably not common. Shapes with text is
           how feature was intended.
   myles: Why do we want this proposal?
   iank: Implementation complex.
   dbaron: Gets rid of worst cases.
   myles: You just look at mins and maxes
   Rossen: Whatever you have with shapes you can make with floats.
   dbaron: Okay, I take back that we might be able to resolve.

<br type="lunch" dur="60min"/>

   Rossen: Let's resume
   <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5879

   [projector projects a diagram on Rossen's computer]
   * astearns wonders whether the rainbow layout versus the black gloomy
              layout with red glowing eyes means anything
   Rossen: This is the picture we were trying to illustrate on the white
           board. It's intended to illustrate the 3 proposals.
   ACTION Rossen send the image of to www-archive@w3.org
   <trackbot> Created ACTION-872

   fremy: Proposal #3 is when you have an image that overflows you
          just push it down, but that was also leaving a lot of empty
          space. Edge is doing that right now.
   Rossen: We do one layout. We're assuming inline is in top left.
   astearns: BFC tried for full width and intersected with float.
   Rossen: Right. If we don't fit because we intersect, we try to fit
           and end up at the bottom (behavior #3)
   florian: Width is full width of containing block?
   Rossen: Might not. It doesn't fit.
   fantasai: That's super weird.
   Rossen: And super performant!
   <fantasai> Rossen was explaining that once they've cleared past the
              floats into a larger-width area, they don't lay out into
              that larger area but keep the width of the initial layout
              into the float-impacted area.
   <fantasai> This is what I thought was super weird

   astearns: Edge is getting bugs on clearing and leaving the empty space
             above.
   Rossen: Say you have a div and a tiny 0 width float and then another
           small float. In this case there's a 0 width, which we layout
           the BFC next to the 0 width. But it intesects with the other
           float. Then we slide the BFC down. Say it doesn't fit and
           then it's before the small float.
   Rossen: you can argue we can fix our bug with behavior #2 which has
           different drawbacks.
   fremy: Proposal #2 is if it doesn't fit you try one more layout.
          You try to find first place you can fit the min content of
          the BFC you're trying to place. If you can fit the min-content
          you put it there. Downside is you may end up in a situation
          where it goes down if the min-width is too small. You try to
          find somewhere you can fit the min-content and there are no
          floats limiting the height below it. It doesn't require
          any layout. It's guaranteed valid. Drawback is it could be
          min width is very small so you get very tall.
   florian: In this logic if there is several places you can fit do
            you try all?
   iank: The first one. In this case there's three areas. You start
         at the first and if it fits you put it there.
   fremy: If it doesn't you try the second and then the third.
   iank: It's a 2 pass layout and you're trying all areas.
   astearns: It fixes the floated UI issue.

   fremy: Option 1 is Firefox. It's literally trying all possibilities.
   fantasai: Nobody gets the rainbow where it is?
   Rossen: Firefox is rainbow.

   iank: I posted a link at 1:22 pm of a test case for this.
   myles: rainbow is FF, 3 is edge, no one does 2.
   iank: Blink and webkit is undefined.
   fremy: There's one thing I don't like is that.
   Rossen: People use zero-width floats to vertically offset other
           floats. It's the only way to offset floats veritically.
   fremy: No gap here (position the float, then the BFC) means that
          someone really wanted that space.
   astearns: So we have 3 which goes below the floats. 2 which makes
             an attempt based on heuristics. And 1 which does the
             best but is expensive.
   fremy: Also will Chrome disable this for shapes.

   astearns: Rossen said there was a conclusion.
   fremy: [missed]
   group decision: no conclusion
   fremy: If people won't agree on #2...I think we should resolve on 2.
   Rossen: 2 is improvement for us and Chrome, and reduced experience in FF.
   iank: The test case I dumped in IRC we do 2 in.
   <iank> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5879
   astearns: Would anyone object to specifying the second option?
   dbaron: Who does it now?
   many: no one
   dbaron: I would object to spec something no one does.

   fremy: We can't spec what Chrome is doing. Firefox is option 1.
          That's better then our version.
   astearns: Sounds like we don't agree.
   iank: We can see how expensive 1 is.
   Rossen: We can resolve on 1, ask whomever implements it to spec it.
           If there is a performance concern, we can ask to get some
           data back. In the meantime other implementations... we'll
           do something to fix.
   Rossen: For normative behavior it's hard to argue #1 isn't the best.
           It's up to us to figure out easy engineering tricks to
           optimize as much as possible.

   Rossen: So is there objections to #1?
   fantasai: Sounds better.
   astearns: Objections to spec #1 for BFCs?
   fremy: No special about shapes?
   Rossen: No, nothing special about shapes.
   astearns: If we specify this, then we'd need a floats module.
   Rossen: Let's get a resolution about the behavior we want.
   astearns: Prop: The working group preference is to specify BFC float
             avoidance behavior to match what is spec in 2.1 for inline
             layout float avoidance behavior
   Rossen: ish.
   astearns: To follow those guidelines and spec it well.
   astearns: Objections?
   RESOLVED: The working group preference is to specify BFC float
             avoidance behavior to match the guidelines of what is
             specified in 2.1 for inline layout float avoidance behavior

   Rossen: Where does this go?
   florian: 2.1?
   astearns: I think Floats module. 2.1 is vague on inline.
   Rossen: In CSS positioning the fork happened for floats and position.
   fantasai: I'd recommend not in the same module because positioning
             and floats are quite different.
   Rossen: That's okay. We can take the line out of 2.1 and start a module.
   Rossen: A resolution for that?
   gsnedders: If we're removing a line from 2.1 we should have a resolution.
   astearns: We're not taking out, we're making a module to refine.
   astearns: objections to someone creating a css float module at some point?
   Rossen: I can create the fork and start it.
   dbaron: I can help, but I don't want to be only person.
   astearns: objections to rossen and dbaron creating a css float module?
   smfr: This isn't about float layout, but wrapping behavior. So if shapes
        trigger same behavior doesn't make sense.
   astearns: Shape-outside is in relation to floats and exclusions would tie in.
   fantasai: I think Floats is right place.
   dbaron: I think if I'm putting it with something, it would be block layout
           and we don't really have a L3 for that.
   myles: That's better then proposal. Rather then a new spec we should have
          someone take up stewardship of the block layout
   fantasai: It has way more stuff in it than just floats.
   astearns: Like with any other module the bits and pieces that refer to
             other specs say it's defined over there.
   astearns: Can be floats module, can be wrap. They're pretty synonymous
             for css so I don't care on the name.
   Rossen: Floats is more specific and targeted.
   astearns: Prop: Start CSS 3 Floats Module with dbaron & fremy as co-editors
   RESOLVED: Start a CSS 3 Floats Module with dbaron and fremy as co-editors

   astearns: We have more layout stuff this afternoon.
Received on Friday, 27 April 2018 21:29:05 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 April 2018 21:29:06 UTC