/irc-logs / w3c / #css / 2009-03-05 / end

Options:

# Session Start: Thu Mar 05 00:00:01 2009
# Session Ident: #css
# [00:51] * Parts: annevk (opera@114.48.30.0)
# [01:00] * Joins: sylvaing (sylvaing@202.221.217.78)
# [01:00] * Joins: szilles (chatzilla@202.221.217.78)
# [01:08] * Joins: jdaggett (jdaggett@202.221.217.78)
# [01:24] * Joins: dbaron (dbaron@202.221.217.78)
# [01:29] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
# [01:29] <RRSAgent> logging to http://www.w3.org/2009/03/05-css-irc
# [01:29] <dbaron> trackbot, start meeting
# [01:29] * trackbot is starting a teleconference
# [01:29] <trackbot> RRSAgent, make logs member
# [01:29] <RRSAgent> I have made the request, trackbot
# [01:29] * Joins: Zakim (rrs-bridgg@128.30.52.30)
# [01:29] <trackbot> Zakim, this will be Style_CSS FP
# [01:29] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [01:29] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [01:29] <trackbot> Date: 04 March 2009
# [01:30] <dbaron> Zakim, remind us in 8 hours to go home
# [01:30] <Zakim> ok, dbaron
# [01:30] <dbaron> RRSAgent, make logs public
# [01:30] <RRSAgent> I have made the request, dbaron
# [01:30] <dbaron> Meeting: Cascading Style Sheets (CSS) Working Group Meeting
# [01:30] <dbaron> Date: 05 March 2009
# [01:33] * Joins: shinyu (shinyu@124.26.216.70)
# [01:33] * Joins: anne (annevk@202.221.217.78)
# [01:34] * Joins: howcome (howcome@202.221.217.78)
# [01:41] <fantasai> Topic: Grouping Page Selectors
# [01:41] <fantasai> howcome: With regular selectors you can group them by comma, but with page selectors you can't do that
# [01:41] <fantasai> p, div { ... } is valid
# [01:42] <fantasai> @page foo, bar { ... } is not
# [01:44] <fantasai> Agreement that this is a sensible thing to do and we should add it to CSS
# [01:45] <fantasai> fantasai: I'm not sure if Melinda would be ok with adding this to level 3
# [01:45] <fantasai> Murakami-san: Our new version supports this
# [01:46] <fantasai> RESOLVED: Add to CSS3 Page as at-risk feature, if Melinda objects make it a note that we will add it in the future
# [01:47] <fantasai> Topic: Values and Units
# [01:47] <fantasai> howcome: What's the interface between the syntax module and the values and units module?
# [01:48] <fantasai> dbaron: I think it's ok as the draft is now
# [01:48] <fantasai> howcome: There's a couple of things I'd like to update in the syntax module
# [01:48] <fantasai> dbaron: Update what?
# [01:48] <fantasai> dbaron: I don't think we have much to put in it other than what's in 2.1
# [01:49] <fantasai> howcome: fantasai wanted to copy over the value definition syntax
# [01:49] <howcome> http://www.w3.org/TR/CSS21/about.html#property-defs
# [01:51] <fantasai> dbaron: why not reference 2.1?
# [01:51] <fantasai> fantasai: I wanted to add &&
# [01:55] <howcome> http://howcome.gotdns.com/img/2009/03-04-tokyo/
# [01:55] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [01:59] <dbaron> dbaron: I don't know that we even want &&; might be better to just write things out, potentially with sub-productions.
# [02:07] <dbaron> dbaron: Or just use || and say one of the parts is mandatory.
# [02:07] <dbaron> dbaron: (say via prose or via other syntax)
# [02:10] <anne> ||+
# [02:16] <dbaron> dbaron: Could we put && in 2.1 even though 2.1 doesn't use it?
# [02:17] <dbaron> ACTION: fantasai to send message to www-style to explain rationale for && and see if somebody can come up with something better
# [02:17] * trackbot noticed an ACTION. Trying to create it.
# [02:17] * RRSAgent records action 1
# [02:17] <trackbot> Created ACTION-126 - Send message to www-style to explain rationale for && and see if somebody can come up with something better [on Elika Etemad - due 2009-03-12].
# [02:17] <dbaron> RESOLUTION: Add && to 2.1 unless somebody comes up with something better, to avoid having to publish a syntax module for just that one new feature.
# [02:18] <fantasai> dbaron: My other comment on values and units was the cycle() feature
# [02:18] <fantasai> dbaron: I'm pretty sure we resolved to add it
# [02:24] <fantasai> howcome: ok, so it's my action point to add that
# [02:24] <fantasai> howcome: can you have recursive cycles?
# [02:24] <fantasai> dbaron: well, you /could/. In my message I explained how it would work. You can create a state machine with that, although it's not the best syntax
# [02:26] <dbaron> http://lists.w3.org/Archives/Public/www-style/2009Jan/0104.html has references to the proposed text
# [02:27] <fantasai> howcome: any other issues?
# [02:27] <fantasai> fantasai: Do you define whitespace?
# [02:27] <fantasai> howcome: yes, I added S tokens
# [02:27] <howcome> http://dev.w3.org/csswg/css3-values/#the-calc-function
# [02:27] <fantasai> fantasai: whitespace should be required
# [02:28] <fantasai> fantasai: at least around the + - signs, because otherwise you have to retokenize inside calc()
# [02:34] <fantasai> dbaron: retokenizing in our implementation isn't that hard, because it's a hand-coded recursive descent parser and we can be mean to our tokenizer and send back pieces of tokens
# [02:35] <fantasai> dbaron: but if you are using a parser generator it's not so easy
# [02:35] <fantasai> dbaron: I think WebKit uses a parser generator
# [02:35] <shinyu> we implemented calc() allowing non-whitespace around + or -
# [02:37] <fantasai> fantasai: I'm concerned also about what we might want to allow inside calc() in the future. If we don't require spaces, that restricts our options.
# [02:38] <fantasai> dbaron: Yeah, so in our implementation we push pieces of tokens back to the tokenizer
# [02:38] <dbaron> our implementation of :nth-child()
# [02:38] <fantasai> dbaron: I suspect Webkit tokenizes :nth-child() as one token, and then hand parses that token
# [02:38] <fantasai> dbaron: which would be much harder to do with calc()
# [02:39] <fantasai> howcome: I suggest we put in the required spaces now. We can take them out later if we need to.
# [02:40] <fantasai> howcome: ok, so it's in the dev version now. Is anyone planning to implement this?
# [02:41] <fantasai> dbaron: in the medium term
# [02:41] <fantasai> Murakami-san: I'm ok with requiring or not requiring white space
# [02:41] <fantasai> Murakami-san: we implement this feature. We allow whitespace around the operators
# [02:41] <fantasai> Murakami-san: or no whitespace
# [02:43] <fantasai> Attendees: jdagget, dbaron, anne, mikesmith, sylvain, howcome, steve, fantasai, Murakami-san
# [02:44] <jdaggett> two t's please
# [02:44] <fantasai> break
# [02:44] <MikeSmith> Present+ Masataka_Yakura
# [02:45] <dbaron> s/jdagget,/jdaggett,/
# [02:53] <fantasai> Topic: Page and Column Breaking
# [02:53] <fantasai> howocome draws three boxes side-by-side on the board
# [02:53] <fantasai> The first box has an M followed by lines representing text
# [02:53] <fantasai> The second box has lines of text followed by a return arrow sign
# [02:54] <fantasai> The third box has an M followed by lines of text
# [02:54] <fantasai> Howcome labels the boxes 1,2,3
# [02:54] <fantasai> Howcome writes a small m at the top of 2 and crosses it out
# [02:55] <fantasai> Howcome: I think we need to resolve the page issue before deciding on the column break properties
# [02:55] <fantasai> howcome: The issue is, where to eliminate the top margin
# [02:55] <fantasai> Howcome: I don't think it should be eliminated at the start of the document
# [02:56] <fantasai> Howcome: The spec says the margins are eliminated at page breaks.
# [02:56] <fantasai> Howcome: The question is should it be eliminated at forced breaks
# [02:56] <fantasai> Steve: THere are three cases of page breaks.
# [02:56] <fantasai> Steve: page-break-before, page-break-after, and named pages
# [02:57] <fantasai> Howcome: I would be so confused by having different behavior for page-break-before and page-break-after
# [02:58] <fantasai> Steve: I am convinced that we should preserve margin on page-break-before
# [02:59] <fantasai> Steve: but not page-break-after
# [03:00] <fantasai> fantasai agrees with howcome
# [03:01] <fantasai> Murakami-san: I agree with howcome. Page-break-before and page-break-after should behave the same.
# [03:01] * anne is not in favor of printing in general :)
# [03:01] <fantasai> Steve: I want a use case for page-break-after
# [03:01] * dbaron thought we were still on break
# [03:01] <fantasai> fantasai: Suppose I want to print CSS2.1 with breaks between sections and chapters
# [03:02] <fantasai> fantasai: I want page-break-before on each chapter, to separate out the chapters from each other and from the cover pages
# [03:03] <fantasai> 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
# [03:04] <fantasai> discussion of use cases and margins and breaking
# [03:06] <fantasai> Steve: Ok, I can live with it
# [03:06] <fantasai> Anne: It's really annoying for projection mode that the margin is collapsed at breaks
# [03:07] <fantasai> RESOLVED: margins kept at forced breaks for page-break-before and page-break-after
# [03:08] <fantasai> what about named pages?
# [03:09] <fantasai> if we collapse there, you always have the option of forcing the break to keep the margin
# [03:09] <fantasai> and you're not guaranteed a break, because elements assigned to the same name do not break in betweenm
# [03:11] <fantasai> one of the main use cases for named pages is e.g. putting a wide table onto a landscape page
# [03:15] <fantasai> 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.
# [03:20] * shepazu zakim, this conference will span midnight
# [03:20] * Zakim I don't understand 'this conference will span midnight', shepazu
# [03:27] <fantasai> Discussion of use cases for preserving margins at unforced breaks
# [03:27] <fantasai> there definitely seem to be some, e.g. for headings
# [03:27] <fantasai> Murakami-san proposes margin-before-conditionality: auto | discard | retain
# [03:29] <fantasai> howcome mentions that registration (preserving line alignment) might solve some of these problems
# [03:29] <fantasai> general agreement that this problem exists and we should solve it, but not for 3.0
# [03:29] <fantasai> margin-before-conditionality.. howcome objects to 'before'
# [03:31] <fantasai> suggestion margin-conditionality, can be treated as shorthand later if we need separate controls
# [03:31] <fantasai> Steve: 'conditionality' is hard to spell
# [03:31] <fantasai> Howcome: 'keep' instead of 'retain'?
# [03:31] <fantasai> seem to have agreement on that
# [03:31] <fantasai> discard seems to be ok
# [03:31] <fantasai> Other names: margin-collapse, margin-break
# [03:33] <fantasai> Looking at margin-break: auto | discard | keep
# [03:34] <fantasai> Murakami-san: what about the margin-after?
# [03:34] * Joins: myakura (caddd94e@64.62.228.82)
# [03:35] <fantasai> fantasai draws margin-break: [ auto | discard | keep ] keep?
# [03:36] <fantasai> (well, first draws margin-break: [ auto | discard | keep]{1,2} but refines to above since margin is always discarded at bottom by default )
# [03:37] <fantasai> Second value applies to margin-after. Defaults to discarding margin if not specified.
# [03:37] <fantasai> Murakami-san notes that this control also applies to the first margin in the document.
# [03:37] <fantasai> ACTION howcome add to GCPM draft as a holding place until next Paged Media draft is started
# [03:37] * trackbot noticed an ACTION. Trying to create it.
# [03:37] <trackbot> Created ACTION-127 - Add to GCPM draft as a holding place until next Paged Media draft is started [on Håkon Wium Lie - due 2009-03-12].
# [03:39] <fantasai> LUNCH BREAK
# [03:39] <fantasai> margin-break: auto | discard | keep | keep-all ?
# [03:39] * Quits: dbaron (dbaron@202.221.217.78) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:42] * Quits: sylvaing (sylvaing@202.221.217.78) (Ping timeout)
# [04:08] * Quits: myakura (caddd94e@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
# [04:50] * Joins: dbaron (dbaron@202.221.217.78)
# [04:50] * Joins: myakura (caddd94e@64.62.228.82)
# [04:54] <fantasai> howcome: the page-break properties control breaking across pages
# [04:54] <fantasai> howcome: the multicol draft has column-breamk proeprties to control breaking across columns
# [04:54] <fantasai> howcome: Some people have suggested to just use the page-break properties to control column breaks
# [04:54] <anne> s/breamk/break/
# [04:54] <fantasai> howcome: this has two advantages. One it saves us two properties
# [04:54] <anne> s/proeprties/properties/
# [04:55] <fantasai> howcome: and second it avoids having to discuss what happens when they conflict
# [04:55] <fantasai> fantasai: A third advantage is that the author only has to set things once
# [04:56] <fantasai> fantasai: e.g. want to avoid breaking between header and 1st paragraph, only set page-break-after: avoid;
# [04:56] <fantasai> howcome writes page-break-before: column
# [04:56] <fantasai> howcome: my main objection to this is aesthetic
# [04:57] <fantasai> howcome: so we could either have column break properties, or move to this here
# [04:57] * Joins: sylvaing (sylvaing@202.221.217.78)
# [05:01] <fantasai> howcome: on the aesthetic side we also have everything match, since -inside is page-break-inside
# [05:01] <fantasai> Murakami-san: avoid affects only page breaks?
# [05:02] <fantasai> fantasai, howcome: should affect both column and page breaks
# [05:02] <fantasai> 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
# [05:09] <fantasai> steve: don't like name 'avoid-page'
# [05:10] <fantasai> howcome: 'column-only'
# [05:10] <fantasai> howcome: page-break-inside: column-only
# [05:10] <fantasai> not much happiness about this
# [05:10] <fantasai> Steve brings up the XSL names
# [05:10] <fantasai> keep-inside: page | column | spread | auto
# [05:11] <fantasai> RESOLVED: page-break-before, page-break-after: column to force column breaks, other values apply to column breaking as well as pages
# [05:18] <fantasai> Topic: GCPM
# [05:18] <fantasai> howcome: we have two implementations of a significant subset of GCPM
# [05:18] <fantasai> howcome: there are certainly things that aren't implemented
# [05:18] <fantasai> howcome: So I propose splitting out the implemented bits and creating something more formal
# [05:21] <fantasai> howcome: named strings and leaders for example
# [05:22] <fantasai> fantasai: we could cut down the css3-content draft into the minimum things, then add those two and create a module from that
# [05:22] <fantasai> howcome: we need an editor
# [05:23] <fantasai> fantasai: well, I have to finish css3-page first, but it's next on my list
# [05:23] <fantasai> howcome: I'm not sure that's fast enough, prince and antenna house have shipping implementations
# [05:24] <fantasai> howcome: maybe we need a new official working draft
# [05:24] <fantasai> fantasai: How about marking the stable sections as stable, and the unstable experimental parts as such, and then publish it as a working draft
# [05:24] <fantasai> howcome and Murakami-san seem ok with this
# [05:27] <fantasai> RESOLVED: howcome to clearly distinguish features that are moving forward, then propose publishing a new WD
# [05:28] <fantasai> howcome: It would be good to know which features are in Antenna House's latest beta
# [05:28] <fantasai> howcome asks when fantasai can work on css3-content
# [05:28] <fantasai> 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?
# [05:31] <fantasai> 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
# [05:32] <fantasai> Murakami-san: named page lists
# [05:32] <fantasai> Murakami-san: that's all
# [05:35] <fantasai> fantasai: wrt image-resolution, I think it should set the default image resolution for everything and not have background-image-resolution
# [05:35] <fantasai> fantasai: we use images lots of places, not just backgrounds
# [05:35] <fantasai> fantasai: border-image, list-style-image, content, etc.
# [05:35] <fantasai> fantasai: this solution doesn't scale
# [05:36] <fantasai> fantasai: if we need more fine-tuned control, then we can introduce a function
# [05:36] <fantasai> fantasai: that takes an image url and an image-resolution value
# [05:38] <fantasai> Steve doesn't understand the use cases
# [05:38] <fantasai> howcome: I was compiling a document for a conference
# [05:38] <fantasai> howcome: the images came from all over
# [05:38] <fantasai> howcome: I needed some way to set the resolutions
# [05:38] <fantasai> steve: So if you had a tool like Photoshop that lets you go in and set the resolutions
# [05:39] <fantasai> howcome: but i don't want to edit the image file, I just want to make sure the dpi is
# [05:39] <fantasai> dbaron: On the Web we pretty much have to ignore image data about resolution
# [05:39] <fantasai> dbaron: Raster images on the web are 1px - 1px
# [05:39] <fantasai> s/1px/1 image pixel/
# [05:41] <fantasai> fantasai: I don't think this syntax makes much sense
# [05:41] <fantasai> fantasai: The only value that can have a fallback is auto, the comma isn't much necessary
# [05:42] <fantasai> fantasai: image-resolution: [ normal | <dpi> ] || auto
# [05:43] <fantasai> Murakami-san: In our implementation the resolution can have two values, horizontal and vertical
# [05:46] <sylvaing> fantasai proposes syntax: [normal || <dpi> <dpi>?] || auto
# [05:48] <sylvaing> szilles: I do not like 'auto' here; the keyword should indicate the purpose
# [05:48] <sylvaing> anne: intrinsic ?
# [05:50] <sylvaing> fantasai: normal | [<dpi> <dpi>? || auto]
# [05:50] * anne wonders how often this problem actually shows up
# [05:51] <fantasai> howcome: do you often need two resolutions?
# [05:52] <fantasai> Murakami-san: we have some, but I don't know how necessary it is
# [05:52] <fantasai> howcome: would you like to see it in the spec?
# [05:53] <fantasai> Murakami-san: we would have it in Antenna House's implementation
# [05:54] <fantasai> general skepticism about whether images with non-square pixels are common enough
# [05:54] <anne> and whether image-resolution is in fact needed
# [05:54] <anne> i.e. the image itself could be fixed
# [05:55] <fantasai> Murakami-san agrees with the syntax change
# [05:55] <fantasai> RESOLVED: image-resolution: normal | [ <dpi> || auto ]
# [05:56] <fantasai> fantasai: ok, wrt background-image-resolution
# [05:56] <fantasai> howcome: it's there because prince implemented it. I agree it's not a scalable solution
# [05:56] <fantasai> fantasai: Does image-resolution affect only images in the content, or also images specified in CSS?
# [05:57] <fantasai> howcome: I don't know
# [05:57] <fantasai> anne: what about video and stuff?
# [06:00] * myakura heard that dvd-video uses non-square pixels, not sure if that's correct
# [06:01] <fantasai> Sylvain and Anne are confused about normal and auto as names
# [06:01] <fantasai> Steve had suggested intrinsic
# [06:01] <fantasai> Anne: if there's an auto value it's usually the initial value
# [06:06] <fantasai> howcome: I could live with from-image instead of auto
# [06:07] <fantasai> fantasai: internal?
# [06:07] <fantasai> howcome: internal to what?
# [06:09] <fantasai> howcome: so from-image?
# [06:09] <fantasai> no comment
# [06:09] <fantasai> back to background-image-resolution
# [06:10] <anne> url-with-resolution("url", <image-resolution>)
# [06:11] <fantasai> fantasai: we dont' need a separate property for every CSS property that takes an image
# [06:11] <fantasai> fantasai: one that affects content and one that affects all CSS-specified images would be enough
# [06:12] <fantasai> suggestion to use a functional notation that would allow setting the dpi on a per-declaration level
# [06:14] <fantasai> howcome writes image("http...", 94dpi)
# [06:15] <fantasai> 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
# [06:16] <fantasai> fantasai and others: shouldn't require url() notation, string is enough, for when you expect urls inside a function
# [06:17] <fantasai> anne and others: can allow it, but just not require it, like for @import
# [06:17] <fantasai> fantasai: but don't use it in any examples!
# [06:18] <fantasai> discussion around other gcpm properties
# [06:18] <fantasai> anne: it seems simpler to not allow it
# [06:19] <fantasai> anne: but for consistency's sake, we should allow it
# [06:20] <fantasai> 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
# [06:21] <fantasai> Review of auto vs. from-image
# [06:22] <fantasai> RESOLVED: image-resolution: from-image instead of auto
# [06:24] <fantasai> Options for getting rid of the background-image-resolution approach of exploding properties
# [06:24] <fantasai> 1. image-resolution applies to both CSS images and content images
# [06:24] <fantasai> 2. image-resolution takes two sets of values, one for content images and one for CSS images
# [06:25] <fantasai> 3. create a new property that applies to all CSS-based images (not just backgrounds)
# [06:25] <fantasai> 4. create a value-based syntax (functional notation) that sets the dpi on a per-image basis
# [06:25] <fantasai> 5. Combine 4 with 1-3.
# [06:26] <fantasai> 0. Do nothing (keep background-image-resolution)
# [06:26] <fantasai> 6. Encourage Prince to remove backgorund-image-resolution but provide no alternative
# [06:33] <fantasai> discussion of various options and what they mean
# [06:33] <fantasai> Straw poll:
# [06:33] <fantasai> Mike: no opinion
# [06:33] <fantasai> Anne: 4
# [06:33] <fantasai> dbaron: 4
# [06:33] <fantasai> howcome: anyone volunteering for 4 has to do the work :)
# [06:34] <fantasai> jdaggett: no opinion
# [06:35] <fantasai> Yakura-san: I like 3
# [06:35] <fantasai> Yakura-san: You could expand the property by saying which properties it applies to
# [06:37] <fantasai> fantasai: I like 3+4, where 3 sets the default
# [06:41] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [06:53] <fantasai> discussion and whiteboard doodling
# [06:53] <fantasai> image-resolution-content and image-resolution-decoration in place of image-resolution and background-image-resolution
# [06:53] <fantasai> where image-resolution-decoration applies to all css-based images
# [06:53] <fantasai> background images, border-image, list-style-image, etc.
# [06:57] <fantasai> Proposal use 3 with 4 as the way forward
# [06:57] <fantasai> Counter-proposal to use 1 with 4 as the way forward
# [06:58] <fantasai> Murakami-san points out the distinction between list-style-image and ::marker { content: url(); }
# [06:59] <fantasai> Then the distinction between ::marker { content: url(); } and img { content: attr(href, url); }
# [07:00] <fantasai> There's no clear distinction between content and style
# [07:01] <fantasai> s/href/src/
# [07:01] <fantasai> howcome: Ok, so I think we're down to one image-resolution property and 4 as the way forward
# [07:02] <fantasai> howcome: Implementations will do background-image-resolution, but that will not be part of the spec
# [07:04] <fantasai> Murakami-san: Prince's image-resolution only applies to all images
# [07:04] <fantasai> s/all/content/
# [07:05] <fantasai> Murakami-san: The image-resolution and background-image-resolution pair is better for our implementation
# [07:06] <fantasai> Murakami-san: The content property with url() that replaces the element
# [07:07] <fantasai> Murakami-san: image-resolution-content applies to images specified by the content property with image URI
# [07:08] <fantasai> dbaron: There's also a distinction in CSS3 between a single image and multiple images
# [07:12] <fantasai> BREAK
# [07:26] * Joins: melinda (melinda.gr@98.246.171.82)
# [07:28] <fantasai> Topic: Multicol
# [07:28] <fantasai> howcome: I propose publishing css3-multicol as LC
# [07:28] <fantasai> fantasai: I would like to see the changes we agreed on in the spec first
# [07:29] <fantasai> howcome: understandable. Would like to smoke out any comments, get a sense that everything is pretty good
# [07:29] <fantasai> howcome: aside from today there've been no changes in syntax or functionality, just a lot of clarifications
# [07:30] <fantasai> fantasai: I think the functionality is quite stable, but it needs another round of review for clarifications etc.
# [07:31] <fantasai> fantasai: So if we're going to Last Call, then I would suggest at least 8 weeks rather than 4
# [07:31] <fantasai> howcome: ok
# [07:31] <fantasai> howcome: I will make those changes, prepare the draft for Last Call, then we can make the final decision once that's done
# [07:31] <fantasai> Topic: Media Queries
# [07:32] <fantasai> Anne: I made all the changes to Media Queries
# [07:32] <fantasai> Anne: So I would like to go to CR
# [07:32] <anne> Disposition of Comments: http://dev.w3.org/csswg/css3-mediaqueries/disposition.html
# [07:32] <anne> Draft: http://dev.w3.org/csswg/css3-mediaqueries/
# [07:32] <fantasai> Topic: Multicolumn
# [07:32] <fantasai> Murakami-san: I feel there's a problem with the margins in multicol
# [07:33] <fantasai> 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.
# [07:33] <myakura> http://dev.w3.org/csswg/css3-multicol/#the-multi-column-model
# [07:33] <fantasai> ""
# [07:37] <fantasai> Murakami draws on the board
# [07:45] <fantasai> Murakami shows some examples
# [07:45] <fantasai> He says that the margins should not collapse through the multicol element
# [07:45] <fantasai> Sylvain: Alex was concerned about this, too.
# [07:46] <fantasai> 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
# [07:46] <fantasai> but since there's now a default auto value for column-count instead of 1, this problem doesn't exist
# [07:47] <howcome> http://dev.w3.org/csswg/css3-gcpm/#creating
# [07:48] <fantasai> sylvain: Alex had some concerns about overflow
# [07:49] <fantasai> howcome: we discussed that at tpac
# [07:49] <fantasai> howcome: resolved to keep things as-is, and discussed adding overflow-style: paged
# [07:49] <fantasai> howcome: we also discussed creating stacks of column rows
# [07:50] <fantasai> fantasai: e.g. with a column-length property
# [07:50] <fantasai> fantasai: but we decided to defer that until later
# [07:51] * Joins: ChrisL (ChrisL@128.30.52.30)
# [07:51] <ChrisL> rrsagent, here
# [07:51] <RRSAgent> See http://www.w3.org/2009/03/05-css-irc#T06-48-51
# [07:53] * Joins: glazou (glazou@82.247.96.19)
# [07:53] <glazou> hello
# [07:53] <jdaggett> morning!
# [07:53] <fantasai> Topic: Media Queries
# [07:53] <glazou> where are the photos taken by Hakon Molly mentioned ?
# [07:53] <fantasai> fantasai: Any objections to publishing CR of Media Queries?
# [07:54] <fantasai> RESOLVED: publish Media Queries as CR
# [07:54] <fantasai> Chris: It would help if in the disposition of comments you had some color coding
# [07:54] <jdaggett> glazou:http://howcome.gotdns.com/img/2009/03-04-tokyo/
# [07:54] <sylvaing> glazou: http://howcome.gotdns.com/img/2009/03-04-tokyo/
# [07:54] * glazou thx
# [07:55] * glazou rhâââ lucky you all
# [07:55] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [07:55] <fantasai> dbaron: When I did the comments for CSS3 Color I colored rejected feature requests differently from other rejected comments
# [07:55] <fantasai> steve: what you really want to note is which resolutions the commentor didn't agree with
# [07:56] <glazou> I received a request by email to extend MQ to detection of implementation of a pair (property, values)
# [07:56] <dbaron> glazou, we've heard that before
# [07:56] <glazou> yes
# [07:56] <dbaron> glazou, too late for this level, anyway, as we just discussed :-)
# [07:57] <glazou> dbaron: oh sure, I was just mentioning it
# [07:57] <fantasai> Topic: Backgrounds and Borders
# [07:58] <fantasai> http://www.w3.org/Style/CSS/Tracker/products/11
# [08:00] <fantasai> http://lists.w3.org/Archives/Public/www-style/2009Feb/0179.html
# [08:00] <fantasai> Whether various border shorthands should reset border-image
# [08:01] <fantasai> in order to give the author a blank canvas to set borders on
# [08:01] <fantasai> dbaron: Also a question is whether border-style should reset border-image
# [08:01] <fantasai> dbaron: since border-image is kind of like a border style
# [08:03] <fantasai> fantasai: I think the 'border' shorthand should reset border-image. Not sure about others
# [08:03] <fantasai> dbaron: complication is that border is no longer border-top+border-left+border-right+border-bottom
# [08:04] * dbaron marvels at the operator-precedence in the previous line :-P
# [08:06] <fantasai> anne: why not just have border-image always override border-style?
# [08:06] <fantasai> dbaron: That's the current behavior. The concern is in complicated style sheets you won't always remember to reset border-image every time you use border-style
# [08:08] <fantasai> ...
# [08:08] <glazou> +1
# [08:08] * dbaron wonders what glazou is +1ing
# [08:08] <glazou> what dbaron said just above
# [08:09] <fantasai> fantasai: I think the two reasonable options here are to either have only 'border' reset border-image, or have any shorthand that sets border-style turn off the image
# [08:10] <fantasai> dbaron: or potentially any property that touchs the border-style, not just any shorthand
# [08:10] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:11] <fantasai> Steve: If only the shorthand turns it off, then to do something like change one value then I have to use the shorthand to get rid of the image
# [08:13] <fantasai> discussion of how authors in complicated style sheets set borders
# [08:13] * glazou answer is "sometimes with great pain" :)
# [08:15] <fantasai> anne: The resetting behavior seems like quite a bit of complexity for something the author can easily solve by resetting border-image
# [08:16] <anne> I also said that I expect sites that use border-image to use it consistently throughout and probably also specify border for backwards compatibility anyway
# [08:16] <fantasai> ...
# [08:18] <fantasai> fantasai: So, the advantage of having 'border' reset the border-image is that we can encourage authors to use it as a way to get a blank border canvas
# [08:19] <fantasai> fantasai: And this will work also in the future when we add more border properties: 'border' will always get you a blank canvas
# [08:19] <fantasai> fantasai: The advantage of having any shorthand that touches border-style reset the border image is that the process is pretty much invisible to the author
# [08:27] <fantasai> Options:
# [08:27] <fantasai> 1. Do nothing. border-image always overrides
# [08:27] <fantasai> 2. 'border' shorthand resets border-image
# [08:28] <fantasai> (and in the future, any other border-tweaking things)
# [08:28] <fantasai> 3. any shorthand that touches the border-style properties resets border-image
# [08:30] <fantasai> Anne: was it considered to make border-image part of the border shorthand?
# [08:31] <fantasai> Straw poll:
# [08:32] <fantasai> howcome: 2
# [08:32] <fantasai> anne: 2 or 1
# [08:32] <fantasai> dbaron: 2
# [08:32] <fantasai> jdagget: 2
# [08:32] <fantasai> Yakura-san: 2
# [08:32] <fantasai> Murakami-san: 2
# [08:32] <fantasai> fantasai: 2
# [08:33] <fantasai> Steve: I dislike how border-image and border-style are independently turned on
# [08:33] <fantasai> Steve: If I add border-characters as my next property, how does it interact?
# [08:33] <fantasai> Steve: It seems like this isn't going to scale
# [08:34] <fantasai> jdaggett: Maybe for the example in the spec, have a use case that is closer to what people are actually requesting?
# [08:34] * glazou 2 for me as wel
# [08:35] <fantasai> fantasai: I'm not a graphics person, we'd have to ask Brad Kemper to come up with one
# [08:35] * sylvaing remembered he's here and votes for 2 as well
# [08:35] <fantasai> fantasai: Anne's comment, should border-image be part of the border shorthand?
# [08:37] <fantasai> fantasai: We /can/ do that syntactically, if we place <border-image> after any style/width/color bits
# [08:39] <fantasai> fantasai: So we can do either border: [ <border-style> || <border-width> || <border-color> ] | <border-image>;
# [08:40] <fantasai> fantasai: Or we can do border: [ <border-style> || <border-width> || <border-color> ] <border-image>;
# [08:45] <fantasai> fantasai: So we can do either border: [ <border-style> || <border-width> || <border-color> ] || <border-image>;
# [08:46] <anne> [ <border-style> || <border-width> || <border-color> ]? <border-image>?
# [08:49] <fantasai> Straw poll on whether we should add border-mage to the shorthand
# [08:49] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:49] <fantasai> Chris: I think if we're having trouble with this, then we shouldn't add it
# [08:49] <fantasai> Sylvain puts his head on the desk
# [08:50] <fantasai> Anne: Yes?
# [08:50] <fantasai> dbaron: No, because if they use border-image that'll at least lead them to the documentation for the feature whereas using the shorthand wouldn't
# [08:50] <fantasai> Chris: so the self-documenting web
# [08:50] <fantasai> Mike: abstain
# [08:50] <fantasai> jdaggett: No
# [08:50] <fantasai> Yakura-san: maybe not
# [08:50] <fantasai> Murakami-san: no
# [08:50] <fantasai> fantasai: no
# [08:50] * sylvaing also said no
# [08:50] * glazou hum, no
# [08:51] <fantasai> Steve: Yes for the reasons Anne listed, but I don't feel strongly about it
# [08:51] <fantasai> howcome: I tend to disagree with Anne a lot today
# [08:51] <fantasai> RESOLVED: border shorthand resets border-image
# [08:51] <fantasai> RESOLVED: border shorthand cannot set border-image
# [08:52] <ChrisL> issue-94?
# [08:52] * trackbot getting information on ISSUE-94
# [08:52] <trackbot> ISSUE-94 -- Syntax for fallback color unclear -- RAISED
# [08:52] <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/94
# [08:55] <fantasai> Steve has concerns that we are deciding this kind of question without author input
# [08:55] <fantasai> jdaggett: I think if we show the designers that syntax they will cry
# [08:55] <anne> (admittedly having border reset border-image does make fallback slightly trickier)
# [08:56] <fantasai> http://dev.w3.org/csswg/css3-background/#the-background-color-property
# [09:04] <ChrisL> (long explanation of the feature)
# [09:08] <dbaron> dbaron: proposes not allowing the piece before / to be omitted (both cases)
# [09:09] <sylvaing> scribenick: sylvaing
# [09:11] <sylvaing> dbaron: if you need the value after the slash, you need to specify the value before it i.e. you can have a or a/b but not /b
# [09:12] <sylvaing> chrisl: if this removes the parsing ambiguity, this seems a good option
# [09:12] <sylvaing> fantasai reviews options
# [09:14] <fantasai> Several options for changing the shorthand
# [09:14] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [09:14] <sylvaing> anne suggests removing the fallback color
# [09:16] <sylvaing> fantasai: I don't want to require specifying background-position and background-size in order to specify background color
# [09:16] <fantasai> I prefer
# [09:16] <fantasai> * require that background-size not immediately follow background-color
# [09:16] <fantasai> (so that if you find a slash after background-color, you know the
# [09:16] <fantasai> fallback color is next)
# [09:17] <sylvaing> fantasai: I'd prefer to have web author feedback before removing the feature
# [09:18] <sylvaing> ACTION fantasai email www-style on whether web designers want fallback color
# [09:18] * trackbot noticed an ACTION. Trying to create it.
# [09:18] <trackbot> Created ACTION-128 - Email www-style on whether web designers want fallback color [on Elika Etemad - due 2009-03-12].
# [09:20] <sylvaing> szilles finds the preferred proposal above to be too hard to explain
# [09:22] <sylvaing> short proposal crossfire ensues. minute taker is reset.
# [09:24] <fantasai> fantasai is just goin to put in my own proposal and let y'all complain during the LC period
# [09:24] <fantasai> :)
# [09:24] <anne> background:red/blue url("test") 2px 2px no-repeat / 100% 50%
# [09:24] <anne> o_O
# [09:25] <jdaggett> glazou: you there?
# [09:25] <glazou> yes
# [09:25] <sylvaing> Topic: F2F schedule, TPAC
# [09:25] <sylvaing> jdagget: Chris sent email re: whether we consider to go to TPAC.
# [09:26] <sylvaing> ChrisL: there is deadline to determine group commitment
# [09:26] <sylvaing> jdaggett: we have a F2F in France, we also have TPAC. Do we do both, one ?
# [09:26] <glazou> deadline 18-mar
# [09:26] <sylvaing> fantasai: the first question is whether we do TPAC; this is the place where we meet the other groups
# [09:26] <glazou> the question is will we have enough people able to travel to france ?
# [09:27] <sylvaing> fantasai: TPAC is more cost-effective since you can travel to multiple meetings at once
# [09:27] <dbaron> http://lists.w3.org/Archives/Member/chairs/2009JanMar/0059.html
# [09:27] <glazou> Tokyo itself is already a "small" meeting because of so many people having budget/travel restrictions
# [09:28] <fantasai> not that small, glazou. The main participants missing are you and peter
# [09:28] <fantasai> (since Apple is usually absent anyway ;)
# [09:28] * glazou and Melinda, Molly, Bert
# [09:28] <fantasai> ah, yeah
# [09:29] <fantasai> Bert's missing too
# [09:29] <fantasai> so
# [09:29] * glazou and Emily and others
# [09:29] <fantasai> all the official-type people
# [09:29] * fantasai doesn't remember Emily
# [09:29] <glazou> TPAC is also later in the year, can help have more agenda items in a better structured agenda
# [09:29] <anne> reasons for Molly are not budget/travel
# [09:30] <Zakim> dbaron, you asked to be reminded at this time to go home
# [09:30] <glazou> TPAC seems to me an almost mandatory meeting because of the join meetings and productive side discussios with other WG and W3C staff
# [09:31] <sylvaing> discussion of TPAC attendance of other groups....
# [09:31] <fantasai> Chris: Eric suggested a mini-TPAC of browser-oriented groups like SVG, CSS, HTML, WebApps, etc.
# [09:31] <fantasai> Chris: Since we're not interested in meeting with Semantic Web etc anyway
# [09:31] <glazou> that's a great idea
# [09:32] <fantasai> Chris: SVG will not attend TPAC because they're doing SVG Open in the same area one month before
# [09:32] <glazou> TPAC's location being not far away from Apple, I hope they will attend...
# [09:33] <fantasai> XML COre, Media Annotations, XML Security, WAI Education and Outreach, XHTML 2, and XForms say they are attending
# [09:33] <anne> s/XForms/Forms/
# [09:33] * anne it's the Forms WG, officially
# [09:33] <fantasai> Not attending: Policy Languages, Semantic Web IG, WCAG, SVG, Timed Text, WAI Evaluation and Repair Tools, MWI Test Suites
# [09:34] <fantasai> Mike: We did a mini-TPAC thing once before, and it was really one of the better meetings
# [09:34] <fantasai> ...
# [09:34] <fantasai> Sylvain: Also if we're on the West Coast Arron can attend too
# [09:34] <glazou> seems there's consensus on TPAC
# [09:36] <ChrisL> mini-TP seems tobe more of interest
# [09:36] <glazou> but same time and location ? or different ?
# [09:36] <fantasai> Steve: I would rather just do the TPAC
# [09:36] <fantasai> fantasai: but you don't have to travel anyway
# [09:37] <fantasai> Steve: I'd like to say the CSS would like to do the TPAC if a significant number of HTML, WebApps, SVG are also doing TPAC
# [09:37] <fantasai> Steve: i18n is another one conceivably useful
# [09:38] <fantasai> various: mini-TPAC would need to be in Bay Area
# [09:39] <fantasai> SVG Open is in Cupertino, hosted by Google
# [09:39] <fantasai> fantasai: We should probably arrange the mini-TPAC there and then, then
# [09:40] <sylvaing> SVG Open 2009: Oct. 2-4 in Mountain View
# [09:40] <fantasai> A large number of this group is on the West Coast
# [09:41] <sylvaing> http://www.svgopen.org/2009/
# [09:42] <sylvaing> szilles: so if the other groups we're interested in meeting with were to attend TPAC we'd go; if not we'd consider SVG Open as an alternative
# [09:44] <glazou> please not svgopen attendance is not cost-free
# [09:44] <fantasai> RESOLVED: We will either do TPAC or mini-TPAC in Oct/Nov in Bay Area
# [09:44] <fantasai> no, glazou, just before or after so we can meet with SVG
# [09:44] <glazou> ok
# [09:44] <fantasai> Discussing June in France
# [09:45] <fantasai> Wed/Thurs/Fri of 1st week in June in Sophia-Antipolis
# [09:45] <glazou> that's 3-5
# [09:46] <glazou> please note 1st-jun is a holiday in france
# [09:47] <fantasai> dbaron: I think we're stretching to get an agenda for a 3-day meeting for this one
# [09:47] <fantasai> dbaron: I don't know if we're going to have more to talk about in 3 months
# [09:48] <fantasai> dbaron: Stuff that's useful to have the whole group talk about, rather than stuff we can go off and do on our own
# [09:48] <fantasai> dbaron: Part of that is my failure to do stuff for us to talk about
# [09:48] <fantasai> dbaron: But if we're going to meet, then we should make sure it's worth it
# [09:48] <fantasai> anne: It's pretty easy for me to go to France, but there should be an agenda
# [09:52] <fantasai> Steve: JLTF took a lot of time, is not likely to happen in France
# [09:55] <fantasai> howcome takes a count of how many ppl will attend
# [09:55] <sylvaing> glazou, we assume you'd come to sophia ?
# [09:55] <glazou> eh, of course
# [09:55] <fantasai> howcome, Chris, Sylvain +1, Anne, maybe dbaron, Steve, fantasai, glazou
# [09:55] * glazou can't telle for Peter
# [09:55] <glazou> s/telle/tell
# [09:55] <sylvaing> and Bert
# [09:56] <glazou> Bert won't have a long trip for that one :)
# [09:57] <fantasai> Steve: Can we spend some time tomorrow discussing what kinds of things we will discuss there, and if we can't do that then we get a pretty good indication that the meeting isn't going to happen?
# [09:57] <fantasai> howcome: I think we should have homework in this group. Everyone who's an editor should have a new draft at least one week before the meeting
# [09:58] <glazou> that supposes nothing will become a potentially interesting or important agenda item between now and June ?
# [09:58] <fantasai> howcome: Then at least the editor knows what issues to prepare and present
# [10:00] <fantasai> Anne: Not much for the group to discuss for cssom-view
# [10:00] <fantasai> Anne: namespaces and media queries are pretty much done
# [10:00] <fantasai> Steve: Status on Snapshot?
# [10:00] <fantasai> fantasai: Waiting on Selectors
# [10:00] <fantasai> fantasai: Selectors is waiting for i18n
# [10:01] <fantasai> Chris: i18n doesn't have anything
# [10:01] <glazou> fantasai: we're beyond the 2 weeks limit we discussed, we should publish now
# [10:01] <fantasai> RESOLVED: Publish Selectors as Last Call Working Draft
# [10:01] <glazou> cool
# [10:01] <fantasai> Four weeks LC period
# [10:01] <fantasai> RESOLVED: 4 weeks LC period
# [10:02] <fantasai> Steve: What they wanted to do isn't the right solution to the problem b/c it doesn't deal with most of the problem, and not even the most important part of the problem
# [10:03] <fantasai> Steve: What's bothering me is that we havent' discussed a coherent way to fit normalizzation into CSS as a whole
# [10:03] <fantasai> jdaggett: Isn't that also an HTML problem?
# [10:03] <glazou> this is more a W3C-wide problem imho
# [10:03] <fantasai> yeah, I totally agree
# [10:03] <glazou> touches many many specs
# [10:03] <fantasai> (jdaggett nods)
# [10:04] <glazou> but that's clear we're impacted
# [10:05] * glazou will have to leave in 10mns from now, business appt
# [10:05] <fantasai> RESOLUTION: We plan to meet in France, and will work on discussing an agenda tomorrow
# [10:05] <fantasai> MEETING CLOSED!!!!
# [10:05] <glazou> :)
# [10:05] * Quits: sylvaing (sylvaing@202.221.217.78) (Quit: sylvaing)
# [10:05] <glazou> have a good dinner all
# [10:07] * Quits: glazou (glazou@82.247.96.19) (Quit: glazou)
# [10:12] * Quits: myakura (caddd94e@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
# [10:18] * Quits: jdaggett (jdaggett@202.221.217.78) (Ping timeout)
# [10:25] * Quits: dbaron (dbaron@202.221.217.78) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [10:28] * Quits: szilles (chatzilla@202.221.217.78) (Ping timeout)
# [10:31] * Parts: anne (annevk@202.221.217.78)
# [10:32] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
# [10:32] * Quits: ChrisL (ChrisL@128.30.52.30) (Client exited)
# [10:34] * Quits: howcome (howcome@202.221.217.78) (Ping timeout)
# [11:29] * Quits: Lachy (Lachlan@85.196.122.246) (Quit: This computer has gone to sleep)
# [11:41] * Zakim excuses himself; his presence no longer seems to be needed
# [11:41] * Parts: Zakim (rrs-bridgg@128.30.52.30)
# [11:46] * Joins: Lachy (Lachlan@213.236.208.22)
# [14:06] * RRSAgent excuses himself; his presence no longer seems to be needed
# [14:06] * Parts: RRSAgent (rrs-loggee@128.30.52.30)
# [14:29] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: Leaving)
# [14:29] * Joins: Lachy (Lachlan@213.236.208.22)
# [15:13] * Disconnected
# [15:13] * Attempting to rejoin channel #css
# [15:13] * Rejoined channel #css
# [15:13] * Topic is 'CSS Working Group Discussion'
# [15:13] * Set by fantasai on Tue Feb 24 21:47:14
# [15:16] * Joins: dbaron (dbaron@222.151.83.100)
# [15:37] * Quits: dbaron (dbaron@222.151.83.100) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [15:55] * Joins: MoZ (chatzilla@82.230.92.154)
# [16:11] * Joins: myakura (myakura@122.29.116.63)
# [16:41] * Joins: Danyal (danyal@85.185.37.201)
# [16:42] * Quits: Danyal (danyal@85.185.37.201) (Quit: bye)
# [17:51] * Quits: myakura (myakura@122.29.116.63) (Quit: Leaving...)
# [17:54] * Quits: melinda (melinda.gr@98.246.171.82) (Ping timeout)
# [18:18] * Joins: melinda (melinda.gr@98.246.171.82)
# [18:24] * Quits: Lachy (Lachlan@213.236.208.22) (Quit: This computer has gone to sleep)
# [18:32] * Quits: melinda (melinda.gr@98.246.171.82) (Quit: melinda)
# [19:19] * Joins: Lachy (Lachlan@85.196.122.246)
# [19:33] * Quits: MoZ (chatzilla@82.230.92.154) (Ping timeout)
# [19:39] * Joins: MoZ (chatzilla@82.230.92.154)
# [20:28] * Quits: MoZ (chatzilla@82.230.92.154) (Client exited)
# [20:56] * Quits: arronei (arronei@131.107.0.71) (Ping timeout)
# [21:01] * Joins: arronei (arronei@131.107.0.80)
# [23:19] * Joins: szilles_ (chatzilla@124.155.113.142)
# [23:50] * Joins: annevk (opera@114.48.161.248)
# Session Close: Fri Mar 06 00:00:00 2009

The end :)