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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Apr 2018 23:14:53 -0700
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <fb430c94-5ea4-b404-e3ff-65c94a89427f@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:


   - 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


   - 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.


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



   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


   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...


   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


   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


   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


   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


   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


   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 06:15:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:10 UTC