W3C home > Mailing lists > Public > www-style@w3.org > November 2009

[CSSWG] Minutes and Resolutions 2009-11-18

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 19 Nov 2009 13:17:39 -0800
Message-ID: <4B05B5F3.5020602@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:22 GMT