- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 20:08:28 -0700
- 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 UTC