<glazou> RRSAgent make logs public

<glazou> thanks RRSAgent

<arronei> Regrets for today I have a comflicting meeting this morning.

<glazou> ok arronei

<glazou> eh

<dsinger> Regrets also from Beth

<glazou> sylvaing: paracetamol is my friend

<scribe> scribenick: TabAtkins

glazou: Extra agenda items?
... No extra items, moving ot list of issues.
... First item, boundaries of mouse-event trapping region.

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Mar/0433.html

<fantasai> http://dev.w3.org/csswg/css3-background/issues-lc-2009

<dsinger> Oh, dean's message about new Ed of transforms and transits

<glazou> dsinger: ack

fantasai: We discussed hit-testing on the mailing list, and conclusion was for it to follow the boundaries of the border box. The parts of border-image that extend out of the box, and things outside the border-radius, shouldn't be included.
... question is, should I put this in as a recommendation or as a note?

david_baron: I think it should go wherever the pointer-events property goes.
... I think if you do include it in the spec, it should be worded in a way such that other specs can modify it.
... Frex, so that Pointer Events can say that an element doesn't receive any events, or whatever.

<fantasai> "The CSS Working Group recommends that the area outside the curve of the border edge does not accept mouse events on behalf of the element."

glazou: Original question: requirement or note?

david_baron: No opinion.

fantasai: Requirement is easiest.

<fantasai> "Portions of the border-image that are rendered outside the border box do not trigger scrolling. The CSS Working Group recommends that such portions are invisible to mouse events and do not capture clicks on behalf of the element."

fantasai: I'm trying to figure out *how* to require it.

<fantasai> (or not require)

<fantasai> I would drop "The CSS Working Group recommends that"

fantasai: to make it a requirement, I'd drop "The CSS WG recommends that..." and leave the rest of the sentence.

glazou: Other opinions?

RESOLVED Second suggestion from Elika, eliding that text, is accepted.

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0068.html

<fantasai> http://lists.w3.org/Archives/Public/www-style/2009Oct/0185.html

fantasai: background-opacity was on the list. I say that we're looking at that functionality for future specs, but want to skip it for now. The commenter seemed to be okay with that, based on their message.

glazou: Did you answer to the guy?

fantasai: Not yet, but he said "It might be too late for this", and it is.

RESOLVED nothing to decide wrt background-opacity

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0185.html

glazou: Issue 3 - slashes in border-image shorthand

bradk: I think the slashes are great for separating numbers, but aren't needed to separate keywords and such.

fantasai: Agreed.

glazou: Also, I think adding slashes everywhere, even if functional, is a bit ugly.
... Refuse the proposal?

<fantasai> peterl: It's ugly, but is it helpful?

david_baron: And also, is it consistent with CSS elsewhere?

glazou: Right, we don't use slashes to separate values, only when it's really needed to discriminate.
... I'm not in favor of this.

bradk: Not in favor either.

<dbaron> I'm probably slightly against

<dbaron> but not strongly

RESOLVED Do not add additional slashes to the border-image shorthand.

<glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0309.html

glazou: Next issue - box-break keywords.

fantasai: The keywords aren't obvious what they meant. We have several new suggestions.
... My preferences are for the ones that include 'slice', because I think it's clear.

<fantasai> http://dev.w3.org/csswg/css3-background/#the-box-break

<fantasai> http://dev.w3.org/csswg/css3-background/box-break.png

<dbaron> 'separate' is probably misspelled more than 'continuous'

fantasai: One is where the entire border is laid out and then sliced by the page breaks. The other is each group has its own background and border.

glazou: I don't think 'separate' is quite right. Maybe 'replicate'?

dbaron: Weren't there 3 values before?

fantasai: That was back when we had the background-break property, but we merged this in.
... The misspelling issue for 'separate' isn't great.

bradk: I like slice.

glazou: I like slice too, but not separate.

<fantasai> Response: Some other suggestions include slice | separate flow | separate slice | split one-box | add-boxes slice | divide

<fantasai> slice | mitosis

<fantasai> :)

TabAtkins: I like slice, but several of the other keywords are close enough to 'slice' that they're not good for meaning 'not-slice'.

<fantasai> slice | each-box

fantasai: slice and each-box?

TabAtkins: Fine with e.

glazou: No.

TabAtkins: Do you want anything with -box?

<sylvaing> slice/repeat ?

glazou: Possibly not. We already have box-break in the property.
... Remember these need to be understood by non-english speakers, even if it's not obvious immediately.

plinss: 'break'?

dbaron: I like sylvain's suggestion.

<dbaron> (slice/repeat)

bradk: What's being repeated? The edges?

fantasai: Kind of the whole thing, sort of.

<sylvaing> brad: what is repeated is whatever is otherwise sliced :)

<fantasai> slice | detach

bradk: Looking up 'separate' in my thesaurus. 'detach'? 'discrete'?

<dbaron> 'discrete' is also commonly misspelled

<sylvaing> if we use slice, the other ought to also be a verb

<dbaron> it's misspelled as 'discreet'

<dsinger> discrete and discreet have discreet meanings (or is that discrete meanings?)

<bradk> descreet?

<smfr> maybe the difficulty with names indicates that box-break is not the right name for the property

TabAtkins: Do we have a general term for 'backgrounds and borders'?

fantasai: 'backdrop'?

<dbaron> no

plinss: Does that imply borders very well?
... I'm thinking of box decoration.
... We already have text-decoration.

TabAtkins: Bad parallel. The background and border properties are already 'box decorations'.

bradk: 'break-method'

glazou: Or put 'decoration' in the value name. "box-break:slice-decoration"

<smfr> box-decoration-braek

smfr: "box-decoration-break"?

<bradk> too long

smfr: What would the values be?

<glazou> I don't think it's too long

plinss: We could be literal: 'open' and 'close'.

fantasai: I had border breaking properties 'open' and 'close', but it doesn't uch apply to background.

<bradk> brake-mode:sliced|discrete

<CesarAcebal> Will this property also affect to shadows?

TabAtkins: What's the name for the individual *things* that are owning these separate backgrounds and borders?

fantasai: boxes generated by boxes

bradk: I still think it's too long.

<smfr> box-decorations: break/continue ?

glazou: I think it should affect shadows. That's what would be expected.

smfr: What about outline?

fantasai: outline isn't necessarily rectangular. It's kind of ua-defined.

bradk: It'd be weird if a box had a border and an outline, and they looked different.

<glazou> decorations-break: yes | no

fantasai: outline always has a box around each piece, while borders normally are continuous.

glazou: What abou decoration-break?

fantasai: That gets mixed up with text-decoration.

TabAtkins: Agreed.

<CesarAcebal> I'd prefer box-decoration-break.

glazou: I don't think so.

bradk: I still like 'break-method' or 'break-mode'.

<glazou> box-decorations: break | unique

fantasai: We're trying to avoid that sort of thing, because it's not clear what 'mode' we're talking about.

smfr: I also think the word 'break' by itself is confusing; word-breaking, etc.

bradk: box-decorations doesn't say what it's for. There's lots of ways to decorate a box.

<dbaron> I don't think 'unique' fits with "make 5 of them"

<smfr> box-decoration-break is the winner!

<glazou> yep:)

<fantasai> box-decoration-break: slice | replicate

TabAtkins: no breaks, or lots of breaks

fantasai: No, there's always breaks. You're just controlling how it looks.

<fantasai> box-decoration-break: cake | muffins

<fantasai> :)

glazou: It seems like we're running in circles.

sylvain: Could you want to break backgrounds and borders different?

dbaron: I think if we go back to separate properties the naming is easy.
... We could go back to background-break or border-break.

sylvaing: The assumption that you want borders and backgrounds to always do the same, it's fine, but is that justifiable?

glazou: I have a case in mind where 'separate' would be a problem. Frex, a gradient on a background, with text-color chosen specifically to contrast the part of the gradient.
... You'd want to have borders on each box, but spread the background out to all.

sylvaing: If we think they might be split, the naming issue would be simplified by just splitting them.

fantasai: We can split them in the future.

sylvaing: How would we split them in the future? Multiple properties?

fantasai: Yeah, you'd map the current values to values in the new split properties.

sylvaing: So we're still looking for a term that means 'backgrounds and borders' without saying 'backgrounds and borders'.

<fantasai> box-decoration-break: slice | clone

TabAtkins: 'box-decoration' hits that pretty well, and also covers shadows and such which we just decided we want.

glazou: I used replicate, and clone works well. It's short.

bradk: I'm still not seeing why 'box-break' is worse than 'box-decoration-break'.
... I thought it was not about whether you're breaking, but how you were breaking.

fantasai: If you saw the property on its own, I'd think 'box-break' was referring to whether or not the box breaks.

glazou: So we go with box-decoration-break. Elika proposed slice and clone.

TabAtkins: Like it.

<bradk> clone the decoration

smfr: I'm not sure I like it. Does it make sense to say you're cloning or slicing the break?

<dbaron> broken-box-decorations: sliced | cloned

<smfr> box-decoration-break: break/continuous

<dbaron> yes/no is bad for property values

smfr: Seems like if we're using -break, it should be yes/no or continuous/separate

<CesarAcebal> And what about 'repeat' instead of 'clone'?

sylvaing: What's the issue with boolean values?

<CesarAcebal> (By similarity with background-repeat: repeat.)

TabAtkins: It goes weird as soon as you want a third value.

dbaron: Not sure I like it, but "broken-box-decorations: sliced | cloned"

<smfr> i don't really like it

<fantasai> break-box-decorations: slice | clone

<fantasai> I don't like having grammatical suffixes in our properties

<bradk> break-backdrop: slice | clone

<dbaron> broken-boxes: slice | clone

smfr: Is there an analogy with tables? Where headers are repeated on every page. There's no CSS for that yet?

<glazou> broken-boxes: repeat-decorations | clone-decorations

plinss: I don't think 'clone' makes sense for the border.

fantasai: Yeah it does. Each copy gets a complete copy of the border.

smfr: I think a property called 'broken-boxes' is going to cause some amusement in general.

<sylvaing> smfr, yes, it could be assumed to be an ie6 thing :)

<dbaron> I'm happy with box-decoration-break, though.

<smfr> box-decoration-breaks: slice/clone ?

fantasai: I think slice/clone is the right thing to do here, I think they're evocative. For the property, I don't want grammatical suffixes in our properties.
... (talks about which ones she prefers because of this)

<smfr> who has the clunky keyboard?

<glazou> sorry lost the call

<fantasai> fantasai: I'm ok with box-decoration-break, or break-box-decoration, or break-backdrop

<glazou> have to redial

<fantasai> fantasai: I prefer the first because we have a pattern of subject-subtopic

<fantasai> fantasai: e.g. text-wrap

<fantasai> fantasai: is about wrapping text

<fantasai> fantasai: text-decoration, is about decorations on text

<fantasai> fantasai: page-break-after is about breakign pages, specifically, after the element

bradk: I still think we're discussing the break-method.

<smfr> box-break-treatment/box-break-appearance?

glazou: 'appearance' is used for UI. 'rendering'?

<smfr> box-break-rendering: slice/clone ?

plinss: box-break-rendering: single/multiple

glazou: Moving discussion to mailing list.

fantasai: As editor, I'm leaning to box-decoration-break:slice/clone. I'll put that in the Editor's draft, and if anyone has better suggestions, send it to the mailing list.

<fantasai> fantasai: If we don't have consensus on something else, that's what we're going with

dsinger: (said something I didn't catch about pushing another draft of some spec by Dean Jackson)

<smfr> dsinger: suggested publishing new WD of transitions and 2d transforms

<smfr> what was the resolution on background-opacity?

Leave it to later, smfr

<smfr> TabAtkins: ok cool

<glazou> smfr: too late for now

<smfr> yeah

<smfr> i don't like it

<glazou> smfr: glad you could join the call btw

<smfr> my meeting finished early

Yeah, I don't like it as it is. As part of a proper treatment of SVG filters, sure.

<fantasai> right, it's the functionality we're considering for the future, not the property as proposed

<smfr> i want background-image: alpha(url(foo.jpeg), 0.5) or something

While I can see myself using it, I can't see myself using it *enough* to require a top-level property when we've got a generalized property on the horizon.

<smfr> or background-image-opacity

<glazou> sylvaing: IE9 demoed right now...

<smfr> any interesting IE9 announcements?

<glazou> let me quote

<glazou> " IE9 rendering engine being demoed right now. . .rounded borders, rendered text through Direct2D, CSS Selector support! "

<smfr> uh oh: http://www.css3.info/ie9-to-include-alternative-css2012-standard/

<smfr> oh, joke

Hehe.

<glazou> lol

<glazou> dbaron: some software have bugs :)

<glazou> sylvaing: what else in ie9?

<glazou> rhâââ firefox just crashed because of silvelight

<glazou> silverlight

<bradk> background-image-opacity, background-image-drop-shadow, background-image-transform, border-opacity, border-drop-shadow, etc.?

Yeah, that's not a maintainable solution.

Someone still needs to generate minutes because I forget how to.

<fantasai> RRSAgent: make minutes

This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/dbaron:/glazou:/
Succeeded: s/if/of/
Found ScribeNick: TabAtkins
Inferring Scribes: TabAtkins

WARNING: No "Topic:" lines found.

Default Present: glazou, +1.206.324.aaaa, sylvaing, bradk, David_Baron, dsinger, plinss, TabAtkins, CesarAcebal, smfr
Present: glazou +1.206.324.aaaa sylvaing bradk David_Baron dsinger plinss TabAtkins CesarAcebal smfr

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 18 Nov 2009
Guessing minutes URL: http://www.w3.org/2009/11/18-CSS-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report