Re: agenda+ SVG 2 Features and Approach

On 5/8/2011 1:09 PM, Doug Schepers wrote:
> Hi, folks-
>
> I have a few more personal thoughts on features for SVG 2; these 
> aren't necessarily the views of the SVG WG.
>
> I believe that the next 2 years are going to be a make-or-break period 
> for SVG.  It's never been easier to use SVG on the open Web, now that 
> all the major browsers support it (though, as with HTML, there are 
> quirks between implementations).  There is a lot of increased use and 
> interest in SVG, but we still aren't seeing dramatic widespread use of 
> SVG.
Backward compatibility is a big issue here. Several times I've tried to 
wade into SVG, only
to find poor UA support. That has certainly changed, drastically, in the 
last 6 months.
But that's the last 6 months. A short span of time.

SVG is a very large spec, very difficult to implement. Far more complex 
than HTML+CSS2.
So, I certainly don't hold it against UAs that it's taken them this long 
to make near-complete
implementations.

I disagree, that this is a make-or-break period. SVG has already made it.

Over the next two years, we will, finally, see more web apps using SVG.
That's going to happen.

> Part of this is probably that there are now more alternatives, like 
> the Canvas API, the 3D stuff, and some new CSS features (some borrowed 
> from SVG, but put in a context more people are familiar with); another 
> part is lack of great tooling for dynamic, interactive SVG; another 
> part is general lack of knowledge about SVG; but part of it might be 
> that SVG just hasn't hit the sweet spot in terms of features that 
> people need to solve their specific problems, and which can't be 
> solved using other technologies.
Normalized SVG paths have hit the sweet spot; it's unfortunate that the 
Canvas API does not exploit them.

I've been investigating normalized svg paths as a means of sharing area 
map data with ATs;
so that they can "see" clickable shapes in my canvas shadow tree.

Many of the CSS features borrowed from SVG are a positive sign, of 
better integration between the CSS box model
and the SVG model. I personally think that normalized SVG paths could be 
integrated into CSS as well, but that's another topic.

The two areas most-lacking in SVG, the two reasons why I continue to use 
a canvas back-end, when an SVG backend may be available,
are bitmap accumulation and n-dimensional trace groups.

SVG DOM simply gets very bloated, when either are used. I end up with a 
10 second draw time on the iPhone instead of under-a-second
with canvas. Think of how you might serialize pressure sensitive pen 
data in SVG. It's rough.

That said, I am serializing my data into SVG+InkML+WebGL [filters] as a 
first stab at a workable format.

On 3d: WebGL + SVG gets me the same level of support for filtering 
images as I get
with Canvas 2d ImageData. Added benefit: I don't have to worry about 
cross domain issues,
as I'm never given access to the underlying data.

When the SVG implementation on the UA isn't so hot, I can fallback to an 
SVG implementation
written in ECMAScript using the Canvas API. Can and do.

In response to your gloomy gloomy message: I respectfully disagree.
SVG continues to benefit from Canvas, 3d and CSS APIs; it benefits
from greater integration with the larger engineering ecosystem.

If you're looking to make my life a little easier, I would like
SVG2 to address some of the reasons why I've had to fall back to the
canvas tag. It'd be swell to use SVG2 + webgl filters without needing the
extra step of having a canvas tag. And it'd be fantastic if SVG could 
reasonably
be used to display InkML trace groups.


-Charles

Received on Sunday, 8 May 2011 20:51:21 UTC