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

Minutes. Weds 11 Jan 2012 Manly f2f

From: Chris Lilley <chris@w3.org>
Date: Thu, 12 Jan 2012 00:00:57 +0100
Message-ID: <745082426.20120112000057@w3.org>
To: SVG WG <public-svg-wg@w3.org>
Hello SVG,

Minutes in HTML at


and below as text:

                     SVG WG Sydney 2012 F2F day 1

10 Jan 2012


      [2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2012/01/10-svg-irc


          Doug_phone, Dirk_phone, Vincent, Cameron, Erik, Dean,
          Takagi-san, Dean, Jun, Cyril, Brian, Chris, Rik


          vhardy, dino, ed, birtles, heycam


     * [4]Topics
         1. [5]https://www.w3.org/Bugs/Public/show_bug.cgi?id=12558
         2. [6]support HTML's entities in SVG.
         3. [7]Mapping
         4. [8]mapping requirements (continued from last slot)
         5. [9]SVG2 Requirements
     * [10]Summary of Action Items

   <dino> agenda link?


     [11] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda

   <vhardy> ScribeNick: vhardy


     [12] http://www.speedtest.net/result/1699186634.png

   <cabanier> cyril is having some issues with his computer

   heycam: let's start with the first topic


     [13] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12558

support HTML's entities in SVG.

   <ChrisL> [14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=12558

     [14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12558

   heycam: the request is that HTML entities be available in SVG
   ... I think this is not possible with just messing with XML.

   chris: I would not like a special version of XML that is SVG
   specific :-)
   ... people should just use Unicode and get used to it.

   <TabAtkins> Presumably SVG-in-HTML has access to all of HTML's
   entities, right?

   chris: the HTML entities do not cover very much (greek, symbols,
   latin-1...). For most characters, people will have to use entities
   or type it in.
   ... we could say that if you use HTML serialization, you can use
   them, if you use XML serialization, you have to include them in the
   DTD (internal DTD subset).

   <heycam> TabAtkins, yes, that will work

   heycam: doug, do you have comments?

   <heycam> ack

   doug: people will want to use the same entities.

   <TabAtkins> ChrisL, I don't know what "magical" is in this context.
   I'm not sure whether the XML serialization of HTML allows the full
   set of HTML entities, or just the XML entities.

   doug: chris argument to use Unicode is good. There are people who
   are going to be surprised that some things work in SVG in HTML but
   not in stand-alone SVG. I think the strongest argument is that
   people will want to use SVG in HTML and get things working the same
   way in stand-alone.


     [15] http://www.w3.org/TR/html5/named-character-references.html

   <ChrisL> tab,the entities inHTMLare declared in the external DTD
   subset, which browsers don't fetch nor do most XMLtools like XSLT

   heycam: yes, but we have to live with these differences, because
   there are differences before the differnet serializations anyway.
   entities is just another thing you can do with XML that is not
   available in HTML serialization.

   <ChrisL> so in general you will get an 'undeclared entity' well
   formedness error

   <TabAtkins> ChrisL: Okay, then we should be fine following the same
   thing here.

   doug: there are certain ones that people will expect, like soft
   hyphens. Things that they can think of the HTML entity name.

   <TabAtkins> Modulo the fact that standalone SVG is forced to use the
   XML serialization.

   <TabAtkins> We can fix that.

   doug: and they do not know the unicode.

   heycam: non-breaking space is one that is very common for me.

   <TabAtkins> <!doctype html><svg>...</svg> can qualify as an
   html-serialized standalone svg, or something like that.

   chris: nbsp, joiners are needed.
   ... if you want those, you can put them in the internal DTD subset.

   heycam: if these entities are useful, they should be supported at
   the XML level rather than SVG. Relying on the DTD is not a great way
   because some processors do not use it. The solution should not be at
   the SVG level.

   chris: we do not want to break things like XSLT that use SVG as
   input or output.

   <TabAtkins> I agree with heycam

   <TabAtkins> Fix XML as necessary, and fix SVG outside of XML as

   chris: Anne has been talking about his XML5 effort. There was an
   idea to use an HTML5 parsing algorithm for general markup languages.
   There may be some renewed interest to change XML.

   <ChrisL> [16]http://annevankesteren.nl/2007/10/xml5

     [16] http://annevankesteren.nl/2007/10/xml5

   <TabAtkins> cyril: Not skype, but I can use anything else.

   <ChrisL> to quote anne "Entities are in fact a fricking nightmare"

   doug: defining an SVG parsing algorithm that is stricter than HTML5
   but looser than XML would be good.

   heycam: so solving is as part of another initiative that would also
   solve it for SVG.

   <TabAtkins> Yes, a parsing algorithm that has the looseness of HTML
   (but not the random quirks like assumed elements and auto-closing)
   would be great.

   heycam: I think people like the XML5 idea.

   chris: for the moment, we are not going to define a new parsing
   solution for SVG.

   doug: why not? Some people in our community are interested, like Tab
   and Anne. I do not think we should take it off the table.

   heycam: I meant that we as the SVG WG will not work on it because it
   is a broader issue than SVG and the SVG WG is not the right place
   for that work.

   chris: this may seem simple, but it could be a huge time sink and a
   very large number of interested parties.

   doug: this is why I am not proposing to do it in SVG2 but in

   heycam: in the group?

   doug: no, but the XML community is not doing this work and has not
   prioritized this even though it has been brought up in the past 5
   years. I do not think we should solve that for SVG 2.

   heycam: interested people in the groupd could work on that, but it
   is probably outside of the charter of the SVG WG. I'd be happy for
   the problem to be solved.

   <TabAtkins> We have a de-facto second parsing solution for SVG
   already. SVG-in-HTML allows unquoted attributes, frex.

   doug: I do not think that SVG parsing is outside the scope of our

   heycam: I think we should use the new parsing solution in XML or
   other markup parsing solutions.

   doug: ok.

   <TabAtkins> Whether we subset this behavior to get a clean
   description of a "looser" SVG parsing, or we use something like XML5
   with similar effects, it's a useful thing to pursue.

   heycam: I think we should respond and close the bug to say that if
   we want to solve this problem, it should be at the XML level and may
   be some SVG WG people could work on that but it would not be done as
   part of an SVG WG deliverables.

   chris: so resolve and wont-fix?

   heycam: yes.

   ed: should we request that change to be made in the XML wg?

   heycam: this is a problem that has been known about for a long time
   and has not been solved. Not sure a message will help more.

   <TabAtkins> The problem with making it a general XML problem is that
   it'll invoke a lot more people trying to improve things. That's
   great, but it's not what we need.

   <TabAtkins> The short-term problem is SVG-in-HTML allowing things
   that standalone SVG doesn't. This can be fixed much more easily by a
   simplified HTML-like parsing solution triggered by some switch.

   <heycam> TabAtkins, well you can just serve it as text/html -- are
   you instead proposing to come up with a new text/svg or something?

   <heycam> TabAtkins, I think it would be harder to get buyin for a
   new parsing mode for SVG content than for markup languages in
   general (despite the fact that solving that might involve more

   <TabAtkins> heycam: SVG-as-text/html is as bad an idea as
   XML-as-text/html. ^_^

   RESOLUTION: The SVG WG thinks this well know limitation on XML
   entities is a wider problem than just SVG and should be addressed by
   working groups addressing markup parsing (e.g., XML WG). When that
   issue is addressed, the problem will be solved for SVG and other
   markups facing that issue (e.g., XSLFO).

   <heycam> [15 minute break]

   <dino> ScribeNick: dino




   <stakagi> First, I would like you to discuss about the need for


     [17] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping

   <jun> [18]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/

     [18] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/

   Jun: Links above for mapping requirements and tiling.


     [19] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Tiling_and_Layering

   <stakagi> Dirk-san's comment

     [20] http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0117.html

   CM: Dirk, can you summarise your comments on mapping?

   Dirk: I think GML is good enough - we need a transformation btw GML
   and SVG. That's all. I'm not sure what else we need.

   CL: I believe that is what we're proposing. A way to map the coord
   system in SVG.

   <heycam> (this DS is Dirk rather than Doug)

   <stakagi> Dirk-san's comment

     [21] http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0117.html

   <stakagi> Enabling usage of huge graphics by a hyperlink means

   Chris: we can't always use the server to do the mapping, since the
   data might come from various sources.

   <stakagi> [22]http://www.w3.org/2011/web-apps-ws/papers/KDDI.html

     [22] http://www.w3.org/2011/web-apps-ws/papers/KDDI.html

   Dirk: it's not client side vs server side, it's more about that it
   shouldn't be integrated into SVG.

   Chris: the proposal is to provide enough information such that the
   client can combine and render data from various sources. It is not
   an attempt to build a GIS system in SVG.

   Dirk: my concern why we would add special logic for maps - but not
   other techs like math, etc.

   Chris: understood - the idea is to provide just enough information
   to overlay map data

   ChrisL: It does not provide any reprojection (other that linear

   <TabAtkins> I believe the underlying primitive - being able to link
   to lots of files and give their bounds, so the UA can decide which
   ones to load based on the viewport position/size, is good.

   <TabAtkins> It sounds useful for lots of things more than maps.

   Doug: also, tiling and layering is useful beyond mapping.

   <TabAtkins> But I'm uncomfortable with any direct tie-in to mapping

   <TabAtkins> Or coords.

   Dirk: I would prefer the new tag/attribute names to be not-specific
   to mapping. I'd rather more generic names.

   <TabAtkins> Another example of a use-case is video games using
   SVG-based graphics.

   Dean notes Tab's comments out loud for the room.

   <TabAtkins> (Though that may require control over how aggressive the
   UA should be in downloading.)

   <stakagi> And I think that it is the important characteristic of WWW
   to use a hyperlink.

   Cameron: (generally agrees with generic approach)

   JunF: This is exactly why we call it tiling and layering - we're not
   trying to be specific to maps.

   <TabAtkins> Also: allowing multiple layers of tiling sounds good.

   JunF: other things can be developed separately

   Doug: Although, I think mapping is important, so I'm ok with some
   features being added to help that use case

   Cameron: I don't want to preclude mapping applications.
   ... people already write mapping applications

   <stakagi> And, implementation of SVGTL is not so large.

   Chris: Although it would be better if we didn't need JS for such
   applications - prefer declarative.

   <TabAtkins> I wouldn't mind optional declarative abilities to pan
   across a large image.

   <TabAtkins> Doing panning/dragging in JS is simple, but painful.

   Cameron: i wonder if there is some intermediate ground where we give
   instructions on how to declare the geographic location, but not
   necessarily require a new implementation (ie. script required to
   process it).

   JunF: I asked Takagi-san if he is happy to use script to match
   mapping data from various sources. He replied that he'd prefer

   <ChrisL> I wanted to point to some earlier work on multi-resolution
   images (SVG 1.2 full)

     [23] http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires

   Takagi: - re-usability
   ... I've been working with various developers of mapping systems in
   Japan. They conveyed that it is difficult to use the data if it is
   tightly integrated with script.

   Cameron: I am wondering if we can come up with some extended format
   for *describing* the mapping regions, but still require script to do
   the stitching together of data.

   <ChrisL> LinkedOpen Data

   Takagi: tends to agree with Cameron's comment. He has been working
   with various government agencies and would prefer a clear-open
   solution. It is easier to share data than a script interface.

   ChrisL: (points to the multi-res image proposal above)
   ... allows you to pull higher resolution data, etc. Similar to
   Microsoft's PhotoSynth. You can certainly do this with script, but
   it is more simple if it is declarative. Other use cases like medical
   imaging, high-resolution photographs, etc

   <ChrisL> There are a lot of use cases for multiresolution imaging,
   both raster and vector

   Cameron: I'm not against a completely declarative solution.

   Dean: does a declarative solution require some kind of UI or API in
   order to control the layering?

   Cameron: That's part of the document.

   Dean: (supports the general idea of being able to define a
   coordinate system mapping btw documents - wonders how or who
   controls the fetching and display of data)

   Cyril: If you have a use case such as a map with two levels of
   quality and multiple tiles. There are different strategies (go deep
   to get high-res data first, or go wide to get a broader low-res map)
   ... The behaviour there is significantly different - who is defining
   what the application should do?

   Cameron: In this case it would be the developer/author.

   Brian: Are we talking about a core SVG feature, or a module?

   Chris: I think it was supposed to be a module, but there are parts
   that should be core (e.g. multiresolution imagery)

   Cameron: we have already agreed that some parts are core SVG. For
   example, path sharing.
   ... my fear is that we go ahead with this and then not enough people
   implement or use it

   Brian: question is how critical this is to the progress of SVG2?

   Chris: I'm aware of two implementations of this already (yet no
   implementations of some other SVG2 features)

   Vincent: Looking at the proposal, I understand the linear
   transformation, but I do not understand how you would use this in

   cameron shows example

   <TabAtkins> Any way to get the example into irc?

   Vincent: I propose collecting use cases

   <jun> <?xml version="1.0" encoding="UTF-8"?>

   <jun> <svg xmlns="[24]http://www.w3.org/2000/svg">

     [24] http://www.w3.org/2000/svg

   <jun> <globalCoordinateSystem

   <jun> srsName="[25]http://purl.org/crs/84"

     [25] http://purl.org/crs/84


   <jun> <circle cx="258.1401" cy="185.1558" r="10.0" stroke="none"

   <jun> </svg>

   <TabAtkins> I don't really understand this example. It sets up a
   coord system, yes. So does viewBox. What's the benefit?

   Cyril: The point is that it exists in the file

   Chris: and it defines where you start

   <TabAtkins> (Also, the use of a matrix() transformation there is
   very difficult to understand. I assume it's actually a scale and

   <TabAtkins> Oh, <gCS> tells you what coords *this file* covers,
   relative to the coord system of the including document?

   (sorry, some unminuted discussion where Dean is educated on the

   <TabAtkins> If my understanding is correct, I'd *much much much*
   prefer something that explicitly declared the bounds. Like a viewBox
   that used units from the including file.

   <TabAtkins> The use of a scale/transform to indicate this is weird.

   Cyril: This is not giving any bound information

   Vincent: and it is a standalone element in the file - the <circle>
   is not a child.

   <heycam> TabAtkins, yes I think we should declare the extent

   <TabAtkins> What's an example of the master file that uses the
   subfile illustrated here?

   <heycam> TabAtkins, I *think* in that document right at the end of
   section 3

   <heycam> TabAtkins, (but I am still confused by it)

   <ed> <svg xmlns="[26]http://www.w3.org/2000/svg" viewBox="20 110 120

     [26] http://www.w3.org/2000/svg

   <ed> <globalCoordinateSystem

   <ed> srsName="[27]http://purl.org/crs/84"

     [27] http://purl.org/crs/84


   <ed> <animation x="0" y="0" width="100" height="70"

   Chris: It seems we are missing the information which describes how
   to actually merge these two files

   <ed> <animation x="100" y="0" width="100" height="70"

   <ed> <animation x="200" y="0" width="100" height="70"
   xlink:href="2_0.svg"/> ... </svg>

   <ed> what I pasted is an example of the master file

   <TabAtkins> (Section 3 of which document? I'm looking at a blog post
   that has that example, but in section 4.3.)

   <cyril> [28]http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/

     [28] http://www.w3.org/Submission/2011/SUBM-SVGTL-20110607/

   <TabAtkins> Yeah, that's still not a usage, I don't think.

   <TabAtkins> Ah, I was getting a 502 last time I tried to access that

   <stakagi> 4.1 Rendering of import SVG data with geographic
   coordinate system

   <stakagi> pluase see

   <TabAtkins> The use of <animation> confuses me.

   <heycam> TabAtkins, think of <animation> as <use>

   <TabAtkins> Also: if <gCS> is used in the child files to declare
   their bounds, that means we have to download *all* of the child
   images to tell where they go.

   <ed> TabAtkins: it's like <html:iframe> or a dynamic form of

   <TabAtkins> That's... less than optimal.

   <TabAtkins> Ugh, that's a bad bad name.

   Dean: It seems that this is saying you should ignore x,y,width and
   height on any element that references data with the
   globalCoordinateSystem element

   <TabAtkins> By "less than optimal" I really mean "completely
   unusable for real-world mapping applications".

   <TabAtkins> Or, hm.

   <TabAtkins> Are the x/y/width/height on <animation> used to declare
   the bounds, or the <gCS> in the child files?

   <TabAtkins> I guess I'm still confused about what <gCS> is supposed
   to accomplish. :/


   <cyril> cyril: Tab the name comes from a smil element: <audio>,
   <video>, <animation>

   <TabAtkins> cyril: The name is bad regardless of its provenance. ^_^

   <TabAtkins> Particularly since <animations> doesn't scream "map
   tile" to me.

   <TabAtkins> It instead sounds like "I misspelled <animate>".

   <cyril> cyril: animation points to an animated vector graphics

   Chris explains image referencing in SVG on a whiteboard (which is
   going to be hard to scribe)

   <cyril> it's specified in SVG 1.2 Tiny

   Chris: the <gCS> element should always use WGS84 and you shouldn't
   have to specify it using that special srsName=<url> syntax, it
   should just say in the spec that it's always WGS84

   Cameron: why not always be <g>?

   Vincent: this isn't a transform on the children. It's a description
   of how the data was transformed.

   <TabAtkins> I don't understand the use of a transform in the first
   place. Either the subfiles should use local coords and make the
   transforming automatic based on the containing file's declared
   bounds, or the local coords should *be* global coords and just
   trivially work.

   <TabAtkins> (For the automatic case, something simple like mapping
   the subfile's viewBox into the containing file's declared
   x/y/width/height for the tile would work I think.)

   TabAtkins, I believe the desire is that the subimage might (for some
   reason) have a different viewport than the coordinate system

   (I might not be conveying that correctly - I'm very confused)

   <TabAtkins> Me too. ;_;

   <stakagi> [29]http://sourceforge.net/projects/wwwmap/

     [29] http://sourceforge.net/projects/wwwmap/

   <stakagi> LGPL implementation

   Takagi: this is a chrome extension that provides tiling in SVG

   <birtles> looking at the source of
   [30]http://svg.mbsrv.net/extmaps/BingMapAu/ContainerBing.svg if you
   want to view the source

     [30] http://svg.mbsrv.net/extmaps/BingMapAu/ContainerBing.svg

   <TabAtkins> I don't think I can sanely evaluate this at this point.
   The example are extremely confusing and the explanations are

   Shane: the x,y,width,height of the referencing element (eg
   <animate>) is telling the UA when to fetch the sub-resource
   ... the important point is section 4.2 of the proposal

   <TabAtkins> That part makes sense, and sounds like an interesting
   and probably useful primitive.

   Dean: I think this should be a new element. Otherwise it is
   significantly changing existing behaviour.

   <TabAtkins> If I'm understanding Shane's back-channel explanation,
   then I still don't understand the point of <gCS>. :/

   TabAtkins, gCS defines each resource's transformation from some
   universal coordinate system (WGS84 for example)

   <TabAtkins> Yeah, just got that in the backchannel.

   <TabAtkins> I understand the mechanics of <gCS> now, but not the

   <TabAtkins> Why do we need this coord indirection? Why not just
   specify the images in the global coords to start with?

   <TabAtkins> ed, agreed.

   <ed> <tile> might be a better name than <animation> for this

   <cyril> Tab: because you don't control the way the SVG is generated
   in every server

   <birtles> ChrisL also brought up the issue of precision

   <cyril> but you can still mash them up if all of them provide gCS

   Cameron: I think Vincent's suggest of enumerating use cases is a
   good one. We'll see how the proposal covers the uses.

   <TabAtkins> cyril, are you saying that we're worried about map data
   using effectively random coords?

   Vincent: And I think a new element is worth investigation.

   <TabAtkins> If it does, then how can we depend on it using <gCS> to
   map its coords?

   <TabAtkins> And if it *can* use <gCS>, why can't it just change its
   coords directly?

   <cyril> I don't understand the questions.

   <TabAtkins> I don't understand the premises. ;_;

   <TabAtkins> Let me try again.

   <TabAtkins> So, <gCS> lets the child files map their local
   coordinates into a global coord system. <gCS> also allows the
   containing file to do the same thing. After applying them both, you
   have a way of connecting together two different kinds of local

   <TabAtkins> But why is this necessary?

   <TabAtkins> The child files can just work in global coords. We're
   talking *map data* - there are reasonably common ways of doing this.

   Cameron: someone needs to distill this proposal into a clear

   <TabAtkins> If a child *can* change itself to include a <gCS>, it
   can also change itself to use global coords directly.

   <TabAtkins> If it can't change itself to use global coords, then it
   probably can't change to include <gCS> either.

   <TabAtkins> So I don't see the use of <gCS>.

   ChrisL: the reason we need localized coordinate systems is for
   accuracy. If you're drawing a map of your house, you don't want to
   use WGS84

   <TabAtkins> Okay, that makes sense.

   Dean: for example, floor plan of a building

   Vincent: or components in machinery

   <TabAtkins> In that case, a clearer method of indicating the
   transform, like a from="x y w h" to="x y w h" would be nice.

   <shans> and we can't just use a <g> because that actually does the
   conversion, and you can't then view the file independently of the
   mapping context

   <TabAtkins> The fact that the examples use matrix() did no favors
   for understanding this concept.

   I believe shane just documented Brian's question and the answer

   <TabAtkins> Or maybe something on <svg> that maps the viewBox into a

   <TabAtkins> I'm just angling for a human-writable version of the
   feature here. There are a few annoying features in legacy SVG that
   were clearly designed without thinking of humans. ^_^

   Cyril: I understand why we need gCS in the children, I'm not so sure
   why we need the gCS in the container

   <TabAtkins> Yes, that's my second concern now.

   Shane: In order to use this proposal in a non-mapping situation,
   then is it enough to leave out the mention of WGS84?

   <stakagi> property name 'srsName' may not be cobinient.

   <TabAtkins> No need for a URI at all. If we *need* to declare what
   the gcs is, use a keyword. But if we can avoid it, do so.

   TabAtkins, I suggested (not minuted) we use something like

   and every other use case is a free for all

   <TabAtkins> Naming issues aside, yes, something like that.

   if you want to combine a medical image with a map, good luck.

   <ChrisL> tab, the srsnameis inherited from the rdf-mess in svg 1.1
   which was a more longwinded way to saythe samething

   <TabAtkins> ChrisL: Okay, but that doesn't mean that *we* need to
   inherit it.

   <TabAtkins> We can do things correctly. ^_^

   Chris: some of these names are a simplification of SVG 1.1. we can
   change them if needed, but not spend too much time on it

   Vincent: would it be sufficient to update the existing metadata that
   exists? The other part of the solution is whether or not we need a
   new element to reference such data

   <TabAtkins> I'll be gone in a few minutes for at least 2 hours.

   Cameron: I'm not sure we should hide the active processing.
   ... we'll break for lunch now, and come up with resolutions

   ---- LUNCH ----

   <heycam> [for one hour]

   <ed> scribeNick: ed

mapping requirements (continued from last slot)

   CM: as vincent said, we need short examples and use-cases, to be
   able to grasp the proposal better
   ... not sure who would be best to work on those

   CL: i can help, but I need someone else to work on it too

   <scribe> ACTION: CL to write up a short description of Tiling and
   layering and use-cases for it [recorded in

   <trackbot> Created ACTION-3197 - Write up a short description of
   Tiling and layering and use-cases for it [on Chris Lilley - due

   CM: is it worth discussing if it should be a module or built into

   CL: too early, we need to see how general it will be first

   CM: that was the first requirement from the wikipage takagi-san made
   ... next one, non-scaling-stroke vector effect
   ... we have already resolved to include the functionality of
   non-scaling-stroke in SVG2
   ... next is shared path segments

   CL: I think we decided to move that to vector-effects

   Vector_effect -- non-scaling stroke

     [32] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Vector_effect


     [33] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Shared_paths

   Fixed-size_object -- transform ref

     [34] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Fixed-size_object

   CM: ST can you explain what you meant with misunderstanding of how
   transform-ref worked?

   ST: the implementation of this fixed-size is different from the spec
   wrt the viewbox behaviour

   CM: what particular functionality is desired here?
   ... so that it stays the same size regardless of scale?

   CL: right

   CM: it's limited to referring to the outermost svg in tiny 1.2

   CL: yes, that's a limitation in tiny, could reference to any sub-svg

   <stakagi> Mr. Alex understands the complete information of these

   CM: it's one of those features where it's useful if the zoom-and-pan
   is done using built-in functionality, not with script
   ... does opera implement transform-ref?

   ED: yes

   CM: is there content taht uses it?

   CL: since alex and kddi implemented this too, there is probably
   content that uses it
   ... it's generally useful

   CM: shouldn't be too hard to implement
   ... you have to track changes to coordinate space

   BB: the use-case is for markers on a map?

   CL: map symbols that don't get bigger when you zoom

   CM: we haven't decided on this one for SVG2, can we do that now?

   CL: non-scaling-stroke and this funcationality sort of goes together

   CM: anyone object to having transform-ref in svg2

   ED: it does mean we introduce something more that CSS transforms
   need to deal with


     [35] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input

   ED: so we'd need to address this issue in the FXTF transform spec

   CM: not sure i like the name 'ref', not really descriptive

   CL: it points to which coordinate system it uses

   (explains the tranform-ref functionality)

   CM: i'd like to see some example documents using this to see its
   ... what if you wanted rotation but not scale, does it cover that?
   ... or the other way around
   ... we had another discussion about wanting text to not rotate

   CL: pinned video in svg tiny 1.2 is similar

   CC: that's 'transformBehaviour' and it is useful, could be used for
   other things than video
   ... changes the way the transform applies to the object
   ... so in one case: only affect the centerpoint

   RC: transform-origin in css is similar too

   CM: don't want to resolve right now on transform=ref right now, want
   to see more examples first
   ... some form of transform-cancelling behaviour

   <ChrisL> 3.4.1 Constrained Transformations


     [36] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Constrained_Transformations

   CM: are people happy requireing that, or do we need more writeup?
   ... want to make sure it's a useful enough feature

   BB: in mapping sure, but outside of that not so sure
   ... UI-components was one use-case mentioned, but you could affect
   this script anyway

   CL: you could say the same about position:fixed

   <heycam> about position:fixed

   BB: just wondering about use-cases outside of mapping

   CC: trying to remember the use-cases

   CM: why would the UI be part of the content, and not in a separate

   CL: callouts, on objects that have text

   VH: you want things to follow along, but nonscaled

   BB: yeah that's a better usecase
   ... might be useful for a diagramming application, but do we need to
   support it in svg itself?

   VH: well, we could just adopt transform-ref since it's specced and

   CM: not sure it addresses everything we discussed here
   ... such as rotation without scaling
   ... but maybe i don't understand transform-ref fully
   ... anyway, regardless of the solution, are the use-cases sufficient
   for us?
   ... whatever in SVG1.2 Full isn't going to help us decide here
   ... if some ppl need more convincing, we need some more examples
   demonstrating the functionality

   <scribe> ACTION: CL to write up general use-cases (mapping and
   other) for constrained transformations, aka transform=ref(...)
   [recorded in

   <trackbot> Created ACTION-3198 - Write up general use-cases (mapping
   and other) for constrained transformations, aka transform=ref(...)
   [on Chris Lilley - due 2012-01-18].


     [38] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Alternative_transforms

   CL: it's been considered before


     [39] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Non-linear_transformation)

   CL: this is different from 3d transformations
   ... DOH was asking for polar coordinate system, and Dailey was
   asking for kalleidoscopic projections
   ... next, on UI


     [40] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Built-in_User_Interface

   CM: for UI controls
   ... built-in, native UI, not sure about that

   CL: making it easier to construct UIs would be better I think

   VH: for video many people want to make their own ui
   ... but you can also specify 'controls' (html5)

   CL: it's useful for vector graphics to have zoom-and-pan controls

   BB: in mapping scenarios you generally want to construct your own ui

   CL: but for some applications, such as a floorplan of a house you
   might not want to go through all that trouble

   CM: i'm not that against having controls
   ... video will be probably more common
   ... compared to vector content
   ... it's not a difficult thing to implement, and you do want
   different ui depending on device, and the implemetation might be in
   a better position to make a better ui
   ... can listen for touch events for pinch-zoom e.g
   ... back to the non-linear transforms
   ... we've already resolved to have support for differnet projections
   ... the mapping requirements page doesn't have this as a hard
   requirement, so no need to reopen taht requirement
   ... back to controls again
   ... this is similar to zoomAndPan
   ... but with a different name

   BB: you can pinch-zoom without any ui on the screen

   CM: that automatic zooming and being able to scroll the css box, and
   not being able to do that on the content inside
   ... not sure what should happen if you have mixed svg and html
   ... would anything we do different here change browsers about how
   they interpret zoom-and-pan

   VH: if it's something we can do and it's not too difficult it should
   be higher on the priority list

   <cyril> s/we've already resolved to have support for differnet
   projections/we've already resolved not to have support for different

   CM: it's not too difficult to do, so we don't save that much work if
   you were to do it yourself in script

   VH: sure, you can change the currentScale/currentTranslate or modify

   CM: propose that we don't include UI controls

   ED: do we have other requests for this in SVG2?

   CM: yes, dailey

   RESOLUTION: we won't require support for built in zooming and
   panning UI in SVG2

   CM: next, programmingless geolocation
   ... scroll to center of mapview automatically

   CL: geolocation is an api

   CC: but this is a declarative way

   CM: not sure it's that useful
   ... to avoid the two lines of script to set the location


     [41] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Programming-less_geolocation

   CC: does feature phones have javascript engines?

   <stakagi> Since this spec is what specialized in the map, according
   to the till now context, it may be difficult for it to put in.

   CL: yes

   BB: if you use this in an <image> you might want it declarative,
   because script is disabled

   CM: but you could use an #svgView(...) on the <image> to set the
   ... doesn't seem that useful
   ... for a map you'd want to use scripting anyway

   RESOLUTION: we won't require automatic geolocation centering of maps
   or content


     [42] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Setting_SVG_views_by_IRI_fragments_using_geographic.28global.29_coordinates

   CM: next, setting svg views with url syntax and in the global
   coordinate system
   ... slightly more useful to me
   ... for static maps, e.g a restaurant location, and you want to use
   a country map with your data
   ... we already have #svgView

   CL: seems straightforward, except you need to say if you link to a
   point outside of a map, or if it's not a map
   ... also needs the geographic location thing

   VH: so you map that point to the center of the viewport

   CM: oh, thought it was an area?

   CL: yes it's an area
   ... but if we make the widht and height optional

   VH: how do you get the transform?
   ... would need the global transform

   CL: if you link to something that's not a map, then we need to say
   what happens
   ... or if you link to a map of sydney and it's a map of melbourne
   ... maybe go to the edge of the map, or whatever

   CM: we should have optional width and height for the svgView thing,
   so that it centers that point
   ... if we have the global coordinates from tiling and layering then
   we should have this
   ... would go naturally with that

   RESOLUTION: if we have the tiling and layering module then we'll
   have a way of making svgView transformations work in global
   coordinate space

   CC: so we couldn't have a keyword svgView(my-location)?

   ED: there are cases where this doesn't map to anything (if disabled,
   or not available), anyway, as said before that needs to be specified

   CM: the kind of maps where you want to center, you're going to want
   interactivity anyway
   ... why do we need a programmingless way of doing it?
   ... that was the reasoning from before
   ... move on, last on the page


     [43] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#API_for_smooth_transition_action_of_zooming.2Cpannning.2Crotating

   CL: don't understand it, is it transitions?
   ... why does it talk about suspendRedraw?

   BB: one possibility is to stop it from updating while you do your
   ... and then you'd unsuspend when you're done zooming

   CL: if you're really zoomed in and you don't want to trigger
   fetching resources while you pan a lot

   BB: difficult to spec I think

   CL: if we had the automatic fetching of tiles, but if we don't have

   CM: if we could disable the automatic tile fetching so that you
   could turn off fine detail while scrolling
   ... being able to turn off tile fetching would be fine

   BB: you may need events for this

   CM: so to fade between different detail?

   BB: yes, maybe

   CL: yes, ahving progress events for this would be useful

   RESOLUTION: we will have a way to control the automatic tile
   fetching in the tiling and layering spec


     [44] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Transformation_functions_between_global_.28geospatial.29_coordinate_systems_and_user.2Fviewport_coordinate_systems

   CM: seems like a nobrainer
   ... we're already going to have better interfaces for mouse events
   and coordinate systems, so we should have this


     [45] http://soln-sr3450.movielink.net.au/common_ip_cgi/prepaid_access.cgi?MAC_ADDRESS=00:24:d7:85:22:80&ASSIGNED_IP=

   RESOLUTION: we will expose the global coordinate system in the SVG
   DOM somehow


     [46] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#DOM_access_API_for_cascading_SVG_Documents

   CM: this is asking for the contentDocument on the referencing
   element (tiles, here it is the image and svgtiny12 animation

   ED: don't think we want to allow this for <image>

   CM: right, this is similar to <html:img>

   RESOLUTION: we will have contentDocument and contentWindow on svg
   elements that reference whole documents except for <image>

   JF: wondering what we should do with the mapping TF
   ... ST talked about creating a community group in japan
   ... but isn't sure if we could run a group in europe

   CM: is this for tiling and layering?

   CL: no, it's for general mapping things, tiling and layering should
   be done in svgwg

   <stakagi> potentially Open Street Map and Open Layers

   <stakagi> communities are candidate

   DS: the SVG IG has not been very active
   ... should we shut it down?
   ... and make a community group for all of the svg community groups
   around the world

   CM: is it the barrier of joining the group? or is it more of a
   don't-have-time thing?

   DS: just want to make it easy for people to join the community group
   ... still requires real experts to drive things forward
   ... but we could reach a broader audience with a community group

   <ChrisL> web mapping community group

   DS: we could have a dedicated mapping com group

   <stakagi> [47]http://www.openstreetmap.org/

     [47] http://www.openstreetmap.org/
     [48] http://openlayers.org/

   DS: i contacted the openstreetmap folks
   ... would be good to have an OSM person on the SVGWG

   --- 15min BREAK ---

SVG2 Requirements

   <birtles> ScribeNick: birtles


     [49] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#to-animateTransform_definition


   CM: so it's about how to get smooth animations for to-animation with


     [50] http://brian.sol1.net/svg/animatetransform-issues/to-animation-and-animatetransform/

   to-animation needs a base value but that's not always possible to

   CM: because of how animateTransform only allows to provide a single
   transform even though it targets a transform list

   <heycam> To animations provide specific functionality to get a
   smooth change from the underlying value to the ‘to’ attribute value,
   which conflicts mathematically with the requirement for additive
   transform animations to be post-multiplied. As a consequence, in SVG
   1.1 the behavior of to animations for ‘animateTransform’ is

   <heycam> ScribeNick: heycam

   BB: the bigger issue is that animateTransform deals with a single
   transform, but targets a transform list

   … that's where the problem comes up

   … how are you supposed to animate lists when the list lengths differ

   VH: they all stack up

   BB: but it's a special case, no other type of animation does that

   CM: <text x=""> for example doesn't have this implicit additive
   animation behaviour

   CC: so olaf wants us to revisit this restriction?

   … is he proposing something?

   VH: this is more of a bug in the spec, having this undefined

   CC: even if it doesn't make sense?

   VH: the spec should say something
   ... we should define it, as being an error or as doing something

   CM: I'm assuming there are two different behaviours implementations
   take here?

   BB: Opera and Batik, if it can match up the transform types, it does
   a smooth interpolation

   … if it can't, then Opera will take 0 as the base value

   … and I think that's what we end up doing in Gecko, it tries to
   match it up

   ED: should we make this requirement more generic?

   VH: define all undefined things in the spec?

   ED: yes

   RESOLUTION: We will attempt to define all explicitly undefined parts
   of the SVG spec.

   CM: next, allow animateTransform type="matrix"

   VH: shouldn't this be allowed in the Transforms spec?

   DJ: yes, but Olaf doesn't like it

   ED: he wants the individual items in the matrix just interpolate

   VH: I remember we went over this years ago

   … if you do simple interpolation between matrix components, it has
   weird and unuseful visual results

   … as soon as you have a skew or rotation

   DJ: the SVG spec doesn't say how to get from matrix A to matrix B

   CL: we talked about doing piecewise interpolations

   CC: in d3.js it does each component

   DJ: it's not what we want though

   … I think SVG/SMIL animations should follow the same model that the
   combined Transforms spec says

   … which is decompose the matrix and use quaternions

   VH: or we have a switch, that's the default behaviour

   DJ: my answer to Olaf was, if there's someone who wants to do that
   they can decompose the matrix manually

   CC: you could have different type="" attribute values, type="matrix"
   and type="matrix-decomposed"

   <dino> (which unfortunately doesn't always work)

   DJ: I think his point was that he might have composed a matrix in a
   different form from what the unmatrix algorithm does

   … I think it's OK to put forward the proposal right now to do matrix
   decomposition as specified

   … that's what 99% of people will want

   RESOLUTION: We will allow <animateTransform type="matrix"> in SVG2


     [51] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse

   ED: maybe it is asking for reversing animations?

   … some way of getting the "from" or "to" value from what it is at
   the moment

   BB: the duration is a problem with animation reversing

   VH: if you do a to-animation, you have the hover effect from 0 to
   100 then 100 to 0, if halfway you start the second one, it'll have a
   dampening effect

   … the first one is still trying to get to 100

   … but it's inconsistent with CSS animations

   CM: what did we already decide for animation reversing in SVG?

   <birtles> time manipulations:

     [52] http://www.w3.org/TR/SMIL/smil-timemanip.html


     [53] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations

   BB: last year I proposed reversing behaviour

   <shepazu> +! to reversing

   … I think it's fair to split that into a separate requirement

   <shepazu> s/+!/+1/

   VH: I think Olaf is asking for something like fill="freeze" but to
   change the actual value

   CC: what's the use for that? so the next to-animation would start
   from there?

   CL: yes

   VH: but we're just guessing


     [54] http://lists.w3.org/Archives/Public/www-svg/2010Nov/0015.html

   <scribe> ACTION: Cameron to mail Olaf to clarify
   eclarative_animation_value_conservation.2Fuse [recorded in

     [55] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse

   <trackbot> Created ACTION-3199 - Mail Olaf to clarify
   eclarative_animation_value_conservation.2Fuse [on Cameron McCormack
   - due 2012-01-18].

     [57] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse

   CM: seems to be asking for a way to declaratively (on click e.g.)
   get the current animated value and stick that in a variable

   … and then use that variable as a value in another animation

   … I don't know what this buys us

   ED: I wouldn't mind seeing use cases for that

   CC: you have the first animation on an element

   … it produces a value

   <shepazu> (I think that it would be better to have some sort of
   animation state machine to drive interactions like that)

   … that value you want to keep it for each time you click on an

   … once you've run the first to-animation, the second time you run it
   it won't animate, because the underlying value is the end value of
   the to-animation, it's not the end value of the animation before

   <shepazu> yes, SCXML could do that

   <shepazu> (as done by BitFlash)

   RESOLUTION: We will not add getValue/setValue for animation value
   conservation and reuse without convincing use cases

   because this can be done easily with script

   next, animation reversing

   BB: maybe speed is useful too (from time manipulation module) but
   let's consider them separately

   CC: I will split the existing requirement request for time
   containers and time manipulation module

   CM: how does it work in Transitions and Animations?

   DJ: there's a difference between reversing the animation

   … it's just playing it backwards actually

   … auto reverse of a transition we also reverse the easing

   … like playing backwards

   … I think dbaron implemented that in Firefox

   … I'm still not completely convinced it's what you want

   … auto reversing of transitions, that is

   … if during a transition you set the target value to whereever it
   was you were coming from, in that case you reverse

   … if you went from opacity 1 to 0, halway through you went to 0.999,
   you wouldn't get the same as going back to 1

   SS: I think it depends strongly on what the designer wants

   … we have a proposal in the CSS WG to control this, specify a range
   of different reversing behaviours

   CL: sounds better than magically relying on a particular value to
   trigger that behaviour

   DJ: the magic isn't so magic because normally you want auto
   reversing on hover transitions e.g.

   … going back to the same state, it's always the same value

   CL: I agree it's useful, just quibbling with the way it's specified

   DJ: a good example is a bounce

   <cyril> I've split the proposed requirement on time manipulation and
   time container into 2 req

   … you don't want that to just play in reverse


     [58] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_manipulation_module


     [59] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers

   BB: you could just make another animation if you want different
   reversing behaviour

   … in SVG you can't do reversing with the current features

   … we need something that can do that

   … if we have the timing features you could write it either way


     [60] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations


     [61] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations


     [62] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations

   BB: I don't think I like any of the options I proposed

   … regarding the timing function, we should follow CSS Animations and
   not Transitions

   … where ease-in becomes ease-out if you reverse

   DJ: it's not just that

   … it's also as if it's an ease-out that started 0.7seconds into the

   BB: yes, you're right

   … as far as syntax I don't have a specific proposal

   … aligning with CSS Animations is important

   CM: let's discuss the other aspects of time manipulation module

   … for this requirement

   … let's start with acceleration/deceleration

   BB: I think that is keySplines on time containers

   … is that a useful feature? I think if we do time containers it
   probably is

   … it's less powerful than keySplines

   VH: but not useful on individual animations?

   <scribe> ACTION: Cyril to ask Jack Jansen the difference between
   accelerate/decelerate and keySplines [recorded in

   <trackbot> Created ACTION-3200 - Ask Jack Jansen the difference
   between accelerate/decelerate and keySplines [on Cyril Concolato -
   due 2012-01-18].


     [64] http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-autoReverseSyntax


     [65] http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-accelerateSyntax

   DJ: it's just a way to avoid writing keySplines, it's a nicer syntax
   for doing keySplines

   … I thought it was a multiplier but it's not

   … it's saying how fast it should be doing the "ease-in" part of the

   RESOLUTION: We will solve animation reversing in SVG2

   CM: then speed attribute

   BB: negative values will make it tricky

   … you have accumulated state as the animations progress

   … negative speed would take that into account

   VH: if speed is on a time container, it's like seeking back all the

   s/speed/negative speed/

   … on an animation element it's not as much of a problem

   CC: we could disallow negative speed values

   CL: for accessibility reasons some people would want to play
   animations slower than usual

   RESOLUTION: We will have support for non-negative speed="" on time
   containers (if we decide to include time containers) in SVG2

Summary of Action Items

   [NEW] ACTION: Cameron to mail Olaf to clarify
   eclarative_animation_value_conservation.2Fuse [recorded in
   [NEW] ACTION: CL to write up a short description of Tiling and
   layering and use-cases for it [recorded in
   [NEW] ACTION: CL to write up general use-cases (mapping and other)
   for constrained transformations, aka transform=ref(...) [recorded in
   [NEW] ACTION: Cyril to ask Jack Jansen the difference between
   accelerate/decelerate and keySplines [recorded in

     [66] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse

   [End of minutes]

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups
Received on Wednesday, 11 January 2012 23:01:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:14 UTC