See also: IRC log
<trackbot> Date: 03 October 2013
<scribe> scribenick: cabanier
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
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
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.
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
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
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]