- From: Doug Schepers <schepers@w3.org>
- Date: Thu, 29 Mar 2012 15:03:34 -0400
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Hi, folks-
Can we talk about a couple of things today?
1) I had a conversation with fantasai, and she's asking for a way to
extract part of an SVG image by its id, which seems reasonable. (see
IRC log below)
2) Hixie updated the Canvas API to include some SVG-like features (based
in part on existing SVG syntax); I knew this was in the pipe, but he'd
said he would email the SVG WG first. On the whole, I think this is
good, but we should do a technical review to make sure that it fits well:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035239.html
Regards-
-Doug
fantasai: If I understand correctly from
http://www.w3.org/TR/SVGTiny12/linking.html#SVGFragmentIdentifiers
An portion of an SVG document can be referenced by name
How would I do that for something like
http://dev.w3.org/csswg/css3-images/sprites.svg ?
shepazu: you would give it sprites.svg#svgView(translate(20,0)), or if
there were an id for each, sprites.svg#pie-2
or reference an svgView element
fantasai: how do I create an id for each?
shepazu: but all of this is very poorly supported in browsers, I'm afraid
» fantasai is trying to create a nice example in css3-images to
encourage people to implement this
fantasai: this is why you want to help me
shepazu: <g transform="translate(20,0)" id="pie-1">
I was actually just thinking about this very find of thing the
other day wanting to use SVG sprites via CSS
shepazu: I could look into what tests we have for it
fantasai: so...
for each <g> element, if I add an ID, that should work?
shepazu: but it's not usually a good idea to reference SVGT1.2, since
Hixie made that spec anathema
per the spec, yes
» fantasai thinks that would be awesome if so
fantasai: k, give me a few minutes here...
http://www.w3.org/TR/SVG/linking.html#SVGFragmentIdentifiers
No, that wouldn't work
because of the last paragraph in that section
shepazu: sprites.svg#svgView(viewBox(0,40,40,40))) should also work
fantasai: so how do I create a document that would actually work as we
want here?
Yeah, but I want to reference by name, that's the point
shepazu: ok
fantasai: Otherwise we'd just use Media Fragments syntax, which is shorter
sure
shepazu: ok, this was actually one of my pet issues
but I think it got hammered down with "backards compatibility" over
the years
shepazu: with is nonsense
so, let me look at SVGT1.2, which should contain the right
functionality
shepazu: and we can define it that way (or whatever way is right) in SVG 2
okay, here's how we defined it
shepazu:
http://www.w3.org/TR/SVGTiny12/linking.html#FragmentIdentifierTraversal
sorry
shepazu: 3rd bullet
so, it's not ideal in one way
fantasai: That does not seem useful either
shepazu: if the viewport is too small, the viewbox zooms out to
encompass the whole element
which is good
fantasai: and if it's not, then nothing happens
shepazu: right
fantasai: so in the case of the picture I showed, you get the whole
series of icons
not any individual one
shepazu: not necessarily
depends on the viewport size
fantasai: the viewport size is defined by the image
shepazu: but year
yeah
fantasai: since you're not providing any other intrinsic sizing here,
that'd be the size of the entire image right?
shepazu: it's not precise enough for this specific use case
fantasai: it's doing something else entirely
it's navigating to the element that's indicated
shepazu: the SVG defines a viewBox
fantasai: but we don't want a navigation spec, we want a "this fragments
represents this [noun]" spec
shepazu: and an intrisic width and height
there are 2 different use cases
shepazu: there's yours, which is valid and useful
then there's the one where you want to navigate around a large
document and see elements in context, which is also valid, and which was
what this definition was for (think, blueprints)
fantasai: yep
shepazu: so, how to satisfy both?
fantasai: Media Fragments has the exact same issue
shepazu: (easily)
honestly, it would be nice to have something in CSS that acts like
the <use> element
fantasai: That's the image() function
shepazu: oh?
uri?
fantasai: http://dev.w3.org/csswg/css3-images/#the-image-notation
shepazu: so, I don't think that operates like <use>
» fantasai doesn't know what <use> does, actually, but image() should be
grabbing clipped-out-fragments wherever possible
shepazu: <use href="sprites.svg#pie-1"/> would only show that element,
not anything else around it
fantasai: That is ideally what we want, I think
shepazu: it basically clones that element
so, change image() to act that way for SVG content
fantasai: how?
image() doesn't define how a fragment identifier is dereferenced
it only clips out whatever is referenced
» shepazu doesn't understand the scope of the question
shepazu: ok
right...
fantasai: as long as SVG doesn't define what is referenced, and defines
how to navigate to it instead, we can't do anything here
shepazu: ahhhh
well, SVG 2 could define how image(#foo) works for SVG content
or CSS could
fantasai: Neither one should have to
SVG shouldn't be defining navigation to fragments, imho
it should define what a fragment represents
shepazu: well, it needs to be defined somewhere
fantasai: and then let the UA figure out how to navigate to it
shepazu: uh, what?
yeah, that worked so well for the last 10 years
fantasai: You could suggest how to navigate to it
but defining your fragment as representing that navigation operation
is not making that referencing syntax useful for anything else
other than navigation
shepazu: in any case, that wouldn't get us around the fact that there
are 2 separate use cases for fragment identifier behavior
fantasai: it would get you to the same place as Media Fragments
which is, defining what the fragment identifier represents
and then you can define navigation to the thing that's represented
and other specs can clip out and reuse the thing that's represented
How do you expect <img src="image.svg#frag"> to behave?
that's kindof a related issue
shepazu: it would show the whole SVG (inasmuch as the viewport and
viewbox define), centered on the element with id "frag"
fantasai: so if the SVG is 4in wide
and the elemnt is on the right edge
does that mean the entire contents of the SVG gets translated 2in
to the left?
shepazu: how big is the viewport?
yes
fantasai: the viewport is 4in wide, right?
shepazu: not necessarily
but we can say so for this example
fantasai: I didn't specify a width or height on the <img>
so it's 4in wide
» shepazu avoids messy conversation around how the viewBox attribute
would mess with this
shepazu: but in simple terms, yes, it would shift over
but if there are other elements around that, it wouldn't hide them
fantasai: right, and if there are elements off the side of the viewport
normally, they'd show
yes?
shepazu: yes
which is why I'm saying image() could define other behavior
fantasai: so the only way to actually get a partial view of the SVG
document is to use Media Fragments
or its equivalent in SVG's more verbose syntax
or a <view> element that let's you create a named anchor for that
verbosity
yeah?
shepazu: right now, yes
I think the verbosity or mediafrag syntax is not the problem
shepazu: the problem is that it's unintuitive to do so people will
want to used named elements, extracted from the SVG and displayed as a
sprite
and we need to define it in a way that takes advantage of caching
fantasai: I don't see the latter as a problem
or at least not a spec problem
shepazu: well, if the same SVG is used thoughout the CSS file, browsers
should cache it, but maybe that's not a spec problem
fantasai: I'm pretty sure the browsers will cache it and not reload it
each time
In fact, I can practically guarantee that will be the case
shepazu: ok
moving on
we could define SVG 2 as you ask separate defining what the
fragment identifier represents from navigatio behavior
would that suffice for you?
fantasai: That would make it possible for CSS3 Images to reference
things appropriately, yes
shepazu: we could make special provision and mention of extracting
fragments, since that's something that SVG does itself with <use>
what timeframe are you looking at?
fantasai: CSS3 Images is moving to CR now, basically; just got the
resolution today.
So I guess we can't have any SVG-specific advice or examples now,
but if you define something that our spec can hook into, then it'll
become defined at the point
s/it'll/the interaction will/
s/the point/that point/
shepazu: ok, well, then at least we know how we should define it
and we could try to put it into SVG 2 sooner rather than later, and
include tests, so experimental implementations could behave correctly
and consistently even before SVG is done
shepazu: is it okay if I send this conversation to the SVG WG?
fantasai: yeah, sure
http://www.w3.org/TR/media-frags/#media-fragment-display
is how Media Fragments handles it
shepazu: ok
thanks
shepazu: I appreciate your reaching out to me
fantasai: I appreciate you trying to help me
shepazu: because I do think this is an important issue
» fantasai agrees
shepazu: sorry it doesn't work out of the box right now
fantasai: SVG icon libraries FTW!
k, I tweaked the wording a bit to be clearer
this should make it relatively easy for you to define things
appropriately in SVG : )
http://dev.w3.org/csswg/css3-images/#image-fragments
once you have normative text that's solid and referenceable, I can
add SVG as an example in that parenthetical
that'd be an editorial edit
and we can add a nice example with named anchors
shepazu: sounds good I think this is a good path forward
fantasai++
Received on Thursday, 29 March 2012 19:03:44 UTC