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

Minutes, 29 April CSS WG telcon

From: Chris Lilley <chris@w3.org>
Date: Wed, 29 Apr 2009 19:05:13 +0200
Message-ID: <1203192287.20090429190513@w3.org>
To: www-style@w3.org
Hello www-style,

Minutes are at http://www.w3.org/2009/04/29-CSS-minutes
and below as text.

resolution: Add three new column-breaking properties per melindas email oprtion 2  http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html

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].

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].



29 Apr 2009

   See also: [2]IRC log

      [2] http://www.w3.org/2009/04/29-CSS-irc

Attendees

   Present
          +1.408.398.aaaa, +1.408.398.aacc, glazou, sylvaing, alexmog,
          dsinger, Bert, ChrisL, fantasai, SteveZ

   Regrets
          anne, molly, david, steve

   Chair
          Daniel

   Scribe
          chrisl

Contents

     * [3]Topics
         1. [4]column-break
         2. [5]email from svg on image fit
         3. [6]almost-ready specs
     * [7]Summary of Action Items
     _________________________________________________________



   <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

column-break

   <fantasai>
   [8]http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

      [8] http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

   [9]http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html

      [9] 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>
   [10]http://lists.w3.org/Archives/Public/www-style/2009Apr/0054.html

     [10] 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>
   [11]http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html

     [11] 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
   [12]http://lists.w3.org/Archives/Public/www-style/2009Apr/0270.html

     [12] 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
   [13]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].

email from svg on image fit

   <glazou>
   [14]http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

     [14] http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

   "The naming was briefly discussed in another SVG telcon[$1\47], 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
   [15]http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
   agreeing there is a problem but asking for a better name [recorded
   in [16]http://www.w3.org/2009/04/29-CSS-minutes.html#action02]

     [15] http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

   <trackbot> Created ACTION-142 - Respond to
   [17]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].

     [17] http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

almost-ready specs

   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> [18]http://tc.labs.opera.com/mediaqueries/

     [18] http://tc.labs.opera.com/mediaqueries/

   not listed on [19]http://www.w3.org/Style/CSS/Test/

     [19] 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:
   [20]http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0075.h
   tml (member only)

     [20] http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0075.html

   <scribe> Agenda:
   [21]http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0075.h
   tml (member only)

     [21] http://lists.w3.org/Archives/Member/w3c-css-wg/2009AprJun/0075.html

   <scribe> Chair: Daniel

   Meetiing: CSS WG telcon

Summary of Action Items

   [NEW] ACTION: daniel respond to
   [22]http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html
   agreeing there is a problem but asking for a better name [recorded
   in [23]http://www.w3.org/2009/04/29-CSS-minutes.html#action02]
   [NEW] ACTION: fantasai work with hakon on spec text to define the
   column-break properties and interaction with page bbreak properties
   [recorded in
   [24]http://www.w3.org/2009/04/29-CSS-minutes.html#action01]

     [22] http://lists.w3.org/Archives/Public/www-style/2009Apr/0490.html

   [End of minutes]



-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Wednesday, 29 April 2009 17:06:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:46:58 GMT