See also: IRC log
<glazou_pain> dsinger: you have to use /invite, that's what I did
<glazou> so we have regrets from szilles, anne, molly, dbaron and probably plinss too
<glazou> hi ChrisL
hi daniel
<dsinger> Which module?
<scribe> scribenick: chrisl
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
am: showed three combinations in
an email
... page-break-avoid and column-break-avoid, all combinations
make sense
... supposr 2 col layout, something is a column and a half
wide
... if we had two separate properties, column-break-avoid would
make it start in the second column
... page-break-avoid would move it to the next page
... if they were totallyy separate
... however, a single break property would move things to the
next column but not necessarily the next page
dg: so you would get a blank page
am: or a blank column before the next page break
<fantasai> break-inside: avoid | avoid-column | avoid-page
<fantasai> would give you all combinations
am: if we think page break is
always a column break, then its hard to say thata page break is
avoided but ok to start im mid column
... close to the opinion that its okay to have separate column
and page properties
el: one property (as above) would do it as well as long as all combinations are listed
<dsinger> Can we lay out all cases? Near end of girst col, near end of second
<dsinger> Pb avoid, cb avoid
<dsinger> Pb+cb avoid?
am: advantage of separate properties is that you avoid first column breaks then page breaks
dg: also an issue of readability
el: can be readable with one property, with good choice of values. encourages people to think about pages when designing columns
<dsinger> A break over page would violate cb avoid?
dg: these are being confused
bb: more interesting question, they are semi independent so all combinations need to be considered either way
dg: some comninations will be unused
bb: is there a list of all the combinations?
am: email did not listall of them
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Apr/0054.html
dg: avoid means 'try to avoid'
am: most common pattern is to avoid all breaks.
dg: column should take precedence over pages
am: some people think there are only two combinations, but differ on which two those are
el: happy to define all three
am: avoid colum, page, both makes sense to me
bb: agree with elika, define all
three even though one is not useful
... avoid-both is ok, if you avoid a column break also avoids a
column break
el: no, avoiding both means you prioritise avoiding page breaks over column breaks
<glazou> ok
<dsinger> right, col1 of page 2 is not col2 of page 1
cl: a page break always produces a new colum break
bb: if its too long then there is no need to push it anywhere
am: avoid is not forbid. its 'attempt to not break"
cl: no way to say 'minimise the total number of breaks'
am: good point, can be complex to optimise for that though
sg: see example with avoid-column
<fantasai> am: I would prefer to specify that you try to lay out, and if it doesn't fit, you push to the top of the next column
am: choice of keeping "most" of
the article together
... prefer a break art the end rather than a break near the
start
... page break is always a column break as well. that has to be
made clear
el: i agree with alex. want avoid to mean 'try layout then push over a break'. more complex stuff needs different keeywords. avoid behaviour is simple and useful so is what we should do now
bb: seems fine
dg: seem close to consensus
el: page break inside option does
not work,
... introducing a shorthand that combines both column and page
is the best option
am: cleaner solution to forget the old property
el: have to support the old property
am: yes but avoid in new documents
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
(consensus seems to be reached)
<fantasai> el: We're down to either alias or shorthand
el so we eliminate the first of melindas options but have to choose between 2 and 3
bb: shorthand seems like overkill
am: fine with either
dg: would like to see a summing up and final proposal
el: can work with hakon to propose something that covers all three combinations, need to pick 2 or 3
2. Add three new column-breaking properties ('column-break-before', 'column-break-after', 'column-break-inside') and define their interactions with the existing page-breaking properties; also define three shorthands ('break-before', 'break-after', 'break-inside') that would set both page- and column-breaking values. Consider deprecating both page- and column-breaking properties in the future.
3. Define 'break-before', 'break-after', and 'break-inside' as aliases to 'page-break-before', 'page-break-after', and 'page-break-inside'.
am: does the alias mean all the values apply to the old properties?
el: no, one is a superset of the others
am: preferable from an implementor standpoint to allow all the properties
el: 'always' value would be a problem
am: ok so i prefer a new set of properties
el: so do I
cl: so everyone seems to like melindas option 2 best
resolution: Add three new column-breaking properties per melindas email oprtion 2 http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
<fantasai> /resolution/RESOLVED/
<scribe> ACTION: fantasai work with hakon on spec text to define the column-break properties and interaction with page bbreak properties [recorded in http://www.w3.org/2009/04/29-CSS-minutes.html#action01]
<trackbot> Created ACTION-141 - Work with hakon on spec text to define the column-break properties and interaction with page bbreak properties [on Elika Etemad - due 2009-05-06].
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
"The naming was briefly discussed in another SVG telcon[1], and the conclusion was that the SVG WG prefers the naming 'content-fit' and 'content-position' because of the reasons already mentioned above.
"
el: concern is that for css, this
only appies to images while the name implies it applies more
widely eg to text content
... but cant comu up with a better name
dg: don't see a clash with the content property, but could live with it
el: wonder if we should ask for better names
dg: ack the problem and ask for a better name
<scribe> ACTION: daniel respond to http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html agreeing there is a problem but asking for a better name [recorded in http://www.w3.org/2009/04/29-CSS-minutes.html#action02]
<trackbot> Created ACTION-142 - Respond to http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html agreeing there is a problem but asking for a better name [on Daniel Glazman - due 2009-05-06].
dg: what can we move to PR?
... chris reported progress with implementations agfainst the
colour module tests
... we are seen as very slow and need to publish and move
forward
... other candidates?
el: namespaces?
... a parsing bug and one test is failing
dg: all implementations fail?
dg; who is doing implementation reports?
el: easy to do once implementations pass, test suite is not very long
dg: discussed media queries with
anne, he thinks some will be untestable as we do not have
suitable devices and that testing on desktop is enough
... concerned that we need to test on mono and character-cell
devices
... desktop ones seem to be interoperable at this time, but
some features do not apply
el: do we have any implementations for grid?
dg: no
el: should make an imp report for dersktop and survey what other devices actually exist. at end of 6 months if there are no implementations of some features or devices we can drop them from the spec
bb: not honest to say we pass a
test if there are no implementations
... some implementatiosn can emullate and always pass
... currently no features at risk
cl: prefer to do an imp report then mark features at risk and republish
sz: only need to claim to be a device, not to actually be that device
dg: yes but not implementation claims to be a grid for example
sz: only issue in testing is if the right selection was made, not whether it then goes on to lay outcorrectly
dg: will not agree to implement like that and claim to have a feature that they in fact don't have
<Bert> If we test '@media (grid)' and '@media not (grid)' and Opera does the right thing for both, sin't that enough?
dg: can test for not-grid
el: probably sufficient.
... will have to say its sufficient
dg: anne had some tests for
desktop only. no tests for other devices. WG should look at
tests from Anne and contribute more
... as soon as we have tests, we can move forward
cl: where are anne's tests?
<Bert> http://tc.labs.opera.com/mediaqueries/
not listed on http://www.w3.org/Style/CSS/Test/
bb: because not reviewed yet
dg: will try to review for next week
cl: cdf testsuite has media query tests which could be re-used
sz: snapshot?
el: depends on 2.1 and selectors
sz: snapshot is important as it actually defines the current state
dg: don't think the snapshot is very useful
<dsinger> well, there will be browsers that are interoperable on defined modules...
<dsinger> bye
meetiing: CSS WG telcon
<scribe> agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0075.html (member only)
<scribe> Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0075.html (member only)
<scribe> Chair: Daniel
Meetiing: CSS WG telcon
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/mind/mid/ Succeeded: s/property/value/ Succeeded: s/dfo/do/ Found ScribeNick: chrisl Inferring Scribes: chrisl Default Present: +1.408.398.aaaa, +1.408.398.aacc, glazou, sylvaing, alexmog, dsinger, Bert, ChrisL, fantasai, SteveZ Present: +1.408.398.aaaa +1.408.398.aacc glazou sylvaing alexmog dsinger Bert ChrisL fantasai SteveZ Regrets: anne molly david steve WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting Got date from IRC log name: 29 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/29-CSS-minutes.html People with action items: daniel fantasai respond[End of scribe.perl diagnostic output]