08:16:55 <RRSAgent> RRSAgent has joined #svg
08:16:55 <RRSAgent> logging to http://www.w3.org/2014/08/25-svg-irc
08:16:58 <heycam> Chair: Cameron
08:17:01 <heycam> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
08:17:10 <heycam> Meeting: London 2014 SVG WG F2F Day 3
08:19:54 <jun> jun has joined #svg
08:20:35 <Rossen_> Rossen_ has joined #svg
08:20:37 <ed> scribeNick: ed
08:21:01 <ed> topic: Performance of transformation in panning & zooming ("transforms", "will-change")
08:22:06 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming
08:23:24 <ed> konno: zooming and panning is for general webpages rather than mapping
08:23:32 <ed> ... it's an important feature
08:23:39 <ed> ... we have three requirements
08:23:49 <ed> ... 1) smooth start
08:24:01 <ed> ... 2) smooth transition during panning and zooming
08:24:15 <ed> ... 3) crisp view after panning/zooming is finished
08:24:36 <ed> ... there are some issues re the performance of zooming & panning
08:24:43 <ed> ... see table in the above wikipage
08:24:57 <ed> krit: is this scripted or native implementation?
08:25:08 <ed> brian: it's scripted, it's not the whole page
08:25:08 <jun> jun has joined #svg
08:25:14 <ed> ... with translate3d
08:25:27 <ed> rossen: so how are you doing this exactly?
08:25:39 <ed> brian: by chaning the transform, so doesn't affect the whole page
08:26:12 <ed> konno: [presents the table https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Facts]
08:26:46 <ed> s/translate3d/scale3d
08:27:26 <ed> ... [demos the first example running in firefox]
08:30:01 <Tav> Tav has joined #svg
08:30:03 <ed> ... shows the last example in chrome, where chrome doesn't render the view crisply after finishing the zooming
08:30:29 <ed> (this is chrome version 36)
08:30:41 <heycam> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Facts
08:32:05 <ed> heycam: maybe 2d scale transform might work better, does it have the same behaviour then?
08:33:05 <ed> konno: possible solutions, specifying css transform more closely
08:33:17 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Performance_in_panning_%26_zooming#Possible_Solutions
08:33:40 <ed> ... it might also be included in the will-change spec
08:33:56 <ed> ... third way is using another way for zoming and panning, maybe using compositor thread
08:34:16 <ed> ... it's a little bit difficult currently
08:34:24 <ed> ... but this is an implementation issue, not a spec issue
08:34:58 <ed> ... should this be a spec issue or a implementation issue?
08:35:09 <ed> krit: that everything is pixelated is an implementation issue
08:35:23 <ed> heycam: css transform prob doesn't say anything about crisp rendering
08:35:36 <ed> Rossen_: you're talking about zooming and panning, but are using transforms
08:35:46 <ed> ... these are different things
08:36:08 <ed> ... they can do similar things, but you can do different optimizations for the zooming and panning than for transforms
08:36:28 <ed> ... depending on the current environment it will cause degenerate cases
08:36:35 <ed> ... causing other elements to be rendered as well
08:36:47 <ed> ... in the context of p&z, the two are completely different
08:37:00 <ed> ... so, are you talking about p&z or about transforms?
08:37:09 <ed> heycam: it's implemented using transforms
08:37:19 <ed> ... because that's what you have to do currently
08:38:12 <ed> Rossen_: in trident we have optimized p&z
08:38:24 <ed> krit: you don't mean svg panning and zooming, right?
08:38:35 <ed> Rossen_: right, not specifically svg panning and zooming
08:38:48 <ed> brian: it's for an element, not for the whole page
08:39:03 <ed> ... the question about spec vs impl
08:39:14 <ed> ... the gecko behavior should be fixed in impl
08:39:31 <ed> ... when we scale using css animation, we don't resample during animation, so that it's smooth
08:39:42 <ed> ... we could adjust heuristics
08:39:52 <ed> ... don't think we need to spec anything for that
08:39:58 <ed> heycam: i think I agree
08:40:14 <ed> tav: are tehre cases where you'd want a different behaviour?
08:40:21 <ed> heycam: jerky zooming?
08:40:37 <ed> Rossen_: in host zooming, we don't resample until you reach a stable state
08:41:12 <ed> brian: we had some heuristics for layers and animation
08:41:23 <ed> Rossen_: it's certainly an implementation issue
08:42:05 <ed> konno: if it's an impl issue, we should create a testsuite for this
08:42:11 <ed> brian: sure, but it shouldn't be a conformance testsuite
08:42:20 <ed> ... just something to link to from the bugs filed
08:42:34 <ed> Rossen_: or submit the tests to the performance WG
08:42:45 <ed> heycam: for like rendering perf?
08:43:08 <ed> Rossen_: yes, I think it'd be good to ping them to see if they have any ideas on this
08:43:39 <jet> jet has joined #svg
08:43:43 <ed> heycam: for the second issue, about chrome and not rendering crisply, if you use 2d scale instead
08:44:17 <ed> krit: for some reason it looked the same (in webkit)
08:44:34 <ed> ... the start and end should always look crisp
08:44:39 <ed> heycam: so you think it's a bug?
08:44:59 <ed> krit: it's using scale3d as the last argument, which shouldn't be hw acc
08:45:07 <ed> Rossen_: have you tried this with text instead?
08:45:17 <ed> ... so without svg, just regular html
08:45:28 <ed> konno: only with svg
08:45:35 <ed> krit: it's using an object tag
08:46:09 <ed> ed: would be interesting to see if it's the same when using <img>, <iframe> or otherwise
08:46:19 <ed> heycam: do you agree that it's an impl issue as well?
08:46:24 <ed> krit/ed: yeah
08:46:48 <ed> heycam: it would be intersting to think about the R3 at some point
08:46:57 <ed> ... so that you don't have to use css animations
08:47:07 <ed> ... like using gestures directly
08:47:12 <ed> krit: link it to scrolling?
08:47:19 <ed> heycam: haven't thought about it much yet
08:47:39 <ed> ... you can define it in terms of css boxes, scale ...
08:48:13 <ed> brian: we want to take web animations off thread
08:48:19 <ed> ... and gestures
08:48:38 <ed> krit: blink said that scrolling should be done with javascript, or polyfills
08:48:46 <ed> ... they might change their minds later
08:49:03 <ed> Rossen_: were you at the input f2f?
08:49:18 <ed> krit: no, this was mailing list
08:49:50 <ed> ... if you do everything in js everything will be 60fps
08:50:08 <ed> brian: they set out current time based on scroll position
08:50:20 <ed> krit: might be an organizational issue
08:50:35 <ed> brian: they said we wish you had the web animations api
08:50:52 <ed> krit: so we agree no spec changes are required?
08:50:55 <ed> all: yes
08:51:10 <ed> topic: HTML integration (aka iframe spec issues)
08:51:13 <birtles> https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration
08:51:30 <ed> brian: this is something konnosan and I have discussed
08:51:49 <ed> ... will go through the wikipage
08:52:05 <ed> ... img is non-interactive, and fairly limited
08:52:09 <ed> ... we want something like iframe
08:52:14 <ed> krit: who are we?
08:52:30 <ed> brian: the people wanting to address mapping use-cases
08:52:41 <ed> ... some ppl said they wanted canvas in svg
08:52:51 <ed> ... you can with foreignObject, but it's cumbersome
08:53:11 <ed> ... at the same time ppl want to be able to put div directly into the svg
08:53:15 <ed> ... this is the background
08:53:45 <ed> ... in order to address this, we've added the embedded content chapter to the svg2 spec
08:53:56 <ed> ... it hasn't had much review yet
08:54:07 <ed> https://svgwg.org/svg2-draft/embedded.html
08:54:35 <ed> ... it combines some exisitng elements like foreignObject and image, so mostly the chapter is new, but there's some old content too
08:54:59 <ed> ... some work commissioned by KDDI, got delayed due to multiple inheritance...
08:55:11 <ed> ... inheritng from both SVGELement and HTMLElement wasn't a good approach
08:55:26 <ed> ... from the mozilla viewpoint, and even from a spec POV
08:55:39 <ed> ... should we really have an svg iframe element to begin with?
08:55:53 <ed> ... led to discussion on svg and whatwg list
08:56:05 <ed> ... we should instead allow html elements without having foreignObject
08:56:28 <ed> ... that was the discussion there led to
08:56:53 <ed> ... treat such elements as relative positioned
08:57:04 <ed> ... layout is the second issue, one is parsing one is layout
08:57:15 <ed> ... there's an outline of how it might work
08:57:29 <ed> ... the proposal had x and y attributes
08:57:41 <ed> ... we already decided to have x and y properties
08:58:08 <ed> ... svg iframe had x, y and transform attributes
08:58:31 <ed> ... if we want to allow that under this new proposal we'd need to add x,y and transform to HTMLElement
08:58:56 <ed> ... there are two big issues, first is how to support parsing
08:59:03 <ed> ... I put a fragment in the wikipage
08:59:10 <ed> <!doctype html>
08:59:10 <ed> <svg>
08:59:10 <ed> <span id="s"></span>
08:59:10 <ed> <div id="i"></div>
08:59:30 <ed> ... what happens is whenever it sees the html elemnents it breaks out of the svg parsing mode
08:59:47 <ed> ... because some pages on the web had content like this, which would otherwise break
09:00:09 <ed> ... if we want to allow these elements to be descendents of the svg, we'd need to not break of svg mode
09:00:17 <ed> ... so we'd need to change the html5 parser
09:00:24 <ed> ... question is, is this something we can do?
09:00:38 <ed> ... if we do, then pages that have no closing svg element would stop rendering again
09:00:46 <ed> rik: well, they'd render differently
09:01:57 <ed> brian: except if we make these elements render as children of the svg, then perhaps they woukld start rending
09:02:22 <ed> ... however, the defaiult rendering for <svg> is overflow:hidden, so they might not render after all
09:03:08 <ed> ed: right, but we decided to make overflow:visible for this case at this F2F
09:03:38 <ed> heycam: the scorlling behavior might become wonky
09:03:58 <ed> krit: if we do render, everything will be positiioned relative to the top left of the svg root
09:04:16 <ed> heycam: the block will still be 300px, even if we have overflow visible
09:04:33 <ed> brian: why don't we just break these pages?
09:04:51 <ed> krit: I'd expect that codepens would break alot
09:04:59 <ed> heycam: like examples ppl have coded up?
09:05:57 <ed> doug: why don't we have an <html> element inside the svg?
09:06:23 <ed> brian: the other suggestion from anne, if we embed html elements in svg, you need to opt-in
09:06:29 <ed> ... so that you can choose
09:06:32 <cyril> cyril has joined #svg
09:06:46 <ed> heycam: it would be strange for the presence of an attribute to change the parser behavior
09:06:58 <ed> brian: anne said the same thing, he doesn't like it, but it's possible
09:07:25 <ed> doug: is there some reason why we don't want to put the elements inside an <html> content (instead of foreignObject)
09:07:31 <ed> ... what's the goal?
09:07:42 <jwatt> jwatt has joined #svg
09:07:44 <ed> ... if we get wrapping text, what's the reason we want this?
09:07:46 <cyril> RRSAgent, pointer
09:07:46 <RRSAgent> See http://www.w3.org/2014/08/25-svg-irc#T09-07-46
09:07:52 <ed> brian: it's iframe, canvas etc
09:08:00 <tkonno> (FYI) http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Iframe_spec_issue_through_the_development
09:08:06 <cyril> RRSAgent, make log public
09:08:29 <ed> doug: if I wrote a document, like a barchart, and I wanted some text assoc with it, i'd prob want to put the text into the same structure, so having html root there would be kind of a pain
09:08:45 <ed> ... but for standalone video, canvas I don't think it's so much of a pain
09:09:10 <ed> ... we could advance from this at a later stage
09:09:20 <ed> brian: how is this different compared to foreignObject?
09:09:26 <ed> doug: it's not, jsut easier to type
09:09:46 <ed> brian: if you want to nest and svg in another svg, using iframe
09:09:58 <ed> doug: couldn't you use a <use> element?
09:10:12 <ed> brian: no, want interaction and separate document
09:10:34 <ed> ... the reason <image> isn't good is because it isn't interactive
09:10:49 <ed> doug: what would the perf characteristics be like?
09:11:31 <ed> ... I'd rather have a custom element thgat behaves like iframe, so taht we could optimize it for this use-case
09:11:43 <ed> brian: the feedback was that we don't want that
09:12:11 <ed> doug: html already have four different iframes, don't see why we couldn't have one
09:12:25 <ed> ... you'd be establishing a viewport inside the svg for the html
09:12:38 <ed> heycam: I think what ppl are saying is they don't want the duplication
09:12:48 <ed> jwatt: can't we sidestep the issue
09:13:05 <ed> ... by using a UA stylesheet
09:13:58 <heycam> <box><div>...</div></box>     |     box > * { position: absolute; top: 0; left; 0; width: 100%: height: 100%; }
09:14:06 <heycam> where that rule goes in the UA style sheet
09:14:12 <heycam> avoids having to write <div style="position: absolute; ...">
09:14:42 <shepazu> shepazu has joined #svg
09:15:07 <ed> jwatt: one problem i'm trying to fit the content inside the foreigobject to a specific area
09:15:38 <ed> heycam: what if you stick an animate tag inside a foreignobject
09:15:48 <ed> Rossen_: not sure foreignobject content has to be html content
09:15:56 <ed> ... could be anything else, VRML or whatever
09:16:11 <ed> jwatt: we don't want to have to use namespaces
09:16:26 <ed> ... maybe we could come up witha  tag like iframe with the expansion
09:16:46 <ed> ... with some attribute that knocks it into a special mode for the parsing
09:16:48 <ed> krit: i'm worried about breaking content
09:17:00 <ed> ... we should think about the layout as well
09:17:21 <ed> ... ppl want to put a rect aligned to some text, in terms of html we should think about how that might work
09:17:31 <ed> ... something like VML did in the past
09:17:36 <ed> jwatt: not sure it's related
09:18:05 <ed> heycam: so brian, what's the specific list of issues with foreignobject that we could solve with the proposals?
09:18:22 <ed> brian: authoring, it's a long hard name, that you have to wrap things in
09:18:50 <ed> ... when you hae something like map, with hundreds of tiles, the overhead of haivng to wrap in FO is high
09:19:12 <ed> ... the dimensions of the FO and having to set the same on the canvas / video etc is cumbersome
09:19:31 <ed> jet: is it typically hand-written svgs?
09:19:41 <ed> brian: maybe it's mostly the filesize issue
09:19:56 <ed> ... for handwritten stuff it's mostly the thing with the sizing
09:20:25 <ed> heycam: if we had had audio, video, canvas from the start we'd have had them directly without the wrapper
09:20:42 <ed> ... we could perhaps treat replaced elements different to the others
09:20:52 <ed> ... so video different to div e.g
09:21:08 <ed> brian: for templates you have to wrap things in FO, which is a pain
09:21:25 <ed> ... the use.cases for this will grow, and the overhead of having to wrap elements is bad
09:22:02 <birtles> s/wrap elements is bad/wrap elements is unfortunate/
09:22:05 <ed> Rossen_: it's pretty natural to want non-wrapped elements, like <button> for native UI
09:22:22 <ed> heycam: i'm optimistic about trying to go ahead to allow arbitrary html elements inside svg content
09:22:24 <birtles> s/for templates/for <template>s/
09:22:45 <ed> heycam: what are the downsides of doing this besides breaking content?
09:22:51 <ed> brian: how to define the layout
09:23:05 <ed> ... needs to be worked out
09:23:25 <ed> tav: suddenly you will have lots of "junk" in the svg (html elements), which editing tools will have to support
09:23:41 <ed> heycam: do editing tools support foreignobject atm?
09:23:53 <ed> tav: it'll be a black box, nothign inside the FO is supported
09:24:11 <ed> ... if I had an svg I'd expect to be able to see it and be able to edit it in the editor
09:24:19 <ed> heycam: do you see that as a bad thing?
09:24:27 <ed> tav: if tehre are svg native alternatives maybe
09:24:34 <ed> ... I don't know
09:24:45 <ed> brian: a similar thing, svg in opentype
09:24:51 <ed> ... what does it say about FO?
09:24:54 <ed> heycam: it's disabled
09:25:00 <ed> brian: we might do the same
09:25:15 <ed> tav: i like the idea of the html tag
09:25:28 <ed> brian: for things like <template> that is really unnatural
09:25:46 <ed> ... why would you have to wrap it in <html>?
09:25:53 <ed> doug: how many features do you think we want in svg?
09:25:58 <jet> jet has joined #svg
09:26:25 <ed> cyril: the integration so far in svg2 is very unintutive and strange
09:26:46 <ed> ... either you go with raplacing FO with <html>, or we need to document better
09:26:50 <ed> brian: why are they confused?
09:27:01 <ed> ... if you had a <form> inside a <g> for example
09:27:13 <ed> cyril: as long as the layout is defined it'd be fine
09:27:35 <ed> tav: how would this work with xml parsing?
09:28:02 <ed> cyril: this is also an issue for video elements, do you have to close tags, and controls attributes
09:28:10 <ed> heycam: whatever xhtml requires would apply here
09:29:03 <ed> tav: right now if put <html> directly in svg, it'll parse but won't know what else to do with it
09:29:13 <ed> heycam: with xml you can construct arbitrary DOMs
09:29:29 <ed> brian: hearing some opposition to allwoing html elements to be used bare within svg
09:29:34 <ed> ... not sure exactly why
09:29:44 <ed> ... tab atkins, roc and so on
09:29:57 <ed> ... don't have a sense of whether this is doable
09:30:07 <ed> ... not a fan of redefining the elemnets in terms of svg
09:30:19 <ed> ... a compromise of having a box of html element might work
09:30:34 <ed> heycam: we resolved to try and mopve things to the same namepsace
09:30:50 <ed> ... so you'd have the iframe element in the same namespace
09:30:51 <cyril> s/mopve/move/
09:31:13 <ed> ... so there's not really going to be svg and html versions of the same element, they'll actually be the same
09:31:39 <ed> ... it's consistent with that
09:32:05 <ed> ed: I think it would be really nice to not have to wrap things in <html> or FO
09:32:12 <ed> krit: this would require parser changes
09:32:18 <ed> heycam: yes, all of the proposals would
09:32:37 <ed> ... would it help to sort out the issues, and get a more concrete proposal
09:32:55 <ed> brian: yes, and try to get more feedback from the html people
09:33:19 <ed> heycam: it would be good to inform them of the different ways to handle things
09:33:31 <ed> brian: sounds good
09:33:56 <ed> jet: selling the change to the html5 parser will be hard I think
09:34:13 <ed> Rossen_: it does also bring the issues with authoring tools
09:34:31 <ed> jet: also sandboxing and security, the cost is high of removing FO
09:34:53 <ed> brian: long term I think we'd want to get rid of FO
09:35:33 <ed> cyril: but why? it can be used for PDF and lots of different things, it's the extensibility point
09:35:48 <ed> brian: this would be replacing this with something people would find easier to use
09:36:06 <ed> cyril: FO doesn't add its content to the DOM, right?
09:36:19 <ed> jwatt: if it's inline markup then that will get included in the DOM
09:36:56 <ed> cyril: we can put VRML in FO in our player
09:37:09 <ed> ... or any other format that's supported, just by looking at the mimetype
09:37:24 <ed> heycam: don't think there's a mimetype attribute on FO
09:37:59 <ed> ... so an action to make things more concrete?
09:38:45 <ed> ACTION: brian to write up a more concrete proposal for allowing html elements directly in svg (related to https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda/HTML_integration)
09:38:46 <trackbot> Created ACTION-3648 - Write up a more concrete proposal for allowing html elements directly in svg (related to https://www.w3.org/graphics/svg/wg/wiki/f2f/london_2014/agenda/html_integration) [on Brian Birtles - due 2014-09-01].
09:39:02 <ed> -- 15 min break --
09:47:01 <stakagi> stakagi has joined #svg
10:03:00 <jwatt> jwatt has joined #svg
10:07:11 <stakagi> Thanks!
10:10:33 <nikos> nikos has joined #svg
10:10:47 <jun> jun has joined #svg
10:11:15 <stakagi_> stakagi_ has joined #svg
10:12:08 <stakagi__> stakagi__ has joined #svg
10:13:30 <stakagi_> stakagi_ has joined #svg
10:13:53 <cyril_> cyril_ has joined #svg
10:14:02 <cyril_> scribe: cyril
10:14:06 <cyril_> scribeNick: Cyril
10:14:22 <cyril_> Topic: HTML Integration (issue 2)
10:14:34 <Rossen_> Rossen_ has joined #svg
10:14:37 <cyril_> scribeNick: cyril_
10:14:45 <cyril_> brian: defining layout
10:14:58 <cyril_> scribeNick: cyril_
10:15:06 <cyril_> ... I'm trying to represent the proposal, initial from RoC
10:15:40 <cyril_> ... original proposal was that html children of SVG element are treated as position relative
10:15:56 <cyril_> ... so that you have x/y properties position things as you expect
10:16:20 <cyril_> so that <iframe width=.. height ...> would wokr
10:16:52 <cyril_> Rossen: what about position: fixed (or page)
10:17:07 <cyril_> brian: the question was raised about other position values
10:18:22 <cyril_> rossen: the problem I have is that display: inside on your SVG element hosting HTML
10:18:31 <cyril_> ... display-inside should be grid
10:18:42 <cyril_> ... I should be able to use grid positioning
10:18:52 <cyril_> ... this is just one example: multi-column ...
10:19:02 <cyril_> ... I would expect to work on foreignObject
10:19:16 <cyril_> ... blink currently supports multicolumn on foreignObject
10:19:53 <cyril_> as a general behavior of the fO, or the new HTML integration, I'd expect allowing display-inside to anyhting other that svg
10:20:22 <cyril_> ... we should just define the containing block
10:21:00 <cyril_> ... overall I don't think we have too much of a problem
10:21:10 <cyril_> ... we should say that fO defines the initial containing bloc
10:21:22 <cyril_> ... and display types is a different discussion
10:21:38 <ed> https://svgwg.org/specs/integration/#foreign-content
10:22:17 <cyril_> heycam: I thought we talked about positioning HTML elements outside of fO
10:22:51 <cyril_> Rossen: on the contrary, if I have a rectangle, and HTML inside, what would happen
10:23:10 <cyril_> birtles: the proposal is not to use rectangles, just the nearest svg viewport
10:23:46 <cyril_> ed: the svg integration spec has some text regarding fO and initial containing block but the SVG 2 spec does not talk about it
10:25:00 <cyril_> heycam: is the desire to have display inside SVG so that the whole tree can use CSS layout to define where everything goes
10:25:11 <cyril_> ... SVG is like a replaced-elements, CSS stops, and SVG handles it
10:25:20 <cyril_> ... the desire is to have CSS control the whole thing
10:25:25 <cyril_> ... is that the purpose ?
10:25:28 <cyril_> birtles: I don't know
10:25:50 <cyril_> ... It was the result of a discussion between RoC and Tab
10:26:09 <cyril_> heycam: I'm not sure it's a useful thing
10:26:32 <cyril_> krit: the idea is that later SVG can adopt other CSS layouts
10:26:52 <cyril_> birtles: Anne was also in favor of that
10:27:07 <cyril_> krit: the idea is to be able to use SVG/HTML seamlessly
10:27:18 <cyril_> heycam: long term I wanted to do layout in SVG
10:27:30 <cyril_> ... allowing display and position to opt-in to CSS positioning
10:27:49 <cyril_> ... I don't know if on the root element it's the right or wrong thing without going all the way
10:28:12 <cyril_> krit: maybe at some points we want to have SVG specific layout
10:28:50 <cyril_> Rossen: having the new svg display type saying that the only layout I can do in SVG is svg, it's fine
10:29:13 <cyril_> ... but I would expect being able to change it, and if changing it does not work, would seem strange
10:29:24 <cyril_> heycam: we need to go one step ahead at least
10:29:41 <cyril_> krit: I don't we will be ever able to use all CSS layout in SVG
10:30:01 <cyril_> heycam: what's the reason for having display-inside: svg ?
10:30:18 <birtles> http://lists.w3.org/Archives/Public/www-svg/2014Jun/0144.html
10:31:25 <cyril_> heycam: Tab is suggesting that once we have the SVG layout model, then x/y can be used as is
10:31:46 <cyril_> ... I'd like to check other layout before locking that in
10:32:21 <cyril_> Rossen: the implications of display is that you are defining what x/y means inside that layout type
10:33:32 <cyril_> ... if we are tying that display-inside to an element type, we are preventing the use of other layout types when the content inside is anything else than svg
10:33:42 <cyril_> krit: it's hard to discuss it without the proponents
10:33:53 <cyril_> Rossen: we can discuss that in some weeks
10:34:09 <cyril_> ... we are going to discuss that in CSS WG F2F in 2 weeks
10:34:54 <cyril_> Rossen to discuss svg layout using CSS during the coming CSS F2F meeting
10:35:01 <cyril_> ACTION: Rossen to discuss svg layout using CSS during the coming CSS F2F meeting
10:35:01 <trackbot> Created ACTION-3649 - Discuss svg layout using css during the coming css f2f meeting [on Rossen Atanassov - due 2014-09-01].
10:35:34 <cyril_> heycam: if this proposal was to help for raw iframe in SVG, I don't thnk that the smallest way to make it work
10:35:49 <cyril_> ... we could just say that iframes are positioned with x/y
10:36:05 <cyril_> ... and we could then think more deeply on the layout question
10:36:18 <cyril_> Rossen: would you expect CSS display on svg element to affect the iframe
10:36:30 <cyril_> heycam: like <g display=flex>
10:36:41 <cyril_> ... maybe but there are lots of details to be worked out
10:36:50 <cyril_> Rossen: also inheritance
10:37:02 <cyril_> heycam: I would say yes because that's normal inheritance
10:37:30 <cyril_> Rossen: I played with fO in different implementations and had issues
10:38:22 <cyril_> Topic: Decision on tref
10:38:26 <Tav> http://tavmjong.free.fr/SVG/TREF/tref.html
10:38:50 <cyril_> Tav: a past decision left me thinking
10:39:19 <cyril_> ... before the previous meeting I had looked at the discussion on tref
10:39:30 <cyril_> ... someone proposed to deprecate tref
10:39:47 <cyril_> ... someone else says tref is useful for shadowing text and has been using it
10:40:11 <cyril_> ... I agree this is not the best way of using it, but he's got a hundred of installations using it
10:40:25 <cyril_> doug: standalone svg installations ?
10:40:35 <cyril_> Tav: it's mixed
10:40:49 <cyril_> shepazu: they still could be conformant 1.0 and 1.1 viewers
10:41:05 <cyril_> Tav: but there are other viewers browsers, using the same content
10:41:14 <cyril_> shepazu: Doug argued against deprecating
10:41:43 <cyril_> Tav: there was an issue with the security model of tref, but the same model as use could be used
10:42:13 <cyril_> ... some other people came in, saying it was useful and waiting for FF to implement
10:42:59 <cyril_> ... so just from reading the email, I don't see any reason for deprecating it
10:43:10 <cyril_> shepazu: there is more information, another thread of conversation
10:43:18 <cyril_> ... on one of the chrome-dev channel
10:43:35 <cyril_> ... and everebody agreed there (including Alex Russell)
10:44:15 <cyril_> ... Chrome is removing it, FF is not implementing it
10:44:28 <cyril_> ... if we want interoperability, that's going to be hard
10:44:47 <cyril_> Tav: from an external viewpoint, on the list, it looks like we are ignoring feedback
10:45:16 <cyril_> ... I got a sense from external people that their input is not important
10:45:19 <jwatt_> jwatt_ has joined #svg
10:46:25 <cyril_> ... the other problem is that it was removed, not deprecated
10:46:55 <cyril_> ed: there are very few things that you can do with tref that you can't with use
10:47:54 <cyril_> Tav: the basic thing is that we are breaking things that exist without much warnign, and I feel bad the way it's being done
10:48:12 <cyril_> shepazu: we can't force Chrome to support tref, or FF or IE
10:48:35 <cyril_> cyril_: we can at least say how to solve the same use cases differentlu
10:48:52 <cyril_> shepazu: yes, we should make some wiki page
10:49:18 <cyril_> ... there is a general practice that we deprecate in one version and remove in the next
10:49:32 <cyril_> Tav: we'd have much less problem with that
10:49:45 <cyril_> shepazu: I don't know about the requirements for deprecated features
10:50:50 <cyril_> ed: long time ago, I wrote up a polyfill for tref
10:51:24 <cyril_> nikos: the deprecation won't reinstate it in blink
10:51:41 <cyril_> krit: it's there in webkit
10:51:55 <krit> still
10:52:03 <cyril_> heycam: it's been removed from the spec
10:52:21 <cyril_> shepazu: we could have a section at the end of the spec about removed/deprecated things
10:52:32 <cyril_> heycam: probably it's mentionned in the change list
10:54:37 <cyril_> cyril: how would you solve a localization use case without tref ? with use ?
10:54:59 <cyril_> ed: tref can be used inside a text element, but use cannot
10:55:31 <cyril_> heycam: CSS text layout would be more difficuly
10:55:42 <cyril_> s/difficuly/difficult/
10:57:04 <cyril_> heycam: I think it's not implemented in FF because it's a weird feature
10:57:42 <cyril_> ACTION: Doug to inform the community why we removed tref and how to solve the use cases
10:57:43 <trackbot> Created ACTION-3650 - Inform the community why we removed tref and how to solve the use cases [on Doug Schepers - due 2014-09-01].
10:58:12 <ed> there's a sort of polyfill for tref in http://svg-wow.org/buffered-rendering/bokeh.html
10:58:24 <cyril_> Topic: fill and stroke improvements
10:58:49 <cyril_> krit: we already resolved that we want to have multiple layers for fill and stroke
10:58:59 <cyril_> ... the syntax is the same as the background property
10:59:17 <cyril_> ... so I would suggest that we add blend modes in fill and stroke
10:59:43 <cyril_> Tav: so for the problem of text visibility, we could use "difference"
11:00:03 <cyril_> ... you want the text to stick out from the background
11:00:17 <cyril_> ... one solution is to use a stroke of a different color behind the fill
11:01:12 <cyril_> krit: I want to blend just with the different layers within the fill
11:02:22 <cyril_> ... the fill is isolated as a group, and the stroke too
11:02:37 <cyril_> cabanier: so they would knock out each other
11:06:47 <cyril_> krit: people would like to use the same pattern in background and fill and stroke, we just miss blending
11:07:37 <cyril_> krit: you can already blend within the pattern
11:07:58 <cyril_> ... but people want to copy/paste what they have in background for the fill
11:08:56 <cyril_> heycam: about from background-attachment, is background-blend-mode the only background property that fill and stroke don't support
11:08:59 <cyril_> krit: yes
11:09:18 <cyril_> ... it's just an alignment with CSS in terms of syntax
11:09:38 <cyril_> heycam: if we explicitely use the same model, we should go for it
11:09:56 <cyril_> Tav: I want to think about it a bit more, but I think I agree with it
11:10:03 <cyril_> nikos: yes, makes sense
11:12:22 <cyril_> ACTION: Tav to investigate blending for fill and stroke
11:12:22 <trackbot> Created ACTION-3651 - Investigate blending for fill and stroke [on Tavmjong Bah - due 2014-09-01].
11:12:36 <cyril_> Tav: are you implementing it?
11:12:40 <cyril_> krit: yes and no
11:13:10 <cyril_> Tav: I would think it'd be pretty easy in Inkscape
11:13:22 <cyril_> ... it can be useful for cross-hatching
11:14:05 <cyril_> Topic: CSS layout properties
11:14:31 <krit> https://svgwg.org/svg2-draft/layout.html
11:15:10 <cyril> cyril has joined #svg
11:15:17 <cyril> scribeNick: cyril
11:15:40 <cyril> krit: I added some properties in the above link
11:15:52 <cyril> ... cx, cy, r, rx, ry
11:16:05 <cyril> ... we also have width and height but they are already in CSS
11:16:07 <stakagi> stakagi has joined #svg
11:16:28 <cyril> but we should clarify that they are CSS ropperties now
11:16:48 <cyril> we already have an experimental implementations in webkit (nightly)
11:17:11 <cyril> ... it supports viewport units, calc, css animations and transitions
11:17:22 <cyril> ... and the relevant attributes turn to presentation attributes
11:17:53 <cyril> cyril: so there would be a difference for type=XML and type=CSS in animations
11:18:04 <cyril> krit: yes the same difference as for other properties
11:18:55 <cyril> heycam: if you use vw and vh in a standalone document, what would you use ?
11:18:58 <cyril> krit: the window
11:19:22 <cyril> Rossen_: in CSS it's always the physical viewport
11:20:20 <cyril> Rossen_: the adoption of vh and vw is good in CSS, so people should not expect a different behavior
11:20:37 <cyril> heycam: it's just unfornate to have the same word "viewport"
11:20:43 <cyril> cyril: it's worth a note in the spec
11:20:46 <cyril> heycam: yes
11:21:07 <Rossen_> s/physical vieport/nearest viewport/
11:22:50 <cyril> ACTION: Dirk to add a note to the spec to clarify the use of viewport units versus the use of percentage of viewport
11:22:50 <trackbot> Created ACTION-3652 - Add a note to the spec to clarify the use of viewport units versus the use of percentage of viewport [on Dirk Schulze - due 2014-09-01].
11:23:19 <cyril> cyril: note, the title of the page should be fixed, it says "Filter Effects"
11:24:32 <ed> ACTION: dirk to make the initial values for the svg layout properties dependent on the element, r on radialgradient is different than r on circle (auto?)
11:24:32 <trackbot> Created ACTION-3653 - Make the initial values for the svg layout properties dependent on the element, r on radialgradient is different than r on circle (auto?) [on Dirk Schulze - due 2014-09-01].
11:25:47 <cyril> heycam: we should replace the grey line for presentation attributes to a link to that
11:26:10 <cyril> cyril: there should be a note explaining the consequences of these attributes becoming properties
11:26:47 <ed> nit: the heading links at the top of the chapter don't work
11:28:20 <cyril> -----lunch break ----
11:39:57 <jet> jet has joined #svg
11:44:33 <tkonno> tkonno has joined #svg
12:26:29 <jun> jun has joined #svg
12:29:36 <nikos> nikos has joined #svg
12:41:03 <tkonno> tkonno has joined #svg
13:04:38 <commit> commit has joined #svg
13:04:38 <commit> [13test] 15heycam pushed 3 new commits to 06master: 02http://git.io/yfWm8Q
13:04:38 <commit> 13test/06master 14fed0628 15Cameron McCormack: Rename svg2-tools/ to tools/.
13:04:38 <commit> 13test/06master 148fb423f 15Cameron McCormack: Update Makefile to point to new tools location.
13:04:38 <commit> 13test/06master 1401e963b 15Cameron McCormack: Ignore build directories.
13:04:38 <commit> commit has left #svg
13:08:45 <commit> commit has joined #svg
13:08:45 <commit> [13test] 15heycam pushed 1 new commit to 06master: 02http://git.io/CB5w2w
13:08:45 <commit> 13test/06master 14a882407 15Cameron McCormack: test change
13:08:45 <commit> commit has left #svg
13:10:15 <jun> jun has joined #svg
13:11:04 <Rossen_> Rossen_ has joined #svg
13:11:34 <ChrisL> ChrisL has joined #svg
13:27:13 <commit> commit has joined #svg
13:27:13 <commit> [13test] 15heycam pushed 1 new commit to 06master: 02http://git.io/_-2DbA
13:27:13 <commit> 13test/06master 148608157 15Cameron McCormack: Another test change.
13:27:13 <commit> commit has left #svg
13:31:36 <commit> commit has joined #svg
13:31:36 <commit> [13test] 15heycam pushed 2 new commits to 06master: 02http://git.io/nycJ3w
13:31:36 <commit> 13test/06master 1472b873d 15Cameron McCormack: Another test change.
13:31:36 <commit> 13test/06master 14bd21f5e 15Cameron McCormack: And one more.
13:31:36 <commit> commit has left #svg
13:34:38 <commit> commit has joined #svg
13:34:38 <commit> [13test] 15heycam pushed 2 new commits to 06master: 02http://git.io/WRVt0Q
13:34:38 <commit> 13test/06master 1418185ff 15Cameron McCormack: one change
13:34:38 <commit> 13test/06master 140e1f0f7 15Cameron McCormack: two change
13:34:38 <commit> commit has left #svg
13:35:46 <tkonno> tkonno has joined #svg
13:44:06 <Cyril> Cyril has joined #svg
13:49:37 <krit> tkonno: ed: https://bugs.webkit.org/show_bug.cgi?id=136225
13:59:04 <jet> jet has joined #svg
14:21:49 <Rossen_> Rossen_ has joined #svg
14:36:23 <jet> jet has joined #svg
14:41:01 <Cyril> Cyril has joined #svg
14:41:05 <krit> SubScript: krit
14:41:21 <Cyril> SuperScript: krit
14:41:22 <krit> ScribeNick: krit
14:41:43 <krit> topic: update on SVG integration spec
14:41:44 <heycam> https://svgwg.org/specs/integration/
14:41:59 <krit> heycam: The spec hasn’t changed the last time
14:41:59 <ChrisL> ChrisL has joined #svg
14:42:04 <nikos> nikos has joined #svg
14:42:06 <ChrisL> rrsagent, here
14:42:06 <RRSAgent> See http://www.w3.org/2014/08/25-svg-irc#T14-42-06
14:42:21 <krit> s/the last time/since the last time/
14:42:52 <krit> heycam: last time the OpenType group wanted a stable version by a part date
14:43:20 <krit> heycam: since then I talked with Vlad how to reference this document
14:43:36 <krit> heycam: he was concerned about making a normative reference unless it is REC
14:43:53 <krit> heycam: in which case I think it doesn’t make sense to reference the document normatlively
14:44:02 <krit> heycam: so I duplicated the changes to the OT spec
14:44:19 <krit> heycam: and added an informative text and reference to the SVG WG spec
14:44:37 <krit> heycam: saying that the SVG spec may update it
14:44:52 <krit> ChrisL: we had this issue before and it didn’t work out
14:45:26 <krit> heycam: SVG2 has context-fill/stroke which is not REC… So I duplicated this as well with a note as well
14:45:44 <krit> heycam: so there is no particular time frame requiring us to get this along
14:45:56 <krit> heycam:
14:46:17 <krit> heycam: Dirk didn’t you have something to talk about fetching? The work with Anne?
14:46:27 <krit> krit: won’t be in the integration spec but in SVG2
14:46:52 <krit> Cyril: wanted to look at the document cause it is quite small
14:47:02 <krit> Cyril: and issue 1 is something we can dicuss
14:47:12 <krit> Cyril: what is relevant for the document for instance?
14:47:26 <krit> Cyril: currently there are 3 interesting sections
14:47:46 <krit> Cyril: the intro says it will also add more recommendation how to extend or use SVG
14:48:00 <krit> Cyril: [quoting the spec]
14:48:20 <krit> Cyril: we don’t need to have those
14:48:31 <krit> s/Cyril/heycam/
14:48:44 <krit> heycam: sizing and reference mode are most interesting IMO
14:48:58 <krit> Cyril: I thought it was the same as processing modes
14:49:04 <krit> heycam: I split it out
14:49:18 <krit> heycam: they said animations in combination and scripting ….
14:49:27 <krit> Cyril: more higher level
14:49:59 <krit> Cyril: summary table of all different elements referencing element and the reference mode they use
14:50:06 <krit> Cyril: should be added
14:50:31 <krit> krit: just elements? or documents?
14:50:34 <krit> Cyril: just Cyril
14:50:40 <krit> Cyril: just elements
14:51:00 <krit> heycam: we should just have what we use on the web platform
14:51:14 <krit> Cyril: how are reference modes and processing modes related?
14:51:33 <krit> heycam: I might need to update the text in the example still
14:52:03 <krit> heycam: static image document is an example of an reference mode
14:52:21 <krit> Cyril: the way you reference the document has impact how you process the document
14:52:25 <krit> heycam: that is right
14:52:46 <krit> krit: so you are saying processing is important as well?
14:52:52 <krit> Cyril: I think it should be clear
14:53:48 <krit> heycam: the set of reference mode can be referenced by the referencing elements that we add to the reference table
14:54:40 <krit> heycam: the dot points in the issue has some nice to have
14:54:49 <krit> heycam: but would say we should delay to for now
14:55:08 <krit> heycam: the sizing stuff (next two dot points) has been defined
14:55:23 <krit> Cyril: isn’t sizing specified in CSS
14:55:25 <krit> krit: no
14:56:02 <krit> Rossen_: if it is embedded in contributes to the box model
14:56:26 <krit> heycam: we talked about intrinsic ratio, but where do we define that?
14:56:30 <krit> heycam: Is it defined?
14:56:47 <krit> Rossen_: don’t think it is defined but it apparently was discussed to the last F2F
14:56:49 <krit> heycam: yes
14:57:00 <krit> heycam: we can talk about it the next time
14:57:22 <krit> Cyril: ForeignObject use and size is not specified
14:57:30 <krit> heycam: ppl come up with their own ideas
14:57:39 <krit> heycam: cause the main SVG spec doesn’t say
14:57:54 <krit> Rossen_: does it need any particular element defined?
14:57:56 <krit> heycam: no
14:58:01 <krit> Rossen_: don’t think so either
14:59:15 <krit> Cyril: the description like context (XML or HTML context for SVG) should go into this document
14:59:55 <krit> heycam: doug wanted to have a format to use HTML parser
15:00:06 <krit> heycam: probably not more work
15:00:40 <krit> Rossen_: we can do HTML parser with additions in general
15:00:53 <krit> krit: there are certain cases where it is not enough
15:01:59 <krit> Rossen_: I think I agree that parse modes and expectations should be part of the document
15:02:10 <krit> heycam: ok, but it doesn’t need to be normative
15:02:33 <krit> Rossen_: at least interested people would have a document they can look at
15:02:59 <krit> Rossen_: and then we should discuss
15:03:12 <Cyril> we should loosen the parsing
15:03:21 <krit> a less restrictive parsing mode
15:03:53 <krit> heycam: so the 2nd last point would be an interesting reference for user
15:04:29 <krit> heycam: I had this but was hard to read.
15:05:01 <krit> heycam: ok, so we add sizing, html vs xml parsing mode and that is all
15:05:24 <krit> Rossen_: I had issues with scroll bars and overflow on foreignObject
15:05:50 <krit> krit: ok, but fO is not part of SVG integration and should be discussed with SVG2
15:05:57 <krit> Rossen_: just mentioning it
15:08:39 <krit> Rossen_: do we need to define the CSS cascade when it comes to integration?
15:08:58 <ed> FO is overflow:visible per default according to the current svg2 spec text
15:09:09 <Rossen_> http://codepen.io/anon/pen/CfGqy
15:09:44 <krit> krit: we do have different behavior with inner svg and other referencing modes
15:10:27 <krit> Rossen_: in the example I specified background color to the foreignObject and expected to get it applied.
15:12:28 <krit> krit: it should not apply to SVG elements at this problem
15:12:57 <krit> jwatt: I think it should
15:13:04 <krit> Rossen_: should be specified explicitly
15:13:37 <krit> Cyril: IMO a fO element should establish a viewport
15:14:31 <ChrisL> Its the combination of what is outside (FO) and what is inside (HTML or something using CSS) that establishes the containing block
15:15:25 <krit> Cyril: I though fO should inherit into the content of fO.
15:15:30 <krit> all: yes, that is correct
15:15:58 <krit> jwatt: I was saying that nothing stops us from defining background-color on fO element. It is currently not specified
15:16:00 <krit> krit: agree
15:16:26 <krit> heycam: what happens if you have multiple foreign namespace elements?
15:16:51 <krit> Rossen_: maybe it should be added to integration spec that you can not do that
15:16:57 <krit> Rossen_: but we need to be careful
15:17:09 <krit> Rossen_: because nesting may should work again
15:17:31 <krit> ChrisL: I think we should not define what happens with multiple childs
15:17:42 <ChrisL> and tell people not to do it
15:18:35 <krit> Rossen_: If I spec flex box on fO, I expect the content of fO to follow it
15:19:46 <krit> Rossen_: fO is just the equivalent of the viewport box
15:19:48 <ChrisL> fair enough
15:20:25 <krit> krit: does it imply that viewport units are bounds to fO boundaries?
15:20:29 <krit> Rossen_: yes
15:22:14 <krit> Rossen_: it is contextual, so fO should be part of integration spec
15:22:19 <krit> Cyril: I think so too
15:22:22 <krit> krit: do not agree
15:22:27 <krit> jwatt: don’t agree either
15:22:43 <krit> jwatt: I would also say it is not context dependent
15:23:03 <krit> Rossen_: for me it is just a viewport with scrollbars and stuff in it
15:23:56 <krit> Rossen_: would you change the FF implementation to add background-color and scrollbars to fO?
15:23:59 <krit> jwatt: yes
15:24:27 <krit> Rossen_: ok, so then I agree it is not contextual
15:25:26 <krit> Rossen_: are there any OM restrictions for the integrated content?
15:25:30 <krit> heycam: what do you mean?
15:25:48 <krit> Rossen_: scroll offset offset counts and all these regular HTML queries
15:26:11 <krit> heycam: the CSS OM view spec makes offsetTop work on plain SVG element
15:26:36 <krit> Rossen_: the reason I am asking: we define fO to be a viewport, then all queries would end there
15:27:29 <krit> Rossen_: if vh and vw are reset to the new viewport, the queries should as well
15:27:35 <krit> heycam: not sure if I fully agree
15:27:45 <krit> heycam: up to a cetain degree I do
15:28:10 <Rossen_> http://codepen.io/anon/pen/CfGqy
15:30:01 <krit> Rossen_: I updated the test
15:30:16 <krit> krit: as I expected, the viewport units use the real CSS viewports
15:30:26 <krit> Rossen_: FF does the same
15:31:43 <krit> krit: I think that fO is part of the document and does not simply embed a new document like iFrame
15:31:49 <krit> heycam: I agree with Dirk
15:33:29 <krit> heycam: why would it be different from getting from HTML to inline SVG to SVG to HTML
15:35:09 <krit> heycam: so the initial containing block is the size of the viewport. I would think it is more like a positioning containing block
15:35:14 <krit> Rossen_: it is different
15:35:20 <krit> Rossen_: we do not establish that
15:36:28 <krit> Rossen_: and don’t want to. Otherwise you print the content of the fO on every page if you print it as we do with other pos cont blocks
15:36:37 <krit> krit: we could come up with a new box
15:36:48 <krit> Rossen_: good luck with bringing that up to CSS WG
15:38:58 <krit> heycam: the initial containing block, the rendering of the box regardless of the box inside ()always renders HTML background border)
15:40:42 <heycam> ScribeNick: heycam
15:41:10 <heycam> heycam: so if you have <foreignObject style="background:red"><otherlanguage/></foreignObject> does the red background still paint?
15:41:20 <heycam> jwatt: yes I think it should
15:41:32 <heycam> ... partly for consistency, but also because an author has specified these things, so presumably they want them
15:41:50 <heycam> Rossen_: so this also needs to create a "CSSOM root"
15:43:23 <heycam> ... so for example offsetTop calculations stop at the foreignObject
15:45:54 <heycam> RESOLUTION: foreignObject will paint its box (including background, borders, etc.) and be a "CSS OM" root for offsetTop etc.
15:46:02 <heycam> ACTION: Cameron to make foreignObject paint its box and be a CSS OMroot
15:46:02 <trackbot> Created ACTION-3654 - Make foreignobject paint its box and be a css omroot [on Cameron McCormack - due 2014-09-01].
15:46:51 <heycam> heycam: for the "using Fetch" issue, Dirk says he will work on the in the main SVG spec
15:47:11 <heycam> heycam: next issue, should animations run in the resource document?
15:47:12 <heycam> Rossen_: yes
15:47:24 <heycam> s/yes/yes it's an issue/
15:49:35 <heycam> heycam: should the timelines between all resource document references to the same document be synchronised?
15:49:48 <heycam> ... maybe that lets you tell whether the resource document has already been referenced
15:50:04 <heycam> birtles: for fonts I think you want this to be synchronised
15:50:23 <heycam> Rossen_: there are many open questions about when the timeline actually begins
15:51:49 <heycam> krit: if a resource document has a <pattern> with an SVG animation in it; should the animation run on the pattern?
15:52:07 <heycam> jwatt: these resource documents might be embedded in documents from different domains
15:54:10 <Cyril_> Cyril_ has joined #svg
15:54:28 <heycam> Cyril: what about resource documents referencing other resource documents?
15:54:33 <heycam> heycam: that's disallowed, at least in firefox
15:54:37 <heycam> ... you can only go one level
15:54:54 <heycam> birtles: at least these resource documents shouldn't be synchronised with the referencing document
15:54:57 <heycam> ... use might be different
15:55:02 <heycam> ... since that clones the subtree
15:59:35 <heycam> krit: Rossen do you want animations running at all in resource documents?
15:59:43 <heycam> Rossen_: I think it might be hard to argue for those use cases
15:59:56 <heycam> s/for/against/
16:01:33 <heycam> ChrisL: I think there are only two possibilities here; all references to a given resource document uses the one timeline
16:01:40 <heycam> ... or they are all different
16:02:07 <heycam> jwatt: you really don't want to be using all that memory
16:02:11 <heycam> ... you could make it opt in
16:02:29 <heycam> Rossen_: I don't believe it will be that hard to enumerate your resources and find out if you have a matching one that's already existing, and just reuse that
16:02:41 <heycam> ... then you'll be getting into a timeline that's already in motion
16:02:47 <heycam> ... I agree I don't want to waste resources though
16:02:54 <heycam> birtles: you can probably use <use> as a way to opt in
16:03:10 <heycam> ... the behaviour there might end up being different, if it's doing something like a clone of the DOM tree you would effectively be restarting animations
16:03:17 <heycam> ... so <use> might be the mechanism for that
16:03:28 <heycam> jwatt: I certainly think the default should be a single instance of the resource document
16:03:42 <heycam> ... then we can look at what the opt in mechanism for different instances should be later
16:05:56 <heycam> krit: external resources are not supported for the most part in Blink/WebKit
16:06:46 <heycam> Rossen_: IE will implement them
16:06:51 <heycam> ... animations not running would be much simpler
16:06:58 <heycam> ... can we make the case for not running them?
16:14:23 <heycam> ACTION: Cameron to look into whether and how animations should run in resource documents.
16:14:23 <trackbot> Created ACTION-3655 - Look into whether and how animations should run in resource documents. [on Cameron McCormack - due 2014-09-01].
16:16:12 <heycam> http://www.w3.org/TR/SVGTiny12/linking.html#externalReferences
16:17:12 <heycam> krit: I don't think HTML specifies a timeline for gifs
16:17:20 <heycam> ... it allows the implementation to optimise if it is able
16:17:45 <heycam> Rossen_: but using the same timeline is how it works
16:18:02 <heycam> nikos: would usage patterns be different though? where a <pattern> might be used multiple times in different places?
16:19:35 <heycam> ACTION: Cameron to reword the smiley example text in SVG Integration
16:19:35 <trackbot> Created ACTION-3656 - Reword the smiley example text in svg integration [on Cameron McCormack - due 2014-09-01].
16:25:11 <heycam> RRSAgent, make logs public
16:25:14 <heycam> RRSAgent, make minutes
16:25:14 <RRSAgent> I have made the request to generate http://www.w3.org/2014/08/25-svg-minutes.html heycam
16:25:55 <birtles> http://www.whatwg.org/specs/web-apps/current-work/#images-2
16:26:10 <birtles> "All animated images with the same absolute URL and the same image data are expected to be rendered synchronised to the same timeline as a group, with the timeline starting at the time of the least recent addition to the group."
16:26:26 <birtles> "In other words, when a second image with the same absolute URL and animated image data is inserted into a document, it jumps to the point in the animation cycle that is currently being displayed by the first image."
16:36:35 <heycam> Present: Cameron, Brian, Cyril, Konno, Rossen, Rik, Dirk, Jonathan, Nikos, Doug, Chris, Tav, Jun, Jet, Erik
16:36:39 <heycam> RRSAgent, make minutes
16:36:39 <RRSAgent> I have made the request to generate http://www.w3.org/2014/08/25-svg-minutes.html heycam
17:33:53 <jun> jun has joined #svg
18:21:44 <Cyril_> Cyril_ has joined #svg
18:28:03 <thorton> thorton has joined #svg
18:28:44 <jun> jun has joined #svg
20:23:17 <ChrisL> ChrisL has joined #svg
21:05:39 <astearns_> astearns_ has joined #svg
21:35:00 <nikos> nikos has joined #svg
21:35:00 <birtles_> birtles_ has joined #svg
21:35:06 <pdr__> pdr__ has joined #svg
21:40:10 <TabAtkins_> TabAtkins_ has joined #svg
21:54:45 <jun> jun has joined #svg
22:10:02 <thorton> thorton has joined #svg
22:27:42 <Tav> Tav has joined #svg
22:53:14 <jwatt> jwatt has joined #svg
22:55:06 <stakagi_> stakagi_ has joined #svg
23:19:00 <stakagi> stakagi has joined #svg
23:47:58 <stakagi_> stakagi_ has joined #svg
23:59:21 <stakagi> stakagi has joined #svg