W3C home > Mailing lists > Public > www-svg@w3.org > October 2013

Minutes, 3 October 2013 SVG WG telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Fri, 04 Oct 2013 10:25:33 +0200
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <op.w4e8cvqkgeuyw5@gnorps>
As html:


as text:


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

                                - DRAFT -

                     SVG Working Group Teleconference

03 Oct 2013



    See also: [3]IRC log

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


           +1.425.373.aaaa, +49.341.263.2.aabb, [IPcaller], ed,
           +61.2.980.5.aacc, Doug_Schepers, nikos, krit, cabanier,
           stakagi, thomas, Tav

           CL, Luc, Cyril, heycam, brian, rich




      * [4]Topics
          1. [5]TPAC 2013 dial-in
          2. [6]Modes of SVG SVG integration
          3. [7]Hit testing SVG root
          4. [8]feImage and new crossOrigin attribute
          5. [9]fx tf meetig in Seattle
      * [10]Summary of Action Items

    <trackbot> Date: 03 October 2013

    <scribe> scribenick: cabanier

TPAC 2013 dial-in

    ed: does anyone need to dial in to TPAC so we can ask for
    conference equipment

    krit: who is not going?

    ThomasSmailus: I'm not
    ... yes. I should dial in

    ed: in that case, let us know what topics so we can schedule



    ed: I'll take an action to arrange conference equipment
    ... me and heycam will prepare an agenda
    ... please let us know what topics you'd like to discuss at
    TPAC (feel free to use the agenda request wikipage) and we'll
    put them on the agenda

    <stakagi> hi

    <stakagi> Yes

    shepazu: it would be good to talk about mapping

Modes of SVG SVG integration

    link: [12]https://svgwg.org/specs/integration/

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

    <krit> [13]https://svgwg.org/specs/integration/

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

    krit: we have this spec and shepazu mentioned the intent
    ... I wonder if we need all these categories
    ... the only really important ones are secure mode and insecure
    ... I'm not sure if these details should be specified. the
    focus should be on security modes
    ... I think that should be the main focus
    ... I wanted to check

    shepazu: why do you think that?

    krit: because browsers don't want to go into these categories
    ... maybe you just want to support static mode
    ... it could depend on the device

    shepazu: this is contrary to the requests from people
    ... they want different categories.
    ... implementors like inkscape don't offer declaritive

    krit: for clarification, I'm fine with that
    ... features can be disabled by browsers.
    ... but they might not want to implement a certain category

    shepazu: but this is what this specification should do

    krit: we should say that there are modules and browsers can
    choose which ones they implement

    shepazu: what's the harm in having categories?
    ... it harms svg if we don't have these
    ... 1. implementations are the consumer of this spec
    ... 2. other specifications are referencing this spec. so they
    have a category of what subset they support

    krit: for me, security is the main part
    ... we can have secure and insecure and then have subcategories

    shepazu: I have no problem with security being the prime
    category. there is animated and secure animated
    ... not everyone follows the spec. for instance css animation
    is applied
    ... so, security is ok to be the main mode, but why is that the
    most important one

    krit: because security is the most pressing feature today

    shepazu: the author/developer comes first for a spec.
    ... it's ok to make security the prime thing but others are
    needed as well to help authors
    ... there should be a secure/insecure mode for each target
    ... what I care about is that publisher want to know what the
    capabilites of the devices are
    ... this seems obvious
    ... it would be nice if someone can agree with me

    ThomasSmailus: I can see the value

    shepazu: we should push implementations to these categories
    ... I'm ok with dropping unrealistic modes

    ThomasSmailus: so, if you target a mode, you implement
    everything for that mode?

    shepazu: yes

    krit: SVG fonts for instance can be optional so browser can

    shepazu: optional features are bad ideas

    ThomasSmailus: they might weaken the status

    krit: optional features can be a good idea

    nikos: there are probably not that many optional features
    ... so we'll probably only have a few modes

    krit: right now, nothing is optional

    shepazu: I think you associate scripting with a security mode
    ... the goal is to profile what the ua is trying to accomplish

    krit: in the security mode you can't do scripting, but in
    insecure mode, you *could* do scripting
    ... for cors, it's different
    ... but in a security mode, you can load resources from
    external resources through script

    shepazu: we should define that SVG needs to define CORs

    krit: I agree and my main focus

    shepazu: some people see a <use> reference external element as
    a security hole

    krit: yes, it can be
    ... the intergration spec should say when you can use <use>

    shepazu: I would decouple script and security

    krit: yes, and we should specify what UA do

    shepazu: yes, but we should also guide UA's if they do
    something silly
    ... I welcome that you fork the spec and do it from another
    angle so we can compare them
    ... if you can show that a mode is useless, we can remove them
    unless we can back them up with reality

Hit testing SVG root

    shepazu: if you have a <div> and you click on it
    ... and there 2 <p>'s and you click on the space between the
    ... what happens?

    ThomasSmailus: I've added invisible object to work around that

    krit: what do you want to have hit?
    ... what is the problem?

    shepazu: what if I'm writing an application, and there's an SVG
    on top of the document and I want to click on a paragraph and
    annotate it

    krit: so you want the svg to be ignore?

    shepazu: yes
    ... I can see what you want to hit the svg root or just want to
    pass through
    ... is that the default behavior

    krit: we had the same issue in webkit. if the svg had click
    through, it went to the background. authors didn't like it

    shepazu: we should have both
    ... maybe by default, the svg root takes pointer events
    ... is unpainted one? no, it's bounding box

    ed: that wouldn't cover the viewport
    ... if the root was empty for instance

    shepazu: should we resolve this?

    ThomasSmailus: yes. I'm running into this problem

    shepazu: right now, SVG has a strange relation with backgrounds

    krit: for an svg svg element we could say 'all'


      [14] https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events

    krit: if you look at the syntax. intiial is 'auto'. and you
    could say for svgsvgelement this means 'all'
    ... auto is not specified yet so we can do whatever we want
    ... it just happens to be implemented across all browsers

    shepazu: how about nested svg elements
    ... could you have nested svg that would have different
    ... or would it be the same as 'auto' on the root?

    krit: not sure if we can differ
    ... on inner SVG elements

    shepazu: if people think this is reasonable behavior

    ed: we need test cases. It seems useful that you can pick a

    shepazu: what is the best default? according to Dirk , webkit
    changed it to ...
    ... erik, what do you think?

    ed: it really depends on your use case. usually I wanted the
    click to go through but that might not be the most common one

    shepazu: I will write it up and do some testing
    ... and you can comment

    <TabAtkins> Note as well that if you need to change the
    "initial value" for particular elements, you can just do that
    in the UA stylesheet. No need to actually mess with the spec.

feImage and new crossOrigin attribute

    krit: filter effects has a new security section



    krit: and this defines new behavior
    ... which makes it more complicated
    ... firefix knows about some issues and other browsers probably
    have it as well.
    ... color should not change behavior of timing because you can
    mount attacks otherwise
    ... fedisplacement map can be used to harvest information
    ... the specification is trying to identify filters which
    expose this risk
    ... feimage can reference external images which can have
    private information
    ... my idea is to have a cors attribute just like in the html
    image so you can specify the cors mode
    ... if it's set, you can use an feImage in a displacement map

    ed: this sounds reasonable
    ... I was wondering about feFlood.

    krit: it can take currentcolor

    ed: same origin would continue to work?

    krit: probably yes
    ... my problem with same origin is that the spec is not there
    ... we can limit the restriction later

    cabanier: will this break current behavior?

    krit: probably
    ... depending on the specs that are in progress

    ed: can we reference it?

    krit: it's in html5 from w3c

    ed: I'm concerned with backward compatibility

    krit: I will make a note

    resolution: krit to add a crossOrigin attribute to feImage

fx tf meetig in Seattle

    krit: I will take care of planning
    ... mon-tues will be css. wed fxg and thurs-fri SVG
    ... let me know if you have suggestions, please reply

    ed: can you send out meeting notes?


    <ed> trackbot, end telcon

Summary of Action Items

    [End of minutes]

     Minutes formatted by David Booth's [16]scribe.perl version
     1.138 ([17]CVS log)
     $Date: 2013-10-03 21:32:50 $

      [16] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [17] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [18]http://dev.w3.org/cvsweb/~checkout~/2002/

      [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/prepare topic/prepare an agenda/
Succeeded: s/ed: please let us know and we'll put them on the wiki page/
ed: please let us know what topics you'd like to discuss at TPAC (feel f
ree to use the agenda request wikipage) and we'll put them on the agenda
Succeeded: s/fetransform/feFlood/
Succeeded: s/yes/probably/
Found ScribeNick: cabanier
Inferring Scribes: cabanier
Default Present: +1.425.373.aaaa, +49.341.263.2.aabb, [IPcaller], ed, +6
1.2.980.5.aacc, Doug_Schepers, nikos, krit, cabanier, stakagi, thomas, T
Present: +1.425.373.aaaa +49.341.263.2.aabb [IPcaller] ed +61.2.980.5.aa
cc Doug_Schepers nikos krit cabanier stakagi thomas Tav
Regrets: CL Luc Cyril heycam brian rich
Agenda: [19]http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec
Found Date: 03 Oct 2013
Guessing minutes URL: [20]http://www.w3.org/2013/10/03-svg-minutes.html
People with action items:

      [20] http://www.w3.org/2013/10/03-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

    End of [21]scribe.perl diagnostic output]

      [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Friday, 4 October 2013 08:26:07 UTC

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