Checking in

Doug,

Thanks again for putting me in a room with the amazing developers you 
work with through the W3C.

I do hope, some time, to work with you in the future. Presently, I sense 
you still have some strong concerns
about my motivations in the community as they relate to SVG.

Not much I can do there, but I do want to tell you that SVG is 
absolutely critical to my business:
we need a standard file format, and that's SVG+InkML. I've made certain 
that our file output renders on iOS SVG.

I do want to make a utility to "degenerate" CSS3+HTML into SVG, but 
that's for another day... mostly
related to that part of the stack that PDF covers. You had someone from 
GPAC, they're doing amazing things,
one of those is dealing with byte offsets in SVG files, allowing for 
arbitrary length SVG to be worked with in a practical
sense. You've got the right people paying attention.

I'd love to see a var x = new DOMEasy(document); x.attr/x.transform..etc 
etc interface. I'm behind you
with this concept of developing a new graphics API. I've had to 
encapsulate the following APIs,
they're exactly what we've needed to develop in the Web stack:
Serialization: SVG, InkML, Rendering: Canvas, WebGL, Semantics: ARIA.

There's a great term called C10k from the server side -- it's related to 
AJAX support,
I'm sure you can continue from there. I'd like to re-use that term for 
the client side,
and also call it C10k --the "Carp 10k" problem.

Microsoft's Fish Tank demo for IE is the inspiration for that title. 
It's been used to show
how SVG, Canvas2d and WebGL handle large amounts of object data. C10k is 
a server-side
issue in showing how services handle 10k connections. This one is how we 
handle 10k swiming
fishes on the client-side.

I can tell you, we want all five of the items that I've listed, 
including the some kind of DOMEasy
chaining interface for even-easier JS coding.

And for the greatest news of all, I can implement it in a way that works 
with existing browsers,
though I certainly want it to be a browser-level feature.

What does it look like? Well, it looks like awesome.
Partly, because we haven't invented it yet.

InkML trace groups correspond to WebGL buffers (typed arrays).
It looks a lot like a polyline: InkML gives ASCII serialization, WebGL 
buffers are used for zero-copy
between web-workers and for efficient streaming to the GPU.

InkML math corresponds to WebGL GLSL (we need a little more here, it's 
easy, I've prototyped it).
It's pretty simple though, you give commands like: c10k.mul(a, 20) 
instead of doing for() b = a*20;

SVG and Canvas 2d handle the unfortunate ms-durations when bezier curves 
and other complex
primitives are executed. SVG also handles ascii serialization.

ARIA does the wonderful work of making the entire semantic interface 
accessible to secondary
user agents, or assistive technologies.

I guarantee to you, these five technologies work, they work together, 
and they can work together quite well.
I've been researching this for four years.

I know that Opera and Microsoft are hoping for an alternative to WebGL. 
I think we can give them one,
without compromising the integrity of WebGL -- because we can still 
build upon WebGL implementations,
allowing vendors to re-use those code bases.

I'm eager Doug. But please, try to understand that apart from being an 
Uber-nerd, I'm in business,
starting up a software company is hard, terrible work. Idealism quickly 
hits reality, and then
lessons get learned.

I'm here, representing my interests, and I'm here on a personal level, 
representing my concern
that accessibility is a human right, it's a matter of personal freedom, 
and one that has been oftenoverlooked
by the still-immature field of web development. I very much will ensure 
that any new specification
has WCAG in mind at every level.



-Charles

Received on Friday, 29 July 2011 02:03:10 UTC