- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sun, 08 Mar 2009 23:33:31 -0700
- 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 UTC