- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 May 2009 01:33:36 -0700
- To: www-style@w3.org
Summary:
- RESOLVED: Add three new column-breaking properties and shorthand to
combine them with page-break properties per melindas email item 2:
http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
- Discussed renaming of 'image-fit' to 'content-fit'. Concern that for
css, this only appies to images while the name implies it applies
to e.g. text content. No better suggestions. Agreed to ask for more
suggestions.
http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
- Reviewed status of specs close to PR.
====== Full minutes below ======
Attendees:
Elika Etemad
Bert Bos
Sylvain Galineau
Daniel Glazman
Chris Lilley
Alex Mogilevsky
David Singer
Steve Zilles (late)
<RRSAgent> logging to http://www.w3.org/2009/04/29-CSS-irc
<glazou> so we have regrets from szilles, anne, molly, dbaron and probably plinss too
Scribe: Chris Lilley
regrets: anne, molly, david, steve
column-break properties
-----------------------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
<ChrisL> http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
Alex: showed three combinations in an email
Alex: page-break-avoid and column-break-avoid, all combinations make sense
Alex: suppose 2 col layout, something is a column and a half wide
Alex: if we had two separate properties, column-break-avoid would make it
start in the second column
Alex: page-break-avoid would move it to the next page
Alex: if they were totallyy separate
Alex: however, a single break property would move things to the next column
but not necessarily the next page
Daniel: so you would get a blank page
Alex: or a blank column before the next page break
<fantasai> break-inside: avoid | avoid-column | avoid-page
<fantasai> would give you all combinations
Alex: if we think page break is always a column break, then its hard to
say that a page break is avoided but ok to start in mid column
Alex: close to the opinion that its okay to have separate column and
page properties
fantasai: 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 first col, near end of second
<dsinger> Pb avoid, cb avoid
<dsinger> Pb+cb avoid?
Alex: advantage of separate properties is that you avoid first column
breaks then page breaks
Daniel: also an issue of readability
fantasai: 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?
Daniel: these are being confused
Bert: more interesting question, they are semi-independent so all
combinations need to be considered either way
Daniel: some combinations will be unused
Bert: is there a list of all the combinations?
Alex: email did not list all of them
<glazou> http://lists.w3.org/Archives/Public/www-style/2009Apr/0054.html
Daniel: avoid means 'try to avoid'
Alex: most common pattern is to avoid all breaks.
Daniel: column should take precedence over pages
Alex: some people think there are only two combinations, but differ on
which two those are
fantasai: happy to define all three
Alex: avoid colum, page, both makes sense to me
Bert: agree with elika, define all three even though one is not useful
Bert: avoid-both is ok, if you avoid a column break also avoids a column
break
fantasai: no, avoiding both means you prioritise avoiding page breaks
over column breaks
<dsinger> right, col1 of page 2 is not col2 of page 1
Chris: a page break always produces a new colum break
Bert: if its too long then there is no need to push it anywhere
Alex: avoid is not forbid. its 'attempt to not break"
Chris: no way to say 'minimise the total number of breaks'
Alex: good point, can be complex to optimise for that though
Sylvain: see example with avoid-column
Alex: 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
Alex: choice of keeping "most" of the article together
Alex: prefer a break at the end rather than a break near the start
Alex: page break is always a column break as well. that has to be made clear
fantasai: 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
Bert: seems fine
Daniel: seem close to consensus
fantasai: page-break-inside option does not work,
fantasai: introducing a shorthand that combines both column and page is the
best option
Alex: cleaner solution to forget the old property
fantasai: have to support the old property
Alex: yes but avoid in new documents
<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
(consensus seems to be reached)
+Steve
<fantasai> fantasai: We're down to either alias or shorthand
fantasai: so we eliminate the first of melinda's options but have to choose
between 2 and 3
Bert: shorthand seems like overkill
Alex: fine with either
Daniel: would like to see a summing up and final proposal
fantasai: can work with Håkon 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'.
Alex: does the alias mean all the values apply to the old properties?
fantasai: no, one is a superset of the others
Alex: preferable from an implementor standpoint to allow all the properties
fantasai: 'always' value would be a problem
Alex: ok so i prefer a new set of properties
fantasai: so do I
Chris: so everyone seems to like melindas option 2 best
RESOLVED: Add three new column-breaking properties per melindas email item 2
http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html
ACTION: fantasai work with håkon on spec text to define the column-break
properties and interaction with page-break properties
Email from svg on image-fit
---------------------------
<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."
fantasai: concern is that for css, this only appies to images while
the name implies it applies more widely e.g. to text content
fantasai: but I can't come up with a better name
Daniel: don't see a clash with the content property, but could live with it
fantasai: wonder if we should ask for better names
Daniel: ack the problem and ask for a better name
ACTION: daniel respond to SVG agreeing there is a problem but asking for
a better name
http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
Almost-ready Specs
------------------
Daniel: what can we move to PR?
Daniel: chris reported progress with implementations against the color
module tests
Daniel: we are seen as very slow and need to publish and move forward
Daniel: other candidates?
fantasai: namespaces?
fantasai: implementations have a parsing bug and one test is failing
Daniel: all implementations fail?
Daniel: who is doing implementation reports?
fantasai: easy to do once implementations pass, test suite is not very long
Daniel: 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
Daniel: concerned that we need to test on mono and character-cell devices
Daniel: desktop ones seem to be interoperable at this time, but some
features do not apply
fantasai: do we have any implementations for grid?
Daniel: no
fantasai: should make an implementation 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
Bert: not honest to say we pass a test if there are no implementations
Bert: some implementatiosn can emulate and always pass
Bert: currently no features at risk
Chris: prefer to do an impl report then mark features at risk and republish
Steve: only need to claim to be a device, not to actually be that device
Daniel: yes but no implementation claims to be a grid for example
Steve: only issue in testing is if the right selection was made, not
whether it then goes on to lay out correctly
Daniel: implementors 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, isn't that enough?
Daniel: can test for not-grid
fantasai: probably sufficient.
fantasai: will have to say its sufficient
Daniel: anne had some tests for desktop only. no tests for other devices.
WG should look at tests from Anne and contribute more
Daniel: as soon as we have tests, we can move forward
Chris: where are anne's tests?
<Bert> http://tc.labs.opera.com/mediaqueries/
not listed on http://www.w3.org/Style/CSS/Test/
Bert: because not reviewed yet
Daniel: will try to review for next week
Chris: cdf testsuite has media query tests which could be re-used
Steve: snapshot?
fantasai: depends on 2.1 and selectors
Daniel: don't think the snapshot is very useful
Steve: snapshot is important as it actually defines the current state
<dsinger> well, there will be browsers that are interoperable on
defined modules...
Meeting closed.
<RRSAgent> I have made the request to generate
http://www.w3.org/2009/04/29-CSS-minutes.html ChrisL
Received on Thursday, 14 May 2009 08:34:30 UTC