- From: Chris Lilley <chris@w3.org>
- Date: Thu, 12 Jan 2012 00:00:57 +0100
- To: SVG WG <public-svg-wg@w3.org>
Hello SVG,
Minutes in HTML at
http://www.w3.org/2012/01/10-svg-minutes.html
and below as text:
SVG WG Sydney 2012 F2F day 1
10 Jan 2012
[2]Agenda
[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
Attendees
Present
Doug_phone, Dirk_phone, Vincent, Cameron, Erik, Dean,
Takagi-san, Dean, Jun, Cyril, Brian, Chris, Rik
Regrets
Chair
Cameron
Scribe
vhardy, dino, ed, birtles, heycam
Contents
* [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?
<cabanier>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
[11] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/Agenda
<vhardy> ScribeNick: vhardy
[12]http://www.speedtest.net/result/1699186634.png
[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
[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
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>
[15]http://www.w3.org/TR/html5/named-character-references.html
[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
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> [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
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>
[17]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping
[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.
<stakagi>
[19]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
Tiling_and_Layering
[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/011
7.html
[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/011
7.html
[21] 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> [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
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)
[23]http://www.w3.org/TR/2004/WD-SVG12-20041027/media.html#multires
[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
practice.
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>
transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
<jun> <circle cx="258.1401" cy="185.1558" r="10.0" stroke="none"
fill="green"/>
<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
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> <svg xmlns="[26]http://www.w3.org/2000/svg" viewBox="20 110 120
85">
[26] http://www.w3.org/2000/svg
<ed> <globalCoordinateSystem
<ed> srsName="[27]http://purl.org/crs/84"
[27] http://purl.org/crs/84
<ed>
transform="matrix(15.3631,0.0,0.0,-18.6994,-1889.2916,849.9202)"/>
<ed> <animation x="0" y="0" width="100" height="70"
xlink:href="0_0.svg"/>
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"
xlink:href="1_0.svg"/>
<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
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> [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
images
<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
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
[31]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>
[32]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
Vector_effect -- non-scaling stroke
[32] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Vector_effect
<heycam>
[33]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
Shared_paths
[33] http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#Shared_paths
<heycam>
[34]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
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
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>
[35]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input
[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
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>
[36]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onstrained_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
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
[37]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>
[38]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#A
lternative_transforms
[38] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Alternative_transforms
CL: it's been considered before
<heycam>
([39]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping
#Non-linear_transformation)
[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
<heycam>
[40]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
Built-in_User_Interface
[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
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>
[41]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
Programming-less_geolocation
[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
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>
[42]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
Setting_SVG_views_by_IRI_fragments_using_geographic.28global.29_coor
dinates
[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
<heycam>
[43]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
API_for_smooth_transition_action_of_zooming.2Cpannning.2Crotating
[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
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>
[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
[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
<cyril>
[45]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=W
AP-316&FLAGS=3&PORT_ID=243&STATUS=8&VLAN_ID=66&UID=28656
[45] 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>
[46]http://www.w3.org/Graphics/SVG/WG/wiki/Requirements_for_Mapping#
DOM_access_API_for_cascading_SVG_Documents
[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
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> [47]http://www.openstreetmap.org/
[48]http://openlayers.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
<cyril>
[49]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#t
o-animateTransform_definition
[49] 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
[50]http://brian.sol1.net/svg/animatetransform-issues/to-animation-a
nd-animatetransform/
[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
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
[51]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
eclarative_animation_value_conservation.2Fuse
[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
[52] http://www.w3.org/TR/SMIL/smil-timemanip.html
<birtles>
[53]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_improvements#Wanted_feature:_reversing_animations
[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
<birtles>
[54]http://lists.w3.org/Archives/Public/www-svg/2010Nov/0015.html
[54] http://lists.w3.org/Archives/Public/www-svg/2010Nov/0015.html
<scribe> ACTION: Cameron to mail Olaf to clarify
[55]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
eclarative_animation_value_conservation.2Fuse [recorded in
[56]http://www.w3.org/2012/01/10-svg-minutes.html#action03]
[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
[57]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
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
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>
[58]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_time_manipulation_module
[58] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_manipulation_module
<cyril>
[59]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_time_containers
[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
<birtles>
[60]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_improvements#Wanted_feature:_reversing_animations
[60] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations
<cyril>
[61]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_improvements#Wanted_feature:_reversing_animations
[61] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Wanted_feature:_reversing_animations
<ed>
[62]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
on_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
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
[63]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].
[64]http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-autoReve
rseSyntax
[64] http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-autoReverseSyntax
<cyril>
[65]http://www.w3.org/TR/SMIL/smil-timemanip.html#TimeManip-accelera
teSyntax
[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
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
Summary of Action Items
[NEW] ACTION: Cameron to mail Olaf to clarify
[66]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#D
eclarative_animation_value_conservation.2Fuse [recorded in
[67]http://www.w3.org/2012/01/10-svg-minutes.html#action03]
[NEW] ACTION: CL to write up a short description of Tiling and
layering and use-cases for it [recorded in
[68]http://www.w3.org/2012/01/10-svg-minutes.html#action01]
[NEW] ACTION: CL to write up general use-cases (mapping and other)
for constrained transformations, aka transform=ref(...) [recorded in
[69]http://www.w3.org/2012/01/10-svg-minutes.html#action02]
[NEW] ACTION: Cyril to ask Jack Jansen the difference between
accelerate/decelerate and keySplines [recorded in
[70]http://www.w3.org/2012/01/10-svg-minutes.html#action04]
[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