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

[CSSWG] Minutes and Resolutions Seattle F2F 2011-07-26 AM: paint servers, pointer-events

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 05 Aug 2011 17:34:46 -0700
Message-ID: <4E3C8C26.3090205@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Day 3 of the Seattle CSSWG F2F was an FXTF joint meeting with the SVGWG.

SVG Paint and CSS Images
------------------------

   - RESOLVED: Tab to add wording to CSS Image Values 4 about how SVG Paint
               Servers apply to CSS
   - RESOLVED: Tab to draft something about how CSS image values apply to
               SVG. This will live in the CSS Image values 4 spec for now
               (it may move later).
   - RESOLVED: The new image generator methods (eg. turbulence) to be added
               to CSS Image Values 4
   - Some concern about restraining scope / keeping syntax sane for the new
     image generator methods.

Hit Testing and Transparency, pointer-events
--------------------------------------------

   - RESOLVED: List all the current values for pointer events, everything
               other than "none" is treated as "auto" unless applied to SVG
               content
   - RESOLVED: Add an author conformance criteria saying that they should
               not use the other pointer-events values outside of SVG
   - RESOLVED: Add 'pointer-events: auto' to SVG 2
   - RESOLVED: Drop the SVG UA stylesheet rules. Add a note saying that SVG
               will be adding 'auto' as the default value in a future spec.
   - Discussion of click-jacking via pointer-events and <iframe> and other
     security implications of pointer-events and the hit testing model
   - RESOLVED: Integrate Hixie's proposal on hit testing and define hit-testing
               in CSS 3 UI and coordinate with SVGWG for harmonizing with SVG.
   - Discussion of opacity-sensitive hit testing and hit testing masks.

Filters
-------

   - Discussion on merging SVG Filters and CSS Filters into one spec
   - Discussion on custom filters: problems, advantages
   - Discussion on interaction of hit testing and filters

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

Present:
   Tab Atkins (Google)
   David Baron (Mozilla)
   Brian Birtles (Mozilla)
   Rik Cabanier (Adobe)
   Tantek Çelik (Invited Expert)
   Erik Dahlstrom (Opera)
   Patrick Dengler (Microsoft)
   Elika J. Etemad (Invited Expert)
   Arron Eicholz (Microsoft)
   Simon Fraser (Apple)
   Sylvaing Galineau (Microsoft)
   Daniel Glazman (Disruptive Innovations)
   Koji Ishii (Invited Expert)
   Dean Jackson (Apple)
   Brad Kemper (Invited Expert) via phone + IRC
   Anne van Kesteren (Opera)
   Peter Linss (HP)
   Divya Manian (Opera)
   Cameron McCormack (Mozilla)
   Alex Mogilevsky (Microsoft)
   Edward O'Connor (Apple) via phone + IRC
   Florain Rivoal (Opera)
   Alan Stearns (Adobe)
   Shane Stevens (Google)
   Jennifer Yu (Microsoft)
   Steve Zilles (Adobe)

<RRSAgent> logging to http://www.w3.org/2011/07/26-fx-irc
<plinss> and at  http://logs.csswg.org/irc.w3.org/fx/?date=2011-07-26
<ed> Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda

SVG Paint and CSS Images
------------------------

   <smfr> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0111.html
   TabAtkins: There was a proposal a while ago about using SVG paint as
              CSS images.
   <smfr> http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
   TabAtkins: That's one proposal. I plan to add it into CSS Image Values 4
   TabAtkins: The other way around is CSS into SVG paint servers
   TabAtkins: e.g. <rect fill="linear-gradient(top blue)">
   TabAtkins: but there are other useful things like the element() function
   TabAtkins: question is where to specify using CSS images as paint servers?
   dino: what's the status of SVG specs
   heycam: SVG 2e was just published. We are starting on new specs now.
   heycam: it would be ok to specify this in image values spec
   ed: many SVG implementations already support things like CSS3 colours
       anywhere you can use a <color> in svg even though that isn't supported
       in the SVG spec(s)
   dino: it seems weird for a CSS specification to define SVG behaviour
   heycam: we could do it in the SVG spec, it would take time
   szilles: It would be ok for the SVG spec to do this, by specifically
            calling out the CSS image values spec as the normative behaviour.
   tantek: The problem then is that the CSS image values spec now requires an
           SVG implementation to exit CR
   dbaron: it's ok if there are two browser engines that implement it
   TabAtkins: Mozilla already have an implementation
   <TabAtkins_> http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.html
   tantek: i am not formally opposing, but I think it is a potential serious
           issue.

   TabAtkins: all the CSS image values would be SVG paint servers in
              userSpaceOnUse
   heycam: uSoU percentages are relative to the viewport, not to the
           bounding box of the shape
   TabAtkins: then the problem is that absolute lengths are not the same.
              You don't have a middle ground where percentages are relative
              to the bounding box and keeping units.
   TabAtkins: I don't want to create a new unit space just for this.
   heycam: are there other issues?
   TabAtkins: I think coordinate spaces are the only issues.
   dino: what CSS image values have percentages?
   TabAtkins: only gradients
   vhardy: How about the keywords like top left etc? Would that be to the
           SVG bounding box?
   TabAtkins: we're dropping those temporarily. We'll have to deal with that
              when it comes back in. I might have to think about coordinate
              systems a little bit.
   TabAtkins recaps yesterday's CSS discussion on gradients
   <bradk> I thought we were unresolved on whether or not to do away with
           corner-to-corner gradients for now. No concensus.
   <fantasai> bradk, i believe they were officially deferred from CSS IM 3
   <bradk> dino, Are you sure? I don't recall seeing a resolution for that.
           I thought it was "no consensus, back to the list".
   <dino> bradk, no, I'm not sure.
   <fantasai> There was no consensus on removing anything from Gradients
   <dino> bradk, but Tab is speaking now as if it was a resolution :)
   <fantasai> Well, Tab's wrong then. :)
   <bradk> wouldn't be the first time. ;)
   <bradk> sterns, dino, I'm not really opposed, if we are just talking about
           corner-to-corner, and not about removing keywords version altogether.
           But I'd rather just resolve remaining issues first. Anyhoo... not
           topic for now...

   ed: SVG 1.1 doesn't include the stroke and markers in the bounding box.
       That might be important for gradients also.
   TabAtkins: we may have to do some mode switching as you go from CSS to SVG.
   TabAtkins: My plan will be to define how to use SVG paint servers in CSS,
              and draft something for the other way around. We can decide
              where to put the other way around.
   heycam: CSS may have the same issue with calculating bounding boxes
   TabAtkins: yes, it's fairly well defined there. It defines the region of
              the canvas, such as content-box, border-box, etc.
   RESOLVED: Tab to add wording to CSS Image Values 4 about how SVG Paint
             Servers apply to CSS
   RESOLVED: Tab to draft something about how CSS image values apply to
             SVG. This will live in the CSS Image values 4 spec for now
             (it may move later).
   <tantek> dino, TabAtkins, re: 2nd Resolution - suggest making that a
            non-normative section.

   Dino: We had a mailing list discussion about new image generators, kinda
         like your example of ppl using solid color with a slight noise
   Dino: We're sending out massive images right now when we don't need to
   Dino: Add things for noise, checkboard, halo, etc. Not suggesting we add
         all those
   <smfr> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.html
   Cam: How does Compositing work?
   Dino: Becomes difficult in filters spec, bc sometimes you want the
         generated below, and other times above.
   Dino: e.g. ppl do a halo effect where a flash moves across the text.
   Dino: In that case you want it above.
   Dino: Tab said it would be better to allow an image anywhere in CSS
   Dino: e.g. say your background is blue with a faint noise texture above it
   <cabanier> discussion:
              http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0025.html
   Cam: With bg now you can specify multiple things?
   smfr: multiple images, yes
   Dino: So, Tab and I came to an informal agreement that would be a good thing
         to do, but maybe we should have a resolution
   Tab: Things in CSS spec that would move to being image values are :
   Tab: flood ...
   Tab: Unfortunately colors are not image types in CSS. Bg has special case
        of bg-color
   TabAtkins: flood would map to image() (eg. image(blue))
   Tab: But you can't have list-style-image: blue;
   Tab: If we don't get that otherwise, the image() function lets you smuggle
        that in
   TabAtkins: because image() has a fallback for a color
   Tab: Because it allows a fallback color
   TabAtkins: without an intrinsic size
   TabAtkins: turbulence could be an image value
   TabAtkins: the rest are filters so should stay as filters
   dino: I propose asking for examples on the list of generated images.
   RESOLVED: The new image generator methods (eg. turbulence) to be added
             to CSS Image Values 4

   smfr: I am concerned about the syntax overhead of specifying some complex
         filters. eg. a checkerboard has colour, repeat, offset.
   TabAtkins: I agree. We'll have to balance that.
   fantasai: Once SVG Paint Servers are allowed, it may be better to reference
             an library of SVG images as a CSS paint.
   ed: The noise function in SVG is defined in C, but it doesn't scale to
       GPUs very well. I'd like to replace it with simplex noise.
   vhardy: are you suggesting changing the algorithm as is?
   ed: we can't remove what is there
   vhardy: it was hard to get the algorithm right, we shouldn't change it.
   vhardy: so which SVG filter primitives will become paint server?
   TabAtkins: It won't be the full set.
   dino: turbulence/noise is the only new one

Pointer events and alpha-level hit testing
------------------------------------------

   tantek: We have some degree of interop with the pointer-events property.
           Mozilla + IE support it. WebKit supports "none" and "auto" for HTML.
   tantek: so it has been added to CSS 3 UI
   <tantek> https://developer.mozilla.org/en/css/pointer-events
   dbaron: I believe Mozilla support is similar to WebKit - none and auto
           (for HTML content)
   <smfr> http://dev.w3.org/csswg/css3-ui/#pointer-events
   tantek: I've added all the values to CSS (eg. visiblePainted). We need to
           make sure they are compatible with the way SVG defines it.
   smfr: We've had requests to support visiblePainted in HTML for image content.
   ed: SVG does ignore hit tests on fully alpha pixels in an image
   <ed> http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
        (last paragraph, scroll down a bit)
   <ed> "The value visiblePainted means that the raster image can receive
        events anywhere within the bounds of the image if any pixel from
        the raster image which is under the pointer is not fully transparent,
        with the additional requirement that the ‘visibility’ property is
        set to visible."
   dbaron: we need translations of the purely SVG names. define what "stroke"
           means in HTML.
   tantek: I suppose reducing the values now to "auto" and "none", then put
           wording pointing people at a future spec for the other values
           (eg. the SVG ones)
   heycam: would the CSS spec define what shapes, etc are for the SVG case?
           or should that be in the SVG spec?
   tantek: I'll redefine "auto" slightly. It currently references
           visiblePainted, but we're moving that out.
   tantek: I'll normatively reference the SVG spec for SVG content.
   <bradk> shouldn't there be a value for 'pointer-events' to determine
           clickability based on an opacity value?
   heycam: we should define a term in the SVG spec like "hit testable area"
           and have that as a reference target
   tantek: we can do that for a future spec, but we should move forward with
           this now - ie. not wait for a future SVG spec
   vhardy: what do you do for a stylesheet targeting both languages? SVG will
           allow more values.
   tantek: this is an old problem. some specifications allow different values.
   dbaron: i suspect that the current implementations accept all the values
           that SVG supports, and treats the common value the same across
           both languages.
   tantek: then maybe the specification should define "auto" and "none",
           then say that everything else is defined in the host language.
   tantek: this does mean that any new functionality will need new values
   TabAtkins: hopefully people are not using visiblePainted and expecting
              it to behave as "auto".
   TabAtkins: so we might be able to redefine visiblePainted
   TabAtkins: put the values in the spec and say that people should not use
              them outside of SVG.
   TabAtkins gave an example that the scribe missed
   tantek: that example is deprecated values. this is different.
   <vhardy> Example of precedent where SVG only uses a subset of the existing
            value set: http://www.w3.org/TR/SVG/painting.html#DisplayProperty
   szilles: the wording should be "these values only have defined meaning in SVG"
   RESOLVED: List all the current values for pointer events, everything
             other than "none" is treated as "auto" unless applied to SVG
             content
   RESOLVED: Add an author conformance criteria saying that they should
             not use the other values outside of SVG

   <tantek> http://wiki.csswg.org/spec/css3-ui#issue-4
   tantek: Issue 4 is related to the computed value
   <tantek> @namespace svg "http://www.w3.org/2000/svg";
   <tantek> svg|svg { pointer-events: none }
   <tantek> svg|svg>* { pointer-events: visiblePainted }
   heycam: i don't think any content will be relying on seeing a computedStyle
           of 'visiblePainted'.
   heycam: so it would be ok to return 'auto' for SVG content
   tantek: the style rule was an attempt to address the difference in
           implementations.
   ed: I think it would be ok to make SVG content have 'auto' as the initial
       value
   vhardy: If 'auto' is added to CSS3 UI, we'll need to update/add the SVG
           specification.
   heycam: yes
   ACTION: Cameron to update the SVG 2 specification, adding 'auto' the
           pointer-events specification.
   <trackbot> Created ACTION-35
   <ChrisL> which svg specification is that,Cameron?
   <heycam> ChrisL, that'd be SVG 2
   <ChrisL> ok

   <tantek> http://wiki.csswg.org/spec/css3-ui#issue-5
   tantek: moving on to issue 5
   tantek: I believe the style rule I gave above gives the SVG behaviour to
           non-graphical elements.
   discussion about what elements in SVG should get pointer events
   <tantek> svg|svg { pointer-events: visiblePainted }
   dbaron: the SVG element doesn't paint anything, then it should be ok to
           have pointer-events applying to everything
   heycam: also <g>
   heycam: I think it should be auto everywhere
   tantek: SVG doesn't specify 'auto'. we're trying to ship an interoperable
           spec today.
   vhardy: the property value is saying what is generating events, not where
           you can place a listener.
   tantek: are SVG ok with accepting this change?
   Some discussion missed by scribe
   <ChrisL> wasn't it mentioned earlier thatsome html browsers accept
            visiblePainted?
   <ChrisL> if the goal is interop now, that it the most interoperable value
   heycam: SVG2 will be a while coming. We'll change the value there.
   RESOLVED: Drop the SVG UA stylesheet rules. Add a note saying that SVG
             will be adding 'auto' as the default value in a future spec.

   <smfr> http://wiki.csswg.org/spec/css3-ui#issue-6
   tantek: this makes Issue 6 a non-issue now
   sylvaing: Question - is there a restriction on what elements the
             pointer-events apply to?
   tantek: do you have an example in markup?
   sylvaing: we're worried about click hijacking
   heycam: using elementFromPoint
   smfr: This is a valid point to bring up.
   sylvaing: MS is likely to add some restrictions on passing events down to
             iframes, or whatever.
   tantek: doesn't SVG define this with <foreignObject> ?
   shepazu: spec doesn't say anything
   tantek: what about implementations?
   No one responds to suggest that SVG implementations are doing anything
     to avoid click jacking at the moment
   sylvaing: It's likely that we will not propagate an event into an iframe
   tantek: There are two problems: what should implementations do? and now
           what should the specs say?
   <tantek> http://dev.w3.org/csswg/css3-ui/#pointer-events0
   tantek: I think the specification does have enough room to allow
           implementations to not propagate events across origin if necessary.
   tantek reads current CSS 3 UI spec language
   (can someone paste it in or link?)
   dbaron: I think that's more likely a bug in the spec rather than a loose
           reading. It should be defined more precisely.
   anne: agree. elementFromPoint only returns the iframe.

<br/>

   Scribe: vhardy
   ed: Let's continue on the CSS UI issues.
   <tantek> http://dev.w3.org/csswg/css3-ui/#pointer-events0
   tantek: we were discussing the click jacking scenario with
           pointer-events: none.
   tantek: sylvaing has a demo
   tantek: the strawman proposal is to say that the UA must keep track of
           the fact that the event fell through something that had
           'pointer-events: none' and then check for cross-origin.
   dbaron: you have the same issue with opacity.
   dbaron: the better protection is for web site to not allow being framed.
   sylvaing shows a demo where a frame hides Amazon.com and a 'play' button
            passes through and activates an 'add to cart button' without
            the user's knownledge.
   sylvaing: this is not a new issue, but it should be addressed.
   tantek: the spec. as is, nothing says nothing about where the event goes
           if the element does not handle it. It does not require anything
           specific about z-order or children lower in the rendering stack.
   shepazu: I think the spec should be more specific.
   dbaron: pointer-event's intent is to filter the targets of events and
           to let the event target something lower in z order.
   shepazu illustrates the purpose of pointer-events: none.
   anne: even if we want to be vague for cross origin, we need to be
         specific for same origin.
   tantek: there is a missing reference here to the definition of hit testing.
   anne: it should be in the pointer-events specification.
   tantek: I do not agree.
   <dbaron> http://www.webkit.org/specs/PointerEventsProperty.html
   tantek: does HTML5 define hit testing?
   anne: no
   <anne> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
   smfr: I thought it was defined.
   <shepazu> http://www.w3.org/TR/SVG/intro.html#TermHitTesting
   anne: I think we had agreed that the definition of hit testing would be
         in CSS 3 UI.
   <anne> http://people.opera.com/lstorset/TR/pointer-events/ED-pointer-events-20100820.html
   tantek: this is just about the property.
   tantek: there is nothign about geometry, z-index, etc...
   <anne> http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
   <anne> hixie's notes on hit testing ^^
   anne: the first reference I pasted has a portion that needs to be part
         of the spec.
   shepazu: The SVG 1.1 2nd edition has a definition of hit testing, which
            is new to SVG (was not in previous version).
   anne: this was never in HTML5.
   anne: this should be in CSS.
   tantek: or DOM Events?
   several: CSS.
   shepazu: should be in CSS.
   tantek: should be split in CSS (geometry and opacity aspects) and then
           the definition of events should be in DOM Events.
   anne: sure.
   tantek: this is essentially what Hixie's note is doing.
   smfr: hit testing is the reverse of painting (order-wise). Where we talk
         about painting order, we could talk about hit testing.
   tantek: Hixie's note talks about painting order too.
   tantek: are you saying that Hixie's note should be integrated in the spec.?
   anne: yes.
   tantek: hit testing should be defined in CSS, in CSS UI.
   anne: pointer-events is just about hit testing.
   (discussion about Hixie's proposal and comments that were made).
   shepazu: also needs to take into account SVG for hit-testing, so that the
            definition is not just HTML.
   dbaron: it is the opposite of z-order, so it should be fairly easy.
   tantek: there are only a few exception cases with elements like body, but
           the rest should apply for SVG.
   shepazu: we should coordinate on this.
   tantek: z-index and z-order should be in one place and hit testing should
           reference that.
   heycam: there are some SVG specificities that are different from HTML.
   <ChrisL> svg has a painting order, which is also relevant (as z-index is
            for html/css)
   anne: it would be nice if the hit testing algorithm was generic, with
         possible arguments (like 'stop at the iframe')
   shepazu: I think we need to do some more work and re-coordinate on this later.
   <smfr> http://lists.w3.org/Archives/Public/www-style/2010Aug/0407.html
   ACTION: Tantek to integrate Hixie's proposal on hit testing and define
           hit-testing in CSS 3 UI and coordinate with Doug for harmonizing
           with SVG.
   <trackbot> Created ACTION-36
   RESOLVED: tantek to integrate Hixie's proposal on hit testing and define
             hit-testing in CSS 3 UI and coordinate with Doug for harmonizing
             with SVG.

   tantek: this was the issue of security, partially. What do we need to say
           about the scenario sylvaing presented.
   shepazu: I liked the proposal with a dirty flag for something that passed
            through because of pointer-events: none and then not propagate
            to cross-origin.
   tantek: the alternate proposal is to make a note that sites that do not
            want to have this happen should not allow being framed.
   dbaron: we should also talk to some people in the web security field.
   dbaron: some people at Mozilla would know about this.
   ACTION: shepazu and dbaron to reach out to web security experts and get
           an opinion on whether or not we should address security concerns
           on the hit testing algorithm. Coordinate with Tantek for the
           CSS 3 UI spec.
   <trackbot> Created ACTION-37
   ed: is there anything more that we need to discuss here?

   shepazu: want to talk about transparency.
   shepazu: proposal for alpha-levels.
   shepazu: this came up from Zynga.
   shepazu: they do most of their HTML5 games with PNGs that have transparency
             and they need to do their own hit testing on the PNGs.
   shepazu: they would like to say that if a pixel has a certain level of
            transparency, then the hit testing is not positive.
   shepazu: if opacity is less than x, then pass the even through
   tantek: do they want the hit testing mask?
   shepazu: they do not want to do their own hit testing.
   tantek: there are cases where there is a hole and you still want to hit
           positive for the hole.
   smfr: I have not heard Zynga asking for a separate image.
   tantek: where the opacity may address some of the use cases, it seems that
           a separate mask would cover more use cases.
   vhardy: and the image's opacity could be the default mask.
   tantek: yes.
   shepazu: this also solves some issues for SVG.
   shepazu: this is an issue we need to look into.
   smfr: it is not obvious that this needs to go into pointer-events.
   shepazu: right.
   shepazu: Paul Bakaus for Zynga mentioned he would rather not maintain
            two images.
   smfr: I think the threshold for pointer-events is simple enough that we
         could put it into pointer-events.
   ..  a separate image is more complex and should be separate.
   heycam: with filters, we started to talk about pointer-events issues.
           It would be nice if we could resolve all these problems with a
           single solution.
   <tantek> Hixie's notes http://lists.w3.org/Archives/Public/www-style/2009Feb/0287.html
            refer to full transparency as allowing events to pass through
   tantek: currently, in Hixie's proposal, only 100% translucent pixels let
          the event go through.
   <dino> We are talking about adding a threshold instead.
   <tantek> so we're talking about increasing that threshold from opacity:0
            to opacity:x where 0≤x≤1
   dino: sometimes, you want the hit testing area to be larger than the
         element itself.
   tab: sometimes, you want the letters to be selected to have a larger
        selection area. It would be easier if there were hit testing controls.
   shepazu: Alex Danilo said this is too difficult to implement because you
            might have to get the graphics back from the GPU.
   szilles: so you may have to precompute things.
   tantek: the mask solves that problem.
   vhardy: having a mask, isn't that equivalent to just having the texture
           around?
   vhardy: if you're keeping some data for hit testing, that's the same as
           keeping on the gpu and in memory
   smfr: i think it might be expensive at run time
   smfr: doable, but it may be slow
   tantek: if you go back to Paul's usecase, he is keeping his own mask in JS.
   tantek: that means the shapes are their masks.
   tantek: so they have implemented masks as a work around. We could provide
           masks to resolve their issue.
   <shepazu> Alex's critique:
             http://lists.w3.org/Archives/Public/www-svg/2011Apr/0052.html
   <shepazu> Paul's email
             http://lists.w3.org/Archives/Public/www-svg/2011Apr/0050.html
   heycam: the email does not hint at their implementation method.
   shepazu: quoting the email..
   heycam: it seems to be a good shorthand.
   tantek: if doing things in canvas and JS works, then shouldn't it be
           feasible in implementations?
   tab/shepazu: the point Alex Danillo made is valid.
   <ChrisL> there are some video codecs on gpu like for mpeg etc. those
            might be usable for jpeg decoding
   <ChrisL> but in general the bandwidth of the back channel from gpu to cpu
            is not very good
   smfr: if you have filters that are implemented on the GPU, then you need
         to do read-back from the GPU and that is expensive.
   tab: box shadows do not impact hit testing.
   tab: round-borders affect hit testing.
   tab: border-image does not affect hit testing.
   <ChrisL> bordser is a classic case for needing more values like visibleBorder
           for hit testing
   tab: I would be ok to say that things may slow down if you do hit testing
        on a filtered image, for example.
   discussion on various filter effects that may affect hit testing.
   dino: we all realize that a threshold is not enough because we need a mask
         image in many cases. Can it be integrated with the pointer-events
         property.?
   tantek: we are talking about CSS UI 4 right?
   several: yes.
   shepazu: I think the threshold is enough for most cases.
   smfr: the GPU efficiency is an issue to consider.
   tantek: I would like to add this to CSS UI 4.
   <dino> ACTION: Dean to draft a proposal for specifying hit testing regions
          or masks for CSS 4 UI
   <trackbot> Created ACTION-38
   ACTION: tantek to specify how opacity:0 impact hit testing.
   <bradk> opacity:0.001 should not be different from opacity:0 WRT hit testing
   <tantek> Issue 9: http://wiki.csswg.org/spec/css3-ui#issue-9
   <smfr> bradk: opacity already has discontinuitues: 0.9999 creates stacking
          context, 1 does not
   <ChrisL> bradk, hit testing is like pregnancy. it is on/off not a sliding
            scale
   ACTION: Doug to propose that opacity of a pixel does not affect its
           pointer-event behavior for CSS 3 UI.
   <trackbot> Created ACTION-39
   ACTION-39: http://wiki.csswg.org/spec/css3-ui#issue-9
   ACTION: shepazu to write up proposal for opacity threshold for pointer-events
           for CSS 4 UI
   <trackbot> Created ACTION-40

   tantek: http://wiki.csswg.org/spec/css3-ui#issue-10
   tantek: I think we are ducking this.
   ed: the issue was mostly for SVG.
   (discussion on filter effects and masks applying to HTML in SVG, through
    foreignObject)
   heycam: we would need to say that the mask actually impact hit testing.
   heycam: and clip-path as well.
   vhardy: this should go into the hit testing section.
   <tantek> https://developer.mozilla.org/en/CSS/clip-path
   <tantek> https://developer.mozilla.org/en/CSS/mask
   ACTION: Doug to propose wording for CSS 3 UI about how masks and clip-paths
           impact hit-testing.
   <trackbot> Created ACTION-41

   <tantek> https://developer.mozilla.org/en/CSS/-webkit-mask-box-image
   <shepazu> http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.html
   <birtles> https://developer.mozilla.org/En/Applying_SVG_effects_to_HTML_content
   tantek: we need a definition of these properties in a CSS spec.
   ed; we could put clipping and masking in the FXTF filter spec.
   <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
   * Ms2ger wonders why that doc links to a 2008 HTML5 draft
   ACTION: ed to move clip-path and masks to the FX Filter specification draft.
   <trackbot> Created ACTION-42
   <ed> ms2ger references will need to be updated there yes

   tantek: I have no more issue on CSS 3 UI that requires CSS/SVG coordination.
           I have gone through the issues I had.

Filter Effects
--------------

   <dino> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FilterEffects
   dino: we have a lot of issues.
   dino: first issue is to come up with a name other than SVG filters.
   dino: there are pure css filters and then markup filters.
   chris: advanced filers? markup filters?
   dino: the whole spec. is CSS, there is a part that uses markup for advanced
         filters.
   (discussion on 'advanced filters' v.s. 'markup filters')
   shepazu: I think markup filters is better
   smfr: declarative filters?
   <ChrisL> the filters previously known as SVG
   <ChrisL> custom filters
   dino: shorthand syntax and long-hand syntax?
   tantek: is this a CSS module?
   <ChrisL> its a jointly developed module
   dino: not currently. But it should be?
   dino: it should just be "Filters"
   tantek: I think we should call them 'CSS 3 Filters'
   fantasai: "CSS Filters", it's not level 3
   <ChrisL> can we please drop the 'levels' stuff
   shepazu: the spec. defines markup for filters.
   fantasai: if it's generic, we should call them "W3C filters", like
             W3C Selectors
   chrisL: agreed.
   <Ms2ger> HTML5 Filters?
   shepazu: markup filters is the most descriptive.
   <fantasai> XFilters :)
   <ChrisL> people are gradually being used to pointing to other media from css.
            images, svg, etc
   dino: the options we have heard:
   ... element based filters
   ... shorhand/longhand filters
   ... markup filters
   ... XML Filters
   <ChrisL> w3c filters
   ... W3C Filters
   ... XFilters
   <ChrisL> shorthand has an existing meaning in css, be careful to avoid
            confusion there
   <ChrisL> extensible filters
   <ChrisL> custom filters
   <ed> canned filters
   ACTION: dean to make a naming proposal to distinguish between CSS and
           markup filters.
   <trackbot> Created ACTION-43

   dino: next issue is to have a custom filter using a particular language.
   <smfr> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html
   <ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#feCustomElement
   patrickdengler: there are lots of issues with custom filters (security).
                   In IE, we did not see any use of the custom filters we
                   provided.
   dino: what are the pros and cons?
   ... cons: security, not used often.
   ... Adobe has a public repository of pixel bender filters and there are
       20+ filters there.
   ... pros: it is great for us as spec. developers because we do not have
             to define every effect.
   ... cons: we need to define a filter.
   dino: sometimes, people also want to protect their shader code.
   <ed> patrick: inkscape has hundreds of defined filter effects that only use
                 the existing svg filter functionality
   <ChrisL> orcuda
   dino: on the language approach, if we accept WebGL, there is a shading
         language specified there. GLSL is not always the right solution.
         HLSL is not either. Sometimes, solutions like pixel bender or
         Core Image filters are better. I think Silverlight has something
         similar to HLSL.
   dino: seems like there is a lot of cons.
   <smfr> ChrisL: or CUDA?
   vhardy: i think there are very nice effects that would could have with
           custom fitlers. We can come back later with more arguments.
   chrisl: if there was a DOM interface for custom filters, that may be easier.
   dino: one use case where Apple uses a custom filter is for video output to
         TV, or custom color correction.
   heycam: if we had custom filters, what if you do not have hardware accel.
   vhardy: then there is a software path.
   ACTION: vhardy to come back with more arguments on custom filters and
           make a proposal.

   dino: next is pointer-events on filter regions.
   <ed> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0109.html
   ed: we found that having filters impact hit testing is costly.
   smfr: and there are cases like blur where the hit becomes an area.
   dino: is that like shadows? Or should we deal with it with masking as well?
   vhardy: in svg if you have text on a path, with hit testing and text
           selection, that kind of "distortion" works
   vhardy: it doesn't if you go through a filter pipeline, pixels gets
           shifted around
   ... you're still operating on the original geometry you had
   dino: you want 2 things. one is controlling whether hit testing happens
         on the output, and possibly something about whether you should map
         back to the input pixel from the output pixel
   fantasai: how would you determine that for a blur?
   dino: there are multiple pixels
   vhardy: it's not a 1-to-1 mapping
   ChrisL: if you have a filter that displaces things, or if the visual
           result is quite different from the original, ...
   fantasai: why not use transforms for shifting content?
   vhardy: with filters you could use your source multiple times
   dino: I think there's a difference between hit testing, have I clicked
         on this element, and text selection, which is where you need to
         select a character
   dino: the text might be in a different spot
   vhardy: if you use SourceGraphic and feOffset, you could have a rectangle
           and make it a grid of four rectangles and that's the visual rendering
   fantasai: in that case, it would be most natural to say if you click
             anything in there it hits positive
   fantasai: if you want to multiply images, then that's different from just
             mirroring
   fantasai: nobody expects to click on a reflection of an icon and have that
             hit test
   fantasai: if you want something that's actually solid, there should be some
             other way of doing it that affects layout
   shepazu: you should use a mask in this case
   shepazu: nobody's asked for this either
   fantasai: I think we haven't seen convincing use cases
   dino: if we have the mask image proposal, you would point to the filter
         image as the mask
   vhardy: I think that covers most of what we need
   vhardy: but I think still conceptually this is an important issue
   ed: raise an issue for this?
   <ed> I raised ISSUE-5 for the hit-testing
   <ed> http://www.w3.org/Graphics/fx/track/issues/5

   dino: next one is enable-background.
   dino: there is a general proposal to deprecate it.
   proposal at: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/FilterEffects
   cabanier: enable-background is defined for SVG and not for HTML. We need
             to define what that does for CSS/HTML.
   <ChrisL> adobe used to implement it
   dino: who implements enable-background.
   <ChrisL> but it seems under-implemented in current svg implementations
   <vhardy> Opera, Batik, Illustrator, Inkscape?
   <ChrisL> it would be good if adobe illustrator stopped writing it needlessly
            on svg exports
   ed: lunch break.

<br type="lunch"/>
Received on Saturday, 6 August 2011 00:35:17 GMT

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