W3C home > Mailing lists > Public > www-style@w3.org > August 2012

[CSSWG] Minutes Telecon 2012-08-29: Masking, Animating Transforms

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 29 Aug 2012 20:08:28 -0700
Message-ID: <503ED92C.7070509@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - RESOLVED: Keep clip-path in the Masking spec, mark integration with
               'clip' as an issue
   - RESOLVED: rotate3d() is interpolated by its angle when the two (normalized)
             vectors match, by matrix interpolation otherwise.
   - RESOLVED: rotateX/Y/Z() interpolate with rotate3d() in the obvious way.
   - RESOLVED: Remove mask-attachment from the Masking spec.
   - RESOLVED: Keep mask-origin in the Masking spec.
   - Open discussion on mask-clip, and whether/how to allow unclipped masks

====== Full minutes below ======

Present:
   Rossen Atanassov
   Tab Atkins
   David Baron
   Ber Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Rebecca Hauck (Adobe)
   Koji Ishii
   Brad Kemper
   Peter Linss
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Lea Verou (W3C)
   Steve Zilles

Regrets: jjansen, sylvaing
<RRSAgent> logging to http://www.w3.org/2012/08/29-css-irc
Scribe: SteveZ

TPAC
----

   Bert Do we need to reserve a polycom device
   Daniel: Will a Skype device suffice"
   Bert: using Zakim is no problem, but we would need to rent a polycom
   PeterL: just using Skype would be enough
   Daniel: John Daggett has provide the Skype device in the past; I will
            ping him to see if he is coming.
   <dbaron> Sylvain might also have one of those devices...
   Daniel: where are we wrt the Sunday meeting?
   Bert: the people that offered to pay will get an invoice for their
         contribution from Alexandra who is working on the details
   Daniel: make sure to notify the contributers who gets the invoice
   SteveZ, Tab, Aaron: we will check if an invoice to ERCIM in euros is OK

Test the Web Forward
--------------------

   <stearns> http://testthewebforward.org/paris-2012.html
   Stearns: The 3rd instance will be Friday and Saturday before TPAC
   <stearns> please send a message to testthewebforward (gmail.com)
             if you will be able to attend
   Daniel: I will be there
   Venue is TBD

CSS Masking
-----------

   <glazou> http://wiki.csswg.org/topics/css-masking
   <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#the-mask-image
   krit: Some people at F2F this was discussed and members requested more
         time to view spec.
   krit: via mailing list some properties were removed
   krit: can we remove some of the background properties: mask-attachment
         (not implemented by Webkit), mask-origin and mask-origin
   smfr: we should keep mask-origin be
Scribe: TabAtkins
   smfr: mask-attachment could be used for interesting design issues
   smfr: But it has the same problems wrt transforms as background-attachment
   glazou: mask-attachment could be use for keyhole views effects

   krit: There's another reason with keeping mask-origin.
   krit: CSS and SVG differ in how they apply.
   krit: SVG masks, all descendants of an element are grouped together and
         masked together.
   krit: This is especially relevant for percentage values.
   krit: 100% width is the boundingclientrect, etc.
   smfr: In webkit, when you apply a mask to html, they create stacking
         contexts, just like opacity. So how is SVG different?
   krit: The diff is that if you have border-box, padding-box, etc, you
         clip to these boxes.
   krit: Every mask applied to these elements is clipped to the *-box of
         the element.
   smfr: Ah, this is why dhyatt was reluctant to propose these.  They
         always hide overflow.
   krit: Right. SVG masking on firefox, though, allows overflowing content
         to be shown.
   krit: So this is what I mean.  When you mask to a group element, it
         gets applied to the group's bounding box (which by definition
         includes the entire contents, no overflowing).
   krit: I can post an example for it.

   glazou: Speaking of the three properties you want to drop, would it be
           enough to mark them as at-risk?
   krit: Yeah.
   dbaron: at-risk is for when we think they're a good idea, but we're not
           sure we're going to get them. But this discussion is about
           whether they're a good idea or not.
   dbaron: If they're not a good idea, they should just be dropped.
   krit: There's already an issue that they might be dropped.
   krit: Another issue is, do we keep clip-path?
   krit: SVG already combines masking and clipping to one section.
   glazou: I'd like to resolve on the first three properties.
   smfr: I'd like to keep mask-origin.
   glazou: krit, are you okay with keeping mask-origin, and dropping
           the others?
   krit: Provisionally yes.  It might depend on how we handle clipping
         of masks (to border-box or bounding box).
   krit: So I can provide some examples to help us to decide to keep,
         drop, or redefine.
   <krit> http://www.w3.org/Graphics/fx/wiki/Filter_Effects:_background_and_border_filter
   krit: Here's an example from filter-effects to illustrate the problem.
   krit: Two nested elements, the child overflows its parent.
   krit: With SVG masking, percentages in the mask are referenced relative
         to the bounding box.
   krit: For webkit-mask, it would just be the border-box of the parent.
         Everything else would be masked away, and you can't do anything
         about it.
   <dbaron> I didn't hear well enough to understand the problem.
   * fantasai neither
   smfr: There's a real attraction to reuse the background properties for
         simplicity.
   smfr: [restates the problem]

   fantasai: I think, if you're going to use the same things in filter
             effects, it makes sense to have it apply to overflowing
             content too.
   fantasai: Similar issue - apply a mask or a filterto an inline with
             Zapfino, which overflows its em box.  You don't want it to clip.
   Steve: if you have a line of text that overflows and you are putting a
          shadow on that text it is weird if the shadow disappears at the
           border boundary
   * Rossen agrees with fantasai and Steve

   dbaron: However, I don't think we want to take measurements based on
           an overflow rectangle.
   dbaron: It's not well defined, and even if it were, it would likely
           be confusing.
   szilles: What did you mean "overflow is not well defined"?
   krit: For ..., we just use the bounding client rect, which is just a
         union of border boxes, not overflow.
   <krit> http://www.w3.org/TR/cssom-view/#dom-element-getboundingclientrect
   dbaron: There's not a good definition for what overflow means.
   krit: You'd just use the concept of bounding rect, from CSSOM View.
   TabAtkins: No, that's not what you want.  CSS's notion of this pays no
              attention to the children of an element, only the boxes of
              the element itself.  SVG has no elements which both have
              children and boxes, so it takes the collection of children
              and finds their bounding box.  This is why CSS "ignores overflow".
   smfr: There's a possible solution here.
   smfr: Say that masking is not always clipping to the border box - you
         allow the mask image to project outside the border box, but the
         sizing is still specified in the same way that background is sized.
   smfr: So it could cover the decorations of zapfino, but you'd keep the
         normal background sizing behavior.
   fantasai: I agree.
   TabAtkins: fantasai and I have been exploring a similar issue with
              backgrounds themselves--cases where you want to draw
              background images outside the border box--so I think this
              is a good direction to go in.
   krit: What about percentages in sizing an SVG mask?
   TabAtkins: Since SVG has no such thing as a padding box or border box,
              it can define what it wants (and use the bounding box of
              its descendants).

   <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#clipping-paths
   krit: Okay, so next, should we keep clip-path in the spec?  It's
         already used in Firefox.
   krit: clip-path originally just referenced a <clipPath> from SVG, but
         I just extended it to also use the shape functions from Exclusions.
   smfr: I don't feel strongly.  It seems to overlap with 'clip'.
   krit: Yeah, but 'clip' only does rect(), and requires abspos.
   TabAtkins: I'm interested in us merging clip and clip-path.
   dbaron: We'd probably have web compat problems with that.
   TabAtkins: There's a way around that - say that rect() only applies
              to abspos elements, but the other functions (including
              rectangle()) all work on all elements.
   <smfr> i support this
   <Rossen> Note that this discussion applies to CSS Shapes not CSS
            Exclusions, though they are in one spec at the moment we
            can split them at any time
   RESOLVED: Keep clip-path in the Masking spec, mark integration with
             'clip' as an issue

   <bradk> i would rather have a new "crop" property instead of "clip",
           with measurements from 4 edges

Transforms: rotate3d() interpolation
------------------------------------

   <glazou> http://wiki.csswg.org/topics/interpolation-rotate3d
   krit: We discussed rotate3d() and numerical interpolation at the f2f.
   krit: Current behavior is that we always use matrix decomposition to
         interpolate.
   <krit> http://wiki.csswg.org/topics/interpolation-rotate3d
   krit: The group would like numerical interpolation.
   krit: There are proposals near the end of the wiki.
   krit: If you have two vectors that describe the same axis but point
         in different directions...
   krit: Right now we define rotation around the axis according to the
         direction of the vector.
   krit: If they point in opposite direction, we need to decide how to
         interpolate the numbers.
   krit: If we interpolate the vectors, it gets smaller first, becomes
         a point, then points in the opposite direction.
   krit: This means the rotation direction suddenly changes from CW to CCW.
   TabAtkins: I think it's uncontroversial to interpolate the angle when
              the vector is the same (after normalization).  Interpolating
              the vector is harder.
   krit: Yes.  And right now everyone supports it via decomposition, so
         it'll take time to change.
   smfr: What I care about is that if the normalized vectors match, do
         angle interpolation.  I think it's fine to fall back to matrix
         interpolation otherwise.

   smfr: One thing I think isn't clear is whether you interpolate from
         rotateX() to rotate3d(1,0,0,...), that'll give you angle rotation
         or matrix interpolation.
   krit: Currently you do matrix.
   smfr: That's unfortunate.
   smfr: The spec currently defines a 2d set and a 3d set, and it's not
         clear whether they're equivalent.
   krit: That seems easy.  I thought the resolution was for me to come
         up with a proposal to do vector interp.
   krit: Which I've done (interpolate x,y,z numerically).
   smfr: I don't think that's good.  The "snapping" effect when going
         from 1,0,0 to -1,0,0 is no good.
   dbaron: Yeah, I'd rather fall back to matrix when the vectors don't match.
   krit: Yeah, that would be the easiest way.
   [no objections]
   RESOLVED: rotate3d() is interpolated by its angle when the two (normalized)
             vectors match, by matrix interpolation otherwise.
   RESOLVED: rotateX/Y/Z() interpolate with rotate3d() in the obvious way.

Masking (Cont.)
---------------

   glazou: returning to the mask discussion...
   fantasai: I heard we have concerns about attachment, people want origin,
             so what's hard about resolving?
   <dbaron> does anybody actually want mask-clip ?
   krit: Give me an action to come back with detailed proposals for these
         properties.
   fantasai: My proposal. We drop -attachment unless someone asks for it.
             We keep -origin.  We drop -clip, and say that masks don't clip.
             (If you want to clip, use the box one.)
   krit: Okay, so any objections to removing -attachment?
   dbaron: I'm fine with that.
   RESOLVED: Remove mask-attachment from the Masking spec.
   RESOLVED: Keep mask-origin in the Masking spec.

   glazou: What about mask-clip?
   smfr: I think we want to keep it.  If we they extend out of the box,
         you may want to clip it.
   fantasai: I think it should extend by default, but give us an ability
             to clip it.
   dbaron: Do any of the options in mask-clip correspond to the behavior
           you're asking for?
   smfr: No, we'll need a new value.
   fantasai: Tab and I were thinking of no-clip when discussing this for
             background-*.
   fantasai: I think we have agreement that we need the ability to have
             the image not clipped by the box.
   fantasai: So either that becomes a new value of mask-clip, or it becomes
             the initial value of mask-clip, or we drop mask-clip and just
             make it how things always work.
   <smfr> yes
   glazou: No consensus, so defer to next call.

Meeting closed.
Received on Thursday, 30 August 2012 03:08:56 GMT

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