W3C

- DRAFT -

SVG Working Group Teleconference

03 Oct 2013

Agenda

See also: IRC log

Attendees

Present
+1.425.373.aaaa, +49.341.263.2.aabb, [IPcaller], ed, +61.2.980.5.aacc, Doug_Schepers, nikos, krit, cabanier, stakagi, thomas, Tav
Regrets
CL, Luc, Cyril, heycam, brian, rich
Chair
ed
Scribe
cabanier

Contents


<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 them

<nikos> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20131114&p1=240&p2=1232&p3=234

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: https://svgwg.org/specs/integration/

<krit> 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 mode
... 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 animation

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 choose

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 <p>'s
... 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'

<krit> 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 behavior
... 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 mode

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> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#fedisplacementmap-restrictions

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 yet
... 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?

thanks!

<ed> trackbot, end telcon

Summary of Action Items

[End of minutes]

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

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 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 free 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, +61.2.980.5.aacc, Doug_Schepers, nikos, krit, cabanier, stakagi, thomas, Tav
Present: +1.425.373.aaaa +49.341.263.2.aabb [IPcaller] ed +61.2.980.5.aacc Doug_Schepers nikos krit cabanier stakagi thomas Tav
Regrets: CL Luc Cyril heycam brian rich
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0003.html
Found Date: 03 Oct 2013
Guessing minutes URL: http://www.w3.org/2013/10/03-svg-minutes.html
People with action items: 

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


[End of scribe.perl diagnostic output]