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

[CSSWG] Minutes and Resolutions Tokyo F2F Thurs: Page Breaking, GCPM, Image-Resolution, Multicol

From: fantasai <fantasai.lists@inkedblade.net>
Date: Sun, 08 Mar 2009 23:33:31 -0700
Message-ID: <49B4B83B.5010006@inkedblade.net>
To: www-style@w3.org
Summary:

   - RESOLVED: Add page selector grouping to CSS3 Page as at-risk feature, if Melinda
               objects make it a note that we will add it in the future

   - RESOLVED: If a page-break-before, page-break-after, or use of named page
               forces a page break, then the margin top is preserved after the
               break.

   - DRAFTED: margin-break: [ auto | discard | keep ] to control margin-before at
              page-breaks. auto is behavior decribed above. Can add second value
              to control margin-after (defaults to discard).

   - RESOLVED: page-break-before, page-break-after: column to force column breaks,
               other values apply to column breaking as well as pages

   - RESOLVED: howcome to clearly distinguish GCPM features that are moving forward,
               then propose publishing a new WD

   - RESOLVED: New syntax is image-resolution: normal | [ <dpi> || auto ]
     RATIONALE: Removes unused combinations and unnecessary comma

   - RESOLVED: Replace image-resolution: auto; with image-resolution: from-image;
     RATIONALE: 'auto' vs. 'normal' is hard to understand. ('normal' is 1 pixel == 1px)

   - RESOLVED: URLs inside functional notation where URL is expected should be able
               to take either url() or bare strings (like @import), preference for
               examples is bare strings.

   - Discussed removing 'background-image-resolution' in favor of various options.
     So far idea is that 'image-resolution' applies to all images and we will
     introduce functional notation in the future to allow setting resolution on a
     per-image basis.

   - howcome to prepare css3-multicol for Last Call publication; expecting a long
     (8 weeks) LC period to elicit comments and clarifications

   - Margins of multicol element no longer collapse with first/last children

====== Full minutes below ======

<RRSAgent> logging to http://www.w3.org/2009/03/05-css-irc
Meeting: Cascading Style Sheets (CSS) Working Group Meeting
Date: 05 March 2009

Attendees:
   David Baron
   John Daggett
   Elika Etemad
   Sylvain Galineau
   Håkon Wium Lie
   Shinyu Murakami
   Mike Smith
   Anne van Kesteren
   Steve Zilles

Chair: #css
Scribe: fantasai

Grouping Page Selectors
-----------------------

   howcome: With regular selectors you can group them by comma, but with page
            selectors you can't do that
   p, div { ... } is valid
   @page foo, bar { ... } is not
   Agreement that this is a sensible thing to do and we should add it to CSS
   fantasai: I'm not sure if Melinda would be ok with adding this to level 3
   Murakami-san: Our new version supports this
   RESOLVED: Add to CSS3 Page as at-risk feature, if Melinda objects make it a
             note that we will add it in the future

[[Values and Units Discussion, see next set of minutes]]

<MikeSmith> Present+ Masataka_Yakura

Page Breaking and Margins
-------------------------

   howcome draws three boxes side-by-side on the board
   The first box has an M followed by lines representing text
   The second box has lines of text followed by a return arrow sign
   The third box has an M followed by lines of text
   Howcome labels the boxes 1,2,3
   Howcome writes a small m at the top of 2 and crosses it out
   Howcome: I think we need to resolve the page issue before deciding on the
            column break properties
   howcome: The issue is, where to eliminate the top margin
   Howcome: I don't think it should be eliminated at the start of the document
   Howcome: The spec says the margins are eliminated at page breaks.
   Howcome: The question is should it be eliminated at forced breaks
   Steve: THere are three cases of page breaks.
   Steve: page-break-before, page-break-after, and named pages
   Howcome: I would be so confused by having different behavior for
            page-break-before and page-break-after
   Steve: I am convinced that we should preserve margin on page-break-before
   Steve: but not page-break-after
   fantasai agrees with howcome
   Murakami-san: I agree with howcome. Page-break-before and page-break-after
                should behave the same.
   * anne is not in favor of printing in general :)
   Steve: I want a use case for page-break-after
   fantasai: Suppose I want to print CSS2.1 with breaks between sections and
             chapters
   fantasai: I want page-break-before on each chapter, to separate out the
             chapters from each other and from the cover pages
   fantasai: but I select page-break-after for the sections, because the
             beginning of the chapter is usually so short, just a title and
             maybe a paragraph or two
   discussion of use cases and margins and breaking
   Steve: Ok, I can live with it
   Anne: It's really annoying for projection mode that the margin is collapsed
         at breaks
   RESOLVED: margins kept at forced breaks for page-break-before and
             page-break-after
   what about named pages?
   fantasai: if we collapse there, you always have the option of forcing the
             break to keep the margin
   fantasai: and you're not guaranteed a break, because elements assigned to
             the same name do not break in betweenm
   one of the main use cases for named pages is e.g. putting a wide table onto
     a landscape page
   RESOLVED: If a page-break-before, page-break-after, or use of named page
             forces a page break, then the margin top is preserved after the
             break.

   Discussion of use cases for preserving margins at unforced breaks
   there definitely seem to be some, e.g. for headings
   Murakami-san proposes margin-before-conditionality: auto | discard | retain
   howcome mentions that registration (preserving baseline grid alignment) might
     solve some of these problems
   general agreement that this problem exists and we should solve it, but not
     for 3.0
   margin-before-conditionality.. howcome objects to 'before'
   fnatasai: suggestion margin-conditionality, can be treated as shorthand
     later if we need separate controls
   Steve: 'conditionality' is hard to spell
   Howcome: 'keep' instead of 'retain'?
   seem to have agreement on that
   discard seems to be ok
   Other names: margin-collapse, margin-break
   dbaron suggests margin-break, since its behavior (controlling margin's
     existence at breaks) is similar to border-break
   Looking at margin-break: auto | discard | keep
   Murakami-san: what about the margin-after?
   fantasai draws margin-break: [ auto | discard | keep ] keep?
   (well, first draws margin-break: [ auto | discard | keep]{1,2} but refines
   to above since margin is always discarded at bottom by default )
   Second value applies to margin-after. Defaults to discarding margin if not
     specified.
   Murakami-san notes that this control also applies to the first margin in
     the document.
   ACTION howcome add to GCPM draft as a holding place until next Paged Media
     draft is started

   LUNCH BREAK

Column and Page Breaking
------------------------

   howcome: the page-break properties control breaking across pages
   howcome: the multicol draft has column-break properties to control breaking
             across columns
   howcome: Some people have suggested to just use the page-break properties
            to control column breaks
   howcome: this has two advantages. One it saves us two properties
   howcome: and second it avoids having to discuss what happens when they
            conflict
   fantasai: A third advantage is that the author only has to set things once
   fantasai: e.g. want to avoid breaking between header and 1st paragraph,
             only set page-break-after: avoid;
   howcome writes page-break-before: column
   howcome: my main objection to this is aesthetic
   howcome: so we could either have column break properties, or move to this
            here
   howcome: on the aesthetic side we also have everything match, since -inside
            is page-break-inside
   Murakami-san: avoid affects only page breaks?
   fantasai, howcome: should affect both column and page breaks
   fantasai: If we need more fine-tuned controls, then we can add e.g.
             avoid-page in the future to avoid page breaks but allow
             column breaks
   steve: don't like name 'avoid-page'
   howcome: 'column-only'
   howcome: page-break-inside: column-only
   not much happiness about this
   Steve brings up the XSL names
   keep-inside: page | column | spread | auto
   RESOLVED: page-break-before, page-break-after: column to force column breaks,
             other values apply to column breaking as well as pages

GCPM
----

   howcome: we have two implementations of a significant subset of GCPM
   howcome: there are certainly things that aren't implemented
   howcome: So I propose splitting out the implemented bits and creating
            something more formal
   howcome: named strings and leaders for example
   fantasai: we could cut down the css3-content draft into the minimum things,
             then add those two and create a module from that
   howcome: we need an editor
   fantasai: well, I have to finish css3-page first, but it's next on my list
   howcome: I'm not sure that's fast enough, prince and antenna house have
            shipping implementations
   howcome: maybe we need a new official working draft
   fantasai: How about marking the stable sections as stable, and the unstable
             experimental parts as such, and then publish it as a working draft
   howcome and Murakami-san seem ok with this
   RESOLVED: howcome to clearly distinguish features that are moving forward,
             then propose publishing a new WD
   howcome: It would be good to know which features are in Antenna House's
            latest beta
   Murakami-san: We implemented named strings, leaders, cross-references,
                 footnotes, hyphenation, new counter styles, character
                 substitution, image-resolution and background-image-resolution,
                 page-markes and bleed area, bookmarks, cmyk colors, page floats
                 but limited to value top bottom page and footnote and inside
                 and outside
   Murakami-san: named page lists
   Murakami-san: that's all

   howcome asks when fantasai can work on css3-content
   fantasai: Selectors and css3-background are almost done, css3-page will
             take awhile, maybe 3 weeks full-time.. but I have other things
             to work on too. Let's check back end of April?

Image-Resolution
----------------

   fantasai: wrt image-resolution, I think it should set the default image
             resolution for everything and not have background-image-resolution
   fantasai: we use images lots of places, not just backgrounds
   fantasai: border-image, list-style-image, content, etc.
   fantasai: this solution doesn't scale
   fantasai: if we need more fine-tuned control, then we can introduce a
             function
   fantasai: that takes an image url and an image-resolution value
   Steve doesn't understand the use cases
   howcome: I was compiling a document for a conference
   howcome: the images came from all over
   howcome: I needed some way to set the resolutions
   steve: So if you had a tool like Photoshop that lets you go in and set the
          resolutions
   howcome: but i don't want to edit the image file, I just want to make sure
            the dpi is
   dbaron: On the Web we pretty much have to ignore image data about resolution
   dbaron: Raster images on the web are 1 image pixel == 1px
   fantasai: I don't think this syntax makes much sense
   fantasai: The only value that can have a fallback is auto, the comma isn't
             much necessary
   fantasai: image-resolution: [ normal | <dpi> ] || auto
   Murakami-san: In our implementation the resolution can have two values,
                  horizontal and vertical
   fantasai proposes syntax:  [normal || <dpi> <dpi>?] || auto
   szilles: I do not like 'auto' here; the keyword should indicate the purpose
   anne: intrinsic ?
   fantasai: normal | [<dpi> <dpi>? || auto]
   * anne wonders how often this problem actually shows up
   howcome: do you often need two resolutions?
   Murakami-san: we have some, but I don't know how necessary it is
   howcome: would you like to see it in the spec?
   Murakami-san: we would have it in Antenna House's implementation
   general skepticism about whether images with non-square pixels are common
     enough
   <anne> and whether image-resolution is in fact needed
   <anne> i.e. the image itself could be fixed
   Murakami-san agrees with the syntax change
   RESOLVED: image-resolution: normal | [ <dpi> || auto ]
   Sylvain and Anne are confused about normal and auto as names
   Steve had suggested intrinsic
   Anne: if there's an auto value it's usually the initial value
   howcome: I could live with from-image instead of auto
   fantasai: internal?
   howcome: internal to what?
   howcome: so from-image?
   no comment

   fantasai: ok, wrt background-image-resolution
   howcome: it's there because prince implemented it. I agree it's not a
            scalable solution
   fantasai: Does image-resolution affect only images in the content, or also
             images specified in CSS?
   howcome: I don't know
   anne: what about video and stuff?
   * myakura heard that dvd-video uses non-square pixels, not sure if that's
             correct
   back to background-image-resolution
   <anne> url-with-resolution("url", <image-resolution>)
   fantasai: we dont' need a separate property for every CSS property that
             takes an image
   fantasai: one that affects content and one that affects all CSS-specified
             images would be enough
   suggestion to use a functional notation that would allow setting the dpi on
     a per-declaration level
   howcome writes image("http...", 94dpi)
   fantasai: my concern with the image() notation is that there are a lot of
             other things we've wanted to do with this, such as image slices
             and fallbacks
   fantasai and others: shouldn't require url() notation, string is enough,
                        for when you expect urls inside a function
   anne and others: can allow it, but just not require it, like for @import
   fantasai: but don't use it in any examples!
   discussion around other gcpm properties
   anne: it seems simpler to not allow it
   anne: but for consistency's sake, we should allow it
   RESOLVED: URLs inside functional notation where URL is expected should be
             able to take either url() or bare strings (like @import),
             preference for examples is bare strings

   Review of auto vs. from-image
   RESOLVED: image-resolution: from-image instead of auto

   Options for getting rid of the background-image-resolution approach of
     exploding properties
   1. image-resolution applies to both CSS images and content images
   2. image-resolution takes two sets of values, one for content images and
      one for CSS images
   3. create a new property that applies to all CSS-based images (not just
      backgrounds)
   4. create a value-based syntax (functional notation) that sets the dpi on
      a per-image basis
   5. Combine 4 with 1-3.
   discussion of various options and what they mean
   Straw poll:
   Mike: no opinion
   Anne: 4
   dbaron: 4
   howcome: anyone volunteering for 4 has to do the work :)
   jdaggett: no opinion
   Yakura-san: I like 3
   Yakura-san: You could expand the property by saying which properties it
               applies to
   fantasai: I like 3+4, where 3 sets the default
   discussion and whiteboard doodling
   image-resolution-content and image-resolution-decoration in place of
     image-resolution and background-image-resolution
   where image-resolution-decoration applies to all css-based images
   background images, border-image, list-style-image, etc.
   Proposal use 3 with 4 as the way forward
   Counter-proposal to use 1 with 4 as the way forward
   Murakami-san points out the distinction between list-style-image and
     ::marker { content: url(); }
   Then the distinction between ::marker { content: url(); } and
     img { content: attr(src, url); }
   There's no clear distinction between content and style
   howcome: Ok, so I think we're down to one image-resolution property and 4
            as the way forward
   howcome: Implementations will do background-image-resolution, but that will
            not be part of the spec
   Murakami-san: Prince's image-resolution only applies to content images
   Murakami-san: The image-resolution and background-image-resolution pair is
                 better for our implementation
   Murakami-san: The content property with url() that replaces the element
   Murakami-san: image-resolution-content applies to images specified by the
                 content property with image URI
   dbaron: There's also a distinction in CSS3 between a single image and
           multiple images for 'content'
   BREAK

Multicol
--------

   howcome: I propose publishing css3-multicol as LC
   fantasai: I would like to see the changes we agreed on in the spec first
   howcome: understandable. Would like to smoke out any comments, get a sense
            that everything is pretty good
   howcome: aside from today there've been no changes in syntax or
            functionality, just a lot of clarifications
   fantasai: I think the functionality is quite stable, but it needs another
             round of review for clarifications etc.
   fantasai: So if we're going to Last Call, then I would suggest at least
             8 weeks rather than 4
   howcome: ok
   howcome: I will make those changes, prepare the draft for Last Call, then
            we can make the final decision once that's done

   Murakami-san: I feel there's a problem with the margins in multicol
   A multi-column element establishes a new block formatting context, as per
     CSS 2.1 section 9.4.1. However, the top margin of the first element and
     the bottom margin of the last element collapse with the margins of the
     multi-column element as per the normal rules for collapsing.
   <myakura> http://dev.w3.org/csswg/css3-multicol/#the-multi-column-model
   ""
   Murakami draws on the board
   Murakami shows some examples
   He says that the margins should not collapse through the multicol element
   Sylvain: Alex was concerned about this, too.
   fantasai explains that this behavior was put there because in the past
     there was no value-based distinction between a multicol element with one
     column and a normal element, and we didn't want to introduce a
     discontinuity there but since there's now a default auto value for
     column-count instead of 1, this problem doesn't exist
   Editor's note: The above is wrong. There was always a value-based distinction
   between multicol and non-multicol, but there /was/ a stated desire for a single
   column multicol element to behave like a normal element. It seems this is no
   longer the case.
   General agreement to remove margin-collapsing exception and treat multicol as
   a normal BFC.
   <howcome> http://dev.w3.org/csswg/css3-gcpm/#creating

   sylvain: Alex had some concerns about overflow
   howcome: we discussed that at tpac
   howcome: resolved to keep things as-is, and discussed adding
            overflow-style: paged
   howcome: we also discussed creating stacks of column rows
   fantasai: e.g. with a column-length property
   fantasai: but we decided to defer that until later

[[ Continues with Media Queries, see next set of minutes ]]
Received on Monday, 9 March 2009 06:34:14 GMT

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