- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:50:51 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Masking
-------
- RESOLVED: Add "no clipping" value to mask-clip
- RESOLVED: Deprecate 'clip', recommend 'clip-path' from now on.
- RESOLVED: Add inset() or inset-rectangle() to the Shapes module.
- Discussed percentage sizing reference
- Discussed interpretation of fragment URLs against SVG
- RESOLVED: FPWD Masking as css-mask
Compositing
-----------
- RESOLVED: Turn the Compositing default to be isolated groups.
====== Full minutes below ======
CSS Masking
-----------
Scribe: TabAtkins
<krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
krit: This spec aims to combine Masking in FF and Webkit, combine to
a common spec. Takes from SVG Masking and Clipping, and specifies
how WebKit works.
krit: Have a few issues left.
krit: First is mask-clip.
krit: CSS Masking in webkit is pretty similar to background and its
properties.
krit: While a background is always limited to the border box (you can't
draw outside of it), CSS masking might want to go outside of this box.
krit: For example, a child element overflowing the main element, people
may want to have a mask that covers the whole thing and doesn't
auto-clip away the overflow.
krit: But right now mask-clip only has the same property as background-clip.
krit: I'd like another keyword that takes into account the boxes of children.
TabAtkins: So, not things like shadows? Just the union of geometry, like
getboundingClientRect?
krit: Yes.
krit: Another issue - SVG percentages in a clip need to resolve against
a box. I'd like to let this "union box" also be usable for resolving
percentages against.
krit: Another related issue - set the clip area to the same as the filtered
area.
krit: For example, be able to put a clip on a blurred element without
necessarily auto-clipping the part of blur that goes outside the
geometry.
krit: roc suggested a "none" value, with no automatic limitations (or
UA-defined ones based on knowledge of painting). However, we
still need to decide what SVG percentages are resolved against.
krit: We could use the "union box" for that too - difference being that
stuff outside the 0%-100% range are actually still useful.
dbaron: That's a little weird, if the blur is part of the bounding box.
TabAtkins: It's not - it's just whatever bounding client rect would return.
krit: Next question, origin of the coord space. Since you're referencing
an SVG image, how do you position the image? x/y attributes on the
root <svg> element? Is that allowed?
TabAtkins: It's allowed, but I think it's meaningless right now. We
could maybe fix that.
krit: And for PNG it would just sit at the 0,0 of the coord space?
TabAtkins: Yes.
krit: Ok, but then you still can't ever mask a blur with a PNG - the blur
part will always be outside of whatever boxes you use for the coord
space.
TabAtkins: Okay, so we might want a clip-margin then, to allow the author
to manually expand the clipping box further.
krit: Ok, if you're willing to help me figure that out, we can leave it
unresolved for now.
TabAtkins: Okay, so two additions to the spec being reviewed right now:
TabAtkins: 1) Add a new value to mask-clip/origin which uses the "bounding
box" - same as returned by getBoundingClientRect.
TabAtkins: 2) Add a new "none" value which has no auto-clipping, and which
sets the origin/extent of coordinate space same as "bounding
box" value.
plinss: So the initial suggestion was just to add a "none" keyword?
TabAtkins: Has anyone asked for the "bounding rect" clip?
krit: Firefox does the "none" value right now.
TabAtkins: Okay, so maybe just do the "none" value now, and reserve the
explicit "bounding rect" clip for later.
RESOLVED: Add "none" value to mask-clip
Bert: Do we need to coordinate with SVG on this?
krit: SVG already decided on it - this is SVG coming to CSS to
sanity-check/bless it.
<krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#ClipProperty
krit: The 'clip' property only applies to abspos elements, using the
rect() function.
krit: But 'clip-path' works on everything, with more shape functions
and an SVG <clipPath> element reference.
TabAtkins: So do we want to unify the two properties?
krit: I think I don't - people might be confused about using both rect()
and another shape (doing one on :hover, for instance) and not
knowing why one doesn't work (since rect() would, for legacy
reasons, only work on abspos elements).
TabAtkins: Okay, so you're suggesting deprecating 'clip' and using
only 'clip-path'.
plinss: Sorta sad - clip was the first one that we ever did with the
intention of being extended with more functions like this.
RESOLVED: Deprecate 'clip', recommend 'clip-path' from now on.
TabAtkins: Related to this, can we add an inset-rectangle()?
dbaron: We have a standing resolution from 2001 to add an inset-rect()
<dbaron> Redwood City in 2001
<dbaron> (which was only the second WG meeting I attended in person)
everyone: sounds good, make Rossen do it.
* fantasai suggests just calling it 'inset()'
ACTION rossen to add inset-rectangle(top, right, bottom, left) to the
Shapes spec. (or just inset()).
<trackbot> Created ACTION-514
RESOLVED: Add inset() or inset-rectangle() to the Shapes module.
krit: Last issue is the 'mask' shorthand.
krit: 'mask' property in SVG takes a ref to a <mask> element.
krit: Webkit takes just CSS images.
krit: roc complained that these are not fully compatible with each other
krit: it's not fully clear when pointing to an SVG document whether
to use it as an "image" or as an "image source" (a CSS image,
in other words).
Scribe: krit
TabAtkins: If you have a URL function with an hash, it is not clear if
you refer an SVG element or an paint server, or an resource
TabAtkins: CSS would like to integrate into SVG further
TabAtkins: Use SVG paint servers as CSS images
TabAtkins: fill and stroke would take CSS Images
TabAtkins: this needs two different code pathes
TabAtkins: Is the SVG file referencing a resource, paint server or element?
TabAtkins: Dependent on the context, the file needs to be treated differently
TabAtkins: this might be a problem in more impementation
TabAtkins: that's why he want to know on parse time which code pah we need
Scribe: fantasai
TabAtkins: On mailing list, roc has proposal we're working through on
how to segregate SVG references based on structure of frag
id as to whether it's a paint server or ?
TabAtkins: If it's a frag id, assume it's a paint server
TabAtkins: If it's a media fragment or SVG functional notation, it's an
SVG view
ChrisL: What if you have a normal fragment ID that points to an SVGView
element?
TabAtkins: ... use :target pseudo-class to get similar facts
TabAtkins: Probably safe to shut that down
TabAtkins: Let's discuss this soon, decide on something that's good for
SVG, and incorporate here.
TabAtkins: If you're interested in this, contribute to mailing list
thread on www-style
http://lists.w3.org/Archives/Public/www-style/2012Oct/0766.html
<dbaron> http://lists.w3.org/Archives/Public/www-svg/2012Oct/thread.html#msg19
<dbaron> looks like the first few messages on the thread were www-svg
only, then it was both www-svg and www-style for the rest
SteveZ: Appears to me you want to distinguish paint servers, things
that SVG can fill
SteveZ: my experience is that heuristics is a fragile way to distinguish
SteveZ: Why not add something to referencing mechanism?
TabAtkins: SVG and CSS are already ambiguous in how they handle this
TabAtkins: Luckily way SVG uses CSS URLs is usually referring to a
paint server
TabAtkins: So works already
krit: SVGStack
TabAtkins: mechanism for spriting SVG, using :target to hide everything else
TabAtkins: These would break, because need to load those as an image,
not as a paint server
TabAtkins: But afaict the uses of these in the wild are in <object>
tags, etc.
krit: we've seen a lot of blog posts and bug reports complaining that
we don't implement this
<ed> TabAtkins: yes, that's true, but the use outside of CSS doesn't
use the url()-notation, so it's different
<ed> use of svg stacks that is
fantasai: We have several functions that allow referencing images
fantasai: Why not distinguish based on that?
TabAtkins: roc suggests element() interprets as paint server, image() as view
fantasai: make url() do the legacy thing
TabAtkins: both are legacy things
* fantasai is confused
plinss: Interpreting things differently based on fragment ID is an
architectural faux-pas
plinss: Interpretation of frag ID should be registered with media type
plinss: Let's not do something that breaks the Web architecture
TabAtkins: Two legacy behaviors are bg-image: url(svg); treats as an image
TabAtkins: fill: url(svg); treats as a paint server
fantasai: Then per-property, define handling of url() per property
TabAtkins: doesn't work for masking -- could load svg as a mask path,
or as an image
fantasai: So pick a default, and then can use other function names to
do something different
ChrisL: why not add a keyword with several values? The initial value is
auto which means do the magic thing but you can add specific
keywords for paint server or image if auto does the wrong thing
for you
dbaron: we already have the image()/element() functions to distinguish
them, so I don't think we need further keywords to distinguish
krit: Mozilla also has to consider CORS, which is one reason we need to
know ahead of time
krit: So let's leave this issue open for now
krit: Can we publish a FPWD with changes we resolved today?
plinss: any objections?
RESOLVED: FPWD Masking
plinss: Have similar issue wrt shortname
...
TabAtkins: It's a Level 1 spec
TabAtkins: So could just call it css-mask
RESOLVED: call it css-mask
<br duration=22m>
Compositing
-----------
Scribe: TabAtkins
<cabanier> slides for blending discussion:
http://cabanier.github.com/blending/#/
cabanier: Blending spec currently says that blending/compositing always
happens in a non-isolated group. I propose that they happen
in an isolated group.
cabanier: Two reasons - first, non-isolated are much more expensive to do.
cabanier: Two, some OS frameworks (such as Cairo) can't do them natively,
so they'd have to be done by hand.
cabanier: So I fear that they would be non-implementable as written today.
cabanier: [goes through his slides]
cabanier: So in isolated groups, as soon as you have a stacking context,
the elements in there only blend/composite with each other,
not with elements outside the stacking context.
cabanier: (in SVG, the relevant group is the <g> element)
cabanier: Authors generally *prefer* non-isolated groups, but the
implementability just seems to be too painful right now.
TabAtkins: So we might still want to have a property that merges groups?
cabanier: Already exists. I'm just asking to change the default.
cabanier: (Also, that property probably won't be implemented yet, and
may be removed from this level.)
cabanier: I know some of the graphics people will be unhappy, but they
can work around it by putting things in the same stacking context.
cabanier: This weirdness already exists sometimes - z-index can be
disrupted by opacity creating a new stack.
* hober an oldie but a goodie: http://w3cmemes.tumblr.com/post/22708671971
TabAtkins: Relevant Moz implementor would be roc, right?
krit: Cairo was cited as the problem. Direct3D will have the same problem.
lstorset: Will this affect existing SVG impls?
cabanier: It's a new property, so no.
RESOLVED: Turn the Compositing default to be isolated groups.
dino: What about publishing the spec?
cabanier: It's already a WD.
cabanier: And I'll request a new WD when I make edits.
Received on Wednesday, 14 November 2012 06:53:35 UTC