- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 9 May 2011 10:48:43 -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: <BANLkTikTg2j+tuR+LWeOWYL32R4=RcOZeQ@mail.gmail.com>
On Fri, May 6, 2011 at 5:54 PM, Dean Jackson <dino@apple.com> wrote: > From now on I'm going to use the term Markup filters rather than SVG > filters. > > On 07/05/2011, at 10:38 AM, Rik Cabanier wrote: > > 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. > > I don't think we plan any at the moment. What we call CSS filters is simply > an extension to the existing "filter" property that allows some effects > using keywords. > > I would hesitate to add anything to CSS that could not be replicated in > markup. As I said, if we come up with new effects then they should be added > in both places. eg. filter: awesomeeffect(10) and <feAwesomeEffect>. > > I was thinking more along the line of HTML vs SVG. For instance, SVG has <g> that is used for grouping but there is no such thing in HTML (almost everything could be a group in that world). At some point we will have to create a similar grouping concept in HTML. I know there's already implied grouping when you use transforms or animations, but I'm unsure if this is already formalized. > - 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) > > > I don't mind if the group wants to remove some unused/unnecessary/difficult > features from markup - such as enable-background. All I suggest is that we > do it in a staged fashion, where they are first labelled as deprecated. But > if people feel strongly that they should be removed immediately, I'll accept > that too. > > 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 > > I think all existing markup filters should remain and be available to all > content via the filter property. > There was a discussion between you and Tab Atkins about this under the title 'generators in filters'. I thought the consensus was to move these to the image values module. Are you suggesting instead that they are available in images values and filters? - mark the feComposite filter as only applying to SVG. A future CSS/SVG > compositing spec can address this better. > > > Again, I think if you have a <div> with a filter property of > "url('filterlibrary.html#whatever')", then the whatever filter can use all > the existing markup filter effects, including feComposite. Note that > feComposite only describes the compositing within the filter chain - it > doesn't affect the result of the filter composited into the document. That's > where the new compositing spec comes in. > After reading a bit more on this filter, I agree. > > Dean > > > 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 Monday, 9 May 2011 17:49:12 UTC