W3C home > Mailing lists > Public > public-houdini@w3.org > June 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 5 Jun 2015 14:46:22 -0700
Message-ID: <CAAWBYDB7rFjttWH3DUSY==ProFFKebGNQbo0SriXrHS4WMcvWg@mail.gmail.com>
To: "public-houdini@w3.org" <public-houdini@w3.org>
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).

Thoughts?

~TJ
Received on Friday, 5 June 2015 21:47:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 5 June 2015 21:47:10 UTC