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

[CSSWG] Minutes and Resolutions 2009-04-29

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 14 May 2009 01:33:36 -0700
Message-ID: <4A0BD760.3040708@inkedblade.net>
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 GMT

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