[CSSWG] Minutes TPAC Mon 2012-10-29 PM I: Masking, Compositing


   - 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


   - 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
   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
   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
   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
   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
   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
   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
   <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?

   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>

Scribe: TabAtkins

   <cabanier> slides for blending discussion:
   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