- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 05 Aug 2011 17:34:46 -0700
- 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 UTC