Re: Filters spec: CSS vs SVG

On Tue, May 10, 2011 at 6:30 PM, David Dailey <ddailey@zoominternet.net> wrote:
> 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.)

Yup, just use a color instead.  (Or, if Filters absolutely require an
image, you can use the image() function, like "image(blue)", to
generate an image of the appropriate color, but I want to avoid that
actually being necessary wherever possible.)


> 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.

The CSSOM is really sucky, in general.  Efforts are being made to fix
it, but in general this hasn't been a huge priority, and so not much
work has been done on it.  For the most part, the CSSOM is similar to
if the HTML DOM only exposed .nextSibling, .children, and .innerHTML.

However, the underlying concepts in CSS, which should be exposed by
the CSSOM when someone cares enough to specify it (which I'd like to
at some point, though I've got too much on my plate now), are similar
to what SVG has, except somewhat more unified.  CSS has paint servers
(anything defined as part of the <image> type), and these paint
servers may be constructed from other paint servers.  The Image Values
spec already defines two composite paint servers, the image()
function* and the cross-fade() function**, and the Filters spec should
define a bunch more.  (Though, looking at the Filter Effects spec, it
appears to be taking a slightly different tack.  Hm.)

SVG happens to split this up a slightly different way.  It has paint
servers (colors, <pattern>, <linearGradient> and <radialGradient>),
and then filter effects are a separate type of thing.  A few "base"
filter effects act very similar to paint servers (<feImage>,
<feFlood>, <feTurbulence>), and the rest are composites of other
filters.

The difference seems mainly to originate from the fact that SVG draws
a distinction between paint servers, images, and filters.  Filters
naturally take as input the element they're applied to, but you can
pull in other images with <feImage>, though to pull in paint servers
you have to first create an image that uses the paint server and then
pull that in with <feImage>.  Filters are not, themselves, paint
servers, they just alter the rendering of the element they're applied
to.  In CSS, on the other hand, everything is an image.  Paint servers
are images, composites are images, and filters are/should be images as
well.


> 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?

CSS the language is expected to continue to grow in features for some
time.  CSS the syntax has been stable for a long time (though I'm
proposing a few features that slightly violate the core syntax, though
in a way that fails gracefully).  The CSSOM hopefully won't stabilize
anytime soon, because there's a lot of work to be done on it.


> 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.

Right, CSS is a layout/styling language concerned only with
presentation, not semantics.  In CSS we don't need to care about the
meaning of what we're manipulating, because you shouldn't ever be
creating meaningful content with CSS (meaningful content should always
live in the source language).

~TJ

* The image() function is a filter-like paint server because of the
directionality argument.  It can represent either the input image or
an inline-flipped version of it.

** The cross-fade() function is defined so you can represent image
transitions.  It ramps the opacity of the two source images
appropriately, and then composites them with 'plus'.

Received on Wednesday, 11 May 2011 23:14:47 UTC