W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2012

Agenda+ Fragment Identifiers, New Canvas API Features

From: Doug Schepers <schepers@w3.org>
Date: Thu, 29 Mar 2012 15:03:34 -0400
Message-ID: <4F74B206.9090700@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 29 March 2012 19:03:45 GMT