IRC log of css on 2009-03-05

Timestamps are in UTC.

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