See also: IRC log
<glazou> RRSAgent make logs public
<glazou> thanks RRSAgent
<arronei> Regrets for today I have a comflicting meeting this morning.
<glazou> ok arronei
<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.
<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.
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: 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.
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
... 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: 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.
<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
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.
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.
dbaron: I like sylvain's suggestion.
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?)
<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'?
plinss: Does that imply borders
... I'm thinking of box decoration.
... We already have text-decoration.
TabAtkins: Bad parallel. The background and border properties are already 'box decorations'.
glazou: Or put 'decoration' in the value name. "box-break:slice-decoration"
<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.
<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.
<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!
<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
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
... (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.
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> 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> oh, joke
<glazou> dbaron: some software have bugs :)
<glazou> sylvaing: what else in ie9?
<glazou> rhâââ firefox just crashed because of silvelight
<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[End of scribe.perl diagnostic output]