See also: IRC log
<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> 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 http://www.w3.org/2005/06/tracker/irc for help.
This is scribe.perl Revision: 1.137 of Date: 2012/09/20 20:19:01 Check for newer version at 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 scripting disabled/ Succeeded: s/it was easier to implement it/it was made our implementation simpler (we did execute scripts in external use documents before, as required 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: http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0020.html Found Date: 08 Nov 2012 Guessing minutes URL: http://www.w3.org/2012/11/08-svg-minutes.html People with action items: 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 scribe.perl diagnostic output]