- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 27 Apr 2018 14:28:36 -0700
- To: www-style@w3.org
=========================================
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