Re: Applying SVG properties to non-SVG content

On Sat, Jul 12, 2008 at 6:58 AM, Bert Bos <bert@w3.org> wrote:

> The paint server idea probably needs some work. What is the MIME type of
> an SVG paint server? It seems to require some special-casing of SVG: if
> the URL refers to an image/svg+xml file and the URL has a fragment ID,
> then it's not the whole SVG file that is drawn, but only the element
> with that ID (assuming it is a valid paint server according to the SVG
> spec).


I'm not sure why the mime-type matters, but I see your point that one might
expect url() with a fragment identifier to behave just as if there was no
fragment identifier.


> Opera currently seems to ignore the fragment ID and just draw the whole
> SVG file. The MIME type definition for image/svg+xml doesn't seem to
> say anything about fragment IDs.


Would it be better to introduce a new CSS value, say "element()", instead?

Carefully done, that might let us solve another problem, which is that with
url() there is no way to refer to an element in the styled document from a
stylesheet, nor a way to refer to an element in a specific subdocument (such
as an <IFRAME> of the styled document).


> A different problem is how to set the priorities. Compared to all the
> other work being done in SVG and CSS, how high a priority is this and
> how many resources are available for it? Should it be done in the next
> two years (at the cost of what other work?), can it wait a year or two,
> should it not be done anytime soon, or not be done at all...


I'm happy to be the editor. If no great controversy arises (and so far, so
good) it shouldn't be much work. I've been working on it because I think it
is rather important and also urgent. These effects are aready available in
platforms that compete with the standards-based Web.

There's also a strategic issue within the standards community. It seems the
"path of least resistance" to adding a single feature to a standard like CSS
(or SVG) is to just go ahead and extend CSS (or SVG) with a new spec for
that feature, rather than creating a dependence on another standard that has
that feature. It's often more convenient for authors, it's often more
convenient for implementors, and it's often more convenient for those doing
the spec work, Unfortunately, in the long term, repeated iterations of that
approach will lead us to a lot of code, spec and authoring know-how
duplication. Instead I'd like to have standards integration in place so that
these features are *possible*, and then explore how we can make things
better, for example by adjusting standards for smoother integration (e.g.,
dropping the requirement for an <svg> container around SVG subtrees) or
providing convenience syntax that can hide the integration boundaries.


> > Another thing I'm interested in resolving is
> > how we should expose these in Gecko releases; using a vendor prefix
> > would be more annoying than usual because I've created no new
> > properties here (in fact, no new syntax at all).
>
> I see the problem...
>
> Maybe the problem isn't too big, though. There probably aren't many
> style sheets that are applied to HTML and contain SVG properties. And
> among those that do, there are probably not many where the SVG
> properties are applied to HTML elements.


The problem is if we shipped something in Gecko but later we decided our
behaviour didn't make sense. Although the Web won't come to depend on this
stuff quickly so I think we could commit to changing our behaviour after
release.

But if we decide element() is a good idea, then this becomes easier because
we can make it -moz-element() as necessary.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]