RE: Filters spec: CSS vs SVG

Tab wrote (about feDisplacement):

"This is similar to how <feImage> will remain in the SVG syntax to pull
images into the filter pipeline, but the corresponding concept in the
CSS syntax is just the url() function."

<feFlood> would presumably be in this same category, I suppose. (Just checking to see if I get the idea.)

I'm confused about filter pipelines in CSS. My concept of filter pipelines is very DOM-ish, so I'm having a hard idea of visualizing the flow chart of a complex graph of filters being implemented without DOM. The mathematics of filters is graph theoretic, and CSS seems adverbial rather than sentential.

When one uses <script> or <replicate> to dynamically modify attributes of filters, I have generally found the CSS DOM far more unwieldy to traverse, find, modify and pluck than the SVG DOM.

If one has a graph-like object (I suppose it is actually a poset) of filter-like things, implemented in CSS and one wants to fiddle with things (adjectives associated with nouns nested in a phrase-structure and case-inflected grammar, e.g. <filter>) using script, are the techniques for doing this straightforward? I ask since I don't know.

But then there has always been in my mind an idea that the CSS tree is less consistent across browsers and less mature than SVG DOM. I hear folks fuss about SVG DOM, but at least it is relatively consistent across browsers and that is something I've never witnessed with any of the continually morphing manifestations of CSS. Is there a belief that CSS will stabilize?

The topic borders on some fairly fundamental issues of SVG semantics, I think: in geometry, how to separate presentation from semantics? Consider the two halves of the pseudo-glyph 5 in the HTML5 logo. The semantics *is* a 5, but what form of presentation language would style it into four differently colored paths? That would require, I think, a more powerful theory of presentation than the fun thing known as CSS was intended to be. Separating the x,y coordinates from everything else, would be an obvious course of action, but then what of feDisplacement or transform which serve as modifiers. If we are to extend <animate> so that <animateModifier> (by extension from <replicateModifier>) will be able to go and morph the modifiers of objects: the gradients, the filters, the transforms, the patterns, and the masks , then thinking of geometry as somehow distinguishable from presentation seems to me to be of limited utility. Texture is just as tactile as shape if we render our shapes in another modality.


Regards
David

Received on Wednesday, 11 May 2011 01:30:58 UTC