- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Feb 2014 01:17:17 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Fragmentation
-------------
- Extensively discussed element/box/fragment distinction.
- RESOLVED: use the terminology "element", "box", and "fragment"
- RESOLVED: put fantasai's explanation of element/box/fragment distinction
in Display and Fragmentation.
- RESOLVED: Don't use "element", "box", or "fragment" in new terms that
aren't elements, boxes, or fragments. Where possible,
convert old terminology accordingly as well.
- RESOLVED: border-radius should get sliced across fragments, maintaining
unfragmented geometry.
- RESOLVED: Overflow that breaks into a new fragment container does so
by forcing its container to generate an additional zero-height
fragment (which then contains the transform origin).
====== Full minutes below ======
Fragmentation
-------------
Scribe: TabAtkins
fantasai: Main issue is element vs box vs fragment.
<smfr> http://dev.w3.org/csswg/css-break/
fantasai: Dirk posted some issues about how the spec is confusing.
fantasai: We have three things that need names right now.
fantasai: 1) thing in source document that has a tagname/etc
fantasai: 2) abstract layout object that is maybe associated with (1).
Often 1 per (1), sometimes 2+ or 0 per.
fantasai: So far in CSS, never more than 2 per.
fantasai: And it has properties, like 'width'.
fantasai: 3) pieces of (2) that are rectangular after fragmentation.
dbaron: If you're display:none, you have (1) but no (2).
dbaron: If you're display:table, you have a single (1) but two (2)s -
table box and table container box.
dbaron: Depending on how you interpret block-in-inline-splitting-the-inlines,
there might be more than 2 (2)s per (1).
fantasai: Currently we call (1) an element, (2) a box, and (3) a fragment,
or box fragment.
fantasai: If anyone wants something else, propose it.
SimonSapin: I don't think we have an issue for (1). It's called an
"element" in DOM and Selectors too.
SimonSapin: The issue is with "box" - we sometimes use it when we mean (3).
fantasai: [goes through another element/box/fragment example]
fantasai: CSS 2.1 uses "element" and "box" interchangeably to refer
to all of these.
fantasai: Or at least, "element" for (1) and (2), and "box" for (2)
and (3) (and sometimes (1)).
fantasai: We're trying to replace all of this by writing CSS3 specs.
<dbaron> (SteveZ proposes "unresolved formatting object"; ChrisL proposes
"universal formatting object")
dbaron: One thing that confused people is that "box" may not be rectangular.
Bert: Can "box has property" be a shorthand for "element has property"?
Bert: In 2.1, we want to say that boxes have properties. Is this true?
Tab, fantasai: yes! Also anonymous boxes need that.
fantasai: Yes, we agreed on that a while ago. Anonymous boxes definitely
have properties.
Bert: Is the box structure always a tree?
fantasai: Yes.
Bert: What about margin boxes? They're not in the same tree as the
elements.
fantasai: They're in a separate tree.
SimonSapin: Paged Media also has a terminology problem with "page box".
SimonSapin: For each page, there's a root box, which contains the
root boxes, and the box for the page content.
SimonSapin: Someone we say "page box" for the root box, sometimes for
the content box.
fantasai: So, I thought we had an agreement several years ago regarding
terminology, which is what's in the Fragmentation spec.
fantasai: But Dirk said he's confused.
Rossen: And hopefully we make this the last time we talk about this.
shepazu: I think it would be valuable for everyone involved to have a
very clear explanation for this written in a spec, like what
you just presented here.
fantasai: I think we could handle this between Display and Fragmentation.
TabAtkins: Yeah, I can take fantasai's explanation/diagram and put it
in Display.
krit: So can we resolve to keep these terms?
shepazu: And resolve to put a good explanation of these terms somewhere?
Bert: I'd rather have "box" mean "rectangular".
florian: I'm confused by "region box". If it's none of those, we
shouldn't use the existing words.
krit: Why not use "box" for "fragmentainer"?
fantasai: Because not all boxes are fragmentainers.
plinss: Why not call it "fragmenter"?
* dauwhe there has to be a joke about breaker boxes here somewhere,
but I can't find it.
RESOLVED: use the terminology "element", "box", and "fragment"
RESOLVED: put fantasai's explanation of element/box/fragment distinction
in Display and Fragmentation.
dbaron: 4 wrenches: content box, padding box, border box, margin box
dbaron: could use * edge, * rectangle
SimonSapin: * area
fantasai: area already has an incompatible definition, and these terms
are used consistently all throughout our specs
RESOLVED: Don't use "element", "box", or "fragment" in new terms that
aren't elements, boxes, or fragments. Where possible,
convert old terminology accordingly as well.
* tantek recommends a field trip to nearest The Container Store
* sgalineau wants to see tantek fragmenting boxes at The Container Store
<tantek> sgalineau, we can practice box-sizing
[some of the more obscure XSL:FO jokes have been edited out]
fantasai: So, let's say we have a large border-radius on a box, and
it's fragmented partway through the curve.
fantasai: Do we keep the curve sliced across the fragment edge, or do we
"correct" the edges in one fragment to connect to the box edge.
smfr: I think graphical slice is right - it'll keep the relationship with
background.
fantasai: Yeah, probably.
krit: WK does that. FF "corrects" the border-radius.
dbaron: Mats Palmgren wrote some patches to do the slicing behavior,
it hasn't landed yet.
RESOLVED: border-radius should get sliced across fragments, maintaining
unfragmented geometry.
<fantasai> Clarify that for variable-width fragments, this is handled
like for bg images
fantasai: If box fragments have different widths/heights, each piece
draws its portion fo the bg, assuming the whole element has
the same width as the fragment's piece.
fantasai: [is just quoting from the spec]
<fantasai> http://dev.w3.org/csswg/css-break/#joining-boxes
<florian> "piece" should be "fragment"
krit: What about the height?
fantasai: You lay out the box and fragment.
krit: Oh, so you sum the height of the fragments, and use that?
fantasai: Yeah. Backgrounds and borders are drawn after layout, so
that's fine.
fantasai: But Shapes are done before/during layout, which might be a
problem.
krit: If you take a fragment with the largest width, this'll be your
"reference box" for general layout...
fantasai: No.
fantasai: This only doesn't work if you have an image with an aspect-ratio,
where the height of the image depends on the width of the box.
fantasai: So in each fragment the image's progress changes, it's not
monotonic.
fantasai: So you have to figure out the image's height, and use that
through the entire tiling process.
fantasai: We use the width of the widest fragment for this, to disambiguate.
fantasai: So if you want an SVG image to stretch across the entire box,
that'll work even if you fragment into different sizes.
fantasai: It'll be stretched/squished in some fragments, but it'll work.
krit: The spec seems to be unclear on this, it seems to say two different
things about height.
krit: So I'd like more detail.
krit: Just make sure that it's really explicit.
krit: Another issue.
krit: Transform-origin is relative to border-box.
krit: So it's changed in each fragment.
krit: But if something overflows, and the *overflowing content* gets
fragmented, what's the transform-origin in that stuff?
dbaron: The spec isn't clear, but I thought we'd agreed to do a single
origin, based on the union of the fragments.
[confusion over whether the union is the unfragmented box, or the
bounding box of the fragments]
krit: In Tucson, we resolved to do transform origin per fragment.
fantasai: The question was whether you transform first and then fragment,
or fragment first and then transform.
* sgalineau thought we punted on transforms of inlines due to their
fragmentation. This seems complicated for similar reasons...
fantasai: But I don't think we specifically talked about transform origin.
Rossen: I think it's more natural to do origin per fragment.
dbaron: I've seen people want to transform inlines, and if it gets split
across lines, to rotate as a whole, rather than per-line.
krit: WK just does visual slicing right now.
[I think dbaron said that he wants to do a single transform-origin in
the unfragmented coordinate space of the box]
<dbaron> yes..
fantasai: (1) take the bounding box of all fragments and use transform
origin in that.
TabAtkins: (Which is nonsensical.)
<dbaron> I believe the spec did at one point say to do (1), though.
fantasai: (2) Each fragment computed origin per its fragment rectangle.
fantasai: (3) Take the composite (unfragmented) box (same as we do for
background positioning), find the transform origin in that,
then have each fragment use that origin.
<dbaron> I think (3) produces substantially better results from (2).
szilles: The Tucson minutes are clear that we resolved on per-fragment
transforms (and implicitly origins)
dbaron: I don't recall that was what we were discussing, and I may have
misunderstood at the time. I'd object to that now.
krit: [shows WK doing visual slicing, but FF doing per-fragment transforms]
florian: WK doing option 3, FF doing option 2.
smfr: [something about hyatt]
krit: hyatt agreed that it should be per border-box, and each column
fragment gets its own border box
dbaron: I take back what I said earlier; I'm ok with doing option (2).
smfr: I think authors transforming fragmented content are crazy anyway.
smfr: The whole reason we punted on inlines was to avoid this issue.
smfr: should box-decoration-break affect this behavior?
[people say no]
<dbaron> (Which, looking at http://lists.w3.org/Archives/Public/www-style/2013Feb/0472.html ,
is what we resolved in Tucson.)
TabAtkins: So with option (2), what happens with the overflowing content
in the original example?
krit: Mailing list explanation is that the overflowing fragment effectively
has a 0-height box at the start of its fragmenting.
<krit> http://jsfiddle.net/WLByL/
florian: And we have agreement that the overflowing content fragments?
TabAtkins: Yeah, we have browsers doing that.
plinss: I'm not sure about the fragmented overflow.
plinss: If an element creates two fragments, then when it overflows,
that overflow should just extend from that second fragment.
plinss: It can't go to the third column, because there's no third fragment.
plinss: Thus, if we want overflow to go in the third column, then by
definition we've created a third fragment.
florian: I don't find that multicol defines block-direction overflow
plinss: Doesn't surprise me at all.
plinss: So something needs to define this.
astearns: Note that column balancing uses the height of the overflowing
stuff too.
TabAtkins: That's fine; the third fragment can still be zero height.
The balancing algo would just refer to the height of the
overflow of each fragment, rather than to the height of
each fragment.
florian: Why does column balancing use the height of the overflow?
astearns: I can't explain it. It makes no sense to me. I just observe
that behavior.
<fantasai> The reason is that many pages are created just from abspos
elements, which means the entire page overflows the
zero-height root.
<fantasai> We still want to print all of that, so the overflow creates
pages.
<fantasai> If it creates pages, it should also create columns.
<fantasai> We want columns and pages to behave the same way.
?: Fragmentation is a way of handling overflow.
"overflowing overflow is still overflow"
RESOLVED: Overflow that breaks into a new fragment container does so
by forcing its container to generate an additional zero-height
fragment (which then contains the transform origin).
plinss: zero height or width depending on overflow direction
<astearns> I want to loop back on shape serialization at some point
Received on Tuesday, 4 February 2014 09:17:47 UTC