- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 19 Feb 2014 16:20:54 -0800
- To: "www-style@w3.org" <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>, www-svg <www-svg@w3.org>
Custom Filters
--------------
RESOLVED: take custom shaders out in a week, unless somebody objects
before that.
SVG Hover Effects
-----------------
CSSWG and SVGWG discussed translating some common hover effects from
CSS to SVG, and the problems thereof.
====== Full minutes below ======
Custom filters removed?
-----------------------
krit: Agenda request: filter effects and custom filters.
<krit> http://dev.w3.org/fxtf/filters/
krit: We had to limit them already because of security.
krit: And they don't have the expected power.
krit: Current impls have problems with them.
krit: Especially with combined custom and standard filters.
krit: (Not all impls.)
krit: We still believe in filter effects, but custom filters isn't
the right solution.
Simon: We removed them in webkit, so support the removal.
krit: New feature would not use shaders.
ChrisL: Seems slightly sad since Microsoft added webGL support.
ChrisL: But if two impls removed them already...
krit: No impls currently remaining.
Rossen: What was this again?
krit: Pixel manipulation with WebGL
heycam: Plan for replacement?
krit: Looking for more use cases, providing hit testing effects.
krit: Hit testing was a problem with current solution.
heycam: So no future for generic shader-like thing?
krit: Many users were relying on pixel shaders, but they were security
threat, so we had to limit them already.
krit: Couldn't actually look at color value.
krit: We want to come up with a proposal, and want feedback.
krit: More focus on use case of CSS.
heycam: A bit afraid to get a 100 different canned effects...
florian: What is the proposal?
krit: Not in presentable shape yet.
Rossen: Can we remove after seeing the new proposal?
sgalineau: But it is holding up the spec.
ChrisL: Are you asking to defer removal a bit?
sgalineau: The feature will go away, so what do we get by keeping it
in a bit longer?
krit: I'm more focusing on SVG filters at the moment, and bringing
that to LC.
<sgalineau> the feature would end up at risk so not sure what the value
of keeping it around
plinss: So take out? move to future level?
krit: Other impls might take it up again.
Rossen: Like to defer decision by a week.
krit: OK with me.
sgalineau: What do we get in a week?
RESOLVED: take custom shaders out in a week, unless somebody objects
before that.
Hover Effects in SVG
--------------------
Topic: backgrounds and colors and outlines in SVG
shepazu: Sometimes want to use outlines and colors, e.g., on hover.
shepazu: SVG doesn't have on-hover effect on it sown.
shepazu: Have to find the bounding box yourself.
shepazu: These effects do no affect flow.
krit: :hover is supported.
ChrisL: What spec?
krit: it is automatic.
shepazu: Is this a terrible idea?
shepazu: Would we allow whole background thing, or just color?
shepazu: Fill area would be bounding box of element.
shepazu: Use case is hover.
krit: Why not add an element behind it?
shepazu: Kind of a pain. I've done it.
shepazu: Keep track of transforms, etc, yourself.
shepazu: It is not perfect, but it is a start.
shepazu: Could add stroke effects to the outline also, vector effects.
shepazu: But simple thing now, and rest for future.
heycam: [showing something]
heycam: Approaches in the past included filters, and filling bounding
box with color. Bit of a hack.
shepazu: I prefer "on hover, background = white"
krit: Sceptical about background. Don't see use case.
krit: Don't think this is what you really want to have.
krit: Consider a complex shape, rectangle behind it is not what you want.
smfr: repeated images with fill?
krit: Yes, just decided today :-)
shepazu: I suggested things that don't change reflow.
[discussion of what it should look like for different shapes]
shepazu: SVG often used for icons.
krit: Icons don't have hover.
simonf: Often element behind the icon has the hover.
krit: Outline for accessibility.
shepazu: I'd like to find out the concerns of the CSS WG with this.
[CSS WG has no opinion]
ChrisL: More consensus on outline than on backgrounds.
florian: CSS doesn't have definition of where outline goes, does it?
dbaron: Correct. I have thought about it, but not finished.
florian: I remember something about 3d transforms making outline harder.
krit: Outline gets smaller when object is smaller because of clip path,
but we decided recently that outline should actually be clipped.
<ed> svg tiny 1.2 has viewport-fill and viewport-fill-opacity properties
that are similar to what shepazu is asking for with bg, though
more limited in which elements they apply to
heycam: Does CSS define outline is outside the box?
dbaron: We have or had an outline-offset.
florian: I think we have neither a definition nor interop.
leif: Significant latitude for impls.
ChrisL: That was certainly so with the orig definition.
leif: Not even defined if it is on top of everything, or only on top
of the element
leif: But outline-offset is not problematic, but don't know about interop.
Meeting closed.
<RRSAgent> http://www.w3.org/2014/01/30-css-minutes.html
Received on Thursday, 20 February 2014 00:21:23 UTC