- 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:36 UTC