minutes, Tokyo 2013 SVG F2F Day 2, 4 June 2013

Minutes from Day 2 of the Tokyo 2013 SVG F2F are below.  (The link also 
contains yesterday's minutes for some reason.)

   http://www.w3.org/2013/06/03-svg-minutes.html


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

03 Jun 2013

    [2]Agenda

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

    See also: [3]IRC log

       [3] http://www.w3.org/2013/06/03-svg-irc

Attendees

    Present
           Jun, Cyril, Tav, Tab, Satoru, Yusuke, Tomoaki, Cameron,
           Rik, Dirk, Nikos, Brian, Shane

    Regrets
    Chair
           Cameron

    Scribe
           Cyril

Contents

      * [4]Topics
         11. [15]Text flow
         12. [16]CSS syntax in presentation attributes
         13. [17]SVGSVGElement.current{Translate,Scale,Rotation}
         14. [18]Security of resource documents
         15. [19]SVG streaming
         16. [20]global coordinate system
         17. [21]zoom feature for media queries
         18. [22]Progress report of browser implementation for SVG
             Map
         19. [23]Variable Width Stroke
         20. [24]Color interpolation: scaling, etc.
      * [25]Summary of Action Items
      __________________________________________________________


    <nikos> scribenick: nikos

Text flow

    <Tav> [46]http://tavmjong.free.fr/SVG/TEXT_FLOW/

      [46] http://tavmjong.free.fr/SVG/TEXT_FLOW/

    Tav: You can see some examples from InkScape
    ... This never gained traction
    ... for svg 2 we need to re think it and keep it simple and
    consistent with CSS
    ... my proposal is to rely on CSS exclusions and shapes
    ... 1.2 flowed text missed padding
    ... those are defined in CSS exclusions
    ... flow between shapes goes from the first shape listed to the
    next
    ... my explanation is how it works in CSS

    dirk: you can't flow text from different shapes in CSS

    TabAtkins: you need to use regions for that

    Tav: regions might be overkill for svg, but we can discuss that
    later
    ... there are a couple of problems. We don't have the line
    break and paragraph
    ... you can work around that using whitespace property with pre
    wrap and pre line
    ... there a a lot of other interesting things from CSS 3 that
    we would need: text-align, etc
    ... you could keep x and y on tspan and if a renderer is
    capable of flowing text it would ignore them and if not then
    use them as fallback
    ... so that's my proposal. Doug has another.

    heycam: you said in your blog post that some features
    dissapeared from CSS?

    Tav: exclusions was split into two and the ability to link to
    SVG paths was removed
    ... shape inside was deferred to a future version
    ... this was done a couple of weeks ago. I don't know why

    cabanier1: I think it was to speed up progress

    Tav: the way inkscape implements is to create a path. It's not
    any harder to do shape inside

    <stearns_> shape-inside also has an issue with overflow - can't
    size shape to content easily

    cabanier1: It's hard to specify but I don't know the details
    exactly

    krit: The problem is with floating I think
    ... the idea is to iterate over the specifications quickly
    ... do shape outside first and then shape inside next

    heycam: it seems like shape inside is the more important for
    SVG

    shepazu: I'm fully supportive of this proposal, I think it's
    the right way to go in the long term
    ... I think you should continue to work with the CSS WG
    ... to ensure the SVG use cases and the nice features that you
    have are included in the spec
    ... I like the notion of the fall back and allowing people to
    have multiple fall backs for shaped text

    krit: How do you work with x, y, and rotate on the text
    element?
    ... one of the biggest use cases is to position different
    characters in the doc
    ... how does it work in InkScape

    Tav: there's no change for rotated text

    krit: I mean each character is rotated independently

    Tav: I think rotate is ignored
    ... dx and dy apply. It would be reasonable to move after
    positioning

    Alex: I'd like to ask for aligning the box direction

    heycam: how is that handled in the CSS specs?

    AlexD: I'm not sure it is
    ... we had an algorithm in 1.2 didn't we?
    ... display-line?
    ... the second thing that people have asked for - to wrap a
    rectangle or shape to the text that they have
    ... I don't know if we should look at that now or leave it for
    the future

    heycam: I think it makes more sense to consider it as part of
    broader dynamic layout in svg
    ... there are probably other elements that you want to change
    the position of (not just text)

    AlexD: if we provide a js API that gives you the height of the
    blocks you can use js to shape the content

    heycam: I'd expect that to work already
    ... getBBox()

    shepazu: I agree that people have been asking for this a while
    ... getting the path of the text from the API would also be
    nice
    ... having shapes that adapt to the size of the text, that's
    something that we should defer and use calc()
    ... not a characteristic of text, but a generic use of calc()
    in attributes in SVG
    ... so they can dynamically size things according to text or
    other factors

    heycam: one thing that might be worth tackling before the
    broader layout issue
    ... might he solved on CSS size
    ... is to change the size of the text to fit

    shepazu: going back a level there was the problem of having
    text grow or shrink to fit the available space - is that
    available in flexbox?

    TabAtkins: no. It's been discussed in the past and might come
    up in the CSS f2f
    ... it's a hard problem because of constraints - how far it
    will grow
    ... but it's an idea we want to pursue

    shepazu: has a proposal been put forward for a new unit?

    TabAtkins: that's normally called percent
    ... in a lot of circumstances percent is relative to the space
    of the outer container

    shepazu: I don't think SVG would deal with percentages well in
    that context
    ... unless we do width and height
    ... which is in my proposal

    TabAtkins: having a specific unit would probably be fine
    ... in SVG

    shepazu: one of the things about having the shape fit the size
    of the text
    ... we could allow properties from css like background colour,
    or outline

    krit: outline is already defined for svg

    shepazu: I don't know the complexity of adding that to svg

    AlexD: rect with x, y and width, height = auto would be awesome

    shepazu: I'd rather we add a bit of the CSS box model to SVG
    than make authors do it with js

    heycam: it could make sense to have a rectangular area for
    laying out text in. We could start with that

    shepazu: with Tav's proposal you don't need that
    ... I think our proposals are complimentary
    ... I'll talk about my proposal
    ... link at the end of Tav's proposal
    ... it's very simple
    ... depending on how clever and internationalised we want to be
    ... we can either allow width and height on text
    ... maybe you could demo your build cam?

    [Doug explains his proposal]

    scribe: I have a second proposal

    <shepazu>
    [47]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_T
    ext

      [47] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text

    scribe: I only implemented the bit where you can specify width
    on the text element and it will flow downwards

    [Cam shows his demo]

    scribe: y is the top of the rectangle rather than the origin of
    the first glyph

    shepazu: the one reason I'd say is to not have that behaviour
    as default is for the fall back case it's better if the text is
    rendered on the same line as it normally would be

    heycam: that might make it difficult to position the text
    rectangle

    Tav: could define a different x and y

    shepazu: when you want to put a line break I'd suggest we use
    tspans with dy having a value like 1.5 em or something
    ... and it establishes a line break context
    ... this brings up another point that is a failure tspan
    ... if you want a new paragraph, with dy you have to reset it
    back to the original co-ordinates in order for it to align with
    the first paragraph start point
    ... we should have something like x or dx inherit
    ... I have a second proposal which I don't like as much but has
    some advantages
    ... add properties text-wrap and text-extent
    ... text wrap defines the point at which the text wrap
    ... text-extent is the point at which the line wrapping stops
    ... they would also apply to vertical languages

    TabAtkins: we already have terms in CSS, measure for logical
    width and extent for logical height

    heycam: I know that CSS was talking about logicalised versions
    of properties

    TabAtkins: we still intend to but we are not sure how or when

    shepazu: I'd defer to CSS and follow them
    ... for now we go with intuitive (to westerners), width and
    height
    ... I don't think we should change the y location of something
    just because we set a width and height

    krit: what about using the text area element from 1.2?

    heycam: the name is bad

    shepazu: in 1.2 we define an algorithm and I don't think that's
    a good idea for what I'm proposing
    ... I just want to make it super easy to use and intuitive and
    rely on the behaviour that comes out of CSS

    krit: the switch of behaviour of the text element with
    exclusion or width and height is confusing to me
    ... for shapes suddenly x and y are not relevant anymore
    ... and for your propsal y changes meaning

    shepazu: not in my proposal, that's just Cam's implementation

    krit: x and y set the position of individual characters in
    general

    heycam: if you specify width and height x and y get ignored
    ... but if you don't use automatic wrapping they are used
    ... I don't think it makes sense to combine automatic wrapping
    with glyph position

    shepazu: I don't see the argument for adding a new element

    TabAtkins: the argument is that switching modes based on some
    indicator is not nice

    heycam: I like continuing with the text element. It feels like
    it's not a bigger feature
    ... I don't see a problem with making x and y have no effect
    when you're in a certain mode

    shepazu: let's be clear, cam is proposing different behaviour
    than me
    ... my proposal is for the version without text wrapping, the
    text is all on one line
    ... that's CSS behaviour, if you don't specify a width the text
    will just keep going
    ... I thought I heard Cameron say that he wants to solve the
    case of aligning the text box to another shape
    ... by overriding the y property

    heycam: if you want the rectangle you use top and left, if you
    just want wrapping you use x and y

    krit: we may not need the fall back for Tav's proposal

    heycam: an authoring tool would want to output x and y
    positions for manual line wrapping for ua's that don't do the
    wrapping automatically

    krit: in Tav's proposal you always have tspans which represent
    one line

    heycam: Doug what do you think about supporting both
    positioning proposals?
    ... one origin based with x,y and the other the corner of the
    rect with top,left

    shepazu: it seems sensible to me
    ... the goal I have is to make the most intuitive, easiest text
    wrapping the default
    ... the box model CSS like thing that you are talking about
    might be the behaviour that CSS people default to
    ... I would hope that an authoring tool would provide x and y
    for fall back

    krit: regarding Tav's proposal, if we discuss comma separated
    shapes, they are seen as one shape
    ... what you need is the overflow region spec

    TabAtkins: it sounds like we want a property that gives a
    positioning mode and sets whether x and y is the start corner
    or the baseline of the first line of text
    ... I don't know if I like how top,left and x,y would combine
    together

    shepazu: I'm a little more sympathetic to Tab's proposal than
    yours Cam
    ... it seems to me that both behaviours are desirable
    ... makes more sense to set alignment models
    ... there is a text-valign in CSS?

    TabAtkins: what you want is the alignment properties in the
    alignment draft

    <TabAtkins> [48]http://dev.w3.org/csswg/css-align

      [48] http://dev.w3.org/csswg/css-align

    shepazu: the reason I like Tab's proposal more is that it seems
    manipulable in the same way as other things in CSS
    ... and the more we rely on out the box CSS behaviour the
    easier it is for implementers and authors

    AlexD: I like Tav's proposal and we should pursue it

    <AlexD> Tav's not Tab's

    shepazu: I want to go back to Tav's proposal - i believe that
    the x and the y inside flowing areas would probably just be
    ignored when inside alignment things
    ... my proposal would still allow the fall-backs
    ... Tav's proposal would follow the pace of the CSS WG. My
    solution we could get out quickly
    ... I'd like to pursue this
    ... I would like to ask for resolution to see if we can start
    putting this in the spec
    ... and refining the details
    ... I'd like to start with width and height being a proposal
    for SVG 2

    Tav: I think the only difference is that your proposal defines
    a rectangle differently to mine. I think we can do both

    shepazu: I agree

    krit: My concern is that we keep adding features to SVG 2 and
    we'll never finish

    Tav: this is one of the most important features

    shepazu: yes

    krit: I have nothing against adding it to the specification,
    I'm just saying we should finish what we have

    Tav: I think this will be the last major thing that we add

    birtles: fixing the DOM is the other big one

    AlexD: is textarea from 1.2 deprecated?
    ... I really think we should look at the more complex proposal
    that Tav has put together.
    ... the simple proposal may take longer than we think and the
    complex proposal is on a quick path

    shepazu: Mine can be implemented very quickly and relies on CSS
    ... I think it's also much simpler for authors
    ... this is the equivalent of a canned effect for text
    ... it will be intuitive to authors because they are familiar
    with CSS
    ... I think we should do both but I think my proposal makes it
    easy for authors to do the simple cases

    AlexD: the webkit and blink code support css regions so it
    makes it trivial to implement the shape filling
    ... Cam I'd like to know how yours works with x,y,dx,dy on
    tspans
    ... I can see lots of complications

    heycam: I ignored it because it was a quick implementation
    ... I think it would interpret dx,dy post layout
    ... following x,y,dx,dy when wrapping to a rectangle doesn't
    make much sense so they should be used for fall-back
    ... at least for x,y
    ... you could possibly do something with dx,dy

    AlexD: I would suggest we take Doug's proposal to the FXTF and
    get opinions
    ... I could see it getting hit over the head

    heycam: I think the problems in the past were related to
    defining our own algorithms
    ... this might not have the same problem

    shepazu: let's take it to the CSS WG and see what they say

    heycam: we can bring it up during the FX meeting to get a feel

    krit: Do we want to make a resolution or discuss on the mailing
    list?

    AlexD: how about someone spend 5 minutes and propose to FX

    shepazu: We'll talk about it tomorrow and make any resolutions
    then

    heycam: Does it make sense to have overflow:auto and
    overflow:scroll ?
    ... it's common flash
    ... and could handle the case where you have a different font

    shepazu: I anticipated that would fall out of the model during
    implementation

    heycam: I think it's something to consider making work in the
    spec
    ... I think in Switzerland we were talking about more general
    overflow in SVG
    ... we may want to re-visit that

    shepazu: it could be that CSS WG wants us to talk about margins
    and padding for these regions
    ... whatever let's us get it out there

    Break time

    <cabanier1> scribenick: cabanier

CSS syntax in presentation attributes

    <cabanier1> heycam: should attributes use all the css parsing
    rules

    <cabanier1> … my view is that it's simpler if it's the same
    parsing

    <cabanier1> … but we could disable comments and escapes

    <cabanier1> krit: is that a requirement?

    <cabanier1> heycam: it's doesn't exactly say

    <cabanier1> … but implementation vary

    <cabanier1> krit: ff and wk support comment

    <cabanier1> TabAtkins: in my syntax draft I have 2 algorithms
    that svg can use

    <cabanier1> … in general SVG wants use parser componentvalue

    <cabanier1> … and parse al ist of component values

    <cabanier1> … and then you put whatever grammar on top that you
    want

    <cabanier1> heycam: I think I agree with that but Tav expressed
    doubt in the past

    <cabanier1> TabAtkins: being consisten with the rest of the
    platform is a good benfit

    <cabanier1> … writing the parser based on my spec should be
    very little work.

    <cabanier1> krit: so it can start with a '{'

    <cabanier1> TabAtkins: that would be an invalid value

    <cabanier1> heycam: the issue is if we want to parse with the
    css parser

    <cabanier1> krit: how about uniltless values

    <cabanier1> TabAtkins: that's beyond this spec. it's just a
    scanner

    <cabanier1> … it will matches braces against each other

    <cabanier1> krit: it's a tokenizer

    <cabanier1> TabAtkins: yes

    <cabanier1> heycam: difference is that whitespace is now
    allowed

    <cabanier1> … we don't say how to parse them

    <cabanier1> TabAtkins: the values spec says it should be
    ignored

    <cabanier1> heycam: not all implementations do that

    <cabanier1> … maybe how those things are parsed are new so
    might be different from the past

    <cabanier1> krit: how about width?

    <cabanier1> TabAtkins: an svg length can be a number or a unit

    <cabanier1> … you can say that the grammar for the presentation
    attribute can be a number or a unit

    <cabanier1> … with the number be a unit like px

    <cabanier1> … so when you read it back out, you'd get a unit

    <cabanier1> … the presentation attributes would have made the
    switch for you

    <cabanier1> krit: we'd need a grammar section in SVG then

    <cabanier1> TabAtkins: yes

    <cabanier1> krit: we have a parsing section in the svg spec

    <cabanier1> heycam: we will have to create rules to map
    presentation attributes to property values, and we will allow a
    <number> at that point

    <krit>
    [49]http://www.w3.org/TR/SVG/single-page.html#types-BasicDataTy
    pes

      [49] http://www.w3.org/TR/SVG/single-page.html#types-BasicDataTypes

    <cabanier1> krit: svg 1.2 had the grammar section but it seems
    to be removed from 2.0

    <cabanier1> heycam: much of this section can go away

    <cabanier1> … but we need to replace it what parser to use and
    how to map presentation attributes to property values

    <cabanier1> TabAtkins: the quirks modes spec defines a quirky
    length that we can reuse

    <cabanier1> krit: how about angle

    <cabanier1> heycam: I don't think we need to care

    <cabanier1> krit: svg transform needs it but I think I handled
    it in CSS Transforms

    <cabanier1> heycam: there are non-presentation attributes such
    as x, y on rect

    <cabanier1> … but not a problem since we don't handle them as
    SVG animated lenghts

    <cabanier1> TabAtkins: hmmm, looks like you can't use quirky
    length

    <cabanier1> heycam: so, does anyone else have objections?

    <cabanier1> krit: I can live with it

    <cabanier1> heycam: I prefer the css parser

    <cabanier1> krit: it makes sense

    <cabanier1> Tav: If it's really simple it sounds good

    <cabanier1> RESOLUTION: presentation attributes will be parsed
    using the css parser so they will accept comments, etc

SVGSVGElement.current{Translate,Scale,Rotation}

    <krit>
    [50]http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement

      [50] http://www.w3.org/TR/SVG/struct.html#InterfaceSVGSVGElement

    <cabanier1> krit: we want to have transforms on SVGSVGElement

    <cabanier1> … there are properties like currentScale and
    currentTranslate

    <cabanier1> … the definition is not specified for
    innerSVGElement

    <cabanier1> … the question what it should return for the root
    SVG element that has a transform on it

    <cabanier1> heycam: I think they were for current zoom level

    <cabanier1> … and panning

    <cabanier1> TabAtkins: I don't think that transform should
    apply here

    <cabanier1> … just the pan and zoom

    <cabanier1> RESOLUTION: currentScale and currentTranslate is
    not affected by transforms

    <cabanier1> ACTION: krit to specify unspecified behavior of
    currentScale and currentTranslate [recorded in
    [51]http://www.w3.org/2013/06/03-svg-minutes.html#action05]

    <trackbot> Created ACTION-3501 - Specify unspecified behavior
    of currentScale and currentTranslate [on Dirk Schulze - due
    2013-06-11].

Security of resource documents

    krit: there are 2 different security concern

    … svg as an image

    … and svg in a different document that is reference

    heycam: like a resource document

    krit: the first use case is to have the user upload an SVG doc

    … and you can reference an image in a different domain

    … and then you can figure out how many people open your
    document

    … this is why we should't allow external resources

    … or scripting

    heycam: what is the best list of things to disable

    <heycam> [52]https://svgwg.org/specs/integration/

      [52] https://svgwg.org/specs/integration/

    … I need to do some work on it so Doug can publish it

    krit: all browsers already implement this

    … things that should not be enabled

    heycam: data uri is fine

    krit: references within the same document are fine

    TabAtkins: same origin with a unique origin

    heycam: no external references.

    cabanier: not even on the same

    … server

    krit: no, because of redirects

    heycam: you can put in a link that sends you to the local
    redirect which will then forward you to the external site

    krit: scripting is also out

    … js functions are not called

    heycam: having script being able to modify it would be strange

    … you'd have to find all the things like xhr that try to get
    out and block them

    <heycam>
    [53]https://svgwg.org/specs/integration/#secure_static_mode

      [53] https://svgwg.org/specs/integration/#secure_static_mode

    <heycam> sorry, this one:
    [54]https://svgwg.org/specs/integration/#secure_animated_mode

      [54] https://svgwg.org/specs/integration/#secure_animated_mode

    krit: I'm unsure that 'external references' is enough

    heycam: are you allowed to reference 'a#xxx' or '#xxx'

    <heycam> where "a" is the actual URL of the resource document

    krit: we need more text for external reference and then it's
    fine

    heycam: 2.1 defines it

    krit: we should discuss this with Anne

    [55]https://svgwg.org/specs/integration/#definitions

      [55] https://svgwg.org/specs/integration/#definitions

    … I think we are in agreement?

    heycam: yes, for all image-like use

    … did roc say that you want to allow external resource if
    there's a cors attribute on the image element

    krit: maybe we can do that in the next version
    ... let's move on to the external reference case

    … an external document should have no information that can leak

    … ie evil.com should not get any data from myback.com

    … can have mask, patterm, etc that can leak any privacy

    … roc's filter case uses a fedisplacement map and in
    combination with visiblepainted pointer event "alpa=0" it can
    leak information

    heycam: because you can check which element are under the point

    krit: pointer events should not be affected by alpha

    heycam: let's talk about that later

    krit: can marker etc leak information

    heycam: yes

    krit: but does it leak?

    heycam: it could show that you're logged in

    krit: clippath can influence your hit region

    … and therefor you can't trust

    … it implies that you have different fetching rules

    … ff included the cors checking

    … and we should specify this

    … the referenced resource can reference other resources

    … what should we do there?

    … FF does this but has no restrictions on images

    heycam: ok this is a resource doc, it can reference any image

    krit: yes. I don't think that is a problem.

    … WK can't reference anything external

    … maybe we should ask experts to see if there's a problem

    heycam: one thing in svg2 is that it gets the size
    automatically

    … would that leak information because you can look at the
    boundingbox

    … if the external site put cors on, it means that it's safe

    … so I think that means it's OK

    krit: SVG resource loading needs to be CORS enable

    … and this is missing from the integration spec

    … and we need to differ between image and external SVG
    resources

    heycam: we should clarify that

    … otherwise, do you want to run animations?

    krit: yes

    <stakagi> iframe?

    krit: iframe is also an external resource

    … so we should look between image and everything else

    heycam: and the image content is most restricted

    RESOLUTION: images should not allow any external resources and
    run in Secure Animated Mode
    ... for resource documents we want animated mode and external
    references are CORS enabled and images are always allowed

    <scribe> ACTION: krit to talk to Doug, Anne, Boris and Roc
    about resource handling security in SVG and ask for review of
    the model [recorded in
    [56]http://www.w3.org/2013/06/03-svg-minutes.html#action06]

    <trackbot> Created ACTION-3502 - Talk to Doug, Anne, Boris and
    Roc about resource handling security in SVG and ask for review
    of the model [on Dirk Schulze - due 2013-06-11].

    (some discussion on mask-image)

    krit: I need to talk to Anne

    heycam: Roc, I and krit agree on what we should do

    krit: the last email from roc confused me. I didn't understand
    it

    heycam: me neither

    krit: we can't use the same fetching for images and resources

    heycam: what for new properties that might reference an element
    or a whole document

    … are there going to be more case where the # changes fetching
    behave

    krit: yes, everything that url uses

    … we can reuse the same technique in the CSS shapes proposal
    for instance

    … same for fill and stroke. those can use css image in the
    future

    … I don't like the current model

    … I would prefer to redesign the url function so it's
    consistent everywhere it's used

    heycam: yes. that's your preferece

    … my proposal is to specify the mask properties so it doesn't
    run into this problem

    … has this been discussed at public-fx?

    krit: we agreed on doing the #-hack

    heycam: not sure if I like it

SVG streaming

    <krit> scribeNick: krit

    <Cyril> [57]http://dev.w3.org/SVG/modules/streaming

      [57] http://dev.w3.org/SVG/modules/streaming

    Cyril: in revious F2F I presented SVG streaming
    ... I updated it
    ... it contains 3 main sections 1) use cases
    ... streaming cartoons graphical annotations, lyrics,
    synchronized with audio (karaoke)
    ... 2) some definitions and associate processing
    ... how progressive loading works in browsers
    ... main definition is SVG stream, composed chunks of data,
    called Access Units
    ... some accessunits are important and needed to get current
    frame
    ... you can add it to containers like webM, MPEG

    krit: is a WebM a real container format?

    Cyril: it has an issue "to need defined"
    ... there is another section on HTML 5

    5

    <Cyril>
    [58]http://concolato.wp.mines-telecom.fr/2013/05/31/playing-svg
    -content-in-html5-video-elements/

      [58] 
http://concolato.wp.mines-telecom.fr/2013/05/31/playing-svg-content-in-html5-video-elements/

    Cyril: I suggest allowing in video element or track element
    ... used JS player for this demo and modified it to support SVG
    streaming
    ... it allows SVG animation
    ... that is very nice
    ... [descripbes strategies to make it possible]
    ... video does not have CORS restriction

    heycam: I think video is more like an image
    ... animations are allowed in referenced SVG, but not script

    Cyril: there shouldn't be any restrictions on the origin of the
    content

    heycam: it should have the same restrictions as discussed on
    last topic
    ... [describes Avatar story for social media]

    Cyril: yeah, same restrictions should apply
    ... when you seek into the future you can data from the future
    ... didn't have the JS lib the last time
    ... I tried to map HTML5 video elements (pause)
    ... it doesn't pause document time, but animation
    ... SVG didn't pause time when I did pause() (webkit bug?)
    ... I needed to have a duration attribute to enable loop, hope
    it will be defined in WebAnimations
    ... I reorganized and trimmed the content of the document
    ... I'll contact Silvia and ask for feedback
    ... File formats give mapping between time and byte ranges
    ... [describes section 3]

    heycam: if you have different elements in the doc and this
    could cause different behvaior on CSS selectors

    Cyril: once you are on a access point, then you run as if
    loaded the doc for first time
    ... CSS would be the same
    ... I'd like a review of document
    ... it gives defintions, guidlines ect.
    ... you should scope elements to access points
    ... and the processing of stream (seeking to future)
    ... normative parts to SVG, HTML5
    ... + what happens when you put SVG in MPEG container
    ... I want to have an official ED for the spec

    heycam: does some one disagree?
    ... what about conformance? just published by SVG WG?
    ... can be resolved later

    RESOLUTION: SVG Streaming can get ED

    <shepazu> yay!

    <heycam> ScribeNick: heycam

    <stakagi>
    [59]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coo
    rdinate_Systems

      [59] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems

global coordinate system

    stakagi: I want to respond to your comments about global
    corodinate systems

    … I've prepared this page

    heycam: does this differ from the proposal from last time?

    stakagi: it is the same, except for the viewBox indicating the
    global coordinate system

    <stakagi>
    [60]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coo
    rdinate_Systems#7.13.2_Indication_of_viewBox_in_global_coordina
    te_systems

      [60] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems#7.13.2_Indication_of_viewBox_in_global_coordinate_systems

    birtles: in switzerland we went over the global coordinate
    system proposal

    … we were thinking it's not necessary, or might be necessary

    … in January this year we decided to focus on the iframe issue
    first

    … so I'm not sure that we said it wasn't necessary

    … but there was some confusion

    krit: I think it's required to have a reference to a global
    coordinate system

    … or at least know where in the gcs you are

    <stakagi>
    [61]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coo
    rdinate_Systems#Issues_for_this_method

      [61] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems#Issues_for_this_method

    stakagi: I've listed some issues with SVG's coordinate system
    here

    … orientation of axes is one issue

    heycam: if you as the author putting together these separate
    iframes know that a given iframe's coordinate system has x
    flipped, can you not put a transform="" on the iframe yourself
    to flip it back?

    … so if you are using tile data from some provider, how do you
    know what coordinate system it is in?

    birtles: stakagi will think about that issue some more and get
    back to you

    heycam: the idea of declaring a named coordinate system in the
    document, and then being able to reference it from a #svgView()
    with a viewbox in that coordinate system seems like an ok idea
    ... these days it's not so fashionable to use a url to identify
    something like a particular well known coordinate system

    … I think you need that functionality, because you can't be
    sure that #gcs will be the ID of the GlobalCoordinateSystem
    element in the child tile

    … but maybe a registry of coordinate system keywords would be
    better than urls

    stakagi: I don't mind, these are just possibilities

    heycam: I think both a well known coordinate system ID and
    being able to reference with a #hash could be useful

    … the latter if you don't want to register a new keyword, and
    you are in control of generating the tiles and using the tiles

    … is the axis orientation the only issue that requires a
    globalCoordinateSystem?

    birtles: there are two issues listed there

    … one we've talked about before is precision issues

    … but we decided that might not have been a big deal, you can
    work around it with transforms at the top level

    … also you want the individual files to be oriented in a
    particular view when you open the standalone

    … but another position when you use them as a tile

    heycam: in this proposal do you have to position the iframe
    explicitly? or does it happen automatically due to the gcs?

    birtles: the iframe defines the area in which content will be
    rendered in the outer document

    … (and is also used for automatic loading)

    … but you still have the extra transform due to the gcs that
    makes the tile content appear at the right position within the
    iframe's rectangle

    <stakagi>
    [62]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coo
    rdinate_Systems#7.13.3_Coodrdinate_Transformation_and_Viewport_
    Establishment

      [62] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Global_Coordinate_Systems#7.13.3_Coodrdinate_Transformation_and_Viewport_Establishment

    heycam: I see the parent document also has a gcs element. is
    that used in the mapping of coordinate system from the child to
    the parent, or only for the parent in another ancestor context?

    <shepazu> I think it's important to note that a lot of this
    work on coordinate transformations has been done in the
    excellent and popular D3.js library, so we should leverage that
    work if possible

    shepazu, I'm not sure we're doing anything more than applying
    CTMs that are declared in the document though. doesn't need
    special knowledge about WGS84 means for example.

    heycam: I feel a bit better about the proposal at this
    iteration. the syntax needs a bit more refinement imo.

    birtles: I need to process it a bit more to ensure that the gcs
    is strictly necessary
    ... takagi-san things that the parts of the specification have
    become clearer now, and he'd like feedback

    … he doesn't mind what form the feedback takes

    … being part of SVG 2 would be ideal; if there are other
    suggestions, that's ok too

    heycam: are there parts apart from gcs and iframe?

    birtles: the #svgView

    heycam: maybe that's part of the gcs part of the proposal

    birtles: takagi-san said this gcs might go in the metadata
    section of the spec

    heycam: I think if it's meant to have behavioural changes it
    should go in the coordinate systems chapter
    ... maybe these proposals can remain in a separate module, and
    if they solidify quickly enough they could go in to SVG 2

    … but for the moment stay separate

    <scribe> ACTION: Brian to investigate the issues that require
    the global coordinate system feature [recorded in
    [63]http://www.w3.org/2013/06/03-svg-minutes.html#action07]

    <trackbot> Created ACTION-3503 - Investigate the issues that
    require the global coordinate system feature [on Brian Birtles
    - due 2013-06-11].

    <ys-uchida>
    [64]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Zoom_featu
    re_for_media_queries

      [64] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Zoom_feature_for_media_queries

zoom feature for media queries

    ys-uchida: we have two proposals

    … first is a zoom feature ofr media queries

    … the second is a way to calculate the zoom ratio for the
    display

    … I'll explain the first proposal

    … in the current implementation, we can control the content in
    the child tile according to its width or height on the parent
    svg, if the parent references this child svg

    … the wiki page has an example of this

    … the content changes its appearance according to its width and
    height

    … it references sub-svg in different scales

    … the rendering result shows how this works in current browsers

    … I think the problem of using max/min-width/height properties
    is that you need to specify the width/height if the target
    content has different sizes

    … we cannot simultaneously control different content with
    different sizes

    … if we have a zoom feature, we can control different elements
    with different sizes, using one condition

    … for example change to a high resolution version of some
    content if the scale is doubled

    … here we propose to add a zoom feature to css mq

    krit: this is something that we cannot decide in the SVG WG

    … I think this is something that needs to be discussed along
    with the CSS WG

    ys-uchida: I heard in previous meetings we have proposed
    similar techniques, and I heard that this should be discussed
    in SVG before bringing it to the CSS WG

    birtles: it started here because it started as an SVG
    attribute, and then we decided it would probably be better as a
    mq

    … I think it's ok for us to discuss the feature, and if we
    agree it's reasonable, then bring it to the css wg

    Cyril: what about the custom mqs that were mentioned yesterday?

    … Tab mentioned there was the possibility to define custom mqs

    heycam: I think it might need information outside the document,
    so not sure that would help here

    ys-uchida: the scale is defined by the ctm

    … it's sqrt(abs(det of ctm))

    … I'm not sure whether it can be defined in that way in CSS,
    since there's also perspective transforms, but this works for
    affine transforms

    krit: this is not related to the zoom property?

    heycam: I think this is something different from the zoom
    property?

    <krit> [65]http://www.css3.com/css-zoom/

      [65] http://www.css3.com/css-zoom/

    krit: if it's not related to the zoom property, maybe a
    different name would be better

    heycam: so the values of min/max-zoom are the ratio of scale of
    the child's root coordinate system to the parent's?
    ... you want the ratio of the scale of the natural width of the
    child tile (when you view it as a standalone document), to the
    size it gets rendered at in the end as part of the hierarchy of
    tiles

    ys-uchida: my preference is that you could choose between the
    zoom factor calculated based on only looking at the parent, or
    by going up the whole hierarchy of ctms

    heycam: I think using a plain number in min/max-zoom makes more
    sense than an absolute length value

    ys-uchida: I don't have a strong opinion yet. I think always
    look at the chain of ctms, without using the absolute unit
    length values in the mq, would be ok.

    heycam: this sounds a bit similar to the responsive images use
    cases

    … not sure if it should be solved the same way or not

    … maybe CSS or HTML folks would know more about that

    birtles: I feel like they are related but different

    … looking at <img srcset>, I'm not sure this covers the same
    use case

    [some discussion about why min-height doesn't work]

    heycam: so you could have something like "min-height: outer
    100px" to mean if the height is at least 100px once you
    transformed the child's size to the outermost coordinate
    system, and including zooming

    … that or specifying min-zoom: 0.5 or whatever seems to be
    equivalent

    … not sure which is more convenient

    [Tab discusses an idea he has been having for a similar media
    query feature]

    [Tab explains that the use case expressed here isn't possible
    with current MQs or with his idea]

    heycam: let's bring this up at the FXTF meeting tomorrow to see
    what CSS people think about it

Progress report of browser implementation for SVG Map

    konno: I have two simple issues I want to discuss

    … first is to report the progress of the browser implementation
    of these mapping features

    … the second is a proposal to have a
    externalResourcesRequired-like attribute for dynamic loading

    … we know that eRR was removed from SVG 2

    … but an alternative is needed for dynamic loading for us

    <Cyril>
    [66]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Progress_r
    eport_of_browser_implementation_for_SVG_Map

      [66] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Progress_report_of_browser_implementation_for_SVG_Map

    … we extended Chrome to support the SVG Map features

    … this supports SVG <iframe>

    … we've started working on an addon for Firefox

    [shows demo]

    … we've started a native implementation for Firefox

    … we tried to support the SVG <iframe> element, btu we haven't
    finished this yet

    … dynamic loading is essential for mapping with tiles

    … the tiles that are out of the viewport should not be loaded

    … we need to control the loading according to the viewport

    … so we need a means to do this

    … and for unloading

    … there was externalResourcesRequired in SVG 1.1

    … to preserve the consistency of the existing specification, we
    tried to extend that attribute

    … I don't have a strong opinion to re-use that attribute

    … but this feature is needed for mapping

    … to control loading and unloading

    Cyril: you want to control loading and unloading?

    konno: yes

    birtles: the desire is for a hint to the user agent

    … UAs at the moment try to read as much as they can initially,
    since on mobile devices it can be slow to warm up the data
    connection later

    … things like MQs, generally UAs fetch all of these things
    immediately

    … but for mapping cases, you're linking to so many resources,
    you want to hint the UA that you don't need to read everything
    that's available

    Cyril: this reminds me a lot of picture/srcset

    … you don't want to load it if you don't need it

    birtles: ideally we want to let the browser do everything

    … but does it have enough information to make that decision?

    Cyril: I think we should separate the loading from unloading

    … in the responsive images requirements, they had a requirement
    to not use scripting

    … they did not want to wait for all the load events to trigger,
    and then make a separate request for the image

    … is that also a requirement here, or can you use JS to do it
    here?

    birtles: you're already declaratively linking to iframes

    Cyril: you could create the iframes on the fly

    birtles: seems a bit undesirable to have to use script just for
    this

    … I think this is just a hint to know what strategy to employ

    … if the browser had unlimited memory it shouldn't need to
    unload anything

    Cyril: what information could you give to help the browser
    decide?

    … when something goes out of range, it knows that

    birtles: but it would still load it

    Cyril: the loading is a separate issue

    birtles: if you're using CSS properties to position these
    things, they're going to get loaded

    … HTML srcset is different

    … that actually controls when things get loaded

    Cyril: so why don't we use <picture> or srcset? this is the
    same use case

    birtles: I don't think it's the same

    TabAtkins: I don't think UAs will be smart enough to not fetch
    iframe tiles

    Cyril: and if you use the picture element?

    TabAtkins: same thing

    … it doesn't give you lazy loading behaviour. it's for resource
    selection behaviour.

    Cyril: but you could have a <picture> element per tile?

    TabAtkins: you usually don't want that in <picture>

    Cyril: in <picture> there's a condition to load

    TabAtkins: you want a hint that the browser can work around and
    figure what's best, based on the information it has

    heycam: I am a bit concerned that the heuristics are hard to
    express as hints

    … don't want these hints to just be useful for certain kinds of
    maps

    birtles: maybe certain maps you would tend to pan, others you
    would tend to zoom

    [konno shows the eRR extension proposal]

    heycam: maybe this attribute should be able to indicate whether
    the user would likely zoom rather than pan? who knows

    konno: I have an example of the use of this attribute in on the
    wiki page

    … two questions: is it acceptable to extend eRR, or if not what
    would be an acceptable name for this?

    heycam: I think eRR is not the right attribute, since it's
    defined to control when the load event is dispatched

    … was thinking maybe display:none vs display:inline could
    control whether loading happens

    … but that doesn't help with discarding

    Cyril: I would prefer to use the same mechanism as say
    <picture>

    … maybe the condition needs to become fuzzier

    heycam: sounds a bit similar to web pages loading images as you
    scroll to them

    Cyril: if we could introduce fuzzy conditions for media
    queries, then you would need a <picture> with an <iframe>
    inside

    -- break --

    heycam: I think someone should look into whether <picture> or
    srcset="" can work for this use case

    TabAtkins: also look at preload="" on <video>
    ... I don't think you need control on unloading at all

    heycam: so maybe there are only two values you want: one the
    default, for "load always, never unload", one for "load when in
    viewport, maybe if outside viewport, unload maybe when outside
    viewport"
    ... you always distinguish between display/visibility -- is
    that important?

    TabAtkins: display:none will already suppress loading and maybe
    throw away the document

    heycam: I think the visibility-based one isn't important

    konno: we don't have a strong opinion on that

    [konno-san will investigate <picture>, srcset, etc., and if
    these can't work, propose an updated attribute with a better
    name and values]

    <stakagi>
    [67]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Embedded_C
    ontent

      [67] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Embedded_Content

    heycam: I agree it makes sense to put all those elements in the
    one chapter

    … it's a bit weird that <image> is in the Structure chapter

    <Cyril> scribe: Cyril

    <scribe> scribeNick: Cyril

Variable Width Stroke

    birtles: I have a strawman proposal about the syntax
    ... Tav sent questions on how the feature should work
    ... Rik made some research on how illustrator works

    <cabanier> proposal:
    [68]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_w
    idth_stroke

      [68] 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Variable_width_stroke

    birtles: I'm not too invested in it
    ... I sent something to the list
    ... the few people who replied were positive
    ... suggested to split the width and position
    ... this is good as you can animate separately
    ... the rest I'm not sure about, it's a starting point, the @
    thing is weird

    Tab: I don't like position type
    ... we had the same thing with gradients
    ... putting a requirement that you can only used one unit at a
    time is not good
    ... there are ways to fix that

    birtles: good feedback
    ... positions would become a series of length
    ... don't know how to handle the segment thing

    tab: you can make new units

    heycam: we had the same issue in marker
    ... maybe we can solve that in the same way

    birtles: the @ symbol, I don't know what to do with that

    heycam: you can use the word 'at'

    TabAtkins: you could have value position , value position, ...
    a comma for each pair

    birtles: possible notation for this feature
    ... I've also put an asymmetric example

    heycam: have we decided ?

    <TabAtkins> stroke-widths: [<width> <position>]# repeat?

    birtles: no but we wanted to make sure that it was extensible

    TabAtkins: why is stroke width value just a number

    heycam: this will become a length

    birtles: no they are multipliers

    TabAtkins: we should use % instead so that we can do absolute
    if needed
    ... % would be relative to the width value

    birtles: ok

    Tav: it makes the string a bit longer

    birtles: it could start to add up

    TabAtkins: I don't understand why we are minimizing the size of
    the property

    birtles: fine
    ... that's it for syntax

    nikos: what about defining a stroke widht pattern and apply it
    to multiple paths

    birtles: that's the .hair pattern in the example

    TabAtkins: what does repeat do when you use %

    cabanier: I don't think repeat is really necessary
    ... brushes would be better

    birtles: there is also a star example (letter c)

    Cyril: you can't have discontinuity/jump at segment?

    birtles: no you cannot
    ... with position you could

    heycam: do the numbers mean points on a Catmull-Rom curves or
    straight lines

    Tab: we are talking about having one smoothing type
    ... for the interpolation type

    Cyril: with an additional property

    Tav: why not
    ... and there is the question on whether you could change the
    interpolation type per point

    heycam: I'm not sure you want to embed general path syntax in
    the property
    ... you could use functional notation maybe

    <heycam> stroke-widths-values: curve(10, 20, 10) straight(10)
    curve(10, 20, 10)

    <TabAtkins> stroke-width-values: 10 c, 20 c, 10 c, 10 s, 10 c,
    20 c, 10 c;

    <TabAtkins> stroke-width-values: [[c | s]? && <length>]#

    C 10, 20, 10, L 10 C 20 10 ...

    TabAtkins: what happens at position 0 in the path ?
    ... the default should just be 100%

    cabanier: yes

    TabAtkins: this is equivalent to using the base value in
    animations

    <Tav> [69]http://tavmjong.free.fr/SVG/VARIABLE_WIDTHS/

      [69] http://tavmjong.free.fr/SVG/VARIABLE_WIDTHS/

    birtles: I think we should have one width per point

    TabAtkins: you wouldn't be able to mix arbitrary position and
    point-position

    Tav: I posted a link with some experiments with caps and joins

    cabanier: doe sInkscape have that ?

    Tav: partly
    ... it's pretty obvious what to do with butt and round
    ... not sure about square
    ... that's the difference between the blue or black
    ... I think the black would be more reasonnable

    heycam: it's the same reasoning as for circle

    Cyril: do we allow negative widths ?

    birtles: no
    ... once you have asymmetrical, negative width could be useful

    Tav: do you change the fill ?

    Cyril: according to the rendering model, no

    birtles: there is a lot of added complexity with the asymmetric
    version

    <birtles> (or more particularly, the negative stroke widths)

    Tav: what do we do with arcs in end caps
    ... we have them in line join, not in end caps
    ... at first, I thought they would be
    ... but I think you can do the same with the last width be 0
    ... it's probably not worth the complexity
    ... round joins are also a bit complicated
    ... the grey is what you would get from the red lines

    <cabanier>
    [70]https://docs.google.com/file/d/0B26l3CHMT6bfeWwwREljMmpVRzQ
    /edit

      [70] https://docs.google.com/file/d/0B26l3CHMT6bfeWwwREljMmpVRzQ/edit

    birtles: still a lot details to work out

    <heycam> ACTION: Brian to update the syntax of the variable
    stroke width proposal [recorded in
    [71]http://www.w3.org/2013/06/03-svg-minutes.html#action08]

    <trackbot> Created ACTION-3504 - Update the syntax of the
    variable stroke width proposal [on Brian Birtles - due
    2013-06-11].

Color interpolation: scaling, etc.

    <Tav> [72]http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/

      [72] http://tavmjong.free.fr/SVG/COLOR_INTERPOLATION/

    <heycam> ScribeNick: heycam

    Tav: there are still a few problems with lighting filters, but
    mostly filters handle color interpolation well

    … I think there is a bug in Firefox's lighting filters

    … all of those on should match the colour inside as outside

    … for gradients it is interesting to use linearRGB; it looks
    better

    … the Google I/O logo would've looked better with
    color-interpolation:linearRGB

    krit: we're not planning to do this… not clear if we can
    implement this in all WebKits

    heycam: because you're relying on underlying libraries to do
    gradients for you?

    krit: Skia could implement linearRGB gradients but don't yet

    cabanier: wouldn't it be better to specify values in Lab and
    interpolate in Lab?

    TabAtkins: at computed values time it's already converted to
    rgb

    Tav: I think it's not how you define the colours, but how you
    interpolate them

    … next is up and downscaling

    … the 1x1 SVG should match the solid colour below it

    heycam: what is your suggested way of doing this? opt in?

    Tav: as long as it is an option

    heycam: color-interpolation-scaling?

    TabAtkins: just use color-interpolation

    cabanier: I don't think you want color-interpolation:linearRGB
    to affect scaling an <image> with a PNG

    … it will affect how alpha compositing happens

    Tav: what does blending/compositing spec say about color
    interpolation?

    cabanier: doesn't say anything about it

    … so it should be in sRGB

    Tav: so I just want people to be aware of the problems with
    color interpolation, and in the long run try to move towards
    something more correct
    ... ideally browsers do all operations in an ideal colour
    space, and then we don't need to use color-interpolation to do
    scaling operations correctly

    cabanier: I think we need to get browsers to care about colour
    management

    <scribe> ACTION: Tav to draft some wording for recommended
    scaling techniques in SVG 2 [recorded in
    [73]http://www.w3.org/2013/06/03-svg-minutes.html#action09]

    <trackbot> Created ACTION-3505 - Draft some wording for
    recommended scaling techniques in SVG 2 [on Tavmjong Bah - due
    2013-06-11].

    -- finish --

Summary of Action Items

    [NEW] ACTION: Brian to investigate the issues that require the
    global coordinate system feature [recorded in
    [74]http://www.w3.org/2013/06/03-svg-minutes.html#action07]
    [NEW] ACTION: Brian to update the syntax of the variable stroke
    width proposal [recorded in
    [75]http://www.w3.org/2013/06/03-svg-minutes.html#action08]
    [NEW] ACTION: heycam to gather ideas for solving IDPF issues
    and send that as a liaison [recorded in
    [76]http://www.w3.org/2013/06/03-svg-minutes.html#action03]
    [NEW] ACTION: heycam to integrate the marker resolutions in the
    spec [recorded in
    [77]http://www.w3.org/2013/06/03-svg-minutes.html#action01]
    [NEW] ACTION: krit to specify unspecified behavior of
    currentScale and currentTranslate [recorded in
    [78]http://www.w3.org/2013/06/03-svg-minutes.html#action05]
    [NEW] ACTION: krit to talk to Doug, Anne, Boris and Roc about
    resource handling security in SVG and ask for review of the
    model [recorded in
    [79]http://www.w3.org/2013/06/03-svg-minutes.html#action06]
    [NEW] ACTION: Rik to note those things that create a stacking
    context in the spec [recorded in
    [80]http://www.w3.org/2013/06/03-svg-minutes.html#action02]
    [NEW] ACTION: Tav to draft some wording for recommended scaling
    techniques in SVG 2 [recorded in
    [81]http://www.w3.org/2013/06/03-svg-minutes.html#action09]
    [NEW] ACTION: Tav to put multiple fills/strokes in SVG 2.
    [recorded in
    [82]http://www.w3.org/2013/06/03-svg-minutes.html#action04]

    [End of minutes]
      __________________________________________________________

Received on Tuesday, 4 June 2013 09:21:12 UTC