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

Summary:

   - 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)
       http://wiki.csswg.org/spec/css2.1#issue-92

   - 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 ======

Attendees:

   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
            future
   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
            guidance
   howcome: behavior on columns should be consistent with that for page
            breaks
   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
           container
   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,
            howcome?
   <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
   [unminuted]
   * 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
                  implementation
Received on Wednesday, 14 January 2009 20:40:02 GMT

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