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

minutes, Rigi-Kaltbad SVG WG F2F 2012 - Day 2

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 18 Sep 2012 18:25:17 +0200
Message-ID: <5058A06D.4030706@mcc.id.au>
To: SVG WG <public-svg-wg@w3.org>


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

                                - DRAFT -

                     SVG Working Group Teleconference

18 Sep 2012


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


           Cameron, Doug, Chris, Cyril, Erik, Tab, Nikos,
           Takagi-san, Konno-san, Brian, Dirk, Rik


           Cyril Concolato, Cyril


      * [3]Topics
          1. [4]mask-box-image, mask-image, clip-path: <shape>,
             apply on obb?
          2. [5]New value names -moz-objectFill, -moz-objectStroke,
             -moz-objectValue (for
          3. [6]Connectors
          4. [7]Stars
          5. [8]Dynamic document loading
          6. [9]zooming and panning
          7. [10]performances to transition in zooming and panning
          8. [11]Mapping applications issues
          9. [12]SVG2 fallback for modules that are behind.
         10. [13]Moving the spec to git/github
         11. [14]Change appendixes
         12. [15]Next f2f meeting
         13. [16]What to do with xml:base?
         14. [17]What do do with version and baseProfile?
         15. [18]What about xml:lang and lang?
         16. [19]svg:transform
         17. [20]<animateColor>
      * [21]Summary of Action Items

    <heycam> trackbot, start telcon

    <trackbot> Date: 18 September 2012

    <heycam> Zakim: remind me in 8 hours to enjoy the view

    <birtles> scribenick: birtles

mask-box-image, mask-image, clip-path: <shape>, apply on obb?



    krit: we need to define what the border-box is
    ... we did it yesterday for mask-image and I'd like to do the
    same here
    ... it's so we can do tiling

    ChrisL: how does this apply to SVG?
    ... we don't have borders

    TabAtkins: we have decorated bounding boxes which map to

    krit: it's mainly used for images
    ... to add a border

    ChrisL: so why not add it just to images

    shepazu: stroke would be enough for that

    krit: everything inside the border box is affected by the
    border box

    heycam: do mask-image and border-box cover the same region

    krit: yes, but they allow you to specify the mask differently

    ChrisL: then I agree it should apply to the painted box

    cabanier: why is this not a property on a mask image?

    ChrisL: because it's constructing an image from a mask image
    ... this controls the way it scales

    cabanier: why don't you just say, mask-image, "9 slice"?
    ... is this just to copy what CSS does?

    krit: yes

    RESOLUTION: mask-box-image works on the decorated bounding box

    next, is clip-path: <shape>



    krit: we have new shapes, borrowed from CSS exclusions
    ... ellipse, etc.
    ... the problem is they can use percentages
    ... we need to resolve what they resolve against

    heycam: normally it would be against the clipPath element but
    you don't have that here

    krit: that's right

    heycam: in CSS it's just resolved against the containing block

    krit: the problem is if you use the geometric bounding box
    you'll lose half the stroke

    heycam: that's also the case with objectBoundingBox units on
    the clipPath element
    ... you can use negative percentages etc. to work around it
    ... if we decided clip-path always meant geometric bounding box
    (like objectBoundingBox) then you could still use negative
    percentages there too
    ... just like with the clipPath element
    ... that said, I don't like that
    ... because you don't know exactly how much you need to extend
    the box
    ... e.g. -10% may or may not be enough

    cabanier: so you can apply this to SVG?

    krit: yes, that's right

    heycam: for mask etc. we've decided to use the painted bounding
    box right?

    krit: yes
    ... the painted bbox may differ slightly between platforms due
    to how stroking is calculated

    heycam: I think there are three options
    ... (a) geometric bbox for consistency with objectBoundingBox
    ... (b) is painted bbox for consistency with masking
    ... (c) make it controllable

    krit: for masking it's already (c)
    ... there's the mask-size and mask-origin properties
    ... mask-clip and mask-origin actually

    heycam: it looks like mask-clip can do the clipping and the
    percentage values differently
    ... i.e. clip to one box and have percentages relative to
    another box
    ... mask-clip says which box to clip to

    krit: mask-origin just says which of the boxes defines the
    ... border-box is the painted area and content-box is the bbox

    heycam: the mask properties seem to allow you to control these
    two things (clipping box and origin) separately
    ... but SVG doesn't allow that
    ... for mask it's controllable
    ... but for clip-path is doesn't need to be controllable?

    krit: yes
    ... we need to decide which box to use

    ed: clip paths are always geometrical
    ... in SVG

    heycam: if we make this like objectBoundingBox (geometric) then
    it's like SVG

    ed: clip paths are always just a shape

    krit: the geometric bbox is probably more predictable for users

    heycam: why isn't that always the case for mask

    krit: well we already have those properties for mask

    heycam: why is it useful for masks to have this control but not
    clip paths?

    krit: the mask properties are just there because they already

    heycam: is it useful

    krit: for HTML, it seems to

    cabanier: so should we add this to clip path too?

    krit: so we'd need to clip-path-clip?

    cabanier: instead of duplicating everything why don't we align
    mask and clip so you just make a mask that does a hard clip?

    heycam: I think we've discussed changing the SVG unit selection
    to allow using the stroked bbox
    ... so it might be useful to introduce this control to SVG too

    krit: we could add another property to specify the box for clip
    ... but HTML also might want to clip away overflow

    heycam: overflow: hidden?

    krit: not sure you always want that

    heycam: if we use percentage values for the shape then it's
    similar to using objectBoundingBox
    ... but if you use regular lengths it's like userSpaceOnUse but
    translated to the top-left of the bounding box
    ... do you disagree that clip path should have more control

    TabAtkins: if it's just for percentages I don't care

    heycam: but people will use lengths too

    krit: right
    ... the clip path element has no hard clipping area unlike

    heycam: because there's no clip-path-clip property?

    krit: right

    heycam: clip-path-clip is a bit weird...
    ... you need to do geometry operations to combine the clip
    rectangle with the clip path

    krit: or you just do two clips

    heycam: what is the default for mask... which box?

    krit: border-box (paint area)

    heycam: I think it would be good to have clip default to tht
    ... and maybe have control

    krit: I'll add an issue for that

    ed: I think that's reasonable
    ... probably what you want most of the time is the stroked bbox

    heycam: I'm not exactly sure
    ... it might be ok for percentages
    ... but once you have strokes and lengths it might actually be
    harder to use

    cabanier: I think so too

    krit: so objectBoundingBox might actually make sense with the
    negative percentages

    heycam: but then doesn't that apply to masks too?

    krit: yes, but that's already there

    heycam: I'm happy for this to be an issue in the spec
    ... but I would err on the side of consistency with mask (i.e.
    painted bbox)
    ... the ability to control this would also probably be good

    cabanier: also, you can stroke within a mask
    ... but if you do clipping, you can't stroke the clip path

    <scribe> ACTION: Dirk to add an issue to CSS masking about
    which bounding box to use for percentages in clip-path shape
    definitions [recorded in

    <trackbot> Created ACTION-3362 - Add an issue to CSS masking
    about which bounding box to use for percentages in clip-path
    shape definitions [on Dirk Schulze - due 2012-09-25].

    ed: going back to mask-box-image
    ... what if you wanted to do a filter
    ... that wouldn't be included in the decorated bbox
    ... it would be nice to slice up a filtered image
    ... e.g. a drop shadow

    krit: but we have the issue we're not able to calculate the
    filtered bbox

    cabanier: if you use the shorthand you should know

    krit: but some a potentially infinite

    cabanier: in *some* cases you will know

    krit: but in general, we don't

    cabanier: for shorthands you should know

    krit: is that defined?

    cabanier: if not, perhaps it should be

    krit: but for SVG filters it's not defined
    ... the filter region must be defined by the user
    ... and in many examples the filter region ends up being
    equivalent to the viewbox size

    ed: for us, internally we can calculate the filtered bbox

    krit: but the lighting effect is still infinite
    ... but you clip it to viewbox
    ... also feTile etc. is infinite

    ed: you could use the filter region
    ... I think the most common case is when you use a shadow
    ... people will often run into the problem when their shadow is
    clipped away

    krit: mask-clip and mask-origin would need a new keyword to use
    the filter region
    ... this needs to be checked with the CSS WG as well

    cabanier: if you do a text shadow is it defined how big it is

    krit: the region is not defined

    cabanier: it would be useful there as well
    ... since you don't want to clip that shadow either

    krit: what's the order, masking then clipping?
    ... it matters if you're depending on the size of the bounding

    cabanier: you can always work around it
    ... by adding an extra <div> or <g>

    krit: yes, so what's more intuitive for the author
    ... if we add a keyword for the filter region
    ... then at least the user would know they need to set the
    filter region correctly

    ed: I think that would be ok

    krit: how do you define the filter region for shorthands?
    ... we can discuss that later
    ... let's discuss it on the mailing list

    <scribe> ACTION: Erik to send a mail to a suitable mailing list
    about defining the filter region for filter shorthands (so we
    can define masks to include the filtered result) [recorded in

    <trackbot> Created ACTION-3363 - Send a mail to a suitable
    mailing list about defining the filter region for filter
    shorthands (so we can define masks to include the filtered
    result) [on Erik Dahlström - due 2012-09-25].

New value names -moz-objectFill, -moz-objectStroke, -moz-objectValue
(for stroke-{dash{array,offset},width})

    heycam: as part of the SVG in OpenType work
    ... Edwin has added these new prefixed values which are similar
    to those Chris previous proposed
    ... -moz-objectFill and -moz-objectStroke are the same as
    useFillPaint and useFillStroke

    krit: why are they prefixed?
    ... they're just keywords

    heycam: actually, they might not be prefixed since they're
    behind a pref

    (discussion about prefixing policy)

    heycam: in any case, no one's using this feature yet but we
    need to settle on the names

    cyril: these keywords were proposed for markers right?

    heycam: yes, but they're not actually implemented there yet
    ... for now they have been implemented for SVG in OpenType

    <ChrisL> huh -

      [26] http://lists.w3.org/Archives/Public/www-svg/2007Jun/0006.html


      [27] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects



    (Cameron shows demo of SVG in OpenType in Firefox Nightly)


      [29] http://people.mozilla.org/~cmccormack/temp/svg-glyph-basic.svg


      [30] http://people.mozilla.org/~cmccormack/temp/smiley.svg

    ChrisL: I like currentFill and currentStroke from vector


      [31] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Vector_effects

    ChrisL: but I don't like the names useCurrentFill and
    ... and I find objectFill and objectStroke confusing

    nikos: what about contextFill and contextStroke?

    ChrisL: I like that

    heycam: not bad
    ... or referencedFill / referencedStroke
    ... but which direction is the reference?

    shepazu: I don't mind 'auto', i.e. takes the fill if used on
    the fill
    ... I like context

    heycam: what about contextValue
    ... imagine text has a stroke on it
    ... and you want to use that stroke on a circle in your
    glyph/marker etc.
    ... you can't just use, e.g. the context stroke width there
    since it's a different coordinate system
    ... it automatically adjusts the stroke-width, dash array etc.
    to match the target coordinate system

    ChrisL: it auto scales the values by the ratio of the two
    coordinate systems

    Tav: if I have two different size chars, e.g. super script etc.
    ... what happens to the width?

    ChrisL: nothing
    ... the scaling should be the same for all glyphs as they are
    defined on the same glyph coordinate system (em square)
    ... if you're faking small caps, superscript etc. but applying
    a transform you'll have problems
    ... but that sort of approach is going away in favor of doing
    it corectly tith opentypefeatures, see CSS3 Fonts

    krit: if you have a pattern, can elements inside the pattern
    use these keywords too
    ... which context will it reference?

    heycam: the element which references the pattern
    ... it means if you implement patterns using bitmaps you may
    need to generate different pattern bitmaps based on where it is

    krit: imagine you have a chain of patterns where the elements
    of a pattern references another pattern
    ... which context do you use in the nested context?

    shepazu: it goes to the parent
    ... whichever is the least number of hops
    ... or whatever doesn't lead to infinite loops

    ChrisL: if you limit it to one level, i.e. the pattern level,
    then you could still do longer chaining by setting <pattern

    <ChrisL> resolved: change use* values to context*

    Cyril: what do these values mean outside of a referencing

    ChrisL: if there isn't a context, contextFill means

    heycam: well, currentFillPaint means the fill on this element

    ChrisL: you want to be able to swap the values over without
    having infinite recursion

    heycam: and that only works if you look to the parent

    ChrisL: I originally added the "paint" to the end of the
    keyword to clarify that it is actually a paint and not just a

    birtles: also contextStroke sounds like it includes the stroke
    width, dash array etc, but contextStrokePaint is clear that
    it's just the paint server

    heycam: also I forgot to mention there's also
    -moz-objectFillOpacity, -moz-objectStrokeOpacity so you can
    swap them as well

    <scribe> ACTION: ChrisL to write up contextFill(Paint),
    contextStroke(Paint) proposal in coordination with Cameron
    [recorded in

    <trackbot> Created ACTION-3364 - Write up contextFill(Paint),
    contextStroke(Paint) proposal in coordination with Cameron [on
    Chris Lilley - due 2012-09-25].

    heycam: one reason to prefer contextFill over contextFillPaint
    (i.e. dropping the "paint" word) is that then the part after
    "context" matches the corresponding property

    ChrisL: I'm probably ok with that

    heycam: also, as Doug mentioned should we use a camelCase name
    or a css-like-name?

    Tav: we already have currentColor

    shepazu: we can alias it with current-color

    ChrisL: yes, let's not follow the precedent of currentColor if
    it's disliked
    ... let's put dashes in all of them

    shepazu: Dash-All-The-Things!

    <ChrisL> action-3364?

    <trackbot> ACTION-3364 -- Chris Lilley to write up
    contextFill(Paint), contextStroke(Paint) proposal in
    coordination with Cameron -- due 2012-09-25 -- OPEN


      [33] http://www.w3.org/Graphics/SVG/WG/track/actions/3364

    RESOLUTION: We will name the context keywords in CSS style and
    without the paint keyword, e.g. context-fill,
    context-fill-opacity, context-value etc.

    <scribe> ACTION: Chris to propose the aliasing of current-color
    to currentColor with the CSS WG [recorded in

    <trackbot> Created ACTION-3365 - Propose the aliasing of
    current-color to currentColor with the CSS WG [on Chris Lilley
    - due 2012-09-25].

    Cyril: we said fill="current-fill" is like inherit, isn't that

    heycam: I'm not sure about current-fill, only context-fill
    ... is current-fill valuable if we have context-fill?

    Cyril: I think if we say context-fill and there's no
    referencing happening then the context is the parent?

    <ed> <rect fill="context-stroke" stroke="current-fill" />

    heycam: if we can make context-fill meet the needs of
    current-fill then we might not need both values

    ChrisL: another reason I put "paint" on the end of the keywords
    was to match the keywords in filters, e.g. FillPaint

    Cyril: another question about context-value, why didn't you use
    percentages in the first place?
    ... couldn't you meet the need with percentages?

    heycam: percentages inside the glyph will be relative to the
    glyph coordinate space which is 0 to 2000
    ... they don't get transformed into the coordinate space of the
    referencing context

    Cyril: if you say stroke="3" and the coordinate system has a
    width of 300 and you want the stroke to be 1% right?

    heycam: you don't choose the percentage inside the glyph
    ... that's the choice of the referencing context, not the font
    ... you don't inherit across documents

    Cyril: the document coordinate space is 300 wide
    ... the width you want on the stroke is 3 pixels wide, i.e. 1%
    ... ok, I'll think about it
    ... the context-value goes across documents
    ... unlike inherit
    ... that needs to be noted

    ed: can that apply to any value?

    heycam: no, just fill and stroke properties
    ... hmm, and I suppose the context-fill-opacity and
    context-stroke-opacity properties should also be allowed on the
    opacity property (as not very comfortable just fill-opacity and
    ... I'll look into the implementation in Gecko and see what it
    currently does

    <heycam> [35]https://github.com/edf825/SVG-OpenType-Utils --
    scripts for inserting SVG documents as a table in the OpenType

      [35] https://github.com/edf825/SVG-OpenType-Utils

    <heycam> use the pyinsertsvg directory

    -- break for 15mins --

    <andreas> here is a nice astronomic clock from prague:

      [36] http://drifted.in/horologium-app/

    <Cyril> scribe: Cyril Concolato


    <Cyril> scribe: Cyril


      [37] http://dev.w3.org/SVG/modules/connector/SVGConnector.html

    <scribe> scribeNick: Cyril

    scribe-nick: Cyril

    DS: if you're not familiar with the spec

    <shepazu> [38]http://schepers.cc/w3c/svg/connector/

      [38] http://schepers.cc/w3c/svg/connector/

    DS: the connectors connect shapes
    ... even if sometimes the connector don't touch the shape
    ... there is a logic in the connection
    ... you can't figure out if it is connected or not
    ... I made a script library
    ... the idea is that we will add several attributes
    ... that can go on any rendering elements
    ... we would add one element
    ... 2 elements
    ... the SVG point element does not render
    ... the SVG connector element
    ... there was an idea on having the connector as an attribute
    ... going to center points, without path routing, is not
    visually satisfactory for the user
    ... maybe we want to have connector points located on the shape
    ... the idea is to have SVG points define ports
    ... name it, and say that a line connects to this named port
    ... this is the basics of the connector proposal
    ... i don't think people will use it if there is no drawing
    ... later on if this is a successful, we could add routing
    ... but maybe this could be done with script
    ... for now it is only semantic
    ... as an author I want to define where the ports are

    ed: how does it work when you animate the path

    DS: this is not the perfect proposal
    ... if you are animating the shape, morphing, you'd have to
    animate the ports too

    ed: would it be useful to anchor them on top, bottom, left ...

    ds: on rectangles yeah, but not on any shape

    dirk: did you see the DIA library
    ... there are use cases where you want different type of

    <ChrisL> [39]http://en.wikipedia.org/wiki/Dia_%28software%29

      [39] http://en.wikipedia.org/wiki/Dia_%28software%29

    nikos: what about using markers

    tav: but we can't apply markers on rectangles

    dirk: most people are fine if we define it only for paths
    ... there are details that can be improved

    ds: with markers being child of elements, the marker is a good

    tav: you can define ports using percentages

    cam: if you are changing it in one dimension, the percentages
    will change

    ds: I don't mind if we yoke markers

    dirk: markers should just visualize points but not describe

    tav: yes

    ds: right now the point element is simply x,y
    ... we could adapt it to have smarter positing for markers

    dirk: is there a drawing order

    ds: marker, fill, stroke and then connectors

    dirk: do you want to have it under the shape, above the shape

    ds: we could use z-index

    cl: I don't see why we need additional tools
    ... z-index and document order should be enough

    tav: it would be nice to have an auto-path

    ds: empty d or no d, it renders automatically

    nikos: does it scale ?

    ds: with auto yes, but when you remove auto, you'll have to
    handle the rendering

    <scribe> ACTION: Doug to work on event handling on connectors
    [recorded in

    <trackbot> Created ACTION-3366 - Work on event handling on
    connectors [on Doug Schepers - due 2012-09-25].

    heycam: I like the proposal a bit more
    ... but I'm worried with line routing
    ... straight lines is often not what you want
    ... but I'm not convinced that you want routing in the spec
    ... but if it would be easy for script to do the routing, I
    would be convinced

    cl: that's always been my main concern
    ... we should not have a routing algorithm

    tav: inkscape implements connects
    ... it uses path with special attributes
    ... start object, and end object, and points on these objects
    ... there are a few routing hints
    ... go through, go round (like an exclusion)
    ... it's a path so it uses document order or z-indexing
    ... the scripting engine does the routing

    ds: if we have an API, it would expose ports, type of ports,
    connections on each port ...
    ... if the strings of the port and connectors match, they join

    <ChrisL> [41]http://fritzing.org/news/new-autorouter/

      [41] http://fritzing.org/news/new-autorouter/

    ds: if in the future we decide to have routing, we could plug
    in an algorithm
    ... via script
    ... but a little less complex that what I made
    ... or via CSS
    ... selecting via well define routing algorithms
    ... the rastereffect things could be used
    ... 90° angles with rounded corner
    ... you can also define points inside connectors
    ... the point can change
    ... you can have straight line or polylines

    dirk: the rounded thing could go into a second level of the

    tav: you're propsing a new connector element

    ds: yes

    dirk: I think it would be better as attributes on the path

    ds: there is something about that that bothers me
    ... it changes the way the path works

    cl: it overloads the path too much for me
    ... I'm concerned that it messes up path

    heycam: it you would want to do it, you could extend the path
    syntax d="Shape1.port1 shape2.port1"

    tav: what would browser most likely implement?

    heycam: changing the path would not be sufficient to make the
    semantics clear

    ds: there is a question of API: connector API vs path API
    ... my specific proposal is: should I move forward or not?
    ... I studied all the major syntaxes for graphs
    ... you can describe all graphs

    dirk: can you use symbol svg elements

    heycam: I might be more amenable to the proposal if we could do
    better port positioning

    tav: you can use 'calc()'

    ds: I struggled to have something good
    ... find use cases that it doesn't solve and I'll fix it

    (brian's silence)

    brian: is this part of SVG 2?

    ds: perharps call it SVG 2 connectors as a separate spec
    ... a module

    RESOLUTION: Connectors will be specified as a SVG 2 Connector

    brian: so the primary benefit of this is the semantics?

    ds: It is a new feature, unique to SVG, graphics and semantics

    brian: there is already lots of things to do graphs

    ds: yes, but this one brings semantics
    ... the original SVG proposal included connectors
    ... things like Visio and ODF said they couldn't use SVG
    ... there are graphics library that can't use SVG as an
    interchange format

    <scribe> ACTION: Doug to coordinate with Inkscape folks on
    their connector stuff [recorded in

    <trackbot> Created ACTION-3367 - Coordinate with Inkscape folks
    on their connector stuff [on Doug Schepers - due 2012-09-25].

    brian: I would like to explore the possibilities of this
    ... and I think the approach of saying in the future libraries
    will handle routing is good
    ... but what are the parameters that will be needed

    ds: I left this off, like strength of connections
    ... currently this could rely on the data attribute

    <stakagi> I think that the logical road network of geographic
    information has the almost same concept. Therefore, it may also
    be one of the use cases.

    ds: the things I've chosen are common to all graphs

    heycam: the data thing is a good suggestion


    ds: polygons are degenerated case of stars

    <shepazu> [43]http://svg-whiz.com/svg/StarMaker.svg

      [43] http://svg-whiz.com/svg/StarMaker.svg

    ds: the example shows the different parameters that you can use
    to tweak the stars
    ... these are useful for symbols
    ... it's a pain to draw from paths
    ... I'm fine using inkscape stars
    ... I just want to have a star primitive

    <scribe> ACTION: Doug to work with Tav on the star proposal
    [recorded in

    <trackbot> Created ACTION-3368 - Work with Tav on the star
    proposal [on Doug Schepers - due 2012-09-25].

    ed: can we reuse the polygon element?

    ds: this hasn't been fully explored

    RESOLUTION: SVG 2 will the star element

    <ChrisL> where polygon was changed to be like polyline:


    heycam: sometimes you want to have a square marker and you have
    to define many elements, it might be good to have marker
    short-hand for simple shapes

    lunch break!!!

    <cabanier> scribenick: cabanier

    opic:  Dynamic document loading

Dynamic document loading







    konno: we should read SVGTL and Dynamic document loading

    wiki for dynamic document loading:


    Cyril: what is the global coordinate system?
    ... what is cascading tiling?

    ChrisL: that is the image layering
    ... I dont see how the automatic fetching works
    ... in the previous you used the animation links, but now you
    just point to it with some javascript

    stakagi: we don't need javascript, but geo commity pointed out
    this comment for submission

    chrisl: I think it's important that you can point to a piece
    ... I don't like a system that relies on a huge webservice
    since it's too heavy. I like the system where you have a bunch
    of files on a filesystem

    heycam: how do you generate the url from the tile and the zoom

    stakagi: the geomcommunity generate the url using script
    ... rather than doing that, the proposal is more generic
    ... you can set the url and generate the content automatically.
    There is no fixed requirement to how they appear

    heycam: instead of doing it ahead of time you can do it client

    ChrisL: I don't think so. the files are still stored on the

    heycam: I don't know how much is generated and how much is in a
    static file

    stakagi: there was some feedback that everything is generated
    by script but it's already to generate the tiles by script.
    We're not revising the specification to be script based
    ... you just link to the iframe and it generates the links.

    heycam: that seems the most flexible. If you want your own url
    format, you can do it with script

    Cyril: can someone summarize what is needed to be standardized
    for the tiling part? It just seems like a guideline

    birtles: I think we're coming to that

    andreas: you have to parse everything to get to a certain zoom
    ... if I want to zoom into tokyou, how do I get the tokyo

    cabanier: is it because you always have to start completely
    zoomed out?

    andreas: yes

    ChrisL: you can link to anywhere and continue down from there

    birtles: how can you go back up?

    ChrisL: ah, you can't. Unless you know how the URL are
    constructed and then you can get back out

    stakagi: you have to start from the way top if you want to go

    ChrisL: it seems that every tile should have one that goes up

    andreas: it seems like you don't want to start at the world.
    Openstreet map and google have a way to do this

    ChrisL: you read the documentation and find the url that gives
    you the position.
    ... and then you could use upwards links so you can go to a
    zoomed out tile

    andreas: google maps has fixed tile size and this could allow
    different tile sizes

    Cyril: q-

    ed: I see that there is an attribute 'externalResourceLoading'
    for controlling when external things load, I assume this was on
    the iframes

    heycam: there is a feature where an image is loaded when the
    user scrolls to it

    ChrisL: this is in the spec



    externalResourceLoading =

    <andreas> here is a link describing the OSM?tiling scheme:

      [51] http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

    heycam: I'd rather see this in css

    TabAtkins: we're trying to solve this case in HTML as well. My
    proposal would be a little css to set this up
    ... the element has a callback that it wants to render. that
    way you can do infinite scrolling without having the dom nodes
    hanging around
    ... if you don't want it to garbage collect, you would hold on
    to the reference yourself

    ChrisL: there needs to be a mechanism to do that without the
    user having to do that himself

    TabAtkins: this allows compositted scrolling that is very
    smooth but you do need fixed tilesizes

    heycam: is it because you know the number of items
    ... how if you have different sizes per item

    TabAtkins: you wouldn't know that

    heycam: it seems that this is what is needed here

    birtles: I think we need the declarative support as well.

    ChrisL: you don't have the same problem here. ie like tumblr
    because it's all one tree

    TabAtkins: yes, it might not be an issue for this use case

    andreas: I don't see a reason why there are different tile size

    heycam: maybe because there are different system?

    <stakagi> [52]http://svg2.mbsrv.net/devinfo/devstd/tiling/

      [52] http://svg2.mbsrv.net/devinfo/devstd/tiling/

    birtles: we think because they are different because of density
    (ie a city vs an ocean)

    stakagi: please look at the last picture

    birtles: the file size is proportional to the complexity

    TabAtkins: that is reasonable

    andreas: in google maps they just have dummy tiles so they
    don't download it over and over again

    ed: what do we expect from this discussion?

    konno: it would be sufficient to have a script api to do
    dynamic loading
    ... would that be enough for maps as well?

    birtles: no, I was discussing that
    ... two issues: performance and same origin restriction

    heycam: if you have data from 2 different sites and 2 different
    pyramids how do you combine them?

    ChrisL: this is why you need a native implementation
    (pointer-events, etc)

    heycam: the issue with iframes and pointer events is a problem

    ChrisL: yes

    andreas: this is not something we can solve here
    ... in a workshop with experts who have already done this

    ChrisL: the issue is that the mapping people will require
    something that the implementors don't want to implement

    heycam: I have feeling that there a 2 kind of mapping people:
    the ones that want it all native and the ones that have already
    done it through script

    andreas: regarding the global coordinates system is the one
    that google has, doesn't solve everything
    ... it is not possible to combine it with different projections

    birtles: the main issues that we want to discuss is the level
    of detail and the dynamic loading
    ... in seattle we thought we could do it with js or media
    queries, but we want to see it done declaratively
    ... the iframe approach doesn't impact SVG very much
    ... the others topics we can discuss later
    ... we want to see iframe with recursive dynamic loading. A
    declarative means to specify dynamic loading
    ... we don't have to figure out the specifics

    ChrisL: can I ask Opera if it's reasonable to do this iframe
    like approach with dynamic loading in SVG?

    ed: yes, this sounds reasonable

    birtles: maybe we can't even get it in html

    ChrisL: I'd like to see some content up before we make a
    proposal for HTML

    birtles: we should flag the issue about pointer events

    heycam: I think I sent an email about this

    <heycam> [53]http://www.w3.org/mid/5050A664.1010005@mcc.id.au

      [53] http://www.w3.org/mid/5050A664.1010005@mcc.id.au



    <ChrisL> I'm reminded of
    [55]http://www.w3.org/Graphics/ScalableReq.html where it says
    "Levels of detail " - one of the few requirements SVG has yet
    to meet

      [55] http://www.w3.org/Graphics/ScalableReq.html

    heycam: one thing I'm worried about is that it doesn;t give an
    indication when you want to remove an object
    ... the browser can decide when things should be thrown away
    but the app knows which ones will be reused
    ... if the user is scrolling rapidly or just moving around

    TabAtkins: the quality is better if it is done in the browser

    chrisl: the browser is in the best position to make that

    TabAtkins: I agree

    ChrisL: do we have a resolution if this should go in SVG?

    ed: I'd like to have this functionality

    heycam: seems like a good idea

    TabAtkins: HTML needs to be script based. In this case you have
    everything you need so you know what need to be loaded/unloaded

    resolution: Add an iframe-like element to SVG that includes
    declarative support for dynamic loading

    (… dialog on how pointer-event and iframes that go across
    domains are potentially problematic)

    <ed> s/I'd like to have this functionality/re the
    functionality, everyone ok with allowing the content to
    prevent/forbid the loading of the iframes data?

    <scribe> ACTION: takagisan to write up a proposal for iframe
    like syntax in SVG [recorded in

    <trackbot> Sorry, couldn't find user - takagisan

    <ed> s/I'd like to have this functionality/re the
    functionality, everyone ok with allowing the content to prevent
    or forbid the loading of the iframes data?

    <ChrisL> trackbot, status

    <scribe> ACTION: stakagi to write up a proposal for iframe like
    syntax in SVG [recorded in

    <trackbot> Created ACTION-3369 - Write up a proposal for iframe
    like syntax in SVG [on Satoru Takagi - due 2012-09-25].

zooming and panning



    ChrisL: in svg 1 we had this requirement but in the next
    generation they all dropped it. and now you have it again

    krit: zooming and panning should work

    TabAtkins: it has issues with text selection

    heycam: on mac, you can pinch zoom and tap

    TabAtkins: gistures are intuitive to use

    ChrisL: if you have it at all, it's like operating like an

    birtles: we had a discussion about things that don't scale
    ... was this written down

    ChrisL: what are we aiming at in this section? is it : do you
    expose pan and zoom somehow?

    heycam: there is a difference between zooming the whole page
    and just changing the viewbox

    ChrisL: what is better here than the existing spec that
    requires zoom and pan

    heycam: we don't handle scrolling within the document
    ... for infinite scrolling situation, scroll bars are not

    ChrisL: there are various ways of solving this problem

    TabAtkins: overflow-style was supposed to solve this proble

    <ChrisL> and its not clear we should costrain the browser how
    it offers the functionality. Just that it must be offered

    ed: opera already has this if you have a gesture device or
    shortcuts with a mouse

    TabAtkins: overflow-style tells you to do hidden, scroll bar or

    heycam: if we have elements that expose this, that would solve
    this problem

    birtles: is there still text zoom?

    TabAtkins: most browsers are removing that and are doing full
    page zoom

    <ed> s/ opera already has this/ opera (mac, android e.g)
    support pinch-zooming and so on

    TabAtkins: this is done because layout breaks if you just
    change the size of the text

    birtles: I'm worried about accessibility here

    TabAtkins: I'm unsure if this is something that the author can
    reasonably control

    heycam: I mentioned to ed that overflow-style would be nice on
    SVG elements

    resolution: having something like overflow-style to control
    panning and zooming

    <heycam> … on <svg> and maybe other viewport establishing

    <heycam> … and the ability to specify the valid range that you
    can scroll/pan to (not just the bounding box of the content)

    <ed> ACTION: heycam to write up a proposal for overflow and
    panning [recorded in

    <trackbot> Created ACTION-3370 - Write up a proposal for
    overflow and panning [on Cameron McCormack - due 2012-09-25].

performances to transition in zooming and panning



    birtles: what you see when you do a quick zoom
    ... it's an issue for the browser

    heycam: is it when you zoom into a tile but it hasnt come in

    birtles: there is a concern that this is too heavy

    heycam: this seems like a quality of implementation
    ... this happen on firefox for mobile where you see the zoomed
    in vector

    birtles: the desire is for an API to draw to a bitmap
    ... I follow up with takagi

    <birtles> s/API to draw a bitmap/API to get a rasterized
    version of vector graphics/

    <scribe> ACTION: birtles to follow up with takagisan on what
    exactly is needed to get the bitmap [recorded in

    <trackbot> Created ACTION-3371 - Follow up with takagisan on
    what exactly is needed to get the bitmap [on Brian Birtles -
    due 2012-09-25].

    <scribe> ACTION: andreas to organize a workshop on mapping
    issues [recorded in

    <trackbot> Sorry, couldn't find user - andreas

    <birtles> Please see the use cases for non-scaling objects
    described here:


    <ed> -- 15 min break --

    <birtles> We noted that Chris has the action to write-up
    non-scaling objects

    <TabAtkins> ScribeNick: TabAtkins

Mapping applications issues

    andreas: Showing a few issues with mapping, see if there are
    solutions in existing tech.
    ... First is pointer-events.
    ... Want all the elements at a given point, not just the
    uppermost one.

    TabAtkins: I'm already pursuing that in my list of DOM
    improvements - getElementsFromPoint, to augment

    andreas: Next is contour line labelling. When you put a label
    on a counter (text on a path), the naive method might make some
    labels upside down.
    ... Or when maps are rotated.
    ... Would like some way of ensuring that the text is always
    right-side up.

    ChrisL: So if it rotates more than 90deg off the horizontal,
    flip it over.

    shepazu: The question is how configurable.

    TabAtkins: Don't think it needs configuration.

    Cyril: Sounds like adding the animateMotion rotate attribute to

    andreas: Next is rendering order for bridges. You want some
    parts over, some parts under.
    ... I think this is solved by adding z-index already.

    ChrisL: And splitting up the bridges into multiple paths.

    shepazu: Returning to the previous topic, how exactly would
    they be flipped?

    TabAtkins: They fill the exact same space, just flipping

    andreas: Next issue - some dashing problems.
    ... [shows an example where you want to put markers on the
    corners, but suppress them if the segment is too small]


      [64] http://svg2.mbsrv.net/devinfo/devstd/SkeletonFramesForMap.png

    andreas: Another - wanting dashes just in the center of

    TabAtkins: That's solved by Cam's marker improvements.

    ed: But it's nsot markers, it's dashes.

    andreas: Can markers clip out sections?

    heycam: We want to make that possible, but haven't gotten a
    proposal we like yet.

    andreas: Similar to previous one, suppress dashes on very small
    segments, to maintain the "body" of the line.
    ... Same with some curves.

    TabAtkins: This is theoretically doable automatically - just
    look for path segments that are small relative to the dash
    size, and don't draw the dashes if they're too small.

    heycam: That works if each segment is a visible segment on the
    path, but not if you're doing a smooth curve with lots of small
    path segments.

    TabAtkins: Maybe an addition to <path> that lets you manually
    suppress dashes on a segment?

    heycam: In the <path> children proposal, maybe an element or
    attribute on the child that does that.

    <ChrisL> The setback functionality from vector effects might
    help here

    andreas: Additionally, when having multiple paths joining
    together, you don't want dashes at the join points, so you can
    maintain the visual fact of the join.



    ChrisL: Would you want the ability to stroke multiple paths as
    one, so you can get a continuous dash pattern?
    ... We might bea ble to do that with superpath stuff.

    andreas: Another topic: variable stroke width.

    heycam: We have proposals for that. Unsure of its status.

    andreas: Another topic: markers that repeat from their point
    and reduce in size. Used for some types of path indicators in

    <stakagi> SkeletonFrames



    heycam: With marker-pattern, you can set up custom sets of
    repeated markers, if you're okay with lots of duplication in
    the element.
    ... To get the size change, you'd need 20 different-sized
    markers, though. Maybe a scale factor.

    andreas: Another topic - varied markers on a single path.
    Random, or at least unpredictable.

    heycam: You can do that with jsut the marker-pattern property.
    Just specify several markers, done.

    andreas: next topic, randomness in fill patterns.

    heycam: Tav had a proposal for doing that exactly - use another
    fill pattern as a probabilistic tiling control.

    [several people saying they liked the idea]

    heycam: So you can get denser in some areas, etc.

    andreas: Another topic - when hatching, you don't want the
    hatch lines to be parallel to the shape borders.

    TabAtkins: That's maybe doable automatically - do a quick
    linear algebra weighting the solutions based on how close to
    perpendicular they are to all the borders.

    andreas: Another mapping issue - in maps, especially older
    ones, rivers are hatched parallel to the flow direction, and go
    around islands, etc.

    [several people expressing doubt that can reasonably be done

SVG2 fallback for modules that are behind.

    krit: Some modules may lag behind. What do we do when we
    reference these?

    Tav: Just pull them out?

    ChrisL: Then what to do with the blank spot? Put a marker in
    there pointing out?

    TabAtkins: Yeah, we can word things that are just informative
    references in SVG2 Core, and the modules refer normatively back
    to Core.

    heycam: I think we don't need to worry about this, until and
    unless we are trying to exit CR and depending on things that
    are too low.

    [general agreement]

Moving the spec to git/github

    ChrisL: Becaues the thing holding us back is the fact that we
    haven't moved the spec in the last 3 months. ^_^

    heycam: It's non-trivial, too - we already have a bunch of
    tools on the server.

    ChrisL: Why would we want to do this?

    TabAtkins: It's slightly easier to develop on Window with
    github, because their client is great.



    TabAtkins: But I'm fine with staying where we are.

    krit: I see a benefit that it gets more transparent and easier
    to follow.
    ... Our readers can also review and do typofixes, etc. as pull

    shepazu: I'm opposed to using third-party services.

    heycam: I like git better, but I'm reluctant to make more work
    for myself.

    RESOLUTION: Keep the repository on hg.

Change appendixes

    heycam: Should we have both a "changes from the previous spec"
    appendix and a "changes since SVG 1.1" appendix?

    krit: I definitely want a "changes from 1.1" verisons.

    heycam: And reviewers want changes from the last version.

    shepazu: Different parties want different things.

    heycam: Okay, I'll do both (in the same file).

    ChrisL: Can we annotate the changes with classes or something
    to say which version they're from, so the "changes since last
    version" can be automatically generated from the "changes since
    1.1" list.

    heycam: Only problem is that I sometimes combine multiple
    changes into a single item, and if you add another thing that
    should be appended to that, you can't with that proposal.
    ... it'll be more verbose, but maybe not too bad.

    ChrisL: Also, perhaps we can have a short-ish prose description
    of the changes since 1.1 for normal people to read, while the
    full changelist is still out there for lawyers.

Next f2f meeting

    heycam: We'll have a meeting early next year in Sydney.

    ChrisL: Weren't we moving that from Jan to Feb to accommodate

    heycam: yeah.

    <ed> ACTION: heycam to setup the classes for the SVG2 changes
    appendix (to cover changes from 1.1 and the diff from previous
    draft) [recorded in

    <trackbot> Created ACTION-3372 - Setup the classes for the SVG2
    changes appendix (to cover changes from 1.1 and the diff from
    previous draft) [on Cameron McCormack - due 2012-09-25].

    heycam: And we were colocating Japan with CSS in April or so -
    they haven't nailed down dates yet.

    Cyril: Do we have dates for february?

    heycam: Not yet.

    nikos_office: I thought that the CSS meeting was in June?

    TabAtkins: Dunno.

    ChrisL: So for the feb meeting, week starting Feb 4?

    heycam: We won't have a proper meeting at TPAC.

    ed: Maybe do 5 days, since it'll be a long time since this

    ChrisL: Maybe with a break in the middle - halfday on

    shepazu: John Allsopp arranged a public meeting last time we
    met in Sydney, and I think it went well. We should arrange that

    [general agreement]

    RESOLUTION: First SVG f2f of 2013 is the week starting Feb 4.
    It will be 5 days long.

    heycam: I think that John Daggett will propose meeting June 5-7
    for CSS.
    ... So ours will be June 3-5, with the overlap day being FX
    stuff and CSS stuff interesting for SVG.
    ... Anyone object to those dates?
    ... In terms of hosting, it sounded like Fujisawa-san was
    interested in hosting.
    ... Or maybe Moz will have a larger office by then.

    TabAtkins: Or G can do it.

    heycam: We dont' need to decide hosting yet.

    ed: I cant' say for sure whether the dates are good for me.
    ... But they're probably fine.

    RESOLUTION: Contingent on CSSWG choosing June 5-7 as expected,
    we'll meet June 3-5 in Tokyo.

What to do with xml:base?

    heycam: Should we keep it? It can be set on individual

    TabAtkins: I've gotten good use of it in HTML.

    ed: It's being used in some SVG content, with the subtree.

    TabAtkins: Does XML define what happens with dynamic changes to

    ChrisL: Not well. It points to HTML's <base> and says "like
    ... So we have two choices.
    ... (1) define a new xml:base spec, and push it through the
    disparate XML groups
    ... (2) define what xml:base does *for SVG*.

    heycam: So we need to define xml:base properly.
    ... And think about integration with HTML's <base>.

    RESOLUTION: Someone define what xml:base does properly (in
    dynamic changes, too).

What do do with version and baseProfile?

    TabAtkins: Drop 'em. they don't do anything.

    Tav: They may be useful for authoring tools.

    TabAtkins: You dont' want that normally - if you open an SVG,
    and your authoring tool knows about SVG2, you want to have SVG2
    features. If you *do* want to specifically author for an SVG1.1
    UA, that's a switch at the authoring tool level.

    RESOLUTION: Drop version and baseProfile.

What about xml:lang and lang?

    heycam: I think we chose to use lang on <title>?

    ChrisL: I think the i18n guys prefer one, I think it's lang.

    heycam: What does HTML do with both lang and xml:lang?

    TabAtkins: It's complex, but it eventually pops out a single
    language. I think it's biased towards using lang.

    heycam: Okay, so let's do the same. Allow both, define their
    interaction, encourage lang over xml:lang.

    RESOLUTION: Allow both lang and xml:lang, define their
    interaction, encourage lang over xml:lang.


    ChrisL: How do current kddi apps treat it? It's currently meant
    to let you transform SVG coords to map coords.



    ChrisL: I think people aren't using this? If so, can we remove

    heycam: If no one's using it, let's just remove that section.

    ChrisL: Where the RDF stuff used to be in the spec, we should
    use the simple examples for things people are actually using -
    srsname and transform.
    ... I'd be fine calling it something other than "transform" - I
    dont' like overloading the term.

    heycam: Is this used by multiple organization?

    ChrisL: I think Alex has implemented this. We should ask him.

    heycam: It's just metadata, right? It's not used by us

    ChrisL: Yes.


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


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



    ChrisL: Just call it "geoTransform" or something.

    heycam: Are these things going to be defined by a mapping

    TabAtkins: I think that's best, yeah.

    ChrisL: I think that a "projection" attribute would be useful
    too. SVGOpen people were pushing for at least one extra one.

    heycam: So we remove the geo coords section right now, and move
    it to the mapping module later.

    RESOLUTION: Move the geo coords section to the mapping module,
    and reword appropriately.


    heycam: Let's kill it.


      [73] http://lists.w3.org/Archives/Public/www-svg/2012Aug/0134.html

    birtles: In that email, it's deprecated in SVG 1.1.
    ... So we shoudl remove it now.

    TabAtkins: Do we deprecate but define it? Or just remove it
    ... Depends on whether there's enough content that needs it,
    such that a new browser would need to support it.

    action tab to search for uses of <animateColor> on the web.

    <trackbot> Created ACTION-3373 - Search for uses of
    <animateColor> on the web. [on Tab Atkins Jr. - due

Summary of Action Items

    [NEW] ACTION: andreas to organize a workshop on mapping issues
    [recorded in
    [NEW] ACTION: birtles to follow up with takagisan on what
    exactly is needed to get the bitmap [recorded in
    [NEW] ACTION: Chris to propose the aliasing of current-color to
    currentColor with the CSS WG [recorded in
    [NEW] ACTION: ChrisL to write up contextFill(Paint),
    contextStroke(Paint) proposal in coordination with Cameron
    [recorded in
    [NEW] ACTION: Dirk to add an issue to CSS masking about which
    bounding box to use for percentages in clip-path shape
    definitions [recorded in
    [NEW] ACTION: Doug to coordinate with Inkscape folks on their
    connector stuff [recorded in
    [NEW] ACTION: Doug to work on event handling on connectors
    [recorded in
    [NEW] ACTION: Doug to work with Tav on the star proposal
    [recorded in
    [NEW] ACTION: Erik to send a mail to a suitable mailing list
    about defining the filter region for filter shorthands (so we
    can define masks to include the filtered result) [recorded in
    [NEW] ACTION: heycam to setup the classes for the SVG2 changes
    appendix (to cover changes from 1.1 and the diff from previous
    draft) [recorded in
    [NEW] ACTION: heycam to write up a proposal for overflow and
    panning [recorded in
    [NEW] ACTION: stakagi to write up a proposal for iframe like
    syntax in SVG [recorded in
    [NEW] ACTION: takagisan to write up a proposal for iframe like
    syntax in SVG [recorded in

    [End of minutes]
Received on Tuesday, 18 September 2012 16:26:10 UTC

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