[CSSWG] Minutes and Resolutions TPAC 2011-10-31 Monday Afternoon: @font-face, Flexbox, Multicol, GCPM

Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

CSS3 Fonts

   RESOLVED: @font-face will be same-origin by default with the use of CORS
             to relax for HTTP


   RESOLVED: flex-order as <integer>
   RESOLVED: Publish css3-flexbox as WD
   RESOLVED: abspos elements leave behind placeholders and all that implies
   RESOLVED: Flexbox ordering property named 'flex-order', not 'flex-index'
   RESOLVED: Not addressing stack axis in Flexbox
   RESOLVED: logical keywords are flex-relative, not writing-mode-relative,
             when used in flexbox
   RESOLVED: Effective min-width on flexes is a limitation after the initial
             flex resolution, not while figuring out preferred width of element.
   RESOLVED: minimum width is just min-width; min-content is not an implied
   RESOLVED: For 'flex-align: stretch', honor 'max-width', then start-align
   Unresolved discussion of 'visibility: collapse'.

Multi-column Layout

   RESOLVED: break-before:column won't force a blank column when the element
             is the first in the column.
   RESOLVED: Pages work the same as columns - an element at the top of the
             page with break-before won't force a blank page.
   RESOLVED: page-break-before doesn't create a break if you're at the top
             of the page, where at the top of the page means no content has
             been placed. Borders do not count as content. Zero-height elements
             count as content.
   RESOLVED: percentage in block dimension is computed relative to multi-col
             element, not column box height
   Discussed whether margins should collapse between column-spanning elements.


   Reviewed new features for leaders.
   Reviewed Opera's proposal for paged overflow controls. Some concern about
   defining navigation controls for paged views.
   RESOLVED: Publish CSS3 GCPM as soon as all edits are made

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


Scribe: fantasai

WebApps/CSSWG Joint Meeting Resolution


   jdaggett: We resolved to make the font loading @font-face same-origin
             by default
   jdaggett: Two actions on me
   ACTION jdaggett: Reword how same-origin is described to talk only about HTTP
   <trackbot> Created ACTION-391
   sylvaing: Wouldn't this be an issue for implementations?
   <sylvaing> my question was whether implementations used CORS or From-Origin;
              it seems we made a decision on using CORS
   fantasai: So if I linked a font on a different server via ftp, that works
             around the same-origin restriction?
   ACTION jdaggett: Talk with Anne about how to reference the same-origin
                    things "correctly"
   <trackbot> Created ACTION-392
   Vladimir: ...
   jdaggett: This resolution will eliminate the need for an at-risk rule.
   sylvaing: Will there ever be a connection between this and From-Origin
   Florian: It's CORS
   jdaggett: Once the action items are complete, there will be another point
             at which we can rehash if need be
   <hober> I didn't think we made a decision to use CORS specifically, only
           to have a same-origin restriction by default in @font-face
   jdaggett: So do we have a resolution?
   RESOLVED: @font-face will be same-origin by default with the use of CORS
             to relax for HTTP
   <Bert> to relax restrictions in CORS, the syntax is "Access-Control-Allow-Origin: *"
          in the HTTP response headers, I believe. Is there anything else needed?


   TabAtkins: I have a couple outstanding issues I need to edit, but we
              don't need to worry about -- just resolve corner cases with
              obvious answers
   TabAtkins: Other issue: ATM in the spec flex-order takes a <number>,
              whereas z-index takes an <integer>
   TabAtkins: So we can either make flex-order <integer> or z-index <number>
              to make consistent
   TabAtkins: Prefer <number> because it makes it easier to insert things in
              between later
   ChrisL: what's the impact on z-index of changing it?
   TabAtkins: z-index currently takes <integer>, so this would be expanding it.
   smfr: I'm a little uncomfortable with changing z-index
   smfr: I see a lot of devs setting z-index to maxint -1
   TabAtkins: Would the crazy things ppl do be affected by this change?
   TabAtkins: I don't think so
   Arron: We don't know.
   Molly: I'm afraid.
   Molly: Many designers don't understand CSS, they use properties that we
          define and understand, but they create hacks to work around
          implementations or to address a feature they don't know how else to do
   Molly: What is going to happen if something changes there?
   smfr: Whether it breaks depends on the implementation. Opera had a 16-bit
         implementation at one point
   TabAtkins: floats are above our minimums
   smfr: You can't represent maxint accurately as a float
   TabAtkins: We were talking about required minimum ranges for <integer>
   TabAtkins: will almost certainly be below maxint
   Florian: Possible ppl are writing floats into their z-index, and their
            pages currently work only because it gets thrown out
   TabAtkins: If we believe that's actually a problem, that there is
              significant usage in the wild of invalid z-index values, then
              we have a problem
   Markus: what do we lose by not having <number>?
   TabAtkins: It's mildly more convenient to use <number>.
   Steve: Is the benefit of analyzing this worth the benefit?
   fantasai: you can use the BASIC approach and space your numbers by 100
   TabAtkins: Make flex-order be <integer> and later evaluate whether to
              change flex-order and z-index to <number>
   * sylvaing wonders how existing code that parses z-index value will handle
              a switch to <number>
   RESOLVED: flex-order as <integer>
   fantasai: On another note, why do we have flex-order and z-index?
   TabAtkins: I don't care very much, slightly prefer flex-order
   <Bert> ('nav-index' is also called "index," not "order.")
   Bert mentions tabindex in CSS
   <tantek> hearing 'nav-index', /me puts down the TPAC planning wiki page and
            hurries back to CSS WG
   <sylvaing> z-bikeshedding
   Steve: I think 'index' is slightly better because you have to think about
          what it means, and if you read it you have to look it up
   Steve: I think order implies something it isn't
   Molly: Many people already understand z-index anyway, and in their
          vocabulary, so it's consistent anyway
   holding off until alex is around
   * sylvaing thinks we're arguing for consistency with something everyone is confused about
   TabAtkins: Last thing is to request WD publication. Last draft is from 2009
   dbaron: One reason I hesitate to rename flex-order to flex-index is because
           boxflexgroupthing might be flex-index
   TabAtkins: Oh, you mean like flex-group
   dbaron: I guess flex-group is fine
   RESOLVED: Publish css3-flexbox as WD pending flex-index/flex-order issue

   alex: flex-order changes processing order, not just visual order so I
         think it should be flex-order
   alex: did you go over min-width?
   alex: 8, 10, 12

   alex: abspos children
   <TabAtkins> http://wiki.csswg.org/spec/css3-flexbox#issue-10
   alex: We had an issue about issue of abspos elements creating an empty,
         which is discoverable when justifying
   alex: There is no reasonable way to place that hypothetical static position
   alex: Place where it would have been is inline content, and that gets
         wrapped in an anonymous ocntainer, and that box is empty.
   alex: But justifying with flex-pack shows this placeholder
   alex: Positioning a flex-item without a placeholder is tricky
   fantasai: Why not define the static position as coinciding with the flexbox,
             rather than as a hypothetical child??
   alex: The only thing we don't like is the behavior with flex-pack: justify,
         and I don't mind it being bad for this case since it makes everything
         else work better
   TabAtkins: So we're embracing the placeholder concept.
   Ojan: I don't like that
   Ojan: Weren't you proposing to point its static position as being in the
         middle of the flex-pack space
   dbaron: that's a lot of code to special-case an edge case
   RESOLVED: abspos elements leave behind placeholders and all that implies

   Straw poll: flex-index vs flex-order
   jj: order
   alex: order
   howcome: absain
   koji: absain
   markus: order
   tantek: abstain
   steve: index
   alan: order
   florian: abstain
   bert: no opinion
   ?: index
   brad: abstain
   smfr: order
   dean: abstain
   soonbo_han: index
   shane: order
   hober: order
   luke: abstain
   <Bert> so we decided to call it flex-abstain?
   kim, molly, rossen: order
   dbaron: order
   jdaggett: abstain
   sylvaing: order
   arronei: order
   tab: order
   fantasai: index
   glazou: I don't care
   ChrisL: order
   RESOLVED: flex-order

   TabAtkins: This is to consider z-order axis
   TabAtkins: as a flex order
   TabAtkins: I believe we shouldn't do anything about this right now
   TabAtkins: If we want to address stacked layout, which I think we should,
              we should consider it as another display or part of grid or
              something else. Don't have all the primitives we really want
   TabAtkins: One thing you might want to do, frex, if you have items of
              different size, you might want to size to the size of the
              current item, or size to the size of the largest item so you
              don't resize as you swap them
   TabAtkins: That's a control that you don't have otherwise
   dbaron: What's the use case for size based on the one on top?
   dbaron: Gecko implements this, and we've never gotten a request for size
           based on the one on top
   Rossen: size top sounds like a way of deferring layout of the other things,
           is that your use case?
   TabAtkins: Partially
   TabAtkins: Have a use case for sizing according to top
   TabAtkins: I've seen tab layouts where your headings or whatever are on the
              side, and the contents of your page are the stack
   TabAtkins: You want them all to fill the widths. But if you have a tall
              item and some short items, you don't want the short items to
              have a long scroll bar
   dbaron: Fair enough, but that doesn't seem like flexbox.
   Markus: If we add this we'll have another way to do stacking in addition
           to z-index and grid
   TabAtkins: There's still further things that distinguish this from plain
              flexbox that make it not a good idea to combine
   TabAtkins: Flexbox's alignment primitives are flex-align and flex-pack,
              which are perpendicular/parallel to the flex axis
   TabAtkins: If you have stack, then you have two orthogonal axes, and it's
              not clear which is align and which is pack
   TabAtkins: If we were going to tack it onto one of our layout models,
              grid might be better. not sure if it's the best idea, but
              seems better than this
   Alex ...
   Alex: If you take a grid and give it several items, it will give you a stack.
   <Bert> (Template Layout once had 'display: card | card-container | card-tab'.
          Came from a request from Device Independent WG.)
   TabAtkins: One final thing that makes me hesitant, I'm not sure if we
              want to address in CSS, but if you have tab layout then you
              probably want to show the tabs themselves.
   TabAtkins: Auto-generated, linked up manually, some old proposals, but
              don't know how
   TabAtkins: in JavaScript it's easy, but may want to address it in CSS
   Alex: HTML5 control using script and grid and add to HTML5 as necessary
   TabAtkins: One problem with script is, the tabs should be accessible.
   TabAtkins: Most developers will not and do not in practice hit all of
              the accessibility goals we want there.
   Alex: it needs to be an HTML5 control
   fantasai: Couldn't you use fragment IDs?
   TabAtkins: If we address this automatically somehow via CSS, I doubt
              we want to tie this into z-index.
   <Bert> (http://www.w3.org/Style/Examples/007/target is example using
          fragment IDs (and :target, thanks to Daniel))
   TabAtkins: problem with using z-index is that you want to just deal
              with the flex items, not everything else on the page
   RESOLVED: Not addressing stack axis in Flexbox

   alex: Do 'before'/ 'after' apply to direction based on writing mode or
         based on flex order?
   TabAtkins: Currently flex-align: start aligns to the beginning of the
              flex order
   alex: flex-align: after goes after the first line (towards the second)
   RESOLVED: logical keywords are flex-relative, not writing-mode-relative,
             when used in flexbox

   TabAtkins: Let's say it says width: flex(1)
   TabAtkins: And you give it a min-width of 50px.
   TabAtkins: Should this start the flex calculations from 50px?
   TabAtkins: Or should it start from zero and then check/correct if necessary?
   TabAtkins: This is important if I want to give each item flex of 1, but
              set a minimum for readability
   TabAtkins: If you make it so that everything starts from the minimum width,
              this breaks
   TabAtkins: Everyone will start at their min-width, then they'll flex, and
              then they'll be different size
   TabAtkins: However, that method is easier
   TabAtkins: However I think it is a bad enough behavior that it should be
   TabAtkins: I'm specifying exactly when min/max are taken into account
   TabAtkins: Think we should make sure min/max are handled after flexing.
   fantasai: I think I agree
   dbaron: ...
   TabAtkins: The passes are limited and cheap. It's multi-pass layout, but
              not full layout. Will converge super-fast.
   Alex: Don't think it's possible to avoid multiple returns, but very hard
         to come up with situation that requires more than one return.
   dbaron: Assuming we know how to resolve intrinsic sizes in block dimension
   dbaron: but that's another problem entirely
   <dbaron> but one I think we should try to solve in this spec
   Alex: Let's say you have flex of 1000px, and your max-content is 2000px
         and min-content is 500px
   Alex: min-width is specified to 100 or 0, doesn't matter
   Alex: which of min-width will go to the min, is it going to be min-content
         or min-width?
   alex: I think what's supposed to happen, if width is 'auto' then we should
         look at min-content width
   alex: If width is specified, then we should not look at min-content width.
   fantasai: I think it makes sense? I think it's consistent with what Tab
   TabAtkins: We're working on an implementation, and you're working on an
              implementation, so we should be able to figure out what's sane
   alex: Question is in what cases do we consult min-content, if ever
   alex: Default value of min-width is 0
   alex: so it's always specified
   fantasai: do we need an 'auto' value for min-width?
   alex: ...
   alex: Could say minimum is max(min-width, min-content)
   alex: Problem with that is you can never have a box that is smaller than
   TabAtkins: Could we say by default things can shrink to zero, and if you
              want min-content as a minimum, you say min-width: min-content
   Ojan: Seems non-flexbox specific
   alex: Different because flexibility depends on the width
   Ojan: To be consistent with
   OjaN: if you put min-width: 100px and width: 300px then you'll get 300px
   dbaron: Those don't conflict. If you swap them you get 300px
   Rossen: The problem is that if you want to achieve parity with behavior
           of table cells floaters abspos or anything else that does
   Rossen: min-content is always respected in these types of layout
   Rossen: flex in this case doesn't respect the minimum content
   Rossen: If you have some characters, and default value of min-content
           is 0, flex will currently shrink all the way down to zero
   Rossen: might or might not be what you want
   fantasai: How about changing the initial value of 'min-width' to 'auto'?
   Rossen: When would you not want min-content?
   alex: I have a huge long unbreakable line, don't want to follow that
   steve: Wouldn't you want the same thing in a table?
   TabAtkins: It's easy to do what we want for flexbox. Still means tables
              are confusing, but everybody else works the same way.
   TabAtkins: If you want min-width of 0, set it to zero. If you want
              min-width of min-content, say so.
   RESOLVED: Effective min-width on flexes is a limitation after the initial
             flex resolution, not while figuring out preferred width of element.
   dbaron: The way things need to work for blocks and tables is that min-width
           doesn't affect the pref width of the element, but affects the pref
           width of the parent
   RESOLVED: minimum width is just min-width; min-content is not an implied

   TabAtkins: There was a question when flex-align: stretch combines with
              'max-width' smaller than the size of the flexbox so that it
              can't stretch fully
   TabAtkins: Proposal is to respect the sizing constraint and then start-align
   RESOLVED: proposal accepted

   Ojan: Do we want to address visibility: collapse
   fantasai: the problem with using display:none to dynamically show/hide
   fantasai: ...is that you really only want to take thing out-of-flow in
             one dimension (the main axis).
   <Bert> (Example of 'visibility: collapse' in tables:
   fantasai: You can't do that with display:none, but visibility:collapse
             is *supposed* to solve this in tables.  It does a bad job,
             but we can't do it right.
   (example was of a panel with collapsing panels)
   dbaron: I think it doesn't work well in tables because it hasn't been
           solved right yet.
   dbaron: Because if you have more space for the other things, they can
           be smaller in the other dimension, so they'll still change size.
   fantasai: Tables also have the problem that row/col spans get clipped
             oddly by collapse.
   ojan: My concern with this is that this is sort of a more generic thing.
         Why doesn't this work on lists (hiding, but still incrementing
   fantasai: I'd like it to work there.
   ojan: Right, but there's backwards compat issues.  So let's ignore
         collapse, and solve it properly with a new property or value.
   dbaron: What's the problem with lists that's not solved by display: none?
   TabAtkins: Preserving counters.
   fantasai: Also contribution of the width to the parent's intrinsic size
   TabAtkins: Also, running animations.
   Steve: what happens if I set height to zero
   fantasai: you also have to turn off padding, border, margins, box-shadow,
             etc. etc.
   Ojan: So it's dead in the water to make visibility: collapse; work on
         block elements, I presume?
   dbaron: I don't know, maybe not
   Molly: visibility: collapse isn't taught
   fantasai: Goal is to make it not show up, just like display: none;
             except without some of its problems
   Bert asserts that you'd want to leave extra space so that the content
        after the list stays the same place
   fantasai doesn't understand what we're arguing over anymore
   dbaron: sounds like this is unresolved

Scribe: TabAtkins

   howcome: multicol is in CR.  impls are coming along.
   howcome: But there's one area I've discovered where we don't have interop
   howcome: the break-before/after/inside properties
   <howcome> http://www.w3.org/TR/css3-multicol/#break-before-break-after-break-inside
   howcome: Basic question I need an answer for.
   howcome: Applies to both column and page breaks.
   howcome: Say you have an element, the first in a page or column.
            And you set break-before on it.
   howcome: Should you apply it (forcing a new break), or just leave it,
            since it's already the first element.
   howcome: I think we should do the latter.
   howcome: For both pages and columns.
   fantasai: For pages, you sometimes want blank pages, but you don't want
             *arbitrary* extra blank pages.  Usually you want to start all
             chapters on the left page, or something.
   glazou: Sometimes you do specifically always want, say, 1 blank page
           before chapters.
   fantasai: You can do that by using ::before or similar and give it a
             sufficient height (but no content) to push the rest of the
             content down.
   howcome: 2 out of 3, roughly, do it the way I want.
   <ChrisL> <div class="notes" style="page-break-before:always;background-image:tpilb.png"/>
   howcome: The others force a new break.
   glazou: So the proposal is to *not* create a blank column when the first
           element in a multicol has break-before:always.
   RESOLVED: break-before:column won't force a blank column when the element
             is the first in the column.
   fantasai: For pages, there are use-cases where you want to feed the blank
             pages, there are larger use-cases where you *absolutely don't*
             want that.
   fantasai: So we should use that as the default, and possibly address the
             "force blank pages" later.
   RESOLVED: Pages work the same as columns - an element at the top of the
             page with break-before won't force a blank page.
   howcome: Now, <div><div></div></div><style>div { break-after: all; }</style>
   howcome: Two breaks?  Or do they collapse?
   fantasai: I think they do collapse.  The spec seems to imply that as well.
   TabAtkins: And it's consistent with the decision we just made.
   alexmog: I don't think any browser currently has that behavior.
   fantasai: I intend to fix that in Mozilla.
   alexmog: I think all browsers collapse -after breaks, but not -before breaks.
   alexmog: Things like the <html> element shouldn't count as "content"
            before the element, forcing a break.  Same with display:none
   fantasai: For <div>...</div><div/></div>...</div>, we shouldn't collapse -
             breaks shouldn't collapse through the empty element.
   szilles: I'm surprised at this.  I would think it would be simpler to
            always honor the breaks, not collapse.
   alexmog: Say you have an <h1>, the first thing in the document, and you
            set break-before on it.
   alexmog: But it's *not* actually the first element.  <html> and <body>
            precede it.
   szilles: Isn't that consistent with our previous case?  If the <h1> is
            at the top of the page...
   TabAtkins: This is a different case
   TabAtkins: In this multicol case, the <div> is literally the first thing
              on the page
   TabAtkins: In the other case, the <h1> is not the first thing on the page,
              it's wrapped by a <body> and an <html>
   szilles: Define that as being at the top of the page
   Alex: Orphan control shouldn't .. if you have a region with only room for
         one line, and we have an element with orphan that has 3 lines
   alex: we're currently going to move that to the next region because we're
         not at the top of the page
   * unsure that was minuted correctly
   alex: You have a long enough paragraph, multiple lines
   alex: starts in a region which can fit just one line
   alex: which is ok for titles
   alex: You want that one line to still be in that region, even though with
         orphan control will want to keep it with the rest of the parent
   alex: The reason these cases are related, is if break-before and
         break-after are interpreted as I think in the spec
   alex: they're not "make sure there's a break here", it's "make sure this
         is the first thing on the page"
   alex: For both widow/orphan and breaks, you're still looking at whether
         you're the first thing on the page
   alex: opening tags don't count as making you not at the top of the page
   szilles: That would just fall out of the definition, which is make sure
            this is the first thing on the page
   howcome: ...
   howcome: <chapter><section></section.</chapter>
   howcome: You want each chapter to start on a new page, and each section
            to start on a new page. You want to set break-before sections
            and chapters
   fantasai: 2.1 says that when determining breaks, you look at the break
             properties of all the elements that meet at the given margin.
   fantasai: It's pretty vague, unfortunately.
   alexmog: page breaks don't prevent margin collapsing, though...
   <alexmog> http://www.w3.org/TR/CSS21/page.html#forced
   TabAtkins: Specifically, the definition of "top of a page" is underdefined.
              Does a margin or border on a parent make you no longer at the
              top of a page?  (The correct answer is no.)
   dbaron: It needs to be defined in a whole bunch of cases. Frex Mozilla
           has mTopOfPage, which deals solely with the possibility of
           nothing fitting -- it lets us know if we have made any progress
           in putting things on the page, so that we don't keep breaking
           and placing no content
   dbaron: For that placing a border does count
   alexmog: Having <body> as your parent, even with ??? is honored.
   alexmog: If you look at break-after, which is supposed to be consistent
            with break-before, all browsers collapse break-after.
   szilles: Isn't that the same rule/difficulty in determining if something
            is at the end of the page?
   alexmog: Yes.
   alexmog: [some section] has a very simply rule that just says a forced
            break occurs when any elements contributing to the current margin
            have a forced break.
   alexmog: So you go and do normal margin collapsing, then look at the result.
   alexmog reads from CSS2.1 spec
   fantasai: It wouldn't have been written to imply more than two elements if
             collapsing wasn't meant to happen.
   howcome: So we can just clarify 2.1 if it' snot fully clear.
   szilles: Doesn't the margin definition break if you put a border on <chapter>?
   TabAtkins: Yes, and that's bad.
   dbaron: What happens if one says 'left' and the other says 'right'?
   howcome: I say you choose whichever one grants you the most pagebreaks.
   fantasai: When collapsing breaks there's nothing "between" your breaks.
             I think you should choose the last one, because it's the one
             closest to the next content.
   howcome: I'd like to have a resolution because we're in CR, and we need
            testcases written.
   howcome: I can live with the last one winning if there are conflicts.
   fantasai: The spec is pretty clear that a series of page breaks should
             never generate more than one page break in series.
   howcome: Okay, so collapsing works.  Do borders stop break collapsing?
   alexmog: They block margin collapsing, so.
   howcome: Can't we just lean on margin collapsing's rule?
   fantasai: I don't think there's *ever* a use-case for having a border
             on an otherwise blank page with this.
   alexmog: the 2.1 definition is based on margin-collapsing.
   Florian: We should prioritize authors over implementations, and authors
            don't want a blank page with just a border.
   alexmog: And if we can avoid changing the very complicated margin-collapsing,
            that's good.
Scribe: fantasai
   szilles advocates for just coming up with a good definition for top-of-page
   szilles: Definition is if you haven't put any content on the page, then
            you're at the top. And borders aren't content.
   TabAtkins: This is still wayyy simpler than margin collapsing. There's no
              negatives, no zero-height elements that collapse through, none
              of that.
   howcome: I think there's some kind of consensus here.
   proposal: page-break-before doesn't create a break if you're at the top
             of the page, where at the top of the page means no content has
             been placed. Borders do not count as content. Zero-height elements
             count as content.
   dbaron: So placing an empty block counts, but placing start of a block does
           not count.
   dbaron: Alternative def is placed either a non-phantom line box or a
           non-replaced block with non-zero height, or anything other than
           something that goes in a line box, or something that doesn't go in
           a line box and isn't a non-replaced block
   TabAtkins: Can we just say line boxes is all we care about?
   dbaron: tables? replaced blocks?
   TabAtkins: Why are we allowing ... collapsed through?
   dbaron: Because alex wanted it
   Alex: I really like CSS2.1 definition because it covers lots of cases in
         just 2 lines
   howcome: So we have one proposal which is 2.1, based on margin collapsing
   <dbaron> I'm fine with the 2.1 definition
   howcome: And then another, perhaps simpler, definition
   howcome writes out the definitions
   dbaron: One thing that seems weird is that you have start of a block,
           that's ok, and end of a block, that's ok, but start *and* end of
           block, that's not ok
   TabAtkins: The break-afters generate a break
   TabAtkins: The break-befores don't generate a break: they're already on
              a new page
   fantasai: The thing that's weird is collapsing anything through the
             content area of an element. We do that for margin collapsing,
             and its weird. We should not do that here.
   alex: I have a problem with not counting the border as content
   alex: My margin will be after that border, and while I'm asking to be
         the first thing on the page, I'm not really
   TabAtkins: I think the potential downside of where that might be confusing
              is less bad than having an entirely blank page with nothing but
              a border on it.
   fantasai: Note you're actually not required to print pages that have only
             backgrounds and borders on them
   howcome: It seems you feel quite strongly about this, Alex.
   howcome: Let's take a quick straw poll.
   A: alex
   B: steve/fantasai/tab
   jj: A
   alex: A
   koji: abstain
   Markus: abstain
   Tantek: abstain
   Steve: B
   Alan: abstain
   Florian: B
   Bert: abstain
   lots of abstain
   howcome: we can collapse all the abstain :)
   Rossen: A
   dbaron: A
   sylvaing: abstain
   arronei: A
   Tab: B
   fantasai: B
   smfr: B
   molly: B
   <hober> b
   fantasai: explains the two options
   molly: The empty <div> is there. If we're dynamically generating things,
          it should have an effect
   now howcome is explaining why we're collapsing at all
   Alex: If you look at continuous media, where instead of page-break you
         have a large margin
   alex: e.g. 3em margin
   alex: whatever comes after margin is held together by the results of
   fantasai: If you're collapsing through this empty element, where is this
             break happening?
   fantasai: If you have a bunch of break-afters, and you collapse them,
             and you break the page, the margins that were there get truncated.
   fantasai: But after a forced page break, you keep margins at the top.
   fantasai: If you have an empty div, and you have set break-before and after
             on it, and the preceding and following div also have breaks,
             which page is the middle <div> contributing to?
   dbaron: And more importantly, which page is the empty div on?
   alexmog: Where does it say that margins are truncated after the break?
   howcome: We resolved on that.
   dbaron: [explains the 2.1 spec for it]
   dbaron: And this assumes that breaks exist *between* block-level margins,
           rather than being stuck somewhere *inside* of collapsed margins.
   <dbaron> quoting 13.3.3 point 1 and the note following
   new straw poll!
   jj: A
   alex: A
   Florian: B
   Bert: A
   Brad: B
   hober: B
   smfr: B
   Kim: B
   Molly: B
   Rossen: B
   dbaron: B
   arronei: A
   TabAtkins: B
   fantasai: B
   glazou: B
   ChrisL: B
   Totals: 4 A, 13 B
   RESOLVED: page-break-before doesn't create a break if you're at the top
             of the page, where at the top of the page means no content has
             been placed. Borders do not count as content. Zero-height elements
             count as content.
   ACTION fantasai: put proposal B for page-break collapsing into specs
   <trackbot> Created ACTION-393
   dbaron: We should errata 2.1
   alex: can we get it written up first?

   sylvaing: Column boxes define a containing block, right?
   sylvaing: What if my columns are balanced and I have a percentage height?
   dbaron: If it's auto height, it's auto-height
   dbaron: The column boxes all occupy the full height of the multicol box
   dbaron: They should have the same implicit height
   sylvaing: Don't they adjust when you balance
   <Bert> ACTION bert: create issue against CSS 2.1 corresponding to ACTION-393.
   <trackbot> Created ACTION-394
   RESOLVED: percentage in block dimension is computed relative to multi-col


   howcome: This is what I showed last night.
   howcome: A few other changes we need to go through.
   howcome: WD is a year old.
   howcome: One thing that left GCPM since then is hyphenation
   howcome: We should do an updated WD
   howcome: A couple other things
   glazou: Markus has shown me horizontal navigation in a document that is a
           little bit in conflict with your proposal
   howcome: I don't think it's in conflict, they're going in the same way
   Markus and howcome seem to be ok with the situation
   howcome: I'm not tied to the syntax, but I think it should be declarative
            as you say
   markus: Declarative is good, but you also need JS access

   howcome: First issue is with leaders
   howcome: Bert brought up this point
   howcome: The issue being that he wanted to have control over alignment
            of leaders
   howcome: If I understood correctly, Bert, you wanted to create a leader that's an arrow
   howcome draws: ABC ------------> 1
   <Bert> -> http://www.w3.org/Style/Examples/007/leaders examples of leaders
          (hacked, of course, but showing the way I want them)
   howcome: In order for this arrow, which is in the generated content,
   howcome: to make this visually make sense, Bert wants the point of the
            arrow to connect with the line
   howcome: So that you don't get that effect *draws an arrow where the head
            is broken from the body*
   ChrisL: That assumes the horizontal lines match up with the arrows
   Bert: In the Symbol fonts they do
   howcome: the idea is to add a second argument to the leader function,
   howcome: I think these are the values you need: 'start', 'end', 'center',
            'space', 'pattern'
   howcome: pattern is to make the dots align across lines
   glazou: 'space' will mean whitespace in web author's mind, please use
            something else like 'stretch' (just an example)
   fantasai: Stretching implies stretching the glyph. 'background-repeat'
             already uses 'space' for stretching the gaps
   howcome: You want these leaders to align. I think this is the most
            common use case.
   szilles: Don't understand where the space is added.
   dbaron: You put as many characters as will fit. In normal case you
           right-align them
   dbaron: In space case, you insert spaces between the leaders
   szilles: Need to be clear about whether its between all the characters
            or between each string
   Bert: Not the way it works in TeX, but it's another option
   Bert: The leader unit is a fixed size, doesn't change size
   Bert: Can put space before/after, both, etc. but not inside it
   Tantek: Aren't leaders like border-images?
   Tantek: why not use images
   szilles: Because the common case is to use glyphs
   <ChrisL> typographers also see decorations as glyphs
   fantasai: might want both characters and images
   fantasai talks about matching the dots to the dots in the font, in size,
            postion, and shape; this is why they are glyphs, not images
   szilles: We've talked about a need for characters, there might also be
            a need for images
   molly: I think space, which goes characters out to available space, and
          justification which fits inside the containing block
   molly: What I interpret that as meaning space out the chraacters to take
          up the width
   howcome: That's right
   howcome: The quesiton is between all characters or only where the
            repetition is
   szilles: Why not have two values
   fantasai: space and justify
   fantasai: space like border-image and background-repeat
   ?: letter-space and pattern-space
   molly: justify makes sense
   molly: This addresses both issues
   howcome: Does anyone need center?
   Bert: Sometimes you want as much space before the leader as well as after
   dbaron: Centered absolutely or centered individually?
   Florian: We're resolving to split the space into two, and not remove any
            other value
   some confusion around everything
   * tantek provides a dot-leader example from >10 years ago: http://tantek.com/CSS/Examples/dotleaders.html
   <tantek> (try resizing)
   <tantek> #tablesabuse
   howcome puts in string-space and letter-space
   bikeshedding 'pattern' leads to 'align'
   fantasai: I'd also drop the comma and use ||
   fantasai: just like in properties
   Bert: One more about leaders, but maybe not so easy to solve.
   Bert: How to make double-ended arrows
   fantasai: Just put three strings: "start" "middle" "end"

   TabAtkins: image-resolution is in css3-images, so should remove from here
   howcome: ok, done

   szilles: One other catch with alignment
   szilles: In Indic languages, the leader aligns with the hanging basline
   szilles: In Japanese it would be centered
   fantasai: That should be handled in the fonts
   szilles: The leader needs to be aligned to the relevant baseline.
   szilles: That may fall out
   szilles: Just want it noted
   howcome: Nothing changed in ... various sections ....

   howcome: Paged Presentations
   howcome: This is basically what I demoed yesterday, where we use the
            overflow property to set the axis onto which we put out these pages
   howcome: They could be analyzed and split into two, and we could have
            multiple properties for them
   howcome: We did that at some point in our implementation, but it creates
            many possibilities
   howcome: that we aren't really going to use
   howcome: So instead we have four values that cover the needs we have found
   howcome: there might be others
   howcome: not tied to syntax, but we like the functionality
   howcome: the -controls bit adds the UI
   howcome: native UI for paging
   szilles: I'm concerned that it's not as standardized as scrollbars are
   howcome: It's like HTML5 controls for video
   glazou: that's in the markup
   alex: ... overflow paginator, could be x and y
   howcome: Could split these into 2 properties. Paged thing could be on
            2 oveflow, and the others on a different property
   howcome clarifies that x in paged-x is about how the pages connect,
           not which direction of overflow is affected
   glazou: I'm very concerned about the controls bit
   Florian: Does the first bit forbid the UA to have controls?
   howcome: Alex asked, does touch work both places?
   howcome: This just adds visual controls
   dbaron: In the simplest case it could even be a scrollbar, though probably
           not the best idea, but it could be
   <ChrisL> so the distinction is that the controls take up space
   howcome: We have overflow: scroll, so we are referring to controls already
   fantasai: In scroll vs auto, we're distinguishing whether the controls are
             visible when there's no need to scroll, not whether the UA should
             put controls at all when there is overflow to scroll to
   dbaron: More similar to hidden
   molly: Point out that if the controls are UA-dependent, could be a problem --
         authors will want to style it
   Bert: When we introduced marquee, we added overflow-style and had it as a
         value of overflow-style
   Bert: This seems more like additional values for overflow-style
   Tantek: overflow-style: marquee-paged
   Markus: In the first case (paged-x) you still want some indication of
           where you are
   Markus: The default shouldn't be nothing.
   <tantek> where's Tapas when you need him
   dbaron: There are 2 options, in some sense there's no default. You can
           choose with or without controls
   howcome: This is where we've built a UI through the DOM. These controls
            have been made by the page (shows demo) whereas these are made
            by the UA
   szilles: I'm still confused about what "this" is that you say should be
            in CSS
   Adobe: In Acrobat the controls appear on hover
   howcome: you can choose whether UA gives controls or whether author
            provides controls
   fantasai: What if the author assumes you have a swipe interface for
             paging, and doesn't provide controls, but I don't have that
             interface? Then I'm stuck.
   glazou: When you use the overflow property, you just say that the overflow
           should be visible in some way. You don't make any provision about
           the means.
   <dbaron> I disagree with Daniel.
   <dbaron> I don't think saying there are "controls" is too constraining.

   Markus: Here I'm showing you a similar solution using regions and exlucions
   Markus: You have a template mechanism that handles overflow.
   Markus: At the bottom there is a little indicator of where you are and
           how many pages you have
   Markus: If I use the mouse, I get a scrollbar
   glazou: Here you are stopping the scrolling between two pages
   (markus is demoing)
   markus puts some experimental -ms- snap properties
   markus: Now it snaps between pages
   markus: But you still get a progress indicator, so you know where you are
   markus: Beauty of this approach, based on regions, it's a simple JS
           templating model.
   markus: You can inject animations, etc. etc.
   markus: Not saying howcome's idea is a bad idea, but this brings more

   * tantek notes that Opera claims to support overflow-x and overflow-y:
   Tantek: Can we go back to howcome's demo
   Tantek: You mentioned that simple values etc.
   Tantek: I'm wondering how does that interact with overflow-x and overflow-y
   Tantek: I know Opera supports those.
   Tantek: If you've figured that out, I'd love to understand that interaction
   howcome: These properties only belong on overflow shorthand
   Tantek: That's why I think they should go on overflow-style
   howcome ...
   fantasai: I agree it should go in overflow-style
   dbaron: This changes the layout model
   dbaron: It's not just changing how we get to the overflow

   fantasai: I have a question for Markus: what happens when you print?
   Markus projects:
   body {
     overflow-x: auto;
     overflow-y: hidden;
     -ms-scroll-snap-type: mandatory;
     -ms-scroll-snap-points-x: snapInterval(...)
   Markus: In general the basics of how this app runs, it's just a simple
           page that brings in other html pages as templates
   markus: We also have a default overflow template
   markus: Just a little bit of JS to make this stuff work
   glazou: little bit?
   markus shows template pages
   markus: Place my items, grid
   Markus: What I showed you at the end is playing with this snap thing
   Markus: You can snap after one page, multiple pages, define ranges etc.
   Markus: We presented at the build conference, sdk out there, want to
           bring th WG as a propsoal
   glazou: So this only works with JS?
   fantasai: I don't mind having JS interact with CSS, but I don't want us
             to build layout models here that require JavaScript in order
             to work.

   <tantek> LOL - Håkon's pagination proposal is already in the media:
   <tantek> (and http://dvice.com/archives/2011/10/creator-of-css.php )

   Markus: With scripting you can do interesting animations
   Markus: When we started thinking about pagination, we started with
           something ismilar to howcome's model, but thought it would
           be better to have .... to create a better magazine-type experience.
   hober: ...
   howcome: I encourage you to add pagination to regions
   alex: Pagination should not be part of regions
   howcome: Regions should know how to work with pages
   szilles: I agree with fantasai's statement that layout models shouldn't
            require JavaScript, but also good to define events and things
            to add more
   glazou: Agreed, but the basic thing howcome demoed shouldn't require JavaScript
   * tantek agrees with szilles
   sylvaing: Right, it should be optional
   <tantek> pagination events would be useful
   howcome shows his api
   szilles: I might want to ask questions about pages, like what links are
            on this page
   howcome: I think that's reasonable
   howcome: I object to you calling this a low-end feature, markus.
   howcome: I can recreate the Economist's layout almost pixel perfect with this
   BradK: Howcome's solution, the UA can provide the UI for how the pages
          get turned
   bradk: So you can even hav an ibook like experience, where it's curling
          and everything. Could be a high-end kind of experience
   florian: high-end from control of the user, not the author (?)
   bradk: I consider UA controls an advantage. Don't have to relearn how to
          turn pages on every website
   Alan: I think whatever we build for pagination should work with multicol,
         work with regions, should work without either
   Alan: Could see this for slides
   Markus: As soon as you want more flexibility on what things look like,
           you need regions
   bradk: Scrollbars are the same every page you're at, unless the author
          does something special
   bradk: I think that's good, so you don't have to figure out how to turn pages.
   Szilles: If we're going to do what Brad just said, we should agree on
            what the components are
   szilles: My Kindle can do more than go back and forth between pages
   szilles: A bunch of things ppl expect when paging things
   szilles: Come up with some expectation of what the controls should be
   szilles: controls is too open ended
   [szilles says stuff about bookmarks etc]
   molly: I agree.
   molly: Need consistency, and say explicit about how it needs to be done
   hober: HTML5 doesn't say much about what the video controls should be
   howcome: Depending on what the device is, might have different controls
   Florian: Say what capabilities it has
   molly: I want to step back a moment, I understood that if you use these
          features and allow the UA specific controls, that you will be
          able to style those controls
   Florian: If you want to style it, you build it yourself.
   molly: ok
   hober: UA could provide some hook into its controls, but that's up to the UA
   molly: As long as ppl can create their own controls
   Bert: As long as I as the user can override what the author does
   Bert: I want consistency across pages. I choose my browser.
   fantasai: If the author says, don't put controls, and builds his own out
             of JS, and the user is lke "I can't deal with these weird
             controls, I want my own controls", how do you deal with that?
   Florian: Turning on the UA controls is easy. Killing the author controls
            is not so much.
   szilles: Also need to make sure there are screenreader APIs for this.
   discussion of accessibility apis and what they're capable of
   <mmielke> Links to the Regions based demo (runs on win8 developer preview):
   molly: When you're looking at this content anyway, the content is
          linearized in your core document
   szilles: With regions you can mix streams
   alex: I think this should be a display property
   alex: If it's overflow property, it applies to everything. But paging a
         flexbox doesn't make sense.
   alex: All other kinds of layout that support overflow don't need to support
         paged overflow
   plinss: Don't see why you can't paginate flexbox

   howcome: I'd really like to publish another WD of GCPM.
   howcome: We haven't gone through everything, so we can have big disclaimers
           about syntax and everything
   howcome: But I'd like to get out another WD. First for updates to other
            things. But second there seems to be consensus that we want to
            work on this.
   glazou: Don't have consensus, have interest
   glazou: So provided you document all the issues and comments.
   glazou: It's only a WD and we have interest in the feature
   szilles: I'm def interested in the feature, but not sure where it belongs
   fantasai: It can start here, and then we'll see where it goes. Just like
             everything else.
   TabAtkins: Move counter styles to css3-lists? most is already in css3-lists.
              Willing to take on the next thing
   dbaron: I think there's a bunch of things in this spec, and not a whole
           lot of interest in other things in the spec
   dbaron: So we're going with the model that everything we actually want will go
           out of it?
   fantasai: we're doing that already
   howcome: Like John said, I don't think this module will ever go to REC
   glazou: Any objection to publishing?
   RESOLVED: Publish CSS3 GCPM as soon as all edits are made

glazou: Reminder, lot of joint meetings tomorrow, not necessarily in this room
glazou: Also FXTF on Thursday
glazou: Start here tomorrow.
glazou: We will discuss CSSOM with Anne at 9am
fantasai: jdagget, kojiishii and I will be having a joint meeting with
           the UTC on Thursday

Received on Monday, 28 November 2011 21:59:21 UTC