Minutes and Resolutions TPAC F2F 2010 Monday Afternoon: MultiCol, Flexbox, GCPM

CSS3 Multi-Column Layout
------------------------

   - RESOLVED: If a columnspanning element doesn't fit within the multicol
               element without overflowing, then it doesn't span anymore
   - RESOLVED: column-span applies to "in-flow block-level elements"
   - RESOLVED: column-spanning elements are BFC roots always
   - RESOLVED: Initial value of column-span is 'none' (to distinguish BFC
               behavior of 1-spanning and not-spanning).
   - RESOLVED: Columns overflowing due to forced breaks and not constrained
               height overflow to the right, rather than wrapping to a new
               column row below. Note this causes dataloss when printing.

Flexbox
-------

   - RESOLVED: Change prefix from box- to flex-
   - RESOLVED: Combine box-orient and box-direction into flex-direction
   - RESOLVED: Split box-flex into flex-grow and flex-shrink
   - RESOLVED: 'auto' margins flex as 1
   - RESOLVED: Drop box-flex-group
   - RESOLVED: Mark multiline at-risk.
   - RESOLVED: Rename box-ordinal-group to either flex-order or flex-index
               (mark exact name as issue)
   - RESOLVED: Mark entire transverse alignment as an issue until further notice.

GCPM
----

   - Discussed problem of specially styling pages that are the first or last
     page of a named page set, or that belong to the spread containing that
     first or last page.

   - Discussed problem of tweaking page size to handle widows or orphans.

   - Discussed hyphenate-last-line-avoid property proposal.

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

Present:
   Tab Atkins
   David Baron
   Bert Bos
   John Daggett
   Elika J. Etemad
   Sylvain Galineau
   Daniel Glazman
   Soonbo Han
   Koji Ishii
   John Jansen
   Hĺkon Wium Lie
   Peter Linss
   Markus Mielke
   Alex Mogilevsky
   Ilkka Oksanen
   David Singer
   Anne van Kesteren
   Steve Zilles

Agenda: http://wiki.csswg.org/planning/tpac-2010
<RRSAgent> logging to http://www.w3.org/2010/11/01-CSS-irc
<RRSAgent> http://www.w3.org/2010/11/01-CSS-minutes.html


Scribe: fantasai

CSS3 Multi-Column Layout
------------------------

   howcome: I would like to confirm agreement on a few things
   howcome: Implementations seem to be coming along nicely
   howcome: Hopefully all of the functionality in the spec
   howcome: We need some clarifications in the spec
   howcome: It's all about spanning elements
   howcome: Remember we have a multicol element here, and we lay out
            in colums
   howcome draws on the board
   howcome: The issue is overflow
   howcome: There are two reasons for overflow: you could have a
            constrained height
   howcome: or you could have forced column breaks, more breaks than
            you have columns
   howcome: The issue is what to do if you have an element with
            column-span: all in one of the overflow columns
   howcome: Alex proposed to do nothing, i.e. pretend column-span was
            not set
   howcome: If it's in the overflow columns due to forced breaks,
            though, I think it makes sense to have it break the column
            row and render as column-span: all, with content following
            it filling in columns in a row below it
   ?: What if you have both a constrained height and forced breaks?
   Alex: If it's due to forced breaks, you can try to put it in the main
         section. And if it doesn't fit and cause overflow, then you put
         it in an  overflow column and ignore the spanning behavior
   Alex: One special case: when you try to place a colspan and it itself
         doesn't fit, and creates overflow. That creates a circular
         dependency
   Alex: I think we resolved that if it doesn't fit as a span, you ignore
         the span
   howcome: So the distinction is, if it fits inside the multicol element
            as a span, then it does so, else the spanning behavior is
            ignored
   dbaron: You could also ignore in all cases when there's a constrained
           height
   stevez: I think it should be if it fits or not
   howcome: I think we should honor it in as many cases as possible, so
            I think we should hinge this on whether there's room or not
   stevez: This might interact with the EPUB case, where they paginate
           in addition to doing multicol
   Alex: If the forced-break case is height-constrained, where does the
         overflow columns go?
   Alex: Do the columns overflowing from the second row have full height,
         or shortened height, i.e. height after the rowspan?
   dbaron: So you're saying whether colspan works at all...
   howcome: is dependent on whether there is room inside the multicol element
   Alex: This could create a very ugly case if you have only one line of
         space left at the bottom of the multicol. you would create
         one-line-high overflow columns off to the right
   Alex: As the available space after the colspan approaches zero, the
         number of columns for content after it approaches infinity
   fantasai: From an implementation perspective, I would prefer this method.
   fantasai: The main reason we simplified column-span to 1 or all instead
             of arbitrary numbers was to avoid a column row with columns of
             multiple heights
   fantasai: if overflow columns were full-height columns, then we lose
             that simplification
   SteveZ: Epub wants to have pagination, especially in the multicolumn case,
           because they want to avoid overflow behavior when there are
           mulitiple columns
   fantasai: (Also, if forced-column-breaks can create overflow columns,
             then your full-height columns would overpaint any such
             overflowing columns before the column span)
   [note to minutes: insert pictures]
   dbaron draws some content on the board
   I have a some text, then a forced break, then more content.
   Then a spanning element.
   tab, fantasai: Then you balance the content, which may introduce breaks
                  in the column before the forced break or after it or both
   RESOLVED: If a columnspanning element doesn't fit within the multicol
             element without overflowing, then it doesn't span anymore

   New questions:
   1. do columnspanning elements create a new block formatting context
   2. does columnspanning turn inline elements into blocks?
   3. If the answer to either of the above is yes, does that behavior apply
      when the columnspanning is ignored due to overflowing (as resolved above)?
   2... or does it not apply to inline elements
   fantasai: I think column-span should only apply to block-level elements
   Bert reads the applies-to line from the spec
   RESOLVED: column-span applies to "in-flow block-level elements"
   dbaron: Note in the prose that it has no effect on elements outside a
           multicol element
   <dbaron> Well, really I said that maybe the in-flow aspect is the same
            as the doesn't-work-outside-multicol aspect, and then we got
            to that conclusion.
   fantasai: If a column-spanning element is a BFC root, then margins don't
             collapse through its boundaries.
   fantasai: I don't think that margin behavior should change based on whether
             a colspan is honored or not.
   <sylvaing> CSS3 Multicolumn http://www.w3.org/TR/css3-multicol/
   fantasai: So if it's a spanning element, it should automatically become a
             BFC and no longer collapse margins through its boundary,
             whether or not it's triggered the overflow nonspanning case
   fantasai: I think we might need to distinguish whether an element is
             spanning one column or not spanning, because of this.
   dbaron: I really don't want whether something is a block formatting context
           root depend on layout
   dbaron: I really want to know what floats are relative to before layout
   tabatkin1: So they should become BFCs regardless of whether they actually
              span something or not
   dbaron: We shouldn't have tricky behavior for an error case
   Steve: So column-span: all; would mean span the current column in the
          overflow case
   Steve: i.e. the all in that case means the one column
   RESOLVED: column-spanning elements are BFC roots always
   RESOLVED: Initial value of column-span is 'none'
   <szilles> Arron, the reason for column-span="none" is to be able to say
             that an element without an explicit column-span value does not
             create a Block Formattring Context

   Bert: Last issue is, do margins between spanning elements collapse?
   Bert: e.g. if I have H2 followed by H3, can their margins collapse
   fantasai: What about between the spanning element and the content of
             the columns above and below it?
   Roughly, answers seem to be Yes, and No, but discussing...

   Back to fantasai's issue
   fantasai: If you get more columns than you have space for due to forced
             column breaks, then I think instead of overflowing to the right,
             I think the columns that don't fit should create a new column
             row rather than overflowing off to the side.
   fantasai: This way we avoid an overflow case.
   Alex: I'm concerned people would use this for some weird design cases
         that don't work well
   Steve Zilles echoes the concern
   <Bert> (If the columns "wrap," i.e., the n+1st column starts underneath
          the 1st, then this becomes a way to make a grid in some cases.
          Effect is almost the same between 'display: inline-block' and
          'break-after: always'...)
   dbaron: I'm concerned that we're getting too far from what we're implementing
   howcome: We have implementations of multicol, we have to resolve these issues
   dbaron: We're not getting much author feedback on columns
   tabatkin1: They're not useful in continuous media
   more discussion of this case
   steve zilles thinks this solution causes bad layout
   fantasai thinks avoiding overflow is important
   steve: People will insert forced breaks randomly in order to get the
          layout they want
   fantasai draws a multicol element overflowing, showing how block-column
            overflow would result in a bad overflow situation in the
            constrained height case: since the height is constrained, placing
            overflowing columns below the first row overwrites any content
            after the multicol element
   fantasai draws another one where the multicol has an auto height and
            stretches to fill the content; in this case, if columns are
            wrapped below the first row, no such overflow occurs
   tabatkin1: Assuming overflow:visible, yeah, it looks ugly.  But you only
              get the good overflow if you have explicit column breaks based
              on where you think is "good".
   fantasai: Right, so far.  Ideally we'll have in the future a "column-length"
             that can cause new column rows without forced breaks
   <arron> referring to the first drawing by fantasai, are the columns
           overflowing to the right or below?
   <tabatkin1> arron, they're overflowing down, overlapping content in later
               elements.
   <dbaron> but the drawing is to say that's why they don't overflow down
   fantasai: If we think that column length is needed to get a sane rendering,
              maybe we should go ahead and just add column-length now.
   fantasai: I'm not happy with creating overflow cases when they are not
             necessary
   szilles: I could live with multiple breaks overflowing to the right today.
   fantasai: If we do that today, then you would have to use column-length in
             order to get explicit-break columns to wrap
   tabatkin1: column-length is not the right trigger for wrapping overflowing
              explicit break columns
   tabatkin1: if they're explicit breaks, they're explicit breaks
   tabatkin1: If you set column-length: 40em; and your explicit breaks are at
              20em, what's your column row height?
   steve: Ok, I see what you're saying
   Steve: Ok, I'm willing to withdraw my objection provided you add a note
          about this column-length property
   steve: My concern is that people will start putting in explicit breaks
          just to get the behavior that column-length would have given
   Steve: But if you at least put in the spec that this is not intended for
          this purpose, and how we want to proceed
   Peter: Authors don't read the spec. They'll do whatever it takes to make
          content work the way they want it right now.
   Peter: Let's just put this property in right now.
   dbaron: I'm not sure this is useful
   tabatkin1: This would make multicol usable for me
   Peter: Fundamentally, multicol doesn't make much sense on continuous media
   Peter: But let's not force people into making unusable layouts.
   dbaron: I'm not sure we're addressing use cases with multicol
   dbaron: And I don't think we would implement all this.
   fantasai: column-length is a piece of cake if you do either spanning or
             pagination
   dbaron: But we don't implement column-spanning. And we can't balance columns
           with forced column breaks in our current design.
   Kai: We have a lot of demand for this, actually.
   Kai: We haven't switched from table layouts to CSS due to lack of multicol
   howcome: So how would you decide the gap between the column rows?
   fantasai: use column-gap
   fantasai: can give it two values, just like border-spacing, if needed
   Alex: I want separate properties
   fantasai: Do you need them to cascade independently?
   Alex: I just like having separate properties
   fantasai: If we need separate properties, we can split them out later
             and make column-gap a shorthand.
   Steve: In XSLFO, we replicated the multicol box
   various concerns raised to porting this idea to CSS
   <Bert> (Chained regions, e.g., César's extensions to template layout,
          would solve most use cases as well. That, too, is an example of
          pagination inside a continuous display...)
   Steve: I'm going back to my position of putting a note that this doesn't
          solve the following problems.
   howcome: We go back to the issue of where the overflowing forced-break
            column goes: off to the right, or wrap under?
   howcome: I'm in favor of wrapping under, quite stronger.
   Alex: You need gap and rules, though.
   fantasai thinks we should just use the column-gap and deal with customized
            gaps and rules later
   steve: But I don't think column-gap is good enough.
   <Kai> q+ to say that currently control over layout is key
   fantasai: I'm not saying it's good enough, I'm saying it's adequate as a
             default even in the future when we have all these controls
   fantasai: The only other reasonable default is a zero gap. I don't see how
             that's better
   ...
   tabatkin1 doesn't want to half-ass this
   ...
   Kai: Web page layout is very precise right now.
   Kai: Automatically wrapping columns loses precision
   Kai: It's easier to control if it always overflows to the right
   <Kai> it would be good to have this as default and have the ability to
         have it wrap
   howcome takes a straw poll on behavior
   A - overflow to the right
   B - wrap under
   Bert: A
   Kai: A
   Steve: A
   Peter: B
   Markus: A
   Tab: A
   beth: A
   ?: A
   ??: B
   Chris: A
   Daniel: A
   John: A
   Sylvain: A
   Koji: A
   Arron: A assuming right is actually end
   fantasai: B
   arron, :)
   Alex: A
   dbaron: A
   jdaggett: A
   howcome: B
   no comment from the observers in the room
   Peter: I think it's unfortunate that we're choosing a behavior for multicol
          that doesn't work well for print
   RESOLVED: overflow to the right

Flexbox
-------

  <tabatkins> http://www.xanthir.com/blog/b48Z0
   tabatkins: I put up a list of all the new changes that Alex and I have
              agreed on for the flexbox draft
   fantasai suggests putting that on the mailing list
   tabatkins: Most are pretty small; syntax-level changes

   tabatkins: Major one is that we're changing the prefix from box- to flex-
   tabatkins: Because box is overloaded in CSS

   tabatkins: The next is determining the direction
   tabatkins: We used to have two properties for that
   tabatkins: Don't believe they need to cascade independently, so merged
              them into one that has all combinations
   dbaron: That probably makes sense

   tabatkins: At the last F2F sorta decided that things should flex differently
              when they're growing from when they're shrinking
   tabatkins: e.g. having the biggest flex, which normally becomes the biggest,
              become the smallest when shrinking
   tabatkins: Split into flex-grow and flex-shrink
   tabatkins: Also margins participate in flexing
   tabatkins: 'auto' flexes as 1
   tabatkins: Very common use case was splitting things to align half items
              on left, half on right
   tabatkins: previously had to add a dummy element
   tabatkins: now can do that with margins
   tabatkins: Keeping box-ordinal-group, renamed to something shorter

   tabatkins: Multiple lines, not super-sure about
   tabatkins: Seems like a large enough topic that it should be addressed
              more thoroughly
   Alex: There are no current implementations right now of multiple lines
   tabatkins: so thinking we might push that for the next level
   Alex: What was the motivation for multiple lines?
   dbaron: You'd have to ask hyatt. Not sure he'd know either
   Alex: We had some use cases that seemed interesting, but not sure any
         of them are really important.
   Alex: One example of multi-line box is a dialog box with a lot of tabs
   Alex: But that's not a good design to begin with
   Alex: The biggest problem with multicol is how to handle the last line
   Alex: Sometimes there's only one item on the last line
   Alex: I'm not sure I've seen any good design for this
   Alex: So multiline is only useful in combination with max width or
         something like that
   fantasai had a use case of a catalog, with tiles representing each item;
   fantasai: But pushing multiline flexbox to a next level makes sense to me

   tabatkins: The major change is alignment in the transverse direction
   tabatkins: Previously handled with box-align, which would align the box
              to the top, bottom, or centered
   tabatkins: or could stretch the box
   tabatkins: I expressed some unhappiness about that design
   tabatkins: I spent some time looking at it and realized you can do every
              case except baseline with margins
   * Bert (Talking about tab cards: I'd still like some way to turn a UL,
           or a sequence of SECTIONs, into a stack of cards with tabs...
           But that's unrelated to flexbox.)
   tabatkins: Current proposal is to have one keyword that makes the box shrink
   tabatkins: Can align that box with margins
   tabatkins: [...]
   dbaron: The thing that seems weird to me is if the child is itself a flexbox
           with the alignment in the other direction
   dbaron: It's unclear whether to throw out box-align or throw out box-pack
   dbaron: normally the child is in the orthogonal direction
   dbaron: The control was for the alignment in the axis direction
   * fantasai is not understanding
   dbaron: With your new proposal, if the child is a flexbox with an orthogonal
           direction
   dbaron: which do you use?
   dbaron: because you have two different things telling you how to align stuff
   tabatkins: depends what the child wants to be
   fantasai: I'm getting confused here
   Alex: I think it's a good point. What we're trying to do here is require
         that the child layout has certain capabilities
   Alex: So far there is only one precedent of requirement for nested layout,
         ability to declare its own baseline
   Alex: We're adding requirement of declaring vertical alignment
   Tab draws a big box with two small boxes inside
     one on the left one on the right
     right child has three boxes stacked vertically and is a flexbox
     left child has squiggles aligned to the top
     align: before assigned to big box
     pack: end assigned to right child
   Tab: Hm, I see what you're talking about. Yes, this needs to be explicitly
        resolved somehow
   dbaron: I think you'd want the thing on the child to beat the one on the
           parent
   fantasai: Maybe make it not apply to flexboxes
   Alex: What if the left one is a table?
   dbaron: I think you want these differentiations to apply to non-flexbox
           children
   Alex: Could define this alignment to only apply to block containers
   dbaron: baseline has its own problems with vertical-axis flexboxes.
           That's it's own problem
   Alex: We're making a complicated problem just to solve baseline alignment.
         Not sure it's worth it.
   Tab: baseline alignment is very common for e.g. tab strips
   Tab: Say I have <ul> with <li>, render as a horizontal flexbox tab strip
   Tab: Would want different alignments, bottom aligned, baseline aligned,
        centered...
   Alex: .. nested elements?
   Tab: How would you do that with nested elements?
   fantasai: You might want to align to the top baseline or to the bottom
             baseline

   Alex: Let's step back and talk about logistics of the spec
   Alex: Let's suppose hypothetically that next implementation comes out
         with this new syntax
   Alex: Are the existing implementations going to add another new prefixed
         implementation for this new spec and then on the next round it will
         become standard which will be in three years from now? Is that the
         route that we are looking at?
   Alex: The alternative would be to make small changes to the spec which
         makes Mozilla and WebKit implementations nearly compatible with
         the spec
   Alex: Which means next release of webkit/mozilla/ie would bring us close
         to CR
   Tab: There are some changes that are important and we definitely want,
        e.g. flex-grow flex-shrink split
   Alex: Question is do we consider existing implementations important in
         validating the spec, in which case we are trying to make less
         changes as long as they are equivalent
   Alex: Or are we taking the position that we are changing everything freely
   Alex asks dbaron
   dbaron: I think in the end we're going to have to rewrite a lot of it
           either way. Hard to say when that's going to happen.
   dbaron: But I think we should try and get this right.
   Alex: I'm not as concerned with complexity of implementations. I just
         want this to stabilize faster. Want to know if that matters.
   dbaron: What are these changes relative to?
   Tab: Last official WD
   Tab: Dropped idea of flex units, since couldn't figure out baseline
        alignment with that.
   discussion of stability, etc.
   Markus suggests this is parallel to multicol, fantasai says it's not
          nearly as advanced--hasn't gone through design review, which we
          are doing now
   more discussion of stability and implementation release schedules and
     interop on old syntax etc
   Alex is concerned about interop on old standard instead of on new standard
   Tab: We can try to make changes to box-align more minor.
   Tab: I tried to leave it unchanged and mix in vertical-align to align contents
   Tab; But wasn't getting sane answers when I tried to map out how that works
   ...
   dbaron: I like the idea of using vertical-align. Want to know what the
           issues were.

   Alex: If we resolve on everything except baseline, and can get those
         edits into the spec, that would be a great outcome of this meeting.
   RESOLVED: Change prefix from box- to flex-
   Next issue: combining box-orient and box-direction into flex-direction
   Alex: I'm not too thrilled with changing that. think old is more intuitive
   dbaron thinks the opposite: prefers Tab's proposal
   RESOLVED: Combine box-orient and box-direction into flex-direction
   RESOLVED: Split box-flex into flex-grow and flex-shrink
   dbaron: I think what the spec said and what implementations did is different
   fantasai: So maybe look into what current implementations do to determine
             default behavior of flex-shrink
   Should auto margins flex as one?
   fantasai: I'm strongly in favor
   RESOLVED: 'auto' margins flex as 1
   Tab: Drop box-flex-group? Not sure on this one
   dbaron: I think splitting out flex-shrink would solve many of the use
           cases here
   dbaron: Note we don't implement flex-group
   Alex: We haven't heard any significant use cases, and it's expensive
         to implement
   RESOLVED: Drop box-flex-group
   Drop multiple-line support?
   Alex: Mark at-risk?
   dbaron: We should drop before CR if we're not sure that the spec is ready
   dbaron: At-risk is something that is ready to be implemented, but we're
           not sure that it will be implemented
   <dbaron> I'm ok with either way.
   Tab: The existing behavior is well-specified, just too simplistic to be
        useful
   RESOLVED: Mark multiline at-risk.
   RESOLVED: Rename box-ordinal-group to either flex-order or flex-index
             (mark as issue)
   Tab: Multiple lines .. current syntax is to take values of single or
        multiple
   Tab: Suggest to change to box-wrap: wrap | nowrap
   fantasai: Makes sense to me.
   Alignment in transverse direction
   Alex: Would it help to solve this problem if you could independently
         specify background on the flexbox item from the actual child?
   Tab: It's weird, but would solve my use case
   fantasai cringes
   dbaron: Would prefer to solve it some other way than a pseudo-element
   RESOLVED: Mark entire transverse alignment as an issue until further notice.

GCPM
----

   <howcome> http://dev.w3.org/csswg/css3-gcpm/#page-selection-nth
   howcome: Two issues I have
   howcome: One thing we cut out earlier this year was named page lists
   howcome: But the requirement is still there
   howcome: There's a use case for being able to style pages differently.
   howcome: Named page lists approach was heavyweight; not suggesting to
            re-add that
   howcome: Suggesting :nth page selector
   howcome: Here's an example *pulls up nearest book*
   <arron> I would prefer this to be :nth-page not just :nth
   howcome: You don't want headings on the spread of a chapter heading
   fantasai: How about :first, :middle, :last?
   howcome: Need to access 2nd page
   fantasai: what for?
   howcome: both pages on the spread of the chapter heading need to be
            selected to e.g. drop headers
   discussion of how to indicate the start and end of a named series
   <dbaron> I think if you want @page chapter:nth(2), you need a new
            value for the 'page' property that makes a new chapter
            "restart" the sequence of chapter pages.
   Tab: You could have a :spread() that takes a page name, and is true
        if either side of the spread has a page with that name
   fantasai: But all the pages in that book are "chapter" pages. You
             have to somehow distinguish the start and end of a
             particular chapter page series
   howcome explains some use case involving widows and changing page sizes
   glazou: complex selectors are very hard to present in a UI
   glazou: I'm not saying the feature is not needed, just presenting a
           warning
   dbaron: You want the nth page of that name.
   dbaron: But that's actually different from the nth page
   dbaron: They should be separate selectors
   <dbaron> Some of these examples are :nth-of-name(), some are :nth-page()
   <dbaron> or maybe :nth-of-name() should be :nth-of-sequence()
   <dbaron> ?: maybe we don't need nth... just first-in-sequence?
   fantasai: Seems to me you just need to address the first page, first
             spread, last page, and last spread of a named series
   howcome: The case I need to address an arbitrary page is to address
            widows and orphans
   howcome: The publisher doesn't want to have a single line alone on a page
   howcome: so he tweaks the size of the page before it to accommodate
            an extra line
   Bert: TeX alters the line-height for this case
   howcome: It's a spread. You want to keep the baselines even
   Peter: you have this exact same problem in columns
   Tab: Maybe we need more powerful orphan-widow properties
   Peter: I don't like that we're targetting the page by number
   Peter: You don't want to target the page with a problem.
   Peter: If I edit the document: change the content, or the styling, the
          problem is no longer on the page I targetted.
   glazou: It's a hack

   Discussion returns to the 'page' property
   glazou: What happens if the element that triggers a page group has a
           page break property.  Then it's impossible to know which page
           is the second page he wants.
   howcome: If it's inserted before, you don't count it.
   howcome: The idea is that every chapter starts on the left of a spread.
   howcome: And you want to remove the headings on the second page of the
            chapter.
   glazou: No, you want to remove it on the other page of the spread that
           the chapter start is in.
   tabatkins: If the chapters start on the right, then you want to alter
              the last page of the previous chapter, instead.
   * Bert thinks the sequence of named pages wasn't so bad...
   fantasai: [explains dbaron's comment about why chapter:first doesn't
              work for this use case, with analogy to p:first-child]
   fantasai: [explains proposal for :first-page(pagename), and
              :first-spread(pagename)]
   <fantasai> :first(pagename) selects the page on which an element with
              page: pagename; starts
   <fantasai> :first-spread(pagename) selects that page and potentially
              the next page if they are part of the same spread
   <fantasai> similarly for :last-page(pagename) and :last-spread(pagename)
   <fantasai> and you can combine with :left, :right, or :blank for
              styling as needed

   howcome: That doesn't solve the widows problem.
   plinss: It doesn't fully solve the existing problem, either.  If the
           chapter starts on a right page, and the left page has content,
           you don't necessarily want to style the left page.
   howcome: Yeah, you don't want to select backwards.  Just select the
            second page, if the chapter starts on a left page.
   tabatkins: Okay, if that's the case then I don't have a problem with
              selecting the second page explicitly.
   glazou: I think that this offers too much power - it will be abused.
   <Kai> Wondering about workflows.  As discussed now a piece of text to
         be printed will have to be styled after all textual changes have
         been made.  Any changes to the text before that might change the
         layout and leave the author to re-style the whole text.
   Peter: Whether you have left and right pages or just right pages is a
          print-time decision
   fantasai: not in CSS. All pages are classified as left or right
   howcome: Right, suppose you're printing to PDF
   Peter: If I print this document in non-duplex mode, I don't want left
          and right pages
   Alex: could you have a media query for whether you have facing pages?
   unminuted discussion
   howcome: I want to suppress the headings on the pages in both page on
            the spread to be suppressed
   peter: You want controls for spreads, not for numbered pages
   Bert: We can talk to XSLFO people. They've done this before
   Bert: It might be more involved than just headers and footers.

   <howcome> http://dev.w3.org/csswg/css3-gcpm/#the-hyphenate-last-line-avoid-property
   * dbaron wonders if this is the one-more--hyphen---property
   Alex: Do we need a control for this property?
   Alex: Couldn't we just always avoid it?
   * dbaron thinks Antarctica should be Ant-arc-ti-ca
   <Bert> (Another way to reduce the ugliness in the example: This is
          just a / simple ex- / ample to show / Antarctica.)
   <tabatkins> Bert, that requires more adaptive hyphenation, which is
               almost certainly too expensive for the web.  Fine for
               print, though.
   fantasai: Do we need a control for this, or can we just have the UAs
             be smart about it?
   jdaggett: Do we need different values?
   howcome: There are different policies among publishers. This is a
            control that's been asked for.
   howcome: We can drop the 'always' value; it's not as important.
   glazou: What happens if the last word is wider than the column?
   howcome: It's an avoid, not a requirement
   <fantasai> I think auto should be asking the UA to be smart and do
              something reasonable, not allowing anything....
   Alex: spread should be on by default. Or maybe more than spread
   Peter: Publishers do manual tweaking to avoid awkward breaks. Reset
          breaking for one particular word on one particular page
   Peter: We're not going to do that in CSS
   Peter describes some of the difficult aspects of pagination
   Peter: But if you tweak things at that level, you only satisfy layout
          for that particular output instance
   Peter: It doesn't apply if you change any of the output environment
          parameters
   Peter: By flipping this switch, it'll help some of the time and hurt
          some of the time.
   <Kai> isn't it exactly the ability to output on different output
         environments that makes this feature necessary?
   Peter: I read e-documents on this thing (iphone) all the time. And I
          change the font size all the time.
   Peter: The author isn't thinking of that
   Peter: I don't want us to target the weird thing that happens on my
          computer. I want to target the general problem.

Meeting closed.

<smfr> TabAtkins: i think a big unresolved transform issue is how they
        apply to inlines
<TabAtkins> smfr: Yes, indeed.  Should we talk about that during the FXTF
             meeting on Thursday, or what?
<smfr> TabAtkins: i think the css-wg is more likely to have useful input
<TabAtkins> Ok.  I'll push it on the agenda tomorrow.
<smfr> if it's later afternoon i could join
<TabAtkins> The question is between transform-each-box or
             transform-bounding-box, right?
<TabAtkins> kk
<smfr> options are:
<smfr> 1. disallow transforms on inlines
<smfr> 2. transform the bounding box
<smfr> 3. transform line boxes somehow
<TabAtkins> kk
<smfr> 4. transform each bit like gecko does
<smfr> 5. maybe others
<TabAtkins> Oh, right, (4) is different because of, frex, bidi mixes within
             a line?
<smfr> right
<smfr> i'm tempted to suggest `
<smfr> er, 1
<TabAtkins> Yeah, that might be the best.
<smfr> authors can use inline-box if they have to
<arron> I think 1 would be best too
<TabAtkins> We resolved on "just don't allow it on inline" for column spans
             in multicol, so it seems like we're comfortable with that.
<smfr> sweet

<TabAtkins> smfr: Any thought on radial gradient canonical forms, while I
             have you here?
<smfr> no, i haven't studied the radial gradients spec yet
<smfr> saw your emails tho
<TabAtkins> Did you read my email from yesterday?
<smfr> i saw it, then saw the second one so didn't read the first one
        entirely ;)
<smfr> TabAtkins: i don't quite grok the start point + angle form
<TabAtkins> Okay, so here's how it works.
<smfr> you say the end point is the start rotated around the middle, but
        that's not true if there's an angle
<TabAtkins> Right.  What you do is, first, draw the reference line from
             the start point to the rotated end point.
<TabAtkins> Then, rotate the reference line *around the center of the box*
             by the angle.
<smfr> ok, so 2 things affect the final slant
<smfr> the points, and the angle
<TabAtkins> Then the gradient start is the "point on the reference line
             where a line drawn perpeendicular intersects X corner", etc.
<TabAtkins> Yes, they work together, and have good behavior for their
             defaults.
<smfr> hmm, that sounds more complicated
<smfr> and it doesn't address the use of the explicit start/end points
        which places the gradient over some sub-rect
<TabAtkins> Only because the combination of both a ref-line and an angle
             is strictly unnecessary.  It's only specced that way so that
             the two cases are specific instances of a general case, and
             can be transitioneed together.
<TabAtkins> smfr: I don't know if that's actually a use-case.  I've
             never had to do that.
<TabAtkins> And I made myself a gradient-image generator in PHP, so I
             used gradients pretty freely in designs.
<TabAtkins> 95% of use-cases, I think, can be addressed solely with
             either an angle, or a box-cardinal direction.
<TabAtkins> I'd be fine with just speccing both of those as separate
             functions, but if I can make a single function do them both
             without a lot of hassle, then I'd prefer to.
<TabAtkins> I'd like to align whatever solution I do for linear gradients
             with a similar solution for radials, though.  Radials are a
             much harder problem.
<TabAtkins> Anyway, let me post that email to the list.
<smfr> k
<TabAtkins> k, sent.  now, off to dinner for a few hours.
<TabAtkins> bradk_: Check out the email too.  I think the model I propose
             for linear gradients has roughly equivalent power to yours,
             but more continuous behavior and less abstraction.
<TabAtkins> bradk_: I still don't like the mode where you pretend that
             the angle is relative to a unit box and then transform it.
             But this one, where a bare angle is relative to a horizontal
             line and thus gives us the algebra-inspired behavior, still
             seems cool.
<bradk_> Tab, I see it the other way around, where the keyword just turns
          off the bit that prevents the angle from stretching as the box
          stretches.

Received on Tuesday, 16 November 2010 23:44:15 UTC