fantasai
2017-05-27 00:58:07 UTC
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Floats breakout
+++++++++++++++
Floats
------
- RESOLVED: Rejigger the spec to use the 1d top/floats.
- Florian gave a brief summary of issue 1236 (inline alignment of
block-end floats- https://github.com/w3c/csswg-drafts/issues/1236)
and 1235 (auto width of block-start/end floats-
https://github.com/w3c/csswg-drafts/issues/1235) in hopes of
getting more attention on the topics.
- RESOLVED: We will use values of clear to have in-flow and floated
content clear other page floats. No placement based clear.
- RESOLVED: Add issue to figure out what happens in a non
paginated context.
- RESOLVED: Use 'float: top bottom' as a way to have something
float to the top or bottom based on proximity and
possibility.
- RESOLVED: 1D page floats shortens the content area of the
fragmentation, therefore backgrounds and borders of
the fragmented content do not extend through the float
area.
- RESOLVED: Add start and end keywords always qualify with
block- and inline- prefixes: block-start/block-end/
inline-start/inline-end
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split part of the morning of the 20 April on two
tracks: Floats and Color/SVG.
Floats breakout
+++++++++++++++
Scribe: eae
Floats
======
1D vs 2D Floats
---------------
Florian: The page floats spec was initiated by us because we
thought we'd need it. We did need it and we've been using
it in projects.
Florian: The spec was intended to be a simple subset and with some
implementation experience the trade off between
implementation ease and ease of use might not be the
right one.
Florian: A deeper rewrite has been proposed.
Florian: Basically the current spec only allows one to float in
one direction.
Florian: top, bottom, left, right. Syntax is 1d, implementation is
2d. Float top is top left, bottom is bottom right.
Florian: This was intended as a gentler introduction with the
intention to eventually expose both axis.
Florian: But float: top and float: top left are different things and
we probably want (leaving aside L1 vs L2) one dimensional
page floats to be one dimensional. So that float: top is
float: top and not float: top left.
Florian: What we found most useful is fully 1d float. You can sort
of get there with 2d floats masquerading as 1d floats but
it is hard.
Florian: Should we move away from the model where 2D floats are
pretending to be 1D floats?
Florian: We think we have a fairly good grasp on how 2D floats
should behave.
Florian: We would prefer to define 1D and 2D page floats to be
different things.
Florian: We could then go into details about how clearance works
etc.
astearns: When you're talking about the sort of 2d floats where
you have a float: top not confusing the full width. Does
content flow around it?
Florian: Depends on the exclusion and wrap.
iank: Float center and nothing can wrap around it?
Florian: Regular block layout?
Florian: If it is a block it will consume full width. If an image
it won't be stretched.
iank: This means it'll be pulled up to the root of the formating
context?
Florian: Depends on the type of float.
iank: That is a little bit.
fremy: The main difference between what you described and what is
in the spec is that bottom floats that also go to the line
end (right for English) they go to the beginning of the
line instead. Text wraps around it?
Florian: That is not the only difference.
Florian: First intuition was bottom right over bottom left.
Arbitrary but impl easier for left.
[Florian draws a page with a float in the lower right corner on
the whiteboard. On the next page the remainder of the box is
at the top of the page. Border and background goes behind
float. That is in the 2D-ish model. Not so much for 1D floats.]
Florian: There are use cases for 2D floats. Absolutely. There are
probably ones for 2D floats that consume the full width.
iank: Some implementation feedback. I think most architectures (at
least ours) the float top at the very least will cause us to
go into multi-pass layout which we would not want to get
into.
iank: The current floats work okay as they do not cause elements
to shift beyond the current line. This proposal has floats
where an arbitrary float in a page can cause all elements to
shift.
astearns: That is true. 2D floats means that don't just shift but
triggers relayout.
astearns: 1D floats would not.
iank: They still could due to fragmentation.
iank: With parallel floats it would be even worse.
johanneswilm: I agree that 1D floats - used in most places. The
question about relayouting, would it help if we said
that the float would always defer to the next page/
column? There have been ideas around policies around
placement where one has them be deferred.
iank: That may work without multipass.
Florian: Might work, not sure if good enough.
astearns: Always deferred, what about the case where there is no
next page/column? Not in a fragmentation context?
Florian: What does it do if in no fragmentation context? Different
question we should address separately.
Florian: Would be simplification but might push it too far and not
be good enough for authors.
fremy: For sure 1D floats are much better than 2D ones, closer
match to what authors are implementing. Not sure if you
need to do any layout if you have a top float as we don't
change the width of the page. Assume we can apply overflow.
Push float top to next page. Think that would solve the
problem.
Florian: Could you be more specific?
fremy: Shift everything down or if not possible push to next page.
Florian: Very big page with a lot of content, say 30 pages of
text, is that enough space?
fremy: Don't layout anything that comes after the float. When you
encounter the float you decide if there is enough space
below and then shift down if you can, or if there is not
then push it to next page.
iank: If you have additional floats in parallel flows is an issue
but would work if nothing has fragmented.
Florian: This is something I'd be happy to leave to a quality of
implementation. It would be okay to push to next page.
Would not be happy with the spec mandated it. It should
be allowed for implementors to do the high-quality multi
pass layout.
Florian: Not intended for building UIs with pixel perfect results.
Allowing both sounds reasonable to me.
johanneswilm: How about having a policy and only have browser
implement the lower level where they do the simple
thing that doesn't require multi-pass layout while
publishing apps could allow for the multi-pass
implementations?
Florian: I think we're saying the same thing. Yay.
johanneswilm: I think the difference is that you'd have a way to
specify which one you want to use. Browsers would
only have one, other tools could have other ways of
doing it.
Florian: Not one of five complex ways in this case.
johanneswilm: If you look at Håkon's alternative spec, he has a
number of suggestions including one where floats
disappear after last page, another one where they
are deferred.
Florian: For level-1 we could spec it without mandating a specific
implementation and then in later versions we could allow
the authors to specify behavior with the known limitation
that browsers may never implement it.
iank: The float: top bottom as proposed at the moment can't have
text or other content flow around it.
astearns: This proposal is a bit like shorting the flow height
like normal floats shorten the line box width.
Florian: If we agree on this it would make the first two issues on
the agenda invalid.
Florian: I don't think we can resolve on spec prose but if we
could resolve on basic idea that would be great.
<astearns> proposal: rejigger the spec to use the 1d top/floats
RESOLVED: Rejigger the spec to use the 1d top/floats.
Inline Alignment of block-end Floats
------------------------------------
<kawakubo> https://github.com/w3c/csswg-drafts/issues/1236
iank: I don't think that we would have any interest in
implementing this.
Florian: We do not expect browsers to jump on this. We want to
make a model where if one day your priorities shift we
want to make sure it can be implemented without violating
design principles.
Florian: For books but also applicable to multicol.
myles: Use cases? is this for books?
myles: How important is this particular feature?
Florian: Very. Things like newspapers or scientific article would
use this. As would magazine layout. Very common for print
formatting.
tantek: I think the distinction between print and browsers is
getting less and less important. Things that are paginated
are going to be in the browser. The assumption that the
two are separate is no longer valid. The web is taking
over a lot of print.
Florian: Big gray zone.
myles: We're all in agreement here.
johanneswilm: The point that we need to make the spec is that
before vivliostyle that had implementations but not
compat. We want to end that. The other point is that
this could be provided for browsers using js and
polyfills without the browsers themselves having to
add support for it.
Auto Width of block-start/end Floats
------------------------------------
<kawakubo> https://github.com/w3c/csswg-drafts/issues/1235
Florian: Next up. What do we do about 2D floats. What about left
and right?
Florian: For left page floats you don't want to chunk it from the
page. I don't think that is typical.
Florian: Use case for page float to the left could be when you
have a multicol and you want to float not in the column
but things like side notes (intruding or not).
Florian: Not symmetrical with the bottom line.
<skk> Our ebook product is using multi-col to create page in
browser. As a side-effect, it's difficult to have column in
pages.
iank: Goes through formating contexts? That is concerning from an
impl. point of view.
iank: Page float inside multicol, would bubble up to the page and
then intrude into multicol? That is scary as we have no way
of intruding into it. We have nothing like it today.
fantasai: abs pos plus exclusion.
Florian: Don't want to deep dive. Wanted to mention.
tantek: Do you have a place where you collect examples?
Florian: Have some private ones, not sure we can share. Much under
NDA.
astearns: We have a number of similar examples for exclusions.
<kawakubo> This is an example of page top (inline-start) float
with vertical text:
http://vivliostyle.github.io/vivliostyle.js/viewer/vivliostyle-viewer.html#x=../samples/shirouma/index.html
<rachelandrew> I have some random bits and examples here
https://rachelandrew.co.uk/archives/2016/06/17/thinking-about-page-floats-figures-regions-and-grids/
iank: Exclusions are only for things before the muticol?
Florian: Not here, bubbles out.
iank: Would trigger multi-pass layout which is bad.
Florian: Not the highest priority, lets move on to 2D page floats.
johanneswilm: Sidebars are probably not floats, if they are then
we need work differently, they have some behavior
where basically they have to shift up if their
contents don't fit on the page, or fragment. They
seem to work differently than top and bottom floats.
Florian: Agreement that they are different and complicated, will
deal with some other time.
2D Floats
---------
Florian: If we have a 2D float it goes there (draws float in lower
right corner), if you have another one if there is enough
space it goes to the left (draws it to the left of the
previous float). If there is not it would go above it.
Florian: Controlling this behavior is what clear is for.
Florian: Clear: all means that the top edge must be below the
bottom edge of any previous float. If you can do that do
it. If not it goes to the next page.
Florian: Fits with how existing floats work. If if fits place it
there, if not push down.
Florian: Want to talk about clear as it'll help us reason about
both 1D and 2D floats.
Florian: If it was tall enough not to fit it would be pushed to
the next page/column/whatever.
Florian: This is different from current definition of clear.
Current definition is not about pushing things down,
current one is about limiting floats of the same type.
astearns: Sounds more like a float handling policy than a clear
property.
Florian: In the current spec clearing an in-flow content will not
interact with page floats.
Florian: With clear as currently defined in page float spec it
cannot apply to in-flow content. If we go back to a
definition of clear that shifts content down we can have
it apply to in-flow and that might be desirable.
johanneswilm: If we only have 1D page floats that basically means
the clear values applies to page floats. Correct?
Florian: Not quite. If you have a page with a bottom page float,
then top float that has clear all. In that case clearing
it would force document order pushing the top float to
the next page.
astearns: If you had a top float that had to go to the next
fragment for sizing reasons and the content after had
clear all the content would also go on the next page.
myles: Where would an inline float go if combine with page floats?
Florian: Not sure, haven't thought much about it.
myles: Also, what if it is taller than a page? Chopped in two and
placed on different pages?
astearns: Pushed to the next container, if it is the only page
float it will fragment. Regular left and right floats
also fragment so nothing special there.
...
fremy: I gave this some thought and I think it makes a lot of
sense to use clear as you (Florian) suggested. One thing
you might want is a way to do float top or bottom. You
would be floated to the top but if there is a clear you
might want to be on the same page and then float to the
bottom.
Florian: Fully agree. Next topic I wanted to go into.
proposal: We will use values of clear to have content and float
clear other floats. Placement based clear.
RESOLVED: We will use values of clear to have in-flow and floated
content clear other page floats. No placement based clear.
skk: This allows for the creation of pages?
Florian: Defined in different spec.
Florian: Use case for applying clear to in-flow content is the
beginning of a new section, want to clear all floats from
previous section regardless of whether they're top or
bottom.
Florian: We will likely need more clear keywords than 'all'. In our
use cases 'all' is all we've needed but we can envision
cases where you'd just want to clear specific ones.
Page Floats in Continuous Media
-------------------------------
fantasai: What happens in non-paged media?
Florian: I don't know. Might not apply?
Florian: Top probably makes sense?
<astearns> bottom float with an infinite scroller
fantasai: Much harder to figure out the reference. You might want
to go to the bottom of the section. There are things you
might want to do like have a 2D float at the top left of
a section. No page reference. Could fall back on BFC for
instance.
Florian: Given that we have a mechanism for picking a reference we
could start by saying it doesn't apply and then change it
to define a reference. Might be weird.
myles: It's hard to gage what the best behavior is without a big
corpus of examples. Think it is important and almost a
prerequisites for discussions like this.
iank: Would be nice if the spec had more details around more
complex issues.
Florian: Yes, spec is improved over the previous level but needs
more work.
Snapping top/bottom
-------------------
Florian: Snapping top / bottom
Florian: Very reasonable to say "float me to top or bottom,
whichever is closer"
Florian: Common to say float me left but if I'm within 3ems float
me to the bottom instead
Florian: Current spec has a mechanism that almost does what I said
but doesn't do either.
Florian: If I'm within 3ems of the bottom float me bottom, if I'm
within 3ems of the top float me top. If neither don't
float me. If both are true float down.
fantasai: We have lh units which will get you closer to what you want.
fantasai: Basing on actual line height creates cyclic dependency,
and is rarely going to be different.
Florian: We believe the float me top/bottom is a more important
use case. Proposed syntax is float: top bottom. Means
float me to either top or bottom depending on which is
closest.
Florian: Different from floating to the left *and* top or bottom.
johanneswilm: There was also the idea to have float: left right.
Are we talking about vertical text or is this for
horizontal text? In horizontal snapping left/right
seems less useful.
Florian: Not meant to be writing mode discussion. Needs to be
converted to logical.
Florian: Not use-case driven for float: left right. float: top
bottom was use case driven as was 2D.
astearns: Let's not do left right now then and focus on top bottom
where we have use cases.
iank: Always in logical space?
Florian: Tricky question. In vertical wiring mode still tend to
flow start bottom.
fremy: If you have float for multiple values, i.e. first try start
then bottom. Not sure this is the best way to express that
you have a preference and a fallback. I see float: top
bottom as a way to prefer to float to the top and fallback
on bottom. Float being a fallback list makes more sense,
that way instead of going to the next page float to the
bottom.
astearns: Sounded like the proposed syntax for float to closest
edge looks like a fallback. You would prefer a different
value meaning either value.
Florian: float: top bottom.
astearns: Asking for a different value that doesn't look like a
fallback.
fremy: Ah, so top bottom as being different from it being a list.
Florian: "top-bottom" or "top bottom" not important but the latter
might be easier
Florian: because doesn't require people to remember the order.
myles: Thinking about how to implement this. Place first page
float at the top and then relayout for the rest.
myles: If you shift down then the other content may end up on
another page.
Florian: That is okay.
astearns: Happens with left floats as well, anchor for left float
can be on different line from the float.
astearns: For the first level we'll only do one dimensional floats
where text doesn't wrap around it. Pushed down.
myles: Pushing anchor to next page may make the float fit on
previous page. Could be cyclical.
Florian: Not OK for anchor to be on same page if float is pushed
to next.
kawakubo: I want to float this element to top or bottom but if
there is already another float at the top of the page
then I want to place it at the bottom. Choose which way
to float depending on the presence of another page float
of the same direction.
fantasai: Feature that was previous part of the clear property. We
resolved to move that to a new property.
astearns: If we have that property then it could be used in
combination with float: top bottom
fantasai: Closest possible spot I think.
astearns: We can resolve on closest possible spot in cases where
there are restrictions based on other properties.
proposal: Use float: top bottom as a way to have something float
to the top or bottom based on proximity and possibility
RESOLVED: Use 'float: top bottom' as a way to have something float
to the top or bottom based on proximity and possibility.
In-place Floats
---------------
fantasai: What about in-place floats?
fantasai: Similar to top and bottom floats that we are talking
about. You have a page and layout some content and you
have a box like and image that doesn't fit. You have to
move it to the next page. Because we moved it there is a
giant gap. Maybe I don't care for having this gap. The
exact position of the float isn't super important but I
don't want to gap. Move lines of text to fill the gap?
astearns: Even if it is float left 100% content following the
float can't be above the float.
fantasai: You don't want to float more things, what if we had a
value like float-inplace that acts like a top or bottom
float that doesn't want to leave gaps. Allow text from
below to fill gap.
fremy: position sticky for floats?
fantasai: No, instead of pushing everything to the next page in
essentially becomes a float: top page float.
Florian: Very useful features. Doesn't have to be in spec
initially.
Florian: Ways to work around it and we can add it later.
fantasai: Seems like a simple addition. One dimensional float.
Florian: float:left *and* snap to top or bottom if within a
certain threshold.
Florian: ^ proposal for new topic
* fremy thinks this looks like "float: none, top" (try none; but
if cant without wrapping, use float top)
Florian: A 1D float shortens the fragmentation, therefor
background and borders of inflow content does not go
behind the float.
kawakubo: Page with two columns, if I place a page top float it
takes the full width of both columns. Shortens the
fragmentation. If there is column top float (only in
left column) then one column is shortened but not the
other one.
fantasai: If it is a column float then the column is not shortened
but the content of the column is.
Florian: Column box is the same size but the area used of column
content is shortened.
Florian: I think we have enough feedback and ideas to go ahead and
do a bunch of edits.
proposal: 1D page floats shortens the content area of the
fragmentation, therefore backgrounds and borders of the
fragmented content do not extend through the float area
RESOLVED: 1D page floats shortens the content area of the
fragmentation, therefore backgrounds and borders of the
fragmented content do not extend through the float area
float: end vs float: inline-end
-------------------------------
Florian: I think logical properties are blocked on page floats.
float: end vs float: inline-end
Florian: Are we sill blocked?
fantasai: Seems to me that the main question is whether float
would take two position keywords or would it be an
unordered thing. That is the question.
fantasai: For scroll-snap-align we have two keywords with a fixed
order. Therefore no prefix needed.
Florian: The distinction between 1D and 2D means start in one
dimensions doesn't necessarily imply anything about the
other direction.
Florian: For 1D it can't be just start, it needs to be block-start
etc.
johanneswilm: If I recall correctly, with a 2D float the stacking
direction would be different. Top-left vs left-top.
johanneswilm: If we don't have 2D then it should be easy.
Florian: I think with clear changes this goes away...
Florian: Instead float start isn't a thing, we don't know the
axis. Needs to be block-start or inline-start.
fantasai: Sounds like we're going with block-start and
inline-start.
proposal: Add start and end keywords and always qualify with block
and inline prefixes. block-start/block-end/inline-start/
inline-end
RESOLVED: Add start and end keywords always qualify with block-
and inline- prefixes: block-start/block-end/inline-start/
inline-end
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Floats breakout
+++++++++++++++
Floats
------
- RESOLVED: Rejigger the spec to use the 1d top/floats.
- Florian gave a brief summary of issue 1236 (inline alignment of
block-end floats- https://github.com/w3c/csswg-drafts/issues/1236)
and 1235 (auto width of block-start/end floats-
https://github.com/w3c/csswg-drafts/issues/1235) in hopes of
getting more attention on the topics.
- RESOLVED: We will use values of clear to have in-flow and floated
content clear other page floats. No placement based clear.
- RESOLVED: Add issue to figure out what happens in a non
paginated context.
- RESOLVED: Use 'float: top bottom' as a way to have something
float to the top or bottom based on proximity and
possibility.
- RESOLVED: 1D page floats shortens the content area of the
fragmentation, therefore backgrounds and borders of
the fragmented content do not extend through the float
area.
- RESOLVED: Add start and end keywords always qualify with
block- and inline- prefixes: block-start/block-end/
inline-start/inline-end
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split part of the morning of the 20 April on two
tracks: Floats and Color/SVG.
Floats breakout
+++++++++++++++
Scribe: eae
Floats
======
1D vs 2D Floats
---------------
Florian: The page floats spec was initiated by us because we
thought we'd need it. We did need it and we've been using
it in projects.
Florian: The spec was intended to be a simple subset and with some
implementation experience the trade off between
implementation ease and ease of use might not be the
right one.
Florian: A deeper rewrite has been proposed.
Florian: Basically the current spec only allows one to float in
one direction.
Florian: top, bottom, left, right. Syntax is 1d, implementation is
2d. Float top is top left, bottom is bottom right.
Florian: This was intended as a gentler introduction with the
intention to eventually expose both axis.
Florian: But float: top and float: top left are different things and
we probably want (leaving aside L1 vs L2) one dimensional
page floats to be one dimensional. So that float: top is
float: top and not float: top left.
Florian: What we found most useful is fully 1d float. You can sort
of get there with 2d floats masquerading as 1d floats but
it is hard.
Florian: Should we move away from the model where 2D floats are
pretending to be 1D floats?
Florian: We think we have a fairly good grasp on how 2D floats
should behave.
Florian: We would prefer to define 1D and 2D page floats to be
different things.
Florian: We could then go into details about how clearance works
etc.
astearns: When you're talking about the sort of 2d floats where
you have a float: top not confusing the full width. Does
content flow around it?
Florian: Depends on the exclusion and wrap.
iank: Float center and nothing can wrap around it?
Florian: Regular block layout?
Florian: If it is a block it will consume full width. If an image
it won't be stretched.
iank: This means it'll be pulled up to the root of the formating
context?
Florian: Depends on the type of float.
iank: That is a little bit.
fremy: The main difference between what you described and what is
in the spec is that bottom floats that also go to the line
end (right for English) they go to the beginning of the
line instead. Text wraps around it?
Florian: That is not the only difference.
Florian: First intuition was bottom right over bottom left.
Arbitrary but impl easier for left.
[Florian draws a page with a float in the lower right corner on
the whiteboard. On the next page the remainder of the box is
at the top of the page. Border and background goes behind
float. That is in the 2D-ish model. Not so much for 1D floats.]
Florian: There are use cases for 2D floats. Absolutely. There are
probably ones for 2D floats that consume the full width.
iank: Some implementation feedback. I think most architectures (at
least ours) the float top at the very least will cause us to
go into multi-pass layout which we would not want to get
into.
iank: The current floats work okay as they do not cause elements
to shift beyond the current line. This proposal has floats
where an arbitrary float in a page can cause all elements to
shift.
astearns: That is true. 2D floats means that don't just shift but
triggers relayout.
astearns: 1D floats would not.
iank: They still could due to fragmentation.
iank: With parallel floats it would be even worse.
johanneswilm: I agree that 1D floats - used in most places. The
question about relayouting, would it help if we said
that the float would always defer to the next page/
column? There have been ideas around policies around
placement where one has them be deferred.
iank: That may work without multipass.
Florian: Might work, not sure if good enough.
astearns: Always deferred, what about the case where there is no
next page/column? Not in a fragmentation context?
Florian: What does it do if in no fragmentation context? Different
question we should address separately.
Florian: Would be simplification but might push it too far and not
be good enough for authors.
fremy: For sure 1D floats are much better than 2D ones, closer
match to what authors are implementing. Not sure if you
need to do any layout if you have a top float as we don't
change the width of the page. Assume we can apply overflow.
Push float top to next page. Think that would solve the
problem.
Florian: Could you be more specific?
fremy: Shift everything down or if not possible push to next page.
Florian: Very big page with a lot of content, say 30 pages of
text, is that enough space?
fremy: Don't layout anything that comes after the float. When you
encounter the float you decide if there is enough space
below and then shift down if you can, or if there is not
then push it to next page.
iank: If you have additional floats in parallel flows is an issue
but would work if nothing has fragmented.
Florian: This is something I'd be happy to leave to a quality of
implementation. It would be okay to push to next page.
Would not be happy with the spec mandated it. It should
be allowed for implementors to do the high-quality multi
pass layout.
Florian: Not intended for building UIs with pixel perfect results.
Allowing both sounds reasonable to me.
johanneswilm: How about having a policy and only have browser
implement the lower level where they do the simple
thing that doesn't require multi-pass layout while
publishing apps could allow for the multi-pass
implementations?
Florian: I think we're saying the same thing. Yay.
johanneswilm: I think the difference is that you'd have a way to
specify which one you want to use. Browsers would
only have one, other tools could have other ways of
doing it.
Florian: Not one of five complex ways in this case.
johanneswilm: If you look at Håkon's alternative spec, he has a
number of suggestions including one where floats
disappear after last page, another one where they
are deferred.
Florian: For level-1 we could spec it without mandating a specific
implementation and then in later versions we could allow
the authors to specify behavior with the known limitation
that browsers may never implement it.
iank: The float: top bottom as proposed at the moment can't have
text or other content flow around it.
astearns: This proposal is a bit like shorting the flow height
like normal floats shorten the line box width.
Florian: If we agree on this it would make the first two issues on
the agenda invalid.
Florian: I don't think we can resolve on spec prose but if we
could resolve on basic idea that would be great.
<astearns> proposal: rejigger the spec to use the 1d top/floats
RESOLVED: Rejigger the spec to use the 1d top/floats.
Inline Alignment of block-end Floats
------------------------------------
<kawakubo> https://github.com/w3c/csswg-drafts/issues/1236
iank: I don't think that we would have any interest in
implementing this.
Florian: We do not expect browsers to jump on this. We want to
make a model where if one day your priorities shift we
want to make sure it can be implemented without violating
design principles.
Florian: For books but also applicable to multicol.
myles: Use cases? is this for books?
myles: How important is this particular feature?
Florian: Very. Things like newspapers or scientific article would
use this. As would magazine layout. Very common for print
formatting.
tantek: I think the distinction between print and browsers is
getting less and less important. Things that are paginated
are going to be in the browser. The assumption that the
two are separate is no longer valid. The web is taking
over a lot of print.
Florian: Big gray zone.
myles: We're all in agreement here.
johanneswilm: The point that we need to make the spec is that
before vivliostyle that had implementations but not
compat. We want to end that. The other point is that
this could be provided for browsers using js and
polyfills without the browsers themselves having to
add support for it.
Auto Width of block-start/end Floats
------------------------------------
<kawakubo> https://github.com/w3c/csswg-drafts/issues/1235
Florian: Next up. What do we do about 2D floats. What about left
and right?
Florian: For left page floats you don't want to chunk it from the
page. I don't think that is typical.
Florian: Use case for page float to the left could be when you
have a multicol and you want to float not in the column
but things like side notes (intruding or not).
Florian: Not symmetrical with the bottom line.
<skk> Our ebook product is using multi-col to create page in
browser. As a side-effect, it's difficult to have column in
pages.
iank: Goes through formating contexts? That is concerning from an
impl. point of view.
iank: Page float inside multicol, would bubble up to the page and
then intrude into multicol? That is scary as we have no way
of intruding into it. We have nothing like it today.
fantasai: abs pos plus exclusion.
Florian: Don't want to deep dive. Wanted to mention.
tantek: Do you have a place where you collect examples?
Florian: Have some private ones, not sure we can share. Much under
NDA.
astearns: We have a number of similar examples for exclusions.
<kawakubo> This is an example of page top (inline-start) float
with vertical text:
http://vivliostyle.github.io/vivliostyle.js/viewer/vivliostyle-viewer.html#x=../samples/shirouma/index.html
<rachelandrew> I have some random bits and examples here
https://rachelandrew.co.uk/archives/2016/06/17/thinking-about-page-floats-figures-regions-and-grids/
iank: Exclusions are only for things before the muticol?
Florian: Not here, bubbles out.
iank: Would trigger multi-pass layout which is bad.
Florian: Not the highest priority, lets move on to 2D page floats.
johanneswilm: Sidebars are probably not floats, if they are then
we need work differently, they have some behavior
where basically they have to shift up if their
contents don't fit on the page, or fragment. They
seem to work differently than top and bottom floats.
Florian: Agreement that they are different and complicated, will
deal with some other time.
2D Floats
---------
Florian: If we have a 2D float it goes there (draws float in lower
right corner), if you have another one if there is enough
space it goes to the left (draws it to the left of the
previous float). If there is not it would go above it.
Florian: Controlling this behavior is what clear is for.
Florian: Clear: all means that the top edge must be below the
bottom edge of any previous float. If you can do that do
it. If not it goes to the next page.
Florian: Fits with how existing floats work. If if fits place it
there, if not push down.
Florian: Want to talk about clear as it'll help us reason about
both 1D and 2D floats.
Florian: If it was tall enough not to fit it would be pushed to
the next page/column/whatever.
Florian: This is different from current definition of clear.
Current definition is not about pushing things down,
current one is about limiting floats of the same type.
astearns: Sounds more like a float handling policy than a clear
property.
Florian: In the current spec clearing an in-flow content will not
interact with page floats.
Florian: With clear as currently defined in page float spec it
cannot apply to in-flow content. If we go back to a
definition of clear that shifts content down we can have
it apply to in-flow and that might be desirable.
johanneswilm: If we only have 1D page floats that basically means
the clear values applies to page floats. Correct?
Florian: Not quite. If you have a page with a bottom page float,
then top float that has clear all. In that case clearing
it would force document order pushing the top float to
the next page.
astearns: If you had a top float that had to go to the next
fragment for sizing reasons and the content after had
clear all the content would also go on the next page.
myles: Where would an inline float go if combine with page floats?
Florian: Not sure, haven't thought much about it.
myles: Also, what if it is taller than a page? Chopped in two and
placed on different pages?
astearns: Pushed to the next container, if it is the only page
float it will fragment. Regular left and right floats
also fragment so nothing special there.
...
fremy: I gave this some thought and I think it makes a lot of
sense to use clear as you (Florian) suggested. One thing
you might want is a way to do float top or bottom. You
would be floated to the top but if there is a clear you
might want to be on the same page and then float to the
bottom.
Florian: Fully agree. Next topic I wanted to go into.
proposal: We will use values of clear to have content and float
clear other floats. Placement based clear.
RESOLVED: We will use values of clear to have in-flow and floated
content clear other page floats. No placement based clear.
skk: This allows for the creation of pages?
Florian: Defined in different spec.
Florian: Use case for applying clear to in-flow content is the
beginning of a new section, want to clear all floats from
previous section regardless of whether they're top or
bottom.
Florian: We will likely need more clear keywords than 'all'. In our
use cases 'all' is all we've needed but we can envision
cases where you'd just want to clear specific ones.
Page Floats in Continuous Media
-------------------------------
fantasai: What happens in non-paged media?
Florian: I don't know. Might not apply?
Florian: Top probably makes sense?
<astearns> bottom float with an infinite scroller
fantasai: Much harder to figure out the reference. You might want
to go to the bottom of the section. There are things you
might want to do like have a 2D float at the top left of
a section. No page reference. Could fall back on BFC for
instance.
Florian: Given that we have a mechanism for picking a reference we
could start by saying it doesn't apply and then change it
to define a reference. Might be weird.
myles: It's hard to gage what the best behavior is without a big
corpus of examples. Think it is important and almost a
prerequisites for discussions like this.
iank: Would be nice if the spec had more details around more
complex issues.
Florian: Yes, spec is improved over the previous level but needs
more work.
Snapping top/bottom
-------------------
Florian: Snapping top / bottom
Florian: Very reasonable to say "float me to top or bottom,
whichever is closer"
Florian: Common to say float me left but if I'm within 3ems float
me to the bottom instead
Florian: Current spec has a mechanism that almost does what I said
but doesn't do either.
Florian: If I'm within 3ems of the bottom float me bottom, if I'm
within 3ems of the top float me top. If neither don't
float me. If both are true float down.
fantasai: We have lh units which will get you closer to what you want.
fantasai: Basing on actual line height creates cyclic dependency,
and is rarely going to be different.
Florian: We believe the float me top/bottom is a more important
use case. Proposed syntax is float: top bottom. Means
float me to either top or bottom depending on which is
closest.
Florian: Different from floating to the left *and* top or bottom.
johanneswilm: There was also the idea to have float: left right.
Are we talking about vertical text or is this for
horizontal text? In horizontal snapping left/right
seems less useful.
Florian: Not meant to be writing mode discussion. Needs to be
converted to logical.
Florian: Not use-case driven for float: left right. float: top
bottom was use case driven as was 2D.
astearns: Let's not do left right now then and focus on top bottom
where we have use cases.
iank: Always in logical space?
Florian: Tricky question. In vertical wiring mode still tend to
flow start bottom.
fremy: If you have float for multiple values, i.e. first try start
then bottom. Not sure this is the best way to express that
you have a preference and a fallback. I see float: top
bottom as a way to prefer to float to the top and fallback
on bottom. Float being a fallback list makes more sense,
that way instead of going to the next page float to the
bottom.
astearns: Sounded like the proposed syntax for float to closest
edge looks like a fallback. You would prefer a different
value meaning either value.
Florian: float: top bottom.
astearns: Asking for a different value that doesn't look like a
fallback.
fremy: Ah, so top bottom as being different from it being a list.
Florian: "top-bottom" or "top bottom" not important but the latter
might be easier
Florian: because doesn't require people to remember the order.
myles: Thinking about how to implement this. Place first page
float at the top and then relayout for the rest.
myles: If you shift down then the other content may end up on
another page.
Florian: That is okay.
astearns: Happens with left floats as well, anchor for left float
can be on different line from the float.
astearns: For the first level we'll only do one dimensional floats
where text doesn't wrap around it. Pushed down.
myles: Pushing anchor to next page may make the float fit on
previous page. Could be cyclical.
Florian: Not OK for anchor to be on same page if float is pushed
to next.
kawakubo: I want to float this element to top or bottom but if
there is already another float at the top of the page
then I want to place it at the bottom. Choose which way
to float depending on the presence of another page float
of the same direction.
fantasai: Feature that was previous part of the clear property. We
resolved to move that to a new property.
astearns: If we have that property then it could be used in
combination with float: top bottom
fantasai: Closest possible spot I think.
astearns: We can resolve on closest possible spot in cases where
there are restrictions based on other properties.
proposal: Use float: top bottom as a way to have something float
to the top or bottom based on proximity and possibility
RESOLVED: Use 'float: top bottom' as a way to have something float
to the top or bottom based on proximity and possibility.
In-place Floats
---------------
fantasai: What about in-place floats?
fantasai: Similar to top and bottom floats that we are talking
about. You have a page and layout some content and you
have a box like and image that doesn't fit. You have to
move it to the next page. Because we moved it there is a
giant gap. Maybe I don't care for having this gap. The
exact position of the float isn't super important but I
don't want to gap. Move lines of text to fill the gap?
astearns: Even if it is float left 100% content following the
float can't be above the float.
fantasai: You don't want to float more things, what if we had a
value like float-inplace that acts like a top or bottom
float that doesn't want to leave gaps. Allow text from
below to fill gap.
fremy: position sticky for floats?
fantasai: No, instead of pushing everything to the next page in
essentially becomes a float: top page float.
Florian: Very useful features. Doesn't have to be in spec
initially.
Florian: Ways to work around it and we can add it later.
fantasai: Seems like a simple addition. One dimensional float.
Florian: float:left *and* snap to top or bottom if within a
certain threshold.
Florian: ^ proposal for new topic
* fremy thinks this looks like "float: none, top" (try none; but
if cant without wrapping, use float top)
Florian: A 1D float shortens the fragmentation, therefor
background and borders of inflow content does not go
behind the float.
kawakubo: Page with two columns, if I place a page top float it
takes the full width of both columns. Shortens the
fragmentation. If there is column top float (only in
left column) then one column is shortened but not the
other one.
fantasai: If it is a column float then the column is not shortened
but the content of the column is.
Florian: Column box is the same size but the area used of column
content is shortened.
Florian: I think we have enough feedback and ideas to go ahead and
do a bunch of edits.
proposal: 1D page floats shortens the content area of the
fragmentation, therefore backgrounds and borders of the
fragmented content do not extend through the float area
RESOLVED: 1D page floats shortens the content area of the
fragmentation, therefore backgrounds and borders of the
fragmented content do not extend through the float area
float: end vs float: inline-end
-------------------------------
Florian: I think logical properties are blocked on page floats.
float: end vs float: inline-end
Florian: Are we sill blocked?
fantasai: Seems to me that the main question is whether float
would take two position keywords or would it be an
unordered thing. That is the question.
fantasai: For scroll-snap-align we have two keywords with a fixed
order. Therefore no prefix needed.
Florian: The distinction between 1D and 2D means start in one
dimensions doesn't necessarily imply anything about the
other direction.
Florian: For 1D it can't be just start, it needs to be block-start
etc.
johanneswilm: If I recall correctly, with a 2D float the stacking
direction would be different. Top-left vs left-top.
johanneswilm: If we don't have 2D then it should be easy.
Florian: I think with clear changes this goes away...
Florian: Instead float start isn't a thing, we don't know the
axis. Needs to be block-start or inline-start.
fantasai: Sounds like we're going with block-start and
inline-start.
proposal: Add start and end keywords and always qualify with block
and inline prefixes. block-start/block-end/inline-start/
inline-end
RESOLVED: Add start and end keywords always qualify with block-
and inline- prefixes: block-start/block-end/inline-start/
inline-end