[CSSWG] Minutes Tucson F2F 2013-02-14 Tue AM I: Paged Media 4, Flexbox

Paged Media Level 4
-------------------

   - RESOLVED: glazou to start css4-page based on ideas outlined in minutes
               and http://www.w3.org/mid/50F29E84.1050804@disruptive-innovations.com

Flexbox
-------

   - RESOLVED: Zero-length boxes stay at end of earlier line unless line is
               already overflowing, in which case they wrap
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-1

   - RESOLVED: flex line's cross size is floored at zero
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-2

   - Opened issue on percentage margins on flex items
       http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-16

   - Flex items' cross size to be definite when stretched to fit definite size.
       http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-3

   - RESOLVED: Defer additional spacing controls to Level 2
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-4

   - RESOLVED: Proposed handling of stretched items with intrinsic aspect
               ratio is accepted.
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-8

   - RESOLVED:  http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html
                is WG response for
                http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-9

   - RESOLVED: Flex items can have negative outer size; no clamping to zero
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-10

   - RESOLVED: ::first-line/::first-letter don't apply to flex containers.
               Could revisit later if this is in high demand.
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-13

   - RESOLVED: overflow applies to flex containers
               http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012#issue-15

====== Full minutes below ======

Paged Media Level 4
-------------------
Scribe: fantasai

   <glazou> http://www.w3.org/mid/50F29E84.1050804@disruptive-innovations.com

   glazou: One of my activities right now is my EPUB editor
   glazou: We have a few issues between IDPF and ourselves, W3C
   glazou: They are taking things from us that are unstable drafts
   glazou: They rely exclusively on XML serialization of HTML5

   glazou: One thing ppl do with electronic books is convert Word documents
   glazou: Word allows very powerful headers, footers, footnotes, bookmarks,
           etc.
   glazou: GCPM has very weak headers/footers, and all data you can put
           there comes from generated content
   glazou: These are not elements. They're just text.
   glazou: Not enough to import document coming from word processor
   glazou: We are far behind
   glazou: What we do, allow, is not enough to allow ebooks
   glazou: And not enough to allow importing Word documents into Web formats,
           Ebook formats

   glazou: The way Håkon designed headers/footers in css3-page
   glazou: He divides the page margin into 16 boxes
   glazou: We have new specs on the radar for csswg, grid, flexbox, regions, etc
   glazou: That allow precise layouts
   glazou: we don't need so many boxes now
   glazou: The idea is to take the parts of GCPM/css3-page that make sense
   glazou: And for the rest, deprecate almost what's in Paged Media
   glazou: And move towards much more powerful page definitions
   glazou: Get flows of content, like what's in the Regions spec, to allow
           powerful complex headers/footers, which we don't have right now

   glazou: If I take first word document from my hard disk, e.g. invoice
   glazou: It has header with quote number invoice number, customer number, etc.
   glazou: All of that is lost when you import to HTML+CSS
   glazou: ebook industry is big enough that we should address this problem
   glazou: The current GCPM and css3-page are only implemented by batch
           processors

   glazou: There's not a single browser implementing bits from these specs
   glazou: Very basic properties, page size, maybe
   glazou: I'd like to hear reasons why they were not implemented
   glazou: Not a priority? Only for batch processors? Not implementable?
           Bad perf?
   glazou: My idea is to start Paged Media Level 4
   glazou: If you're absolutely not interested, though, it's not worth the time.
   glazou: Would reuse bits of L3
   tantek: Even if no one is interested, if you have ideas on a simpler
           proposal, it's worth writing up
   tantek: Seeing your ideas may spur other ideas
   <stearns> would this be only for printed output, or would it also include
             paginated views?
   glazou: It's not just simplification, but also a harmonization with
           other proposals in the CSSWG
   glazou: In HTML5 we have <header> and <footer> elements. We are not
           able to deal with them on a per-page basis

   dbaron: Wrt priorities, I think the current draft has not been as high
           priority as other things
   dbaron: I think there are many features that look like a lot of work but
           don't get you much contributes to that.
   dbaron: But that's not the only reason.
   glazou: Not asking for commitment to implement or even review, but can
           I start a draft?
   [people seem supportive of this idea]

   tantek: One big change that has occurred since GCPM was first developed
           and framed is, we shifted from a desktop/print-centric web to
           a mobile web
   tantek: GCPM feels heavyweight large screen
   tantek: That's not the focus to day. The focus is mobile.
   tantek: The only advice I give is any simplification should first,
           foremost, solve mobile use cases that paged media has rather
           than books, print, all these edge cases
   glazou: Books are an edge case?
   szilles: 5% that everybody uses is still pretty important
   szilles: displaying info is key role of Web
   <stearns> mobile (particularly tablets) should raise the priority of
             paginated views, imo
   szilles: At least one issue with small screens is being able to have
            reasonable pagination
   tantek: Do reasonable pagination, but also need to solve the scrolling
           problem.
   glazou: Wrt mobile, one major application is ebook reading
   tantek: Yes, mobile ebook reading, but rather than massive complex
           texts everyone brings as examples
   molly: Isn't it included
   molly: Our primary role is to have interop across these devices
   molly: I disagree, having many years in publishing industry
   molly: Was talking about GCPM to Tim O'Reilly, he said "We are desperate.
          EPUB does not fulfill the needs we have. We need solution that
          incorporates the open standards."

   Rossen: I wanted to mention, the GCPM spec, the way it is currently standing
   Rossen: We've been looking at it quite a bit
   Rossen: it's not something which is easy to develop on top of
   Rossen: Are we building a platform that other ppl will build on top of?
   Rossen: Or are we building the platform which is the reader?
   Rossen: GCPM defines a nice reader app
   Rossen: If you're building a platform, then implementing GCPM itself
           does not allow enough programmability for ppl to build on top of
   glazou: You are thinking in terms of implementation. I'm thinking in
           terms of readers and books [?]
   glazou: Ebook publishers need to do a lot more with footers and headers
   glazou: Not a question of platform, question of usage.
   * stearns agrees rabidly with Rossen
   Rossen: My point is, e.g. debate of "what is a page". Author should
           define what is a page.
   Rossen: Whatever we do should also be printable
   Rossen: All efforts currently putting forward in Fragmentation, regions,
           etc, are all moving in that direction of exposing enough
           primitives on platform so ppl building apps on top can have
           sufficient resources to do that.

   glazou: Again, what I have in mind is more harmonization with other specs
           on WG's radar, than something entirely new
   glazou: We have plenty of things, and we don't use them for page definition.
           We could. It will be much better tailored and much more maintainable
           and manipulable for Web authors

   glazou: More controversial... footnotes
   glazou: Way they're done in GCPM is way complicated. Should do them with
           flows.
   glazou: Same thing with bookmarks
   glazou: A footnote would be an element with some flow
   glazou: Has to be tailored, but should be doable.
   glazou: Mention the ebook case because I'm working on it, but it's not
           the only one
   glazou: When you want to display data, you want to paginate, to scroll
           between pages.
   glazou: We don't address that.
   glazou: We are too weak in terms of CSS rendering
   glazou: So goal is to try to do that
   glazou: My assumption is not that you will agree immediately, but submit
           ideas to WG and start discussion on that
   glazou: Would give very good signal to IDPF if we do that.
   RESOLVED: glazou to start css4-page based on ideas outlined above
   SimonSapin: I agree with most of what you said, except for the part
               of deprecating css3-page
   SimonSapin: … because it’s been implemented and used for many years,
               even though not on the web

   * dbaron wants to ask Rossen what he meant by defining what a page is
   <Rossen> dbaron, my point is that I don't want to define "what a page is",
            I want to give authors the ability to define it themselves
   <dbaron> Rossen, are you talking about allowing authors to do paginated
            overflow like in Håkon's overflow:paged proposal, or something
            else?
   <Rossen> dbaron, this is a good start but not sufficient if you want to
            allow variable page sizes
   <dbaron> Rossen, that sounds like regions or overflow:fragments
   <Rossen> dbaron, yes, these proposals are really good start in this
            direction

Flexbox
-------

   <fantasai> http://dev.w3.org/csswg/css3-flexbox/issues-cr-2012

   First issue is handling of zero-length boxes at end of line
   <TabAtkins> http://dev.w3.org/csswg/css3-flexbox/#algo-line-break
   fantasai: Question is what happens if first item is really wide,
             then add zero-length item
   fantasai: Should it stay on first line or go to next line?
   [discussion of flex line breaking]
   fantasai: We put items until you overflow
   TabAtkins: Then back up by one
   <fanasai> (unless it's the first item, then don't back up, just break)
   TabAtkins: It's possible that you have a negative-length item that
              will make an overflowing item fit, but we don't look ahead.
   szilles: Overflows lefthand side of flexbox?
   szilles: What are user expectations?
   TabAtkins: Don't use negative margins that big?

   <dbaron> sounds like it's worth being clear about what happens with
            negative margins, and not looking further forward
   fantasai: Not a big user expectation issue. Edge cases, we want to
             make sure implementers are happy with it
   TabAtkins: Suppose flexbox is 300px wide. First 2 items 200px wide,
              third is -100px
   TabAtkins: Theoretically, can fit all three in box
   TabAtkins: But since you overflow after adding the second, you break
              after the first item.
   TabAtkins: If ordering was different, had third before second,
              then all three would fit on first line
   dbaron: I'd support defining the negative margins case clearly; it's
           not defined clearly for inline layout.

   fantasai: In the same example, if we had a first item of 400px,
             and second item is 0px or -100px
   fantasai: In both cases, the second item would wrap, even though it
             doesn't increase the length of the flex line
   fantasai: This last example is what this issue is about.

   fantasai: Any further comments? People happy with this interpretation
             of line-breaking?
   szilles: Record what Tab said, that use of negative box sizes is
            discouraged, but it's defined, and in a way that doesn't
            require excessive lookahead
   RESOLVED: Zero-length boxes stay at end of earlier line unless line is
             already overflowing, in which case they wrap

   Issue 2: Handling of negative-size flex lines
   fantasai: If all items in a flex line have negative cross-size, does
             the flex line have negative or zero height?
   TabAtkins: Decided to clamp the flex line's cross-size at zero
   TabAtkins: Could let them be negative, but don't see any reason to do so.
   Rossen: wrt regular block flow, where you can do that...
   TabAtkins: If you have a wrapper div in block flow, and fill with
              negative size things, div is still at least zero height
   Rossen: [...]
   TabAtkins: You can't have negative-height lines, because only way to
              get negative sizes is negative margins
   TabAtkins: In main dimension, can have items overlap each other
   TabAtkins: and have them be negative
   TabAtkins: In cross direction, can overlap, but not have negative
              cross-size for lines
   szilles: Note that some of these issues are relevant to inline layout
   fantasai: This one doesn't apply, because of root inline's line-height.
   RESOLVED: flex lines are floored at zero

   Issue 3: stretch and percentage cross-sizes
   fantasai: Wanted to fill flex items, e.g. each item having content
            with height :100%;
   TabAtkins explains Rudolph's case
   TabAtkins: No way to fill it without invoking more flexbox
   TabAtkins: Believe our proposal is do nothing, it's currently
              workaroundable
   fantasai: But no way to do, e.g. 50% fill

   fantasai: Btw, what are percentage margins relative to on a flex item?
   TabAtkins: Think it's same as block
   fantasai: So relative to containing block's width for both horizontal
             and vertical margins?
   Bert: Should it be relative to writing mode or flex direction?
   TabAtkins: If you think of flex as better block, then should be consistent.
   Rossen: If your cross size changes, you have margins in percent, that
           resolves from the main size, by increasing your cross size,
           main size will increase.
   fantasai: Guess this a separate issue, should probably double-check
             that things work sensibly.
   ACTION fantasai: investigate handling of percentage margins on flex items
   <trackbot> Created ACTION-532
   [discussion between Rossen and Tab wrt margins]
   Tab, Rossen, and fantasai to investigate during the break

   fantasai: So back to the issue, a related concept is that if you have
             'stretch' item, it does not propagate definiteness from the
             flex container to the flex item, so you can't resolve
             percentages against it.
   fantasai: In Rudolph's case, it's trying to reference an auto size,
             so percentages definitely wouldn't work.
   fantasai: But suppose flex container is definite size, 'stretch'
             doesn't allow to resolve against that height right now
   Rossen: Should do so, because stretch is equivalent to height 100%
   Rossen: We did the same thing for Grid as well
   ACTION TabAtkins: Make stretch definite when flexbox is single-line

   Issue 4: Constant spacing around items
   http://lists.w3.org/Archives/Public/www-style/2012Oct/0249.html
   TabAtkins: Basically requesting more spacing controls
   TabAtkins: Have had similar requests from Yehuda Katz
   TabAtkins: Wanting to put fixed spacing among items
   TabAtkins: This one wants specific spacing between flex lines, preferably
              same as spacing between flex items on same line
   TabAtkins: Think to defer to Level 2. Want more spacing controls,
              but do a proper treatment of it later.
   RESOLVED: Defer additional spacing controls to Level 2

   Issue 5: http://lists.w3.org/Archives/Public/www-style/2012Oct/0220.html
   fantasai: If you have percentage that can't be resolved, CSS2.1 says
             it's treated as auto. Currently spec says it computes to auto,
             but we decided it's actually the used value that's auto
   fantasai: We need that to be clear for this issue to be clear in Flexbox
   TabAtkins: Stretch checks against computed value of 'auto'
   fantasai: So question is, when does 2.1 erratum get published?
   http://lists.w3.org/Archives/Public/www-style/2012Oct/0437.html
   http://lists.w3.org/Archives/Public/www-style/2012Oct/0466.html
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
   Bert: Did we want to keep the computed value as a percentage so you can
         back-resolve the parent's width?
   fantasai: No idea. Just know that the current text is wrong.
   fantasai: Bert, do you need anything from the WG on this issue?
   ACTION Bert: Update errata, CSS2.1 spec for bug 15392
   <trackbot> Created ACTION-533

   Issue 6 was editorial
   Issue 7 was straightforward, fixing conflicting wording in spec

   Issue 8 we discussed in December, was waiting on Rossen to confirm
   http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
   http://lists.w3.org/Archives/Public/www-style/2012Dec/0040.html
   Rossen: We ignore aspect ratio once main size is determined
   Rossen: Have overlapping content?
   TabAtkins: No, no overlapping. Just ignore aspect ratio
   Rossen draws example
   <div flex><img/><img flex:1/></div>
   div is 300px, images 100px each, square
   div is 200px tall
   TabAtkins: If it's single line, they both stretch to 200px, and main
              size increases to 200px accordingly
   TabAtkins: Then second one is flex: 1, so it negative-flexes to fit,
              becoming 100px wide. Stays 200px tall.
   RESOLVED: Proposed handling of stretched items with intrinsic aspect
             ratio is accepted.

   Issue 9
   RESOLVED:  http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html

   Issue 10: Do flex items with negative margins increase available space?
   fantasai: Flex items can have negative sizes, we don't clamp the outer
             size to zero
   RESOLVED: Flex items can have negative outer size; no clamping to zero

   Issue 12: Orthogonal Flex Layouts Sub-optimally Defined
   fantasai: We haven't figured out how to solve this yet, so still open

   Issue 13: Should ::first-line/::first-letter apply to a flex container?
   fantasai: Mailing list seemed to think, why bother at this point,
             nobody seems to be demanding it and it's additional complexity
   TabAtkins: It wouldn't be too tricky, since you'd be propagating into
              the first flex item.
   RESOLVED: ::first-line/::first-letter don't apply to flex containers.
             Could revisit later if this is in high demand.

   Issue 14 was closed as invalid

   Issue 15: Should 'overflow' apply to flex containers?
   TabAtkins: We answered yes
   dbaron: It's a lot of work
   TabAtkins: Two of us already do it
   dbaron: Is the idea that you run the entire flex layout algorithm as if
           the container is that size
   TabAtkins: And if you overflow, you add scrollbars and do it again
   dbaron: If you have horizontal overflow, you make a scrollbar that can
           go out to there, but then you do the layout as though the width
           is still the original width minus the scrollbar.
   dbaron: Is that clear?
   fantasai: I think that's implied in the way overflow is defined
   RESOLVED: overflow applies to flex containers

<br type="tea">

Received on Friday, 15 February 2013 04:11:20 UTC