- 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