- From: Rik Cabanier <cabanier@gmail.com>
- Date: Fri, 6 May 2011 17:38:36 -0700
- To: Dean Jackson <dino@apple.com>
- Cc: Chris Lilley <chris@w3.org>, Erik Dahlstrom <ed@opera.com>, public-fx@w3.org, www-svg <www-svg@w3.org>
- Message-ID: <BANLkTi=g0BxpcnFk1oCo1fKS8SUuGrpr8Q@mail.gmail.com>
Thanks for the clarification Dean! In summary: - we will have 1 spec for both SVG and CSS - CSS might have features that don't apply to SVG. The spec needs to call this out. - Likewise SVG might have features that don't apply to CSS. - We should NOT remove existing SVG features (unless everyone agrees that they aren't necessary and are unused) With this in mind, I'll reword my original list: - remove section 6, the filter effects region - mark backgound-image and background-alpha as applying only to SVG content. Revisit when CSS compositing is defined. - mark section on the enable-background keyword as applying only to SVG content. Revisit when CSS compositing is defined. - change default behavior of an unknown filter to 'ignore' instead of the 'null filter' - remove filters that create an image and move them to the image-values spec (ie feTurbulence) for CSS. Leave SVG behavior intact - mark the feComposite filter as only applying to SVG. A future CSS/SVG compositing spec can address this better. On Fri, May 6, 2011 at 12:12 PM, Dean Jackson <dino@apple.com> wrote: > > On 06/05/2011, at 8:15 AM, Rik Cabanier wrote: > > Hi Chris, > > these were just the changes that have been discussed on the FX mailing > list. > In the start of this thread, I said that I wasn't aware that this was > intended to be a replacement for SVG filters. > > I personally don't think that this should be the case and I'm fairly sure > that Dean didn't intend this either. > > > My understanding was, and still is, that the Filters specification is > supposed to cover both the SVG and CSS use cases - ie. it is a replacement > for the SVG filters module. > > The CSS parts were intended to be additions that could be described in SVG. > Whether or not an implementation actually uses SVG filters is a detail left > up to them. Also, the CSS part was intended to be less powerful than SVG > filters - that's where the "dropping" of features comes from. They are just > not available in CSS, giving the implementation the option to never > implement them. > > It did get slightly confusing when the suggestion to drop enable-background > from SVG filters came up. It seems most implementors are happy with this. My > comment was that it was fine to remove it, but since there is content out > there that uses it (eg. Adobe Illustrator output) then we probably should > mark it as deprecated for a while before complete removal. > > Enable-background is important for the SVG compositing spec. Unless we want to simplify SVG blending (which I'm not opposed to), it is necessary. > The CSS filter spec just took the general approach of the SVG filter > specfor simplicity. If possible, we should not change behavior of > overlapping functionality but it should be OK to remove or add keywords. > > > At the moment I don't think there is anything in the CSS part that requires > a change in the SVG part. At least nothing that implies removal of SVG > features. > > I expect in the future we'll be tempted to add more effects - these should > be added to both CSS and SVG. If an effect is not appropriate in CSS, it's > ok for it to be SVG-only. SVG is always the way to do the more complex > effects. > > [Aside: If we start thinking of this spec as CSS vs Markup filters, rather > than CSS vs SVG, it might be helpful. There is only a little bit of actual > SVG in Filters] > Can you elaborate on what you mean with 'CSS vs Markup'? > > Dean > > > For now, the filter spec is supposed to be as simple as possible both for > implementors and web designers. > This means: > - easy syntax for basic filters. More complicated filters can be done using > a subset of SVG filter. The reason for their use is that they were already > well defined. > - no access to the background or blending for ease of implementation > - no enable-background. This concept does not exist in the HTML. > - no section support. HTML generally is not a fixed layout so 'sections' > don't make much sense. > > I agree that IF this is a replacemet spec, we need to thread more > lightly... > > Rik > > On Thu, May 5, 2011 at 5:01 AM, Chris Lilley <chris@w3.org> wrote: > >> On Wednesday, May 4, 2011, 11:29:45 PM, Rik wrote: >> >> RC> Thank Erik!I didn't know that this was a replacement for the current >> spec. >> >> RC> So far, I think these are the following proposed changes: >> RC> - remove section 6, the filter effects region >> RC> - remove backgound-image and background-alpha >> RC> - remove section on the enable-background keyword >> RC> - change default behavior of an unknown filter to 'ignore' instead of >> the 'null filter' >> RC> - remove filters that create an image and move them to the >> RC> image-values spec (ie feTurbulence) >> RC> - remove the feComposite filter and replace with the CSS/SVG >> compositing spec >> >> Given that your first sentence quoted above makes clear that you >> understand that this is a replacement spec that covers both HTML/CSS as well >> as SVG (and SVG/CSS) usage - please provide an analysis of the impact of >> such *radical* changes to existing on existing uses of SVG filters. >> >> > >
Received on Saturday, 7 May 2011 00:39:05 UTC