- From: Erik Dahlstrom <ed@opera.com>
- Date: Fri, 04 Oct 2013 10:25:33 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
As html:
http://www.w3.org/2013/10/03-svg-minutes.html
as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
03 Oct 2013
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0003.html
See also: [3]IRC log
[3] http://www.w3.org/2013/10/03-svg-irc
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
* [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
them
<nikos>
[11]http://www.timeanddate.com/worldclock/meetingtime.html?iso=
20131114&p1=240&p2=1232&p3=234
[11]
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: [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
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>
[14]https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-ev
ents
[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
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>
[15]https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
#fedisplacementmap-restrictions
[15]
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 [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/
scribe/
[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
av
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
/0003.html
Found Date: 03 Oct 2013
Guessing minutes URL: [20]http://www.w3.org/2013/10/03-svg-minutes.html
People with action items:
[19]
http://lists.w3.org/Archives/Public/public-svg-wg/2013OctDec/0003.html
[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:08 UTC