- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 14 Jan 2009 12:39:25 -0800
- 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 UTC