Re: [custom-paint] Replacing some of element()'s use-cases with Custom Paint

On Sat, Jun 6, 2015 at 12:46 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> Currently, the element() function
> <http://dev.w3.org/csswg/css-images-4/#element-notation> basically
> does three things:
>
> 1. Duplicates an element in the tree, to use elsewhere in the document
> as an image. (The "thumbnail" use-case.)
>
> 2. Lets you use an SVG paint server in CSS. (The "paint server" use-case.)
>
> 3. Lets you create a JS-animated image, by referring to an
> out-of-document canvas.  (The "animated image" use-case.)
>
> (There are a few other cases, but they're very similar to or devolve
> into one of these three.)
>
> The third one has had problems for some time.  In particular, in the
> current API, there's no way to know when you should update the canvas,
> whether the image is on-screen, what dimensions the image is, etc.
> You just have to guess at all of this, producing a canvas of some
> guessed size and painting it constantly at some guessed interval
> (probably tied to rAF()).
>
> Custom Paint is designed to do something very similar to this
> use-case, but in a way that resolves all of these problems.  At least
> one proposed syntax variant (a paint() function you can use as a CSS
> <image>) would have the same usability as element(), too.
>
> I think it's reasonable to just declare that Custom Paint is going to
> solve this use-case much better than element() is currently, and
> remove this functionality from element().  element() has always been a
> weird name for this particular piece of functionality anyway; it was
> just a convenient and vaguely-appropriate place to put it.
>
> This also means we can remove the .elementSources map.  This was its
> primary reason for existing.  SVG paint servers can just be put into
> the document rather than held out-of-document in the map, and <img>
> and <video> can be handled through a trivial custom painter, or put
> into the doc off-screen.  This removes a good chunk of element()
> complexity without increasing the use-cases by more than a trivial
> amount (assuming we do Custom Paint right).
>

I'm not sure what exactly "put into the doc offscreen" means. But it seems
fine to cut the elementSources map for now until there's a clearer need for
it.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.