- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 11 May 2011 15:02:49 -0700
- To: David Dailey <ddailey@zoominternet.net>
- Cc: Rik Cabanier <cabanier@gmail.com>, Dean Jackson <dino@apple.com>, Chris Lilley <chris@w3.org>, Erik Dahlstrom <ed@opera.com>, public-fx@w3.org, www-svg <www-svg@w3.org>
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:11:25 UTC