W3C home > Mailing lists > Public > www-style@w3.org > May 2012

[CSSWG] Minutes and Resolutions Hamburg F2F 2012-05-15 Part III: GCPM and Fragmentation

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 15 May 2012 18:23:27 -0700
Message-ID: <4FB3018F.30208@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
GCPM
----

   - Reviewed some features in GCPM, including new float keywords,
     columns() notation in 'float', and float snapping

Fragmentation
-------------

   - RESOLVED: Accept the CSS3 Break proposal as stated in the minutes.
   - RESOLVED: Publish a WD of CSS3 Break in a week after edits announced
               if there are no objections.

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

GCPM
----
Scribe: jdaggett

   Håkon introducing gcpm
   parts  pragmatic, parts blue sky
   in 2007, we had how to generate lists, glossaries, toc
   showing example
   using javascript
   to generate index
   shows page range rather than pages in index
   wanted to highlight feedback from implementors
   interesting - page floats
   allows use to do paginated content on page and screen
   shows demo from last f2f
   implemented from proposals in gcpm

   section 12 page and column floats
   feedback from hyatt
   added new flow-relative values
   added line-left, line-right
   fantasai: similar to start, end but doesn't change due to bidi
   fantasai: terms defined in writing modes spec
   glenn: i object, left is left, right is right
   fantasai: so what does text-align: right mean in vertical?
   stevez: no, no, no
   stevez: can you say inline-left instead of line-left
   stevez: wait, my reason is wrong...
   more argument about left and right vs. start and end
   fantasai and alex arguing more
   alex: sorry, i still think left, right are bad terms
   liam: why do you want to be bidi-independent
   stevez: english text, right-aligned needs to be right-aligned
           not start aligned
   glenn: so you need right/left in vertical?
   fantasai: we have left and right values for text-align, whether you like
             them or not they need a defined meaning for vertical text
   stevez: i think inline- would be better here than line-

   florian: do we need over/under?
   fantasai: We don't need those; you probably want before/after
   bert: where does it go if you say before/after?
   tabatkins: in english before is the same as top
   liam: should be block-left, block-right
   fantasai: wrt adding line-left/line-right in addition to start/end,
             I don't care much
   Håkon: i just copied hyatt's proposal
   <Bert> (Seems 'before' means before the current block, not necessarily
           the top of the page/column/BFC/whatever, but the description
           is a bit short.)

   Håkon: he also added the ability to span columns
   fantasai: why not use column-span
   Håkon: keep this on the float property is the proposal
   stevez: not true Håkon
   stevez: with a media query, i may vary the number of columns
   discussion of columns used at different sizes
   Håkon: in our implementation we couldn't do column spanning
   Håkon: too many weird situations
   Håkon: if you span an arbitrary element in multicolumn
   stevez: you don't have enough there to fully explain the situation
   Håkon: if you have two properties that cascade differently, may not
          mesh well together
   fantasai: column-spanning is effectively setting the width, that's a
             separate thing from its position, which is what float is
             setting.
   fantasai: if you're making the argument of setting the column-relative
             size in 'float', why not also make argument that width should
             be set in 'float' too?
   liam: content can span columns without flowing
   Håkon: in opera, two different properties
   Håkon: column-spanning has to be on the float
   dbaron: if you're going to write that it's going to span columns,
           what's the harm of writing that in the value of the 'float'
           property?
   alans: if you want to span two columns you can say, column-span(2)?
   liam: i was just commenting on column-spanning content not always floating
   * jdaggett why did i volunteer to scribe column spanning discussion….?
   stevez: you would like it to extend back
   discussion on whiteboard b/t
   <fantasai> Håkon drew a 3-column box with three 2-column-spanning floats:
   <fantasai> first float started in first column, spanned into second
   <fantasai> second float started in second column spanned into third
   <fantasai> question was what happens with third float
   <fantasai> which starts in third column
   http://lists.w3.org/Archives/Public/www-archive/2012May/att-0025/gcpm-colspan.jpg
   liam: sometimes call "negative spanning"
   liam: acm papers, tables occur where they occur in content, they span
         there

   Håkon: snap to nearest container edge
   Håkon: e.g. near bottom, want to snap to bottom so don't have one line
          between image and box edge
   Håkon: related to widows/orphans behavior?
   fantasai: don't use widows/orphans properties for this
   Håkon: so what does snap mean?
   fantasai: suggest e.g. snap(3em) = within 3em you snap
   alans: you're trying to decide between syntax?
   Håkon: no, an implementor has proposed it
   Håkon: i think it would be good for comments to happen on the mailing list

   fantasai: I've heard three things so far
     (3) better syntax for snapping
     (2) should use float: columns(2) or float + column-span?
     (1) rename line-left/line-right to inline-left/inline-right?

   Håkon: bert's issue
   Håkon: about running headers
   stevez: xsl uses flow-into and you pick a slot to put it into
   Håkon: do we want this parameter for regions
   arguing whether steve's xsl parameter covers the use case
   Håkon: comment on example 11
   Håkon: keyword approach also possible
   glazou: that's cloning the flow into the region instead of moving it there
   bert: don't know about syntax, want functionality
   stevez: just noting the way it was done in xsl
   Håkon: this is a problem to tackle

CSS Fragmentation
-----------------
Scribe: TabAtkins

   fantasai: One issue, what uses specified height.
   fantasai: Say I have a specified height of 500px on my element.
   fantasai: And there was a large image in my content that spans a page break.
   fantasai: So the image moves down to the next page, there's a gap left
             in the old page.
   fantasai: So does that gap count against my "500px height"?
   http://lists.w3.org/Archives/Public/www-archive/2012May/att-0025/break-slice-clone.jpg
   fantasai: Rossen and I thought it made sense to skip.
   fantasai: when you're using box-decoration:slice, it's not very clear,
             but for box-decoration:clone, it seems pretty clear that we
             want to skip the gap when calculating height.

   dbaron: Are any of the decoration drawn in the gap anyway?
   dbaron: I'd prefer to skip all of that.
   dbaron: I'm concerned about background-position interacting with that,
           and avoiding drawing parts of a background more than once.
   fantasai: [explains box-decoration:clone]
   dbaron: My gut feeling is that I want, whether it uses borders,
           background, or height, for it to be consistent with each other.
   dbaron: We may want a control for the whole set later, but I think
           picking a default for now is fine.

   vhardy: Another issue on the mailing list is about, if the image moves
           to the next page, can the following text move back up to fill
           in the gap?
   TabAtkins: Wasn't there a float keyword proposed to do something like that?
   ?: I think next-page, or if-room?
   howcome: unless-room, but I think snap will do that now.
   [off-topic discussion about floating]

   fantasai: So with a specified height, I'm okay with not drawing
             decorations in the gap.
   fantasai: But with an auto-height element that's multiple pages tall,
             with some gaps in the background would look weird.
   dbaron: I think skipping would be normal behavior, actually.
   plinss: Depends on what the background is for.  If you have a fancy
           background on the <body>, and your element uses a white
           background to put something flat under the text, you'll
           expect it to continue without gaps.
   fantasai: I think it doesn't make sense to slice the background in
             the middle of the page.
   szilles: For government usage, they *really* wanted a specific
             background (like a repeated "mandatory" image) to cover all
             and only the areas that are explicitly the given element.
   szilles: So you want it to gap.
   [some missed discussion about how drawing in the gap is like drawing
    in the margin area]
   fantasai: [gave an example with two floats, both page-breaking to
              the next page but on different vertical positions]
   http://lists.w3.org/Archives/Public/www-archive/2012May/att-0025/break-slice.jpg
   fantasai: Proposal: first, do you use up specified height for the gap?
             The answer is "no, never".
   fantasai: Second, when do you draw the background/borders in the gap?
             Answer is, in the fixed height, no. In auto height, yes.
   TabAtkins: the value of this is that it preserves the invariant that
              dbaron wanted to preserve, while looking good for both for
              the common cases.
   RESOLVED: Accept the CSS3 Break proposal as stated in the minutes.

   fantasai: Then can we publish a WD?
   howcome: No comment against that particular request, but I think in
            general we should be asking for publication against the current
            WD, not against a future spec based on pending edits.
   plinss: In general, I agree.  I think it's safe to make a provisional
           request here.
   RESOLVED: Publish a WD of CSS3 Break in a week after edits announced
             if there are no objections.
Received on Wednesday, 16 May 2012 01:23:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT