W3C home > Mailing lists > Public > www-svg@w3.org > January 2012

minutes, SVG WG Sydney 2011 F2F day 1

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 11 Jan 2012 17:33:22 +1100
Message-ID: <4F0D2D32.40404@mcc.id.au>
To: SVG public list <www-svg@w3.org>


       [1] http://www.w3.org/

                                - DRAFT -

                      SVG WG Sydney 2012 F2F day 1

10 Jan 2012


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

    See also: [3]IRC log

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


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


           vhardy, dino, ed, birtles, heycam


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

    <dino> agenda link?


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

    <vhardy> ScribeNick: vhardy


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

    <cabanier> cyril is having some issues with his computer

    heycam: let's start with the first topic


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

support HTML's entities in SVG.

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

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

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

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

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

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

    <heycam> TabAtkins, yes, that will work

    heycam: doug, do you have comments?

    <heycam> ack

    doug: people will want to use the same entities.

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

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


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

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

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

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

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

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

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

    <TabAtkins> We can fix that.

    doug: and they do not know the unicode.

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

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

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

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

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

    <TabAtkins> I agree with heycam

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

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

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

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

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

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

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

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

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

    heycam: I think people like the XML5 idea.

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

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

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

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

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

    heycam: in the group?

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

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

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

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

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

    doug: ok.

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

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

    chris: so resolve and wont-fix?

    heycam: yes.

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

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

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

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

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

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

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

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

    <heycam> [15 minute break]

    <dino> ScribeNick: dino




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


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

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

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

    Jun: Links above for mapping requirements and tiling.



    <stakagi> Dirk-san's comment


    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


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

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

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

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

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

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

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

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

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

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

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

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

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

    <TabAtkins> Or coords.

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

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

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

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

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

    Cameron: (generally agrees with generic approach)

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

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

    JunF: other things can be developed separately

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

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

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

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

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

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

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

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

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

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

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

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

    <ChrisL> LinkedOpen Data

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

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

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

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

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

    Cameron: That's part of the document.

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

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

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

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

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

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

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

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

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

    cameron shows example

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

    Vincent: I propose collecting use cases

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

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

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

    <jun> <globalCoordinateSystem

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

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


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

    <jun> </svg>

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

    Cyril: The point is that it exists in the file

    Chris: and it defines where you start

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

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

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

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

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

    Cyril: This is not giving any bound information

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

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

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

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

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

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

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

    <ed> <globalCoordinateSystem

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

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


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

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

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

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

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

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

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

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

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

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

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

    <stakagi> pluase see

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

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

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

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

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

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

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

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

    <TabAtkins> Or, hm.

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

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


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

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

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

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

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

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

    <cyril> it's specified in SVG 1.2 Tiny

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

    Cameron: why not always be <g>?

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

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

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

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

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

    <TabAtkins> Me too. ;_;

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

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

    <stakagi> LGPL implementation

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

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

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

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

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

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

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

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

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

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

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

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

    <TabAtkins> ed, agreed.

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

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

    <birtles> ChrisL also brought up the issue of precision

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

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

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

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

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

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

    <cyril> I don't understand the questions.

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

    <TabAtkins> Let me try again.

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

    <TabAtkins> But why is this necessary?

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

    Cameron: someone needs to distill this proposal into a clear

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

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

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

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

    <TabAtkins> Okay, that makes sense.

    Dean: for example, floor plan of a building

    Vincent: or components in machinery

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

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

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

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

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

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

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

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

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

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

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

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

    and every other use case is a free for all

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

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

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

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

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

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

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

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

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

    ---- LUNCH ----

    <heycam> [for one hour]

    <ed> scribeNick: ed

mapping requirements (continued from last slot)

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

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

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

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

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

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

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

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

    Vector_effect -- non-scaling stroke




    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

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

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

    ED: yes

    CM: is there content taht uses it?

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

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

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

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

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

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

    CM: anyone object to having transform-ref in svg2

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


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

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

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

    CL: it points to which coordinate system it uses

    (explains the tranform-ref functionality)

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

    CL: pinned video in svg tiny 1.2 is similar

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

    RC: transform-origin in css is similar too

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

    <ChrisL> 3.4.1 Constrained Transformations



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

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

    CL: you could say the same about position:fixed

    <heycam> about position:fixed

    BB: just wondering about use-cases outside of mapping

    CC: trying to remember the use-cases

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

    CL: callouts, on objects that have text

    VH: you want things to follow along, but nonscaled

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

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

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

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

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



    CL: it's been considered before



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



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

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

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

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

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

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

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

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

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

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

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

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

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

    CM: propose that we don't include UI controls

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

    CM: yes, dailey

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

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

    CL: geolocation is an api

    CC: but this is a declarative way

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



    CC: does feature phones have javascript engines?

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

    CL: yes

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

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

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



    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



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

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

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

    BB: difficult to spec I think

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

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

    BB: you may need events for this

    CM: so to fade between different detail?

    BB: yes, maybe

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

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



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



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



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

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

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

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

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

    CM: is this for tiling and layering?

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

    <stakagi> potentially Open Street Map and Open Layers

    <stakagi> communities are candidate

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

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

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

    <ChrisL> web mapping community group

    DS: we could have a dedicated mapping com group

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

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

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

    --- 15min BREAK ---

SVG2 Requirements

    <birtles> ScribeNick: birtles




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



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

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

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

    <heycam> ScribeNick: heycam

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

    … that's where the problem comes up

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

    VH: they all stack up

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

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

    CC: so olaf wants us to revisit this restriction?

    … is he proposing something?

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

    CC: even if it doesn't make sense?

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

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

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

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

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

    ED: should we make this requirement more generic?

    VH: define all undefined things in the spec?

    ED: yes

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

    CM: next, allow animateTransform type="matrix"

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

    DJ: yes, but Olaf doesn't like it

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

    VH: I remember we went over this years ago

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

    … as soon as you have a skew or rotation

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

    CL: we talked about doing piecewise interpolations

    CC: in d3.js it does each component

    DJ: it's not what we want though

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

    … which is decompose the matrix and use quaternions

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

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

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

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

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

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

    … that's what 99% of people will want

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



    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



    BB: last year I proposed reversing behaviour

    <shepazu> +! to reversing

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

    <shepazu> s/+!/+1/

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

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

    CL: yes

    VH: but we're just guessing


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

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


    <trackbot> Created ACTION-3199 - Mail Olaf to clarify
    eclarative_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

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

    <shepazu> yes, SCXML could do that

    <shepazu> (as done by BitFlash)

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

    because this can be done easily with script

    next, animation reversing

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

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

    CM: how does it work in Transitions and Animations?

    DJ: there's a difference between reversing the animation

    … it's just playing it backwards actually

    … auto reverse of a transition we also reverse the easing

    … like playing backwards

    … I think dbaron implemented that in Firefox

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

    … auto reversing of transitions, that is

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

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

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

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

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

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

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

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

    DJ: a good example is a bounce

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

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





    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







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

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

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

    DJ: it's not just that

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

    BB: yes, you're right

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

    … aligning with CSS Animations is important

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

    … for this requirement

    … let's start with acceleration/deceleration

    BB: I think that is keySplines on time containers

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

    … it's less powerful than keySplines

    VH: but not useful on individual animations?

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

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





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

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

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

    RESOLUTION: We will solve animation reversing in SVG2

    CM: then speed attribute

    BB: negative values will make it tricky

    … you have accumulated state as the animations progress

    … negative speed would take that into account

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

    s/speed/negative speed/

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

    CC: we could disallow negative speed values

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

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

Summary of Action Items

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


    [End of minutes]

     Minutes formatted by David Booth's [71]scribe.perl version 1.136
     ([72]CVS log)
     $Date: 2012/01/11 06:29:06 $
Received on Wednesday, 11 January 2012 06:34:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:33 UTC