SVG WG Sydney 2012 F2F day 1 -- 10 Jan 2012

<dino> agenda link?

<cabanier> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda

<vhardy> ScribeNick: vhardy

http://www.speedtest.net/result/1699186634.png

<cabanier> cyril is having some issues with his computer

heycam: let's start with the first topic

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

support HTML's entities in SVG.

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

heycam: the request is that HTML entities be available in SVG content.
... 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.

<shepazu> 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 etc

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 well.

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> 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 parallel.

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 group.

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 people)

<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

Mapping

+doug

+dirk

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

<jun> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping

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

Jun: Links above for mapping requirements and tiling.

<stakagi> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Tiling_and_Layering

<stakagi> Dirk-san's comment 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 http://lists.w3.org/Archives/Public/public-svg-wg/2011OctDec/0117.html

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

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

<stakagi> 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 transforms)

<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 data.

<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 hyperlinks.

<ChrisL> I wanted to point to some earlier work on multi-resolution images (SVG 1.2 full) 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 practice.

cameron shows example

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

Vincent: I propose collecting use cases

<jun> <globalCoordinateSystem

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

<jun> transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>

<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 transform?)

<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 proposal)

<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 explicitly

<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> <globalCoordinateSystem

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

<ed> transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>

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

<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> 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 file.

<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 <svg:image>

<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. :/

MASS CONFUSION EVERYWHERE

<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 resource

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 definied

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

<TabAtkins> Me too. ;_;

<stakagi> http://sourceforge.net/projects/wwwmap/

<stakagi> LGPL implementation

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

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

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

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 purpose.

<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 data

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 coords.

<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 example.

<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 gcs.

<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. 'glovalCoordnateSystemURI'

<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 "this-is-a-map"

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 afterwards.

---- 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 http://www.w3.org/2012/01/10-svg-minutes.html#action01]

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

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

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

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Vector_effect -- non-scaling stroke

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Shared_paths

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Fixed-size_object -- transform ref

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 really

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

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

<ChrisL> 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 usefulness
... 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

<ChrisL> 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 group?

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 implemented

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 http://www.w3.org/2012/01/10-svg-minutes.html#action02]

<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].

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Alternative_transforms

CL: it's been considered before

<heycam> (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

<heycam> 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 content
... 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 projections/

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 viewbox

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

<heycam> 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 view
... 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

<heycam> 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

<heycam> 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 animation
... 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 it...

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

<heycam> 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

<cyril> http://soln-sr3450.movielink.net.au/common_ip_cgi/prepaid_access.cgi?MAC_ADDRESS=00:24:d7:85:22:80&ASSIGNED_IP=10.71.15.82&ROOM_NO=WAP-316&FLAGS=3&PORT_ID=243&STATUS=8&VLAN_ID=66&UID=28656

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

<heycam> 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 element)

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> http://www.openstreetmap.org/ 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

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#to-animateTransform_definition

2.14.4

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

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

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

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 undefined.

<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

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: http://www.w3.org/TR/SMIL/smil-timemanip.html

<birtles> 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

<birtles> http://lists.w3.org/Archives/Public/www-svg/2010Nov/0015.html

<scribe> ACTION: Cameron to mail Olaf to clarify http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse [recorded in http://www.w3.org/2012/01/10-svg-minutes.html#action03]

<trackbot> Created ACTION-3199 - Mail Olaf to clarify http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Declarative_animation_value_conservation.2Fuse [on Cameron McCormack - due 2012-01-18].

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 element

… 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 that

<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

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_manipulation_module

<cyril> 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

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations

<ed> 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 animation

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 http://www.w3.org/2012/01/10-svg-minutes.html#action04]

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

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

<cyril> 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 curve

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 time

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

- DRAFT -

SVG WG Sydney 2012 F2F day 1

10 Jan 2012

Attendees

Contents

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

support HTML's entities in SVG.

Mapping

mapping requirements (continued from last slot)

SVG2 Requirements

Summary of Action Items

Scribe.perl diagnostic output