- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 19 Nov 2009 13:17:39 -0800
- To: www-style@w3.org
Summary: RESOLVED: Accepted fantasai's proposed text for requiring that the the area outside the border edge do not accept mouse events on behalf of the element. RESOLVED: Not adding background-opacity; will consider functionality for future specs RESOLVED: Reject proposal to allow extra slashes in border-image shorthand NOTED: box-break: continuous | each-box will be renamed box-decoration-break: slice | clone unless there is consensus on a better proposal. RESOLVED: Publish Transitions and 2D Transforms as Working Draft ====== Full minutes below ====== Present: César Acebal Tab Atkins David Baron Elika Etemad Simon Fraser Sylvain Galineau Daniel Glazman Brad Kemper Peter Linss David Singer <RRSAgent> logging to http://www.w3.org/2009/11/18-CSS-irc <arronei> Regrets for today I have a conflicting meeting this morning. Scribe: TabAtkins glazou: Extra agenda items? glazou: No extra items, moving ot list of issues. <dsinger> Oh, dean's message about new Ed of transforms and transits <glazou> dsinger: ack CSS3 Backgrounds and Borders Last Call Issues --------------------------------------------- <fantasai> http://dev.w3.org/csswg/css3-background/issues-lc-2009 glazou: First item, boundaries of mouse-event trapping region. <glazou> http://lists.w3.org/Archives/Public/www-style/2009Mar/0433.html 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. fantasai: question is, should I put this in as a recommendation or as a note? dbaron: I think it should go wherever the pointer-events property goes. dbaron: I think if you do include it in the spec, it should be worded in a way such that other specs can modify it. dbaron: Frex, so that Pointer Events can say that an element doesn't receive any events, or whatever. glazou: Original question: requirement or note? dbaron: No opinion. fantasai: Requirement is easiest. Then we can include that in the test suite so there's consistent behavior for authors to rely on. <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." <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: 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 fantasai, eliding that text, is accepted. <glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0068.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. They are not necessary for parsing here. glazou: Also, I think adding slashes everywhere, even if functional, is a bit ugly. glazou: Refuse the proposal? peterl: It's ugly, but is it helpful? dbaron: 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. glazou: 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 current keywords aren't obvious what they mean. We have several new suggestions. fantasai: 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 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. <dbaron> 'separate' is probably misspelled more than 'continuous' 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. fantasai: The misspelling issue for 'separate' is a good point. bradk: I like slice. glazou: I like slice too, but not separate. <fantasai> Some other suggestions include slice | separate flow | separate slice | split one-box | add-boxes slice | divide ... some discussion about the unclarity of the second keyword ... <fantasai> slice | mitosis <fantasai> :) * sylvaing there is no such thing as too geeky TabAtkins: I like slice, but several of the other keywords are close enough to 'slice' that they're not good for meaning 'not-slice'. ... more discussion ... 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. glazou: Remember these need to be understood by non-english speakers, even if it's not obvious immediately. * sylvaing wonders how obvious any of stuff can be to a Japanese speaker plinss: 'break'? dbaron: I like sylvain's suggestion (slice/repeat) bradk: What's being repeated? The edges? fantasai: Kind of the whole thing, sort of. 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 <TabAtkins> slice is a noun too! <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 * sylvaing agrees with smfr * glazou too TabAtkins: Do we have a general term for 'backgrounds and borders'? <dbaron> no fantasai: 'backdrop'? plinss: Does that imply borders very well? plinss: I'm thinking of box decoration. plinss: We already have text-decoration. <Zakim> +smfr 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? * sylvaing -webkit-box-decoration-break-slicing-mode:collapse <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 much apply to background. <bradk> brake-mode: sliced|discrete <CesarAcebal> Will this property also affect to shadows? fantasai: yes; that was defined before we dropped box-shadow from the spec 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 usually has a box around each piece, while borders are open are at the breaks glazou: What about 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'. fantasai: We're trying to avoid that sort of thing, because it's not clear what 'mode' we're talking about. <glazou> box-decorations: break | unique 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: The difference here is between slicing a loaf of bread and dividing the dough into chunks before baking <fantasai> box-decoration-break: cake | muffins <fantasai> :) * smfr feels hungry 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. dbaron: 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. glazou: 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 looks up replicate in the thesaurus <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'. bradk: 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. * plinss box-break-behavior: ? glazou: So we go with box-decoration-break. fantasai 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 * oyvind broken-boxes: ignore | mend 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 set of keywords here, I think they're evocative. For the property, I don't want grammatical suffixes in our properties. fantasai: (talks about which ones she prefers because of this) <smfr> who has the clunky keyboard? <Zakim> -glazou fantasai: I'm ok with box-decoration-break, or break-box-decoration, or break-backdrop fantasai: I prefer the first because we have a pattern of subject-subtopic fantasai: e.g. text-wrap fantasai: is about wrapping text fantasai: text-decoration, is about decorations on text fantasai: page-break-after is about breakign pages, specifically, after the element <Zakim> +glazou * sylvaing still prefers repeat to clone. it's background-repeat not background-clone. 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. * dsinger box-break-name: consensus | divided | miusunderstood 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: If we don't have consensus on something else, that's what we're going with Publishing Transforms and Transitions ------------------------------------- dsinger: suggested publishing new WD of transitions and 2d transforms RESOLVED: Publish new WD of Transitions and 2D Transforms <smfr> what was the resolution on background-opacity? <TabAtkins> Leave it to later, smfr <smfr> TabAtkins: ok cool <glazou> smfr: too late for now <smfr> yeah <smfr> i don't like it <TabAtkins> 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 <TabAtkins> 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 <bradk> background-image-opacity, background-image-drop-shadow, background-image-transform, border-opacity, border-drop-shadow, etc.? <TabAtkins> Yeah, that's not a maintainable solution. <RRSAgent> http://www.w3.org/2009/11/18-CSS-minutes.html
Received on Thursday, 19 November 2009 21:18:16 UTC