Friday 20 February 2009
Filters, Libraries And The Web
Daniel Glazman writes, somewhat in passing:
We can now apply SVG filters to all content, including HTML 4, in Firefox but I have mixed feelings about the fact you have to know HTML, CSS and SVG to apply such a filter. Seems to me overkill, and too far away from the original spirit of the Web.
He didn't enable comments on that post, so I'll reply here: you don't need to know SVG to use filters. You can just paste filter code from a cookbook into an XML file --- or use an XML file from a library --- and refer to that file from your CSS and HTML. This is not only easy and reasonable; SVG filters provide a rich vocabulary of composable operators, so they're much more flexible and powerful than providing ten canned filter keywords to handle all the author needs that the CSS WG can think of.
You could perhaps reinvent SVG filters with CSS syntax, but I don't see that as a real win for author understanding.
Generally in computer science we prefer to create a set of composable primitives with clean semantics, on top of which libraries are built to make frequent tasks easy, over trying to anticipate every possible need and encoding a feature for each one. Unfortunately CSS has often taken the latter course ... partly because the Web's mechanisms for code reuse are weak. But external document references give us a reuse mechanism that makes using a library of SVG effects quite convenient, IMHO.
Comments
Oh the irony if it does, since svg filters don't work in a data: uri of an svg directly.
Could I tie this together with Thunderhead?
It would be ideal if browsers allowed us to create custom markup+CSS that would be interpreted/executed by javascript+canvas (or whatever) and that we could redistribute as standard libraries.
There are various impediments to doing this right now. (For example, Firefox drops unknown CSS declarations.)
Do you think it will ever be possible to have a graph.js library that would let you do something like this?:
<style>lineplot { line: dotted; }</style>
<script src="graph1.1.js"></script>
<graph><lineplot data="0 0; 1 3; 2 2"/></graph>
His thought is very common among developers but it's something that I really don't understand.
Why do they think it would be simpler to learn a brand new syntax in CSS instead of learning SVG ?
People always argue CSS is designed to be simple. I really think CSS is NOT simple anymore. Since CSS2, I always have to do lots of trials/errors to achieve what I want (especially for layouts).
Is it the xml syntax that scares people ?
I have mixed feelings about bloating the CSS spec. It's becoming monstruous. Developers will have to know new transforms and transitions syntaxes in addition of the already existing and powerful ones (svg filters and smil). Do we really want to reinvent the wheel all the time ?
>it would be ideal if browsers allowed us to create custom markup+CSS that would be interpreted/executed by javascript+canvas (or whatever) and that we could redistribute as standard libraries.
This is exactly you can do with XBL. With XBL, you can create your own markup which have their own content, their own styles (CSS) their own behaviors (js) etc..
http://www.w3.org/TR/xbl/
I was playing with this the other day. Do external references allow any access to the external document. Can you apply a filter and then modify it to animate the filter (say to fade from black and white to color), or does that require that the filter be included in your document?