W3C home > Mailing lists > Public > www-style@w3.org > February 2014

[CSSWG] Minutes Seattle F2F Tue 2014-01-28 PM I: Fragmentation

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 04 Feb 2014 01:17:17 -0800
Message-ID: <52F0B01D.8040304@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:17 UTC