W3C home > Mailing lists > Public > www-style@w3.org > January 2009

[CSSWG] Minutes and Resolutions 2009-01-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 14 Jan 2009 12:39:25 -0800
Message-ID: <496E4D7D.6040605@inkedblade.net>
To: www-style@w3.org


   - RESOLVED: Accepted Melinda's proposal to change "minimum number of
     lines in paragraph" to "minimum number of line boxes in a block
     element" for CSS2.1 Issue 92 (widows and orphans)

   - TENTATIVE RESOLUTION: Accept Melinda's proposed CSS2.1 wording to
     allow margins to be kept after a forced page break.
     PENDING: Steve Zilles' ok.

   - RESOLVED: Background layers determined solely by background-image.

   - Discussed dates for June F2F in Sophia-Antipolis, France.
     June 3-5 and June 24-26 under consideration.

   - Backgrounds and Borders almost ready for Last Call. Given current
     state of implementations, any feature without at least one
     experimental implementation will be marked at-risk in case we need
     to drop it. (We agreed to be more aggressive in using the at-risk
     list than in the past, to avoid dropping back to LC if we wind up
     needing to drop a feature.)

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


   David Baron
   Bert Bos
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Melinda Grant
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   David Singer
   Emily Walters
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/01/14-css-irc
ScribeNick: fantasai

Widows and Orphans

   <plinss> http://wiki.csswg.org/spec/css2.1#issue-92
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Dec/0008.html
   Melinda: I would limit the proposal to the first line there
   Melinda: I suggest changing "minimum number of lines of a paragraph" to
            "minimum number of line boxes in a block element"
   Melinda: This is a change we made to css3
   Melinda: I'm withdrawing the second half of the proposal (wrt table rows)
   Peter: Any objections?
   Bert: I think that's what we always meant it to be, just sloppy prose
   * ChrisL has no opinion
   SteveZ: I agree with Melinda's change
   <dbaron> I agree as well.
   RESOLVED: Accept proposal

Margins at page and column breaks

   <plinss> http://lists.w3.org/Archives/Public/www-style/2009Jan/0087.html
   Melinda: I wanted to talk about top margins with respect to page breaks
   Melinda: I don't have anything wrt columns that I want to put forward
   Melinda: Shall we plunge into that?
   Melinda: Discussion on www-style started by Murakami-san about margins
            at page breaks.
   Melinda: Michael Day has a proposal, that I think is a very good one.
   Melinda: But a piece of it would require change to 2.1
   Melinda: Right now that we say that when a page break occurs between
            blocks, the margins get zeroed
   Melinda: Michael's proposal is that they only get zeroed if the break
            is not forced
   Melinda: If the break is forced, then the top margin is kept
   Melinda: this makes a lot of sense
   Melinda: You don't want the first page of the document, which might
            well be the first page of a chapter/section, to format
            differently from first page of a chapter or section
   Melinda: The first page is not after a page break, so the top margin
            there won't get zeroed
   Melinda: But when you force a page break before the first page of
            chapter 2, chapter 3, etc.
   Melinda: That top margin disappears
   Melinda: That means you have to do exception styling for the first page
   Melinda: Also it's very confusing for authors for the margin to disappear
   Melinda: So the proposal is to open up 2.1 to allow Prince's behavior
   Melinda: I would like to /allow/ that behavior: allow you to retain a
            top margin after a forced break
   <dbaron> Changing 2.1 to allow retention of the top margin after a
            forced page break sounds good to me.
   Melinda: And in CSS3 we want to move to mandating that
   howcome: I support your proposal
   howcome: I think it's a logical behavior
   howcome: I agree with allowing it in 2.1 and requiring it in 3
   SteveZ: I'm not sure if on the 4th page you want to retain the margin
   SteveZ: XSL has a property to control this
   Melinda: XSL-FO does have a property to control whether margins are
            present or not
   Melinda: And I think we do want to have controls in the future
   Melinda: But I think we want to get the best default behavior now
   * sylvaing is in danger of paneling with howcome at sxsw
   Melinda: There were some interesting proposals for margin collapsing
            controls in that thread
   Melinda: The proposal for controls on margin collapsing on the margin
            properties is a good idea and somewhere we should go in the
   SteveZ: I'm concerned about this proposal to preserve margins after
           forced page breaks
   SteveZ: what if you don't want the margin preserved?
   SteveZ: Wouldn't this block extensibility?
   fantasai: No, this would just be the 'auto' behavior.
   fantasai: you could then have other values that say always do this,
             or always do that.
   <ChrisL> I agree with fantasai, this does not block future extensibility
   <sylvaing> it sounds like what we are really defining here is the smart
              default/auto behavior.
   howcome: We don't want to add a new property for every issue
   SteveZ: what if I have a table and I want to force a break to put it
           at the top of the page?
   fantasai: set margin-top: 0; along with page-break-before: always;
   fantasai: If we preserve the margins by default, you always have the
             option of zeroing it out
   fantasai: but you can't put it in if the algorithm requires deleting it
   <Bert> (If table#t1  needs a page-break-before, then you can give it
           margin:0 in the same rule)
   <Bert> (We also can set the first top margin by using a named page
          with that top margin...)
   <ChrisL> Yes, its a more sensible default. As fantasai says, if you
             are forcing a page break, you now have the option of
             retaining or removing the top margin
   Chris: Can we make it a "should" in 2.1?
   Melinda: I think that would be difficult, because we have several
            implementations and they don't all align on this
   <dbaron> So, for what it's worth (since it's hard to get a word in),
            there are some other use cases for margins that disappear.
   <dbaron> It's a quirks mode behavior at the edges of the body and
            the edges of tables cells, at least.
   Chris: but we should give some guidance to implementors
   Melinda: I'm thinking putting it in CSS3 Paged Media will give that
   howcome: behavior on columns should be consistent with that for page
   SteveZ: I certainly understand the argument, I'm just concerned
           that it's going to
   Melinda: I've been trying to think of counter-examples for a long time
   Melinda: I'm happy with this solution
   SteveZ: I know that what I've done for prints, I've put in page breaks
           for many other reasons than starting a new chapter.
   SteveZ: I understand fantasai's point about being able to turn it off
           in that context
   SteveZ: I'm concerned that this kind of design is usually bad
   SteveZ: It makes an assumption that one case is more important than
           the others
   Howcome: I've been pushing for Prince to follow the specifications,
            and I've pushed Michael on this specific issue
   Howcome: But he won't change it, and he points to user feedback.
   <sylvaing> does it make one case more important than the others, or
              does it pick what the default behavior should be ?
   SteveZ worries about this auto behavior closing off the possibility
          of controls in the future.
   Melinda: We don't want to close off the possibility of controls in
            the future. How about you think about that for the next week
            and report back if you find any issues
   SteveZ: My concern is that the decision for whether you want to
           collapse or not doesn't depend on the element but on the
   SteveZ: We're talking about a different behavior when you're
           positioned somewhere particular in a container
   Melinda: I don't understand. could you draw some use cases
   SteveZ: So your use case is the margin at the beginning of a chapter
   * ChrisL div class="chapter"
   more discussion between Melinda and SteveZ, not much very clear
   * ChrisL .chapter ::first-child {page-break-before: always; margin-top:0 }
   Howcome: The one use case you've mentioned so far is you have a table,
            and you want it to start on a new page, and you want to
            collapse the margin.
   Howcome: When you set the break, you can remove the margin
   Melinda: The current behavior is not that the margin collapses, but
            that it is removed
   SteveZ: You want to remove all the margins at that point, however
           deep they are
   fantasai: So you want something like margin-top: hidden;
   SteveZ: You can't zero the margin if you don't know whether you're
           at the top of the page
   Melinda: You're always at the top of the page after a forced break
   SteveZ: what about keep-together?
   Melinda: That's not a forced break. The margins get zeroed as
            currently defined
   SteveZ: Ok, I'm understanding the logic.
   SteveZ: I'm only concerned about future compat.
   ACTION SteveZ: Think about this
   * Bert thinks "this" is a bit ambiguous...
   * sylvaing believes 'this' to be undefined in 2.1
   TENTATIVE RESOLUTION: Accept Melinda's proposal to allow margins to be kept after a forced page break
   PENDING: SteveZ's ok

Background Layering

   fantasai: I heard from Hyatt that basing layering on background-image
             only was ok
   dsinger confirms
   RESOLVED: layering based on background-image only

June F2F

   Peter: We'd like to confirm the dates for June in Sophia-Antipolis
   Peter: Currently listed for 24-26
   Bert: With me those are still fine
   Howcome: The holidays start then, and kids are out of school
   Howcome: I will not be able to attend
   dbaron: I remember signs in Antibes that had parking restrictions
           starting the middle of June
   <dsinger> overlaps a 3GPP SA4 meeting (Ystad) but that's not serious
   Melinda: how far back would we have to move it to enable you to join,
   <dsinger> I always stay in Valbonne, where one can usually park
             (unless there is an antiques fair)
   Howcome: beginning of the month would be better
   Howcome: I think the holidays start around the 14th
   Howcome: 12th
   Howcome: Friday the 12th
   SteveZ: Bert, you're on vacation in June?
   Bert: I'm away from 7-20
   Howcome: What about the first week of June?
   <dsinger> please, no earlier, the current week already starts 5 on
             the road for me
   SteveZ and fantasai can't do the last week of May
   Glazou: 1st of June is a holiday in France
   Chris: What about 3-5th of June
   Bert: probably ok, but I'd like a few days to check that
   <dsinger> not sure I would travel as it would be a standalone...
             but I don't have a conflict
   Melinda: Would we lose anyone on the call if we moved it there?
   * ChrisL dsinger said the current ones are better
   * Bert suggests howcome offers the kids a holiday in France :-)
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2008Nov/0022.html
            was our previous discussion of meeting scheduling for
            this meeting
   Peter: Ok, we'll give Bert a chance to look at that
   Peter: And we'll keep both sets of dates penciled in, come back to this
   <dbaron> I think the reason we rejected first week of June before was
            Bert's constraints, since he was unsure of dates.

Invited Experts

   Peter: Proposal from fantasai
   * glazou agrees with the proposal
   * sylvaing does not need convincing on this one.
   RESOLVED: proposal accepted

Backgrounds and Borders

   fantasai: Preparing for last call
   dbaron: thinking about at-risk
   dbaron, peter: put things at risk if they don't have at least one
Received on Wednesday, 14 January 2009 20:40:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 12:34:21 UTC