- From: Dirk Schulze <dschulze@adobe.com>
 - Date: Thu, 8 Nov 2012 14:24:28 -0800
 - To: "SVG WG (public-svg-wg@w3.org)" <public-svg-wg@w3.org>, www-svg list <www-svg@w3.org>
 
Hi,
Here are the meeting minutes of our weekly telcon from 2012-11-08: http://www.w3.org/2012/11/08-svg-minutes.html
Greetings,
Dirk
   [1]W3C
      [1] http://www.w3.org/
                               - DRAFT -
                    SVG Working Group Teleconference
08 Nov 2012
   [2]Agenda
      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0020.html
   See also: [3]IRC log
      [3] http://www.w3.org/2012/11/08-svg-irc
Attendees
   Present
          [IPcaller], ed, +61.2.980.5.aaaa, nikos, Tab_Atkins,
          +1.415.832.aabb, krit, cabanier, Doug_Schepers
   Regrets
   Chair
          ed
   Scribe
          krit, TabAtkins
Contents
     * [4]Topics
     * [5]Summary of Action Items
     __________________________________________________________
   <trackbot> Date: 08 November 2012
   <TabAtkins> Oh, it's UTC, not GMT, so it doesn't care about the
   seasonal adjustment. kk.
   <krit> ScribeNick krit
   <krit> ScribeNick: krit
   topic Ambiguities in fill:url() / stroke:url() syntax
   TabAtkins: browsers use different code paths for getting
   resources if it is an image or an external resource
   ... this is fine currently
   ... mask is the first property where we may define both
   ... so we need to find a solution how we can differ between the
   two kind of code paths
   ... talked with roc and krit and came up with a simple rule
   that works in most cases
   ... the rule is: for most css properties a URL is always an
   image
   ... fill and stroke would interprete a URL with hash as
   resource instead of an image by default
   ... this would apply to the mask property as well
   ... if URL has an hash, it will point to an resource, otherwise
   image
   ... we would differ on property base if the default would be an
   image (like background) or a resource like on fill stroke
   ... hopefully this does not have a lot of compat problems
   ... it might be diffcult on mask, where things would be
   interprete as image currently, which would be interpreted as
   resource in the future
   ... this is a very low risv
   risc
   TabAtkins: to force an image load you need to take an image()
   function
   ed: for opera this sounds fine
   ... mask would be the only property where it could cause
   problems
   TabAtkins: yes
   <TabAtkins> ScribeNick: TabAtkins
   krit: Tab asked me if there is a technical reason why I'm
   opposed to this behavior for mask-image.
   ... The problem on webkit is that we interpret as resoruce or
   image solely on the property basis.
   ... Currently on -webkit-mask-image it's only an image.
   ... Changing things would mean a decent bit of refactoring,
   which realisticaly speaking is not happening.
   TabAtkins: So, ignoring legacy, if we introduced a brand new
   property that accepted both refs and images, and used this rule
   to distinguish, you're saying it would be a problem?
   krit: Yes, becasue of the necessary refactoring in our CSS
   Parser.
   TabAtkins: Okay. If it's just a matter of lack of resources for
   webkit on SVG, not a problem of actual technical difficulty,
   I'm okay with still accepting this rule.
   <krit> ScribeNick: krit
   krit: not technical difficulty speaking of web point of view
   ... just implementation point of view on webkit
   ... the compat problems could be SVG fragments like view box
   ... these could still be used with image() in the future, but
   would be incompatible at the moment
   TabAtkins: right but roc fantaai and me thought it would be
   easier to make the rule for parsing easier
   ... and introduce image() instead
   <ed> by view box I assume you mean something like:
   #svgView(...)
   TabAtkins: with image() the user can force the parser to
   interpret as image
   ... yes, that is what i mean
   krit: I would like to delay the decision until looking into
   this more in webkit
   TabAtkins: If it is parser relaed, I can take a look as well
   krit: it is parser and structure related
   ed: where shold such a rule get to?
   krit: maybe CSS images or units and values, propably the later.
   But also SVG
   TabAtkins: units and values would be fine
   krit: this is just related to CSS at the moment
   ... what about attributes unrelated to CSS like xlink:href
   TabAtkins: should not effect these
   ed: agree, is different
   ... what about caching behavior
   ... came up on mailing list, should we consider that
   ... should we cache the URL once and reuse it on all the places
   krit: this is difficult if you have different properties
   ... background would be an image and mask would be a resource,
   this should affect caching
   ed: mask property links to an elmeent in an svg and a fill to
   the same document but different id, you could cache the same
   document
   krit: Firefox would not load a resource if it is from a
   different domain
   ... I would like to move this topic to the agenda in two weeks
   ed: fine for me
   topiuc Cross domain resources in resource documents
   topic Cross domain resources in resource documents
   <ed>
   [6]http://lists.w3.org/Archives/Public/www-svg/2012Oct/0025.htm
   l
      [6] http://lists.w3.org/Archives/Public/www-svg/2012Oct/0025.html
   krit: Boris said that FF does not load external resources from
   different domains, I wonder if we specify that
   doug: if browsers do it anyway then I am fine to follow CORS
   ed: what about the same domain
   krit: is there a problem for same domain
   ed: depends
   ... you send an image and get a ping back, so you could get
   some notification from other users
   shepazu: we should be mindful about riscs, but don't see it for
   ed's scenario
   ed: Opera does download cross domain resources but does not
   execute scripts
   krit: lets say you load an external resource which has an
   onLoad event, should this onload event fire?
   ed: for Opera the onload events won't be fired in the document
   that has scripting disabled
   krit: the same for internal resources?
   ... <svg><use xlink:href="doc.svg#rect"/></svg>
   ... <rect onload="alert();" id="rect"/>
   ... this does not fire on opera
   ed: I think this is right
   krit: could scripts lead to any security issues on external
   resources?
   TabAtkins: disabling should not lead to security issues
   ed: not sure if we had security concerns or it was made our
   implementation simpler (we did execute scripts in external use
   documents before, as required by tiny 1.2)
   krit: first, should external resources (corss domain), be
   dependent on CORS headers if they are loaded or not?
   ... this is the current behavior of FF
   ... I think we have the same rules on WebKit like FF
   ed: I think it makes sense to use CORS for external resources
   krit: I think we did not implement it that way in WebKit
   because of security concerns initially, but because of our
   handling of resources in general
   shepazu: and imv?
   s/imv/img/?
   krit: img is different
   ... we don't run scripts but declarative animations on it
   ... img does not contribute to hit testing
   ... even if I am not sure if we follow SVG spec here
   ... if you want hit testing use iframe, object or inline SVG
   ed: we just need to make sure that html:img and svg:image are
   allowed to download external cross domain resources
   krit: I had in mind to specify it explicitly for use, mask,
   filter, clip-path and paint servers
   ... not image resources
   resolution: use, mask, filter, clip-path and paint servers
   should check CORS before downloading external cross domain
   resources
   shepazu: you run into problems if you disallow JS execution on
   external resources
   krit: I don;t want to disallow more then needed. If there are
   no security problems, I am fine with keeping JS
   shepazu: SVG deployment basis would not be to bad on compat
   issues if we CORS scripts as well
   ... SVG could be more restrictive
   ed: I would personal like to let scripts apply the same as for
   HTML
   shepazu: Should we also restrict script to be the same origin
   with cors exceptions
   TabAtkins: sounds good for now
   shepazu: ed is the only one with concerns
   ed: we should verify that it does not break things
   shepazu: do you want to revisit later?
   ed: yes and let SVG not differ to much from HTML, that is my
   concern
   action dirk to follow up with this security model on webappsec
   <trackbot> Created ACTION-3399 - Follow up with this security
   model on webappsec [on Dirk Schulze - due 2012-11-15].
   ed: would be useless if CORS jsut applies to svg:script but not
   on html:script elements
   krit: I am not only talking about script elements
   topic Should MAsking and Filter Effects normatively reference
   SVG2
   krit: I am using the DOM interface model of SVG2 on both specs,
   because WebIDL is just supported with SVG2
   ... We ahve an agreement that ne DOM interfaces should use
   WebIDL
   ... this is actualy not a big deal but means that both specs
   can not leave CR until SVG2 is in CR
   ed: why does it need to reference SVG2?
   krit: because the DOM interface would be incompatible with
   SVG1.1 and WebIDL
   ... this is resolved in SVG2
   ... does anyone problems with that
   TabAtkins: fine with that
   ed: can leave it until it gets critical
   krit: any other concerns
   silence
   krit: do we need a resoultuion
   ed: don't think we need a resolution
   topic point element
   shepazu: defined SVGPointElement for SVG connectors
   ... ther might be other parts in the spec that need this point
   element
   ... I need to define how it works in connectors anyway
   TabAtkins: we should go ahead and lets connectors define Point
   element at the moment
   ... if we need it somewhere else, we can move it to SVG2 core
   krit: absolutely fine for me
   shepazu: would like to hear camerons opinion on that
   krit how far is mesh gradients and star element?
   Tav: waiting for feedback from Adobe
   cabanier: I'll look into that
   shepazu: nothing new on star
   ed: ping
   <ed> krit, yes?
   <ed> trackbot, make minutes
   <trackbot> Sorry, ed, I don't understand 'trackbot, make
   minutes'. Please refer to
   [7]http://www.w3.org/2005/06/tracker/irc for help.
      [7] http://www.w3.org/2005/06/tracker/irc
Summary of Action Items
   [End of minutes]
     __________________________________________________________
    Minutes formatted by David Booth's [8]scribe.perl version
    1.137 ([9]CVS log)
    $Date: 2012/11/08 22:19:43 $
     __________________________________________________________
      [8] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [9] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01
Check for newer version at [10]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
     [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/aching/caching/
Succeeded: s/krtlets/krit: lets/
Succeeded: s/ for Opera all scripts are disabled on external resources./
 for Opera the onload events won't be fired in the document that has scr
ipting disabled/
Succeeded: s/it was easier to implement it/it was made our implementatio
n simpler (we did execute scripts in external use documents before, as r
equired by tiny 1.2)/
WARNING: Bad s/// command: s/imv/img/?
Succeeded: s/ed/shepazu/
Succeeded: s/ing and image/html:img and svg:image/
Succeeded: s/be/reference/
Found ScribeNick: krit
Found ScribeNick: TabAtkins
Found ScribeNick: krit
Inferring Scribes: krit, TabAtkins
Scribes: krit, TabAtkins
ScribeNicks: krit, TabAtkins
WARNING: No "Topic:" lines found.
Default Present: [IPcaller], ed, +61.2.980.5.aaaa, nikos, Tab_Atkins, +1
.415.832.aabb, krit, cabanier, Doug_Schepers
Present: [IPcaller] ed +61.2.980.5.aaaa nikos Tab_Atkins +1.415.832.aabb
 krit cabanier Doug_Schepers
Agenda: [11]http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec
/0020.html
Found Date: 08 Nov 2012
Guessing minutes URL: [12]http://www.w3.org/2012/11/08-svg-minutes.html
People with action items:
     [11] http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0020.html
     [12] http://www.w3.org/2012/11/08-svg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
WARNING: No "Topic: ..." lines found!
Resulting HTML may have an empty (invalid) <ol>...</ol>.
Explanation: "Topic: ..." lines are used to indicate the start of
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report
   End of [13]scribe.perl diagnostic output]
     [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 8 November 2012 22:24:55 UTC